From nobody Mon Jan 2 09:04:37 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C071296CA for ; Mon, 2 Jan 2017 09:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_-BlTwsLOXl for ; Mon, 2 Jan 2017 09:04:34 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2AA1296C8 for ; Mon, 2 Jan 2017 09:04:34 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id v2so129759609uac.2 for ; Mon, 02 Jan 2017 09:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=besKoVstQW4LMZlTXzlso0UkqwyauS6eyee4/cewP1E=; b=gNpa6uSruumze5VR4KB4lDD/bZy/2oRcBIvo1/gQ5mhmUHi0kY25b9gYwqxcGo+Fwq On8eFDHUzGSLAky/FNcCvgXLyDzeKZJ6jAv5u0Okx4cROhTQNPGBuXSdfiIfX8I53+II 549rvqZpkV3MP5SxOAuRd0fb517lsfFyl+KHZCLceibobmeuoaw2R1YBLCf3vWXhZl0n tc48XfEStddF+ePRiVQhQYdo+vPisfT+gUWA8pAeKsKgaqfewgEemmBKg+OTmsNe7RYi ol/L5gwMcnsLSM2V1RhNBHhrKD3HxcBW0ZqIxzTwmGlU5uuXBGYTfsbBqhbjPaZYEy+V s+xA== 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=besKoVstQW4LMZlTXzlso0UkqwyauS6eyee4/cewP1E=; b=kTphkGqj8VZdslrRrE1pWOmnQJbSewofIpsOPz7rDLlBpPB6u6XozRQlCpjPinFpsO AySSqob6T0lGoHoZg/c8cxRyKqXvGda80zRBLwE2OxZu5X770LRmaQTIshXKCtwrbMQx lSzxghAB2mi1lj0RAEJB2fyoVO51dCZIxrZKQyC0YFoKnvTgKvOzU2ZiWV5q0qGknECf 7K1jBjeKFk2nImKON47OPLNJIb81bH2+IhIziDVzj/NHoCgyIGuJzvt7Bbf0ceDsxLsc pT3nDbToee29H2MfgXvNSCy5ziADJmvE+oYSu3fdh0VpKs1rqaGZeNQfFxBaEATSs0DU JRIQ== X-Gm-Message-State: AIkVDXLDxqMqhBtO2Tqlf1eyqcdpbtUgy7TekVsVuDOxvnrXO4b1SC1dMWAfYL5SH88NsPrfbNIWhgul6APCAQ== X-Received: by 10.176.84.156 with SMTP id p28mr35254409uaa.76.1483376673593; Mon, 02 Jan 2017 09:04:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.150 with HTTP; Mon, 2 Jan 2017 09:04:33 -0800 (PST) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Mon, 2 Jan 2017 09:04:33 -0800 Message-ID: To: Kurt Andersen Content-Type: multipart/alternative; boundary=94eb2c1b0c3eb29f5405451f8ba5 Archived-At: Cc: "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Prodding for reviews... and planning NOT to have a meeting in Chicago X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 17:04:36 -0000 --94eb2c1b0c3eb29f5405451f8ba5 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 30, 2016 at 7:49 AM, Kurt Andersen wrote: > 1) Murray had promised some ideas for restructuring the draft to make it > more understandable, but I haven't received them yet. > > I've been making notes about this as I complete the first releasable version of OpenARC. I think it's there now, but really needs some time spent on documentation and then proper testing against a common accepted corpus (see Steve's message) which I can help to construct. The availability of such a thing obviates the need for coordinated testing, which seems to have been hard to arrange lately, although I'd like it if we could get one together perhaps before/during/after the next M3AWG meeting in SF because the DKIM one was so useful. I concur, though, no need to meet in Chicago, at least formally. I'll be there though if anyone wants to work on something. -MSK --94eb2c1b0c3eb29f5405451f8ba5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 30, 2016 at 7:49 AM, Kurt Andersen <kurta@dr= kurt.com> wrote:
1) Murray h= ad promised some ideas for restructuring the draft to make it more understa= ndable, but I haven't received them yet.


I've been making notes about this as I com= plete the first releasable version of OpenARC.=C2=A0 I think it's there= now, but really needs some time spent on documentation and then proper tes= ting against a common accepted corpus (see Steve's message) which I can= help to construct.=C2=A0 The availability of such a thing obviates the nee= d for coordinated testing, which seems to have been hard to arrange lately,= although I'd like it if we could get one together perhaps before/durin= g/after the next M3AWG meeting in SF because the DKIM one was so useful.
I concur, though, no need to meet in Chicago, at least form= ally.=C2=A0 I'll be there though if anyone wants to work on something.<= br>
-MSK
--94eb2c1b0c3eb29f5405451f8ba5-- From nobody Mon Jan 2 10:25:07 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7DD1293F9 for ; Mon, 2 Jan 2017 10:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELQqbqwhM5_c for ; Mon, 2 Jan 2017 10:25:05 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6B61200A0 for ; Mon, 2 Jan 2017 10:25:05 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id 3so304577743oih.1 for ; Mon, 02 Jan 2017 10:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2amixmz4kGwfE5/SX6gqXd9usoUqikzVgYtEOzY656M=; b=SyRbV+rHpHb8a4w2cM9xusGb8XnqKY6YirMtYmwJTm1FqjL92H3OEJf/dXL4JgrFit HIlUWTpF0GfNOtVTqNaVmHBZAvafVIVs52CqjmS9dz5famsNRluUJIloFqE3xQGtCIaI 6HfUsyy9i/2S5hbGjqgNjnxD81KIowHfSKhf8= 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=2amixmz4kGwfE5/SX6gqXd9usoUqikzVgYtEOzY656M=; b=PZ4/GS+1p/73H3AicF3doGB5MMApIYCUGcRud7r+0mZ/9AItMrERp404ltaO7rzZ5P 4DfYwOeUwLMtitHRtpJOP0ebNqCTjrEjDrEE49XHmGtIR9gBnmlwClakTwWjXSojgy5h yQmzxMpDLctCrm7FiX+HJD34Idrae0kzViptdU1VhX7xTZQfKgydQTzFH4jIzt9hw8u2 lrR83uFmGiCWD1zadSPP7IEEsDddygtGTVAPKIPLhFx2gjiFsdzphM3P6YFj5Fc2JIWe 8/1XA3TNOHNqZSUakTvDNTJ+BM0PY8VszacGiT+W+VvJBFH4hI5pkjVjqsoBMqz+6llH 3vZg== X-Gm-Message-State: AIkVDXIjMMRXZlFVCboroTjn1m+hyjU0HUIKYNQiIRhgOAzsfZjXJl4wWRP3N/ZTG7S5yxHWru5OX94X2aU8FA== X-Received: by 10.157.57.183 with SMTP id y52mr26599911otb.6.1483381504533; Mon, 02 Jan 2017 10:25:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.74.136 with HTTP; Mon, 2 Jan 2017 10:25:04 -0800 (PST) In-Reply-To: References: From: Kurt Andersen Date: Mon, 2 Jan 2017 10:25:04 -0800 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a1141a402a5007a054520ab23 Archived-At: Cc: "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Prodding for reviews... and planning NOT to have a meeting in Chicago X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 18:25:06 -0000 --001a1141a402a5007a054520ab23 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 2, 2017 at 9:04 AM, Murray S. Kucherawy wrote: > On Fri, Dec 30, 2016 at 7:49 AM, Kurt Andersen wrote: > >> 1) Murray had promised some ideas for restructuring the draft to make it >> more understandable, but I haven't received them yet. >> >> > I've been making notes about this as I complete the first releasable > version of OpenARC. I think it's there now, but really needs some time > spent on documentation and then proper testing against a common accepted > corpus (see Steve's message) which I can help to construct. The > availability of such a thing obviates the need for coordinated testing, > which seems to have been hard to arrange lately, although I'd like it if we > could get one together perhaps before/during/after the next M3AWG meeting > in SF because the DKIM one was so useful. > I'm happy to host an in-person interop on Friday following M3AAWG (Feb 24) if there is interest (the LinkedIn office is just a few blocks from the conference hotel). I think it would be helpful to have a pre-check run some time in January so that we could potentially have some of the vendors who are interested in leveraging the OpenARC code as a plugin within their product might be able to have a few weeks to possibly hack together an alpha instance for the "big" interop. I'd be happy to review the docs for OpenARC and Steve probably has the most experience working on standing it up inside of VMs so he may be able to contribute suggestions too. Murray, would you be available to join us in SF on Feb 24? --Kurt --001a1141a402a5007a054520ab23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 2, 2017 at 9:04 AM, Murray S. Kucherawy <superuser@gmail.com= > wrote:
On Fri, Dec 30, 2016 at 7:49 AM, Kurt Andersen <kurta@drkurt.co= m> wrote:
1) Mu= rray had promised some ideas for restructuring the draft to make it more un= derstandable, but I haven't received them yet.


I've been making notes about = this as I complete the first releasable version of OpenARC.=C2=A0 I think i= t's there now, but really needs some time spent on documentation and th= en proper testing against a common accepted corpus (see Steve's message= ) which I can help to construct.=C2=A0 The availability of such a thing obv= iates the need for coordinated testing, which seems to have been hard to ar= range lately, although I'd like it if we could get one together perhaps= before/during/after the next M3AWG meeting in SF because the DKIM one was = so useful.

I'm = happy to host an in-person interop on Friday following M3AAWG (Feb 24) if t= here is interest (the LinkedIn office is just a few blocks from the confere= nce hotel). I think it would be helpful to have a pre-check run some time i= n January so that we could potentially have some of the vendors who are int= erested in leveraging the OpenARC code as a plugin within their product mig= ht be able to have a few weeks to possibly hack together an alpha instance = for the "big" interop.

I'd be happy = to review the docs for OpenARC and Steve probably has the most experience w= orking on standing it up inside of VMs so he may be able to contribute sugg= estions too.

Murray, would you be available to joi= n us in SF on Feb 24?

--Kurt

=
--001a1141a402a5007a054520ab23-- From nobody Mon Jan 2 23:26:38 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BC7129405 for ; Mon, 2 Jan 2017 23:26:37 -0800 (PST) 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, MIME_QP_LONG_LINE=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 (1024-bit key) header.d=fastmail.fm header.b=JnyHH5OE; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=GzdMXz8Z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AyieCZflUdc for ; Mon, 2 Jan 2017 23:26:36 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000F5128E19 for ; Mon, 2 Jan 2017 23:26:35 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6185720816; Tue, 3 Jan 2017 02:26:35 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Tue, 03 Jan 2017 02:26:35 -0500 DKIM-Signature: v=1; a=rsa-sha1; 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:x-sasl-enc; s=mesmtp; bh=ovB0SOXlMpVJQ1z W2RObtO36Z3o=; b=JnyHH5OEPNbBJwVqHQfH8lFMCgh6xSsTSsbGwYfHdT5s7EU Rsr7vG6MOIR/AePrVAVvUtWRmV4Qo0a9BNsjuU6lTLpbGKjo0qk2Cxoln0yYyLsV WF31hOL615XtJ1w5VwjrvMF6qjhuyPTVXy1qQvatDl6/Tqs5lIEQLa+n2pgY= DKIM-Signature: v=1; a=rsa-sha1; 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:x-sasl-enc; s= smtpout; bh=ovB0SOXlMpVJQ1zW2RObtO36Z3o=; b=GzdMXz8Z4QhMdAtGffKR 2I9xkd8P14avMNSlimijxy8ZdYBe1Qq1jjgPDZ0WoOnrA3RkIjUccCyI4zetxXoF VJMrCmHltF2bLcu2RCE/EWR6R1DFqBPJvSTmhtv3jJjOywEaqZdJz5WKYn6YYUO2 +Px1PRgi12CQ+CPZ+ICNwXg= X-ME-Sender: X-Sasl-enc: EDn0wGXl3IMs/OfBIgwyVoW88mgd/6ZyM25+fBHdQMSv 1483428394 Received: from [192.168.121.84] (unknown [109.70.248.14]) by mail.messagingengine.com (Postfix) with ESMTPA id C1E162468C; Tue, 3 Jan 2017 02:26:34 -0500 (EST) Content-Type: multipart/alternative; boundary=Apple-Mail-21752946-3B09-4F29-8F0D-0C2C03D04C36 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Tue, 3 Jan 2017 10:35:23 +0300 Content-Transfer-Encoding: 7bit Message-Id: <4C5B9B54-9D1A-4371-9A51-E542CF11317E@fastmail.fm> References: To: "Murray S. Kucherawy" Archived-At: Cc: "dmarc@ietf.org" , Kurt Andersen , Barry Leiba Subject: Re: [dmarc-ietf] Prodding for reviews... and planning NOT to have a meeting in Chicago X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 07:26:38 -0000 --Apple-Mail-21752946-3B09-4F29-8F0D-0C2C03D04C36 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Is it worth having a Hackaton ARC interop testing in Chicago? > On 2 Jan 2017, at 20:04, Murray S. Kucherawy wrote: >=20 >> On Fri, Dec 30, 2016 at 7:49 AM, Kurt Andersen wrote: >> 1) Murray had promised some ideas for restructuring the draft to make it m= ore understandable, but I haven't received them yet. >=20 > I've been making notes about this as I complete the first releasable versi= on of OpenARC. I think it's there now, but really needs some time spent on d= ocumentation and then proper testing against a common accepted corpus (see S= teve's message) which I can help to construct. The availability of such a t= hing obviates the need for coordinated testing, which seems to have been har= d to arrange lately, although I'd like it if we could get one together perha= ps before/during/after the next M3AWG meeting in SF because the DKIM one was= so useful. >=20 > I concur, though, no need to meet in Chicago, at least formally. I'll be t= here though if anyone wants to work on something. >=20 > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-21752946-3B09-4F29-8F0D-0C2C03D04C36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Is it worth having a Hackaton ARC inte= rop testing in Chicago?

On 2 Jan 2017, at 20:04, Murray S.= Kucherawy <superuser@gmail.com> wrote:

On= Fri, Dec 30, 2016 at 7:49 AM, Kurt Andersen <kurta@drkurt.com> w= rote:
1) Murray had promised some ideas for re= structuring the draft to make it more understandable, but I haven't received= them yet.


I've b= een making notes about this as I complete the first releasable version of Op= enARC.  I think it's there now, but really needs some time spent on doc= umentation and then proper testing against a common accepted corpus (see Ste= ve's message) which I can help to construct.  The availability of such a= thing obviates the need for coordinated testing, which seems to have been h= ard to arrange lately, although I'd like it if we could get one together per= haps before/during/after the next M3AWG meeting in SF because the DKIM one w= as so useful.

I concur, though, no need to meet in Chicago= , at least formally.  I'll be there though if anyone wants to work on s= omething.

-MSK
____________________= ___________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mai= lman/listinfo/dmarc
= --Apple-Mail-21752946-3B09-4F29-8F0D-0C2C03D04C36-- From nobody Tue Jan 3 09:09:06 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0A61296B9 for ; Tue, 3 Jan 2017 09:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok276BgWND34 for ; Tue, 3 Jan 2017 09:09:04 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56881296B6 for ; Tue, 3 Jan 2017 09:09:04 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id 3so332022842oih.1 for ; Tue, 03 Jan 2017 09:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ngiyIYWKClePZRzLOmzZn/S51K59hTKeykM51MM+U/Q=; b=GqEnzyACbkuWrLUJ1QmIJuj2uKLGcuidLJrc9c13oRjZUQjp94TSosD6Tktju2RboB j/7qzj0MCq6px5fbsx/e+uZbfmWYry6TEw5cR/tj5NyG2sGJtQBf8PLUKi2SRLL4KxH2 tTm9lqUQkGY+vdRPz6SdYFpxVU1bY7iWaNu7U= 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=ngiyIYWKClePZRzLOmzZn/S51K59hTKeykM51MM+U/Q=; b=RH3TEVqwsy/NTBWMQuZxBjqemfVgLIhKe+hhfCwjnc+C8qOX6hOreoxSK+RpB+4KpQ pYS6zt3+TsFDrh/KTCI3BlySpUu4QussescklbEaXc2dTn8t05WrzyCFaoGlPZNZ8vy8 yKj8vuvUmrSo2NcWT9KnskkEHQ2HSWBxVPRWqpQrd04FJ2gvGybTrjtO/AiC6cpiYhh7 gcs//nTTJZh2vr2PmGAN1hFwHLxewSIcfn7tCrHbfhb28/AP4c1ChtnWI2TTzJENTy4g +3Jw5YXiO70Wl5idWXKkgJns36OotlCDNlE48RBKknOcsZI/CfLzljMfQta/3FMxAsJw LlYA== X-Gm-Message-State: AIkVDXIev04JWR3voyTQOYl9589aIsXOCT9SVXP+MPZRs8N/WfWghuoAqV/bLiaM6zeaRWmKTvqW3dB6NlCgzg== X-Received: by 10.202.181.70 with SMTP id e67mr26422503oif.3.1483463343967; Tue, 03 Jan 2017 09:09:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.74.136 with HTTP; Tue, 3 Jan 2017 09:09:03 -0800 (PST) In-Reply-To: <4C5B9B54-9D1A-4371-9A51-E542CF11317E@fastmail.fm> References: <4C5B9B54-9D1A-4371-9A51-E542CF11317E@fastmail.fm> From: Kurt Andersen Date: Tue, 3 Jan 2017 09:09:03 -0800 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a113cd3c6a7a740054533b975 Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , Barry Leiba Subject: Re: [dmarc-ietf] Prodding for reviews... and planning NOT to have a meeting in Chicago X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 17:09:06 -0000 --001a113cd3c6a7a740054533b975 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 2, 2017 at 11:35 PM, Alexey Melnikov wrote: > Is it worth having a Hackaton ARC interop testing in Chicago? > We could, but I'm not sure how many of the "usual suspects" will be attending Chicago (I know that I'll be on vacation in Ecuador at that time). An interop testing event on Feb 24 in San Francisco would be open to both on-site participants as well as remote folks. --Kurt --001a113cd3c6a7a740054533b975 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 2, 2017 at 11:35 PM, Alexey Melnikov <aamelnikov@fastmail.fm= > wrote:
=
Is it worth having a Hackaton ARC interop testing in Chicago?

We could, but I'm not sure how many= of the "usual suspects" will be attending Chicago (I know that I= 'll be on vacation in Ecuador at that time).

A= n interop testing event on Feb 24 in San Francisco would be open to both on= -site participants as well as remote folks.

--Kurt= =C2=A0

--001a113cd3c6a7a740054533b975-- From nobody Tue Jan 3 20:17:40 2017 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B175129416; Tue, 3 Jan 2017 20:17:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148350345739.27933.10556208067931781583.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 20:17:37 -0800 Archived-At: Cc: dmarc@ietf.org, dmarc-chairs@ietf.org, barryleiba@gmail.com, aamelnikov@fastmail.fm Subject: [dmarc-ietf] dmarc - Not having a session at IETF 98 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 04:17:37 -0000 Barry Leiba, a chair of the dmarc working group, indicated that the dmarc working group does not plan to hold a session at IETF 98. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Wed Jan 11 11:14:12 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B0112949F for ; Wed, 11 Jan 2017 11:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 uu24heSiqXbT for ; Wed, 11 Jan 2017 11:14:06 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95BAD129F4E for ; Wed, 11 Jan 2017 11:14:03 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id w204so100869653oiw.0 for ; Wed, 11 Jan 2017 11:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=0K2qD7Opdm5Yi+SiRcpUFv5ut4P2J8Era7gOjYGj6Kw=; b=cDN6S2RKg8JNI/DbznpcA2hM6IxgmY9/ttaeTfqj0/aZO1nMvKfv3FfuPNIAXBZCv/ /IXlTen/dR6tJ3Ybc/NnVfYLmuEavodr4dus5lRjvWztplvlTQyJSbe6+p7xUPXGLtvo 1ggEGCKrrtXkEmbFD6ObYXmfgZLibynyUnpUv9RRbb+v8M5cwuKLKL1kr8E0JXQXJCeb c1zaJ2dy6F8sHzRJmXftgFVuZE3BQixenu87lmUL76lRVC5i0n8urMFlwexuxxyqtLBd NCM8F4yWsDtmjT9nVTjSO51tDEM8OXiayH9a+IRdOnIATYe0IRSLKFEBwnQMcOYcVJUR IUSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0K2qD7Opdm5Yi+SiRcpUFv5ut4P2J8Era7gOjYGj6Kw=; b=h8nrj6OypS6Sl5668QFSyCx2JN6XD7uPqunnuD9RxnTtKgZnlkgCr5MfhGgDUY9Wsr 71zBd+72Q3VLsNtA6NtZTO6h/I35R/THvdfxyJDC4+BppMgLdnFPW6vbEi4Qg/ylsZVd AtYYEu6/eQICyHCpWNOwYlDSUgmUfWN9LbegJgNzksaMnh8Y+JcDGELOcif6H1rp59fY B9izDeyi/IDqnBBWFnClXKGXULEqQf0vLy8qHcseS405yD/LFKlrLa+O7s0bxj/RXOyb jyQWHVq5tkfl/UxD6Tr3jteJQAWxkDgRZXzmKeYbzicUkgByxgrzYtTtZ6Craz4p95Oi P1hg== X-Gm-Message-State: AIkVDXICHj5m7GSO7XKhOlgjbYFOO3JN8pN/9VIY4zQzgu6K+MF7kaJ8PG0It99BxdS3QtyCqLnzaysac6YWvg== X-Received: by 10.202.235.215 with SMTP id j206mr5109270oih.74.1484162042565; Wed, 11 Jan 2017 11:14:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.14.6 with HTTP; Wed, 11 Jan 2017 11:14:02 -0800 (PST) From: Gene Shuman Date: Wed, 11 Jan 2017 11:14:02 -0800 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=001a113ce9005625bb0545d667fe Archived-At: Subject: [dmarc-ietf] ARC draft issues/clarifications X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:14:10 -0000 --001a113ce9005625bb0545d667fe Content-Type: text/plain; charset=UTF-8 Hi All, I'm currently working on a test suite for ARC, and have run into a few areas in the draft that could use some clarification, mostly with regards to section 5.2.1, which seems like it needs a non-trivial update. I've run into the following issues: - Can messages with violations in their ARC sets(duplicate/malformed i= values, etc), still be considered valid, assuming they pass the chain validation algorithm under the given ordering? - Similarly, can messages with completely duplicate ARC sets still be considered valid? One might expect that these gross violations of the protocol would cause chain validation to fail regardless, however the language 5.2.1. Handling Violations in the ARC Sets > > ....... > > numbers), such header field set(s) MUST be ordered as follows when > > analyzing for *validity* or subsequent signing: > > > seems to imply otherwise. - when implementing the ordering in [5.2.1] for signing, do we include ARC header fields with invalid or non-existent values of i=? missing, i=;, i=-1;, i=string; are all cases that need to be addressed. Easiest would be just to not include them. - Section [5.2.1] says to remove fully duplicate sets, but doesn't mention fully duplicate instances, that dont form a complete set. Is there any reason we're not removing those as well? That seems easier. - Say we're computing AS(2), and are provided with AS(1), AS(1), AMS(1), AAR(1), where we have duplicated i=1 Arc-Seals. It's not entirely clear where the duplicate AS(1) is ordered in the signing process. The relative ordering of the two AS(1)'s is specified in the draft, but is it the case that within an arc set, all AS's are signed before all AMS's? I would assume that the ordering is as I've specified above, but that ordering vs say AS(1), AMS(1), AAR(1), AS(1) isn't entirely clarified. Aside from this family of issues, I've also come across a few other issues that I could use a a bit of clarification on for my work on the test suite. - Arc-Seals are explicitly forbidden for inclusion in Arc-Message-Signatures, but there is no mention of possibly including previous Arc-Message-Signatures in newer signatures, despite the fact it's fairly pointless. Is this intentional? - For both seal & message signatures computation, the spec explicitly states that relaxed header canonicalization is to be used, but for makes no comment about body canonicalization for AMS. Is simple a valid option? It may be worth explicitly noting this. Any thoughts/feedback/clarifications with respect to these issues would be greatly appreciated. Regards, =Gene --001a113ce9005625bb0545d667fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I'm currently working on a = test suite for ARC, and have run into a few areas in the draft that could u= se some clarification, mostly with regards to section 5.2.1, which seems li= ke it needs a non-trivial update.=C2=A0 I've run into the following iss= ues:

- Can message= s with violations in their ARC sets(duplicate/malformed i=3D values, etc), = still be considered valid, assuming they pass the chain validation algorith= m under the given ordering? =C2=A0
- S= imilarly, can messages with completely duplicate ARC sets still be consider= ed valid?

One might expect that these gross violations of the p= rotocol would cause chain validation to fail regardless, however the langua= ge

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">5.2.1.=C2=A0 Handling Viol= ations in the ARC Sets=C2=A0
.......
numbers), such header field set(s) MUST be ordered as follo= ws when
analy= zing for=C2=A0validity=C2=A0or subsequent signing:
=
seems to imply otherwise.

<= div>
- when implementing the ordering in [5.= 2.1] for signing, do we include ARC header fields with invalid or non-exist= ent values of i=3D? =C2=A0missing, i=3D;, i=3D-1;, i=3Dstring; are all case= s that need to be addressed.=C2=A0 Easiest would be just to not include the= m. =C2=A0
- Section [5.2.1] says to re= move fully duplicate sets, but doesn't mention fully duplicate instance= s, that dont form a complete set.=C2=A0 Is there any reason we're not r= emoving those as well?=C2=A0 That seems easier. =C2=A0
- Say we're computing AS(2),=C2=A0and are provided with AS(1), AS(1), AMS(1), AAR(1), where we h= ave duplicated i=3D1 Arc-Seals.=C2=A0 It's not entirely clear where the= duplicate AS(1) is ordered in the signing process.=C2=A0 The relative orde= ring of the two AS(1)'s is specified in the draft, but is it the case t= hat within an arc set, all=C2=A0AS's are signed before all=C2=A0AMS'= ;s?=C2=A0 I would assume that the ordering is as I've specified above, = but that ordering vs say=C2=A0AS(1)= , AMS(1), AAR(1), AS(1) isn't entirely clarified.
=C2=A0
As= ide from this family of issues, I've also come across a few other issue= s that I could use a a bit of clarification on for my work on the test suit= e. =C2=A0

- =C2=A0Arc-Seals are explicitly forbidden for inclusion in A= rc-Message-Signatures, but there is no mention of possibly including previo= us=C2=A0Arc-Message-Signatures in newer si= gnatures, despite the fact it's fairly pointless.=C2=A0 Is this intenti= onal?
- For both seal & mes= sage signatures computation, the spec explicitly states that relaxed header= canonicalization is to be used, but for makes no comment about body canoni= calization for AMS.=C2=A0 Is simple a valid option?=C2=A0 It may be worth e= xplicitly noting this. =C2=A0

Any thoughts/feedback/clarifications with= respect to these issues would be greatly appreciated.=C2=A0

Regards,
=3DGene
=C2=A0
--001a113ce9005625bb0545d667fe-- From nobody Thu Jan 12 13:34:29 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E465E129443 for ; Thu, 12 Jan 2017 13:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 d5rh25Ca8sua for ; Thu, 12 Jan 2017 13:34:26 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9651289C4 for ; Thu, 12 Jan 2017 13:34:26 -0800 (PST) Received: (qmail 99752 invoked from network); 12 Jan 2017 21:34:25 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 12 Jan 2017 21:34:25 -0000 Date: 12 Jan 2017 21:34:03 -0000 Message-ID: <20170112213403.2324.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: gene@valimail.com Subject: Re: [dmarc-ietf] ARC draft issues/clarifications X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:34:28 -0000 In article you write: >I'm currently working on a test suite for ARC, and have run into a few >areas in the draft that could use some clarification, mostly with regards >to section 5.2.1, which seems like it needs a non-trivial update. I've run >into the following issues: > >- Can messages with violations in their ARC sets(duplicate/malformed i= >values, etc), still be considered valid, assuming they pass the chain >validation algorithm under the given ordering? >- Similarly, can messages with completely duplicate ARC sets still be >considered valid? My advice is to fail them all, since that's the way to get the message back to MTA authors to fix buggy ARC code. Perhaps at some time in the future we will see consistent breakage due to legacy non-ARC code that we can recognize as broken but legit, and we can agree to do workarounds for them. But at this point, all the ARC code is new, all of it should work, and if it doesn't, the people who can fix it are still around to make the fixes. R's, John From nobody Thu Jan 12 13:52:58 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6EA129500 for ; Thu, 12 Jan 2017 13:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=teamaol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfSBJc-_JxRF for ; Thu, 12 Jan 2017 13:52:54 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49FDF129443 for ; Thu, 12 Jan 2017 13:52:52 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id 11so35483977qkl.3 for ; Thu, 12 Jan 2017 13:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamaol.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bqSzJCQLgWP0LMOEGMaO+YDRJVKASp0QJeU0U7JlEUs=; b=KEnSyW7ITjDbqeW3lDZiIJiNxiBCc5AxjJDoAIc7wTSl9hd3SCFsMyQm64thhk7RA9 Og/181S0Nj4+OR5bn6zZhKwnhVXrpxgN22xLpGZVg2Luo54uCBoqAjJVmeDP+Ap/h1Tx MiEIA3MWolqJfaRnC2Pp4fV4tqFjbv75/u2IXPTwZSBjaZ4QMl1Rj8t49QOh0t9i/nDO 6HEvakl8PvNIpNJQgczlsH73fmi8haTtWgVst0n8pES7AtCpKLKddWwkRWg11p4Hlzqp aHn0kAPDVPptrbogitBMORhv1N1Pjei7HONCj8yZcWdnfUQLGGinLWBbrlUcyou6BIXp aaLg== 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=bqSzJCQLgWP0LMOEGMaO+YDRJVKASp0QJeU0U7JlEUs=; b=caM77TA1EY9Y+eKxdOr1bCs696aR61471Hex8f2ovR9JlknNZKpSQtlxpqxrRk67iW c5dxRV8RnRowIw5dIoYvZ3xemAZ5FxiH7woS2x9txx/4/eMQDMNuaM4lKWFqHfB1DQND UTMHAk4vv1DBygHby4crbOpmlZlGGD63Guv87pUkDcMhPE788VJVdhrljaVqLZ5vO8ok BzmP9suyVj8hCR8BvYbAzSmMUMGzlZH6X47lAEN3fNe4Dy/yNyr1akvzQstGWO88ZZKg z5Jx19XSWHbNx7GH5i/ffsJxirhi3emqCmNijBXsNHBn76Pml/qcuRaycynaELzsThs9 YRdw== X-Gm-Message-State: AIkVDXJv2XuNYrEcXUbSttDCSjhI0h1gU8DMk8OdzPvWowInoXACCOAD0B6c806kR1/ubNn+HOOB+STx/7LKk9gK X-Received: by 10.55.67.68 with SMTP id q65mr16840607qka.65.1484257971188; Thu, 12 Jan 2017 13:52:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.42.45 with HTTP; Thu, 12 Jan 2017 13:52:50 -0800 (PST) In-Reply-To: <20170112213403.2324.qmail@ary.lan> References: <20170112213403.2324.qmail@ary.lan> From: Paul Rock Date: Thu, 12 Jan 2017 16:52:50 -0500 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a114aca6a20ddcf0545ecbdcc Archived-At: Cc: dmarc , gene@valimail.com Subject: Re: [dmarc-ietf] ARC draft issues/clarifications X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:52:57 -0000 --001a114aca6a20ddcf0545ecbdcc Content-Type: text/plain; charset=UTF-8 As an owner of some of that ARC code, I'm with John here - if I'm broke/malformed, fail the message and tell me so I can try to fix it. On Thu, Jan 12, 2017 at 4:34 PM, John Levine wrote: > In article gmail.com> you write: > >I'm currently working on a test suite for ARC, and have run into a few > >areas in the draft that could use some clarification, mostly with regards > >to section 5.2.1, which seems like it needs a non-trivial update. I've > run > >into the following issues: > > > >- Can messages with violations in their ARC sets(duplicate/malformed i= > >values, etc), still be considered valid, assuming they pass the chain > >validation algorithm under the given ordering? > >- Similarly, can messages with completely duplicate ARC sets still be > >considered valid? > > My advice is to fail them all, since that's the way to get the message > back to MTA authors to fix buggy ARC code. > > Perhaps at some time in the future we will see consistent breakage due to > legacy non-ARC code that we can recognize as broken but legit, and we can > agree to do workarounds for them. But at this point, all the ARC code is > new, all of it should work, and if it doesn't, the people who can fix it > are still around to make the fixes. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- PAUL ROCK Principal Software Engineer | AOL Mail P: 703-265-5734 | C: 703-980-8380 AIM: paulsrock 22070 Broderick Dr.| Dulles, VA | 20166-9305 --001a114aca6a20ddcf0545ecbdcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As an owner of some of that ARC code, I'm with John he= re - if I'm broke/malformed, fail the message and tell me so I can try = to fix it.=C2=A0

On Thu, Jan 12, 2017 at 4:34 PM, John Levine <johnl@taugh.com> wrote:
In article = <CANtLugMzj+cfSjmC9XHt0X3f5f_epjfCVw+5bEjYxLXpdo5Z_g= @mail.gmail.com> you write:
>I'm currently working on a test suite for ARC, and have run into a = few
>areas in the draft that could use some clarification, mostly with regar= ds
>to section 5.2.1, which seems like it needs a non-trivial update.=C2=A0= I've run
>into the following issues:
>
>- Can messages with violations in their ARC sets(duplicate/malformed i= =3D
>values, etc), still be considered valid, assuming they pass the chain >validation algorithm under the given ordering?
>- Similarly, can messages with completely duplicate ARC sets still be >considered valid?

My advice is to fail them all, since that's the way to get the m= essage
back to MTA authors to fix buggy ARC code.

Perhaps at some time in the future we will see consistent breakage due to legacy non-ARC code that we can recognize as broken but legit, and we can agree to do workarounds for them.=C2=A0 But at this point, all the ARC code= is
new, all of it should work, and if it doesn't, the people who can fix i= t
are still around to make the fixes.

R's,
John

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



--
PAUL ROCK
Principal Software Engineer | AOL Mail<= br>P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.|= Dulles, VA | 20166-9305
--001a114aca6a20ddcf0545ecbdcc-- From nobody Sat Jan 14 16:31:30 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C44C1294CE for ; Sat, 14 Jan 2017 16:31:29 -0800 (PST) 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 grG9oyOXB5qP for ; Sat, 14 Jan 2017 16:31:27 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11651294B7 for ; Sat, 14 Jan 2017 16:31:27 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id t8so54765212vke.3 for ; Sat, 14 Jan 2017 16:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dY/TeBxhHCvDZHpBR4z4BBU0oeMD8rvjoX9kOkL1uF8=; b=eRFZL56HbaoJuuFRx5+x+qOtyNBB01smHgtgANBF6Fr8zYYqWlwTdTJwrN7/g0r1dj oa6WHpqg/Oks3UrWiGAie7CPSJbQn5VmE+XPcZWdvXwV8oh+zkf7A739uoI/7eTIsTno jCGWO/p1m/Ux/ERkfvDZUFGoMjKFYTKf9Z5aIa1vj4PnPIq/TgMAQv2hMyAFllVRzZZa O6GNk/8f7YiNcsM0PSnP47Me7P7X172L+/vgEeGkE6pWbw8MAtnJs9JNAD7yECtrKjLO jRNpJGSRg0gGGqtYPiQPM1Y2QVBrjLwaysd3ADaaHT/sqj6EEOKZIwBZx87etf0VU+jZ FIqA== 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=dY/TeBxhHCvDZHpBR4z4BBU0oeMD8rvjoX9kOkL1uF8=; b=It4bWTKmUJRbgQFAxysEFGFT2T0GOSlgIrOHXUPtZbGTwEZL/TNu2y8nMsnGW2gJyu bOKkRkrZs2Y9ebfrKGSIhcKUqRrysnBG61ShVQkj479jj2HHe/ugnl+pdX9gmFShimbX 3qrUs3LPIkhHqECX/2bAwpuuEZ61RqmlRly8ZndQaSujMvAoy0qp4HsWgYnzZ0vEKgBH U2PWFMGmpY2r/TVSjTanEP/xj4C6G4HkxSnst2TKFxNZyUozrJVeBjDlrvxG2pyVTFf0 O9+p+auBHPt7DLNeWL86QueEZLUUj9MkSvx6BPB6i23xz5Yparp+qCIIvBN+nRsoztVd fVxQ== X-Gm-Message-State: AIkVDXKcGsYaKYzo1oTS3yHeuNhKOxYavHAXSXVyKnjyNtBrCeayIw3bZ4lZfNj94LzIO/Bk9XVsBM2zOytAAw== X-Received: by 10.31.5.6 with SMTP id 6mr13468665vkf.117.1484440286834; Sat, 14 Jan 2017 16:31:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.150 with HTTP; Sat, 14 Jan 2017 16:31:26 -0800 (PST) In-Reply-To: <20170112213403.2324.qmail@ary.lan> References: <20170112213403.2324.qmail@ary.lan> From: "Murray S. Kucherawy" Date: Sat, 14 Jan 2017 16:31:26 -0800 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a11441d52fcb5440546172ff9 Archived-At: Cc: "dmarc@ietf.org" , Gene Shuman Subject: Re: [dmarc-ietf] ARC draft issues/clarifications X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 00:31:29 -0000 --001a11441d52fcb5440546172ff9 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 1:34 PM, John Levine wrote: > In article gmail.com> you write: > >I'm currently working on a test suite for ARC, and have run into a few > >areas in the draft that could use some clarification, mostly with regards > >to section 5.2.1, which seems like it needs a non-trivial update. I've > run > >into the following issues: > > > >- Can messages with violations in their ARC sets(duplicate/malformed i= > >values, etc), still be considered valid, assuming they pass the chain > >validation algorithm under the given ordering? > >- Similarly, can messages with completely duplicate ARC sets still be > >considered valid? > > My advice is to fail them all, since that's the way to get the message > back to MTA authors to fix buggy ARC code. > [...] +1. -MSK --001a11441d52fcb5440546172ff9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 12, 2017 at 1:34 PM, John Levine <johnl@taugh.c= om> wrote:
In article <CANtLugMzj+cfSjmC9XHt0X3f5f_epjfCVw+5bEjYxLXpdo5Z_g@mail.gmail.com> you write:
>I'm currently working on a test suite for ARC, and have run into a = few
>areas in the draft that could use some clarification, mostly with regar= ds
>to section 5.2.1, which seems like it needs a non-trivial update.=C2=A0= I've run
>into the following issues:
>
>- Can messages with violations in their ARC sets(duplicate/malformed i= =3D
>values, etc), still be considered valid, assuming they pass the chain >validation algorithm under the given ordering?
>- Similarly, can messages with completely duplicate ARC sets still be >considered valid?

My advice is to fail them all, since that's the way to get the m= essage
back to MTA authors to fix buggy ARC code.
[...]

+1.

-MSK
=
--001a11441d52fcb5440546172ff9-- From nobody Mon Jan 16 03:21:40 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DB01299B2 for ; Mon, 16 Jan 2017 03:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kxjz6fuTY-d7 for ; Mon, 16 Jan 2017 03:21:37 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C7A1299A0 for ; Mon, 16 Jan 2017 03:21:37 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id j15so98520683oih.2 for ; Mon, 16 Jan 2017 03:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=64pMvF6moaL2bclf6nOizvMDVDPntkR4+9nzOgLoXNo=; b=YLV43/NO358RqPnen2/l/0ktluoe7cETKcU4x8onSnj2oVJmpCJDh6wxc2QAPMliXA zu1v7JvWdI1ySERFI1t22m4WgoBUqy17qhpaOQOPXBGgUEvJ1LLmOyCz17HGXbL7YLGE aFzVo6xMBI9bsj2S8lIOvq98rjCuNTE5IUEis= 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=64pMvF6moaL2bclf6nOizvMDVDPntkR4+9nzOgLoXNo=; b=oL27QF1BXxj5coIATHWwXS4BUkuPM2SJC0AF2fsHPw1PlPGGkGrqBoQr7PdBmnZMJm 62qEA7L3OFwSqQqjA284uIcvj3umxFWw62ZSW71a19/W4SSFD3UNLfMCidM1U7utn3aw Pg/Yl4qLHB6MgeYBGIF2nF2oCPo7cEGx8LcxcSm1133XFw1RgHR91+3aPP5e29bZv3R9 +ER/SgTLSmRsSBINDR4vTThRV4yvvVaTDOW7MbANHjGC7WT2XWBOAtTZBnAR2vn0SuTz X49Dt2URleCzqYIBU6Gh2HwscweNMIbBP+SQltRzZWPHJi6io6MeTY3dZtRl0W58iBVa HhLg== X-Gm-Message-State: AIkVDXIIWM5ulLETx5CdoTB4/Ih/TbVF8qUULaB0Nv1sLaqPtoB8xZRvHzss423mx0YnvD6mfZfCA8q4tIMErQ== X-Received: by 10.202.168.214 with SMTP id r205mr16532369oie.48.1484565696528; Mon, 16 Jan 2017 03:21:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.184.69 with HTTP; Mon, 16 Jan 2017 03:21:36 -0800 (PST) In-Reply-To: <20170112213053.2291.qmail@ary.lan> References: <20170112213053.2291.qmail@ary.lan> From: Kurt Andersen Date: Mon, 16 Jan 2017 16:51:36 +0530 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a113cda12fcdd260546346263 Archived-At: Subject: [dmarc-ietf] Fwd: [arc-discuss] a few questions about the spec X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 11:21:39 -0000 --001a113cda12fcdd260546346263 Content-Type: text/plain; charset=UTF-8 Per the excellent eyes of Steven Jones, this conversation was happening in a less-than-optimal forum. I'm forwarding the whole chain to the dmarc WG so that it can continue there instead. --Kurt Forwarded conversation Subject: [arc-discuss] a few questions about the spec ------------------------ From: Gene Shuman via arc-discuss Date: Wed, Jan 11, 2017 at 12:50 AM To: arc-discuss@dmarc.org Hi All, I have a few fairly straightforward questions about the current spec I'm wondering if somebody can help me out with: - Can messages with violations in their ARC sets(duplicate/malformed i= values, etc), still be considered valid, assuming they pass the chain validation algorithm under the given ordering? I think the language implies so, although its a bit unclear. - Similarly, can messages with completely duplicate ARC sets still be considered valid? - Can we include previous Arc-Message-Signatures in newer message signature hashes? Only Arc-Seals are expressly forbidden? ---------- From: Murray S. Kucherawy via arc-discuss Date: Wed, Jan 11, 2017 at 12:57 AM To: Gene Shuman Cc: ARC Discussion On Tue, Jan 10, 2017 at 11:20 AM, Gene Shuman via arc-discuss < arc-discuss@dmarc.org> wrote: > - Can messages with violations in their ARC sets(duplicate/malformed i= > values, etc), still be considered valid, assuming they pass the chain > validation algorithm under the given ordering? I think the language > implies so, although its a bit unclear. > > - Similarly, can messages with completely duplicate ARC sets still be > considered valid? > I would consider both of these to be errors. > - Can we include previous Arc-Message-Signatures in newer message > signature hashes? Only Arc-Seals are expressly forbidden? > I think not, in the same way that DKIM-Signatures don't sign other DKIM-Signatures. -MSK ---------- From: Gene Shuman via arc-discuss Date: Wed, Jan 11, 2017 at 1:03 AM To: "Murray S. Kucherawy" Cc: ARC Discussion I would expect the first two cases to be errors as well, however the spec somewhat unclearly implies otherwise: 5.2.1. Handling Violations in the ARC Sets > > When ordering the ARC header field sets, if there are gross > > violations of this protocol (e.g., such as duplicated instance > > numbers), such header field set(s) MUST be ordered as follows when > > analyzing for *validity* or subsequent signing: > > I would also expect people not to sign message signatures, however I don't think it's explicitly forbidden anywhere. ---------- From: Murray S. Kucherawy via arc-discuss Date: Wed, Jan 11, 2017 at 5:57 AM To: Gene Shuman Cc: ARC Discussion I agree, that section needs work. To me it's a contradiction to provide a workaround to something that constitutes a "violation" or a "gross violation". At that point the validation chain should be considered broken, and that's that. Others: Is there some reason we're doing contortions in these cases to get such messages to validate? I'm not sure the paragraph at the end of 5.2.1 provides enough value to offset the additional complexity. -MSK ---------- From: Gene Shuman via arc-discuss Date: Wed, Jan 11, 2017 at 7:13 AM To: "Murray S. Kucherawy" Cc: ARC Discussion It would make sense that a gross violation would imply cv=fail, and that the ordering shouldn't provide a workaround. I do understand that their still needs to a consistient way of generating signatures for broken messages however. Thinking a bit more about this raises a few more questions about pathological cases: - when implementing the ordering in [5.2.1] for signing, do we include ARC header fields with invalid or non-existent values of i=? missing, i=;, i=-1;, i=string; are all cases that need to be addressed. Easiest would be just to not include them. - Section [5.2.1] says to remove fully duplicate sets, but doesn't mention fully duplicate instances. In the case that we're computing, say AS(2), and are provided with AS(1), AS(1), AMS(1), AAR(1), where the first two AS(1)'s are identical, are both included in the AS(2) signature calculation? If so, in the order I've specified, or is the order something like AS(1), AMS(1), AAR(1), AS(1). This is unclear. Is the case that within an arc set, all AS's come before all AMS's, etc? In general though, I think this section could use a non trivial update to language. If we can solidify the clarifications, I'd be happy to suggest some changes. Regards, =Gene ---------- Suggestion from S. Jones to move to dmarc-wg elided here. ---------- From: John Levine via arc-discuss Date: Fri, Jan 13, 2017 at 3:00 AM To: arc-discuss@dmarc.org In article you write: >Others: Is there some reason we're doing contortions in these cases to get >such messages to validate? I'm not sure the paragraph at the end of 5.2.1 >provides enough value to offset the additional complexity. The usual advice in the standards world is to tell people how to interoperate, and if you want to interoperate, you follow the rules. There are certainly places where we have workarounds for backward compatibility. But ARC is new. There's no existing broken implementations to compatible with. My advice would be to strip out 5.2.1. If an MTA is putting on broken ARC headers, the solution is to tell the MTA authors to fix it. R's, John --001a113cda12fcdd260546346263 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Per the excellent eyes of Steven Jones, this conversation = was happening in a less-than-optimal forum. I'm forwarding the whole ch= ain to the dmarc WG so that it can continue there instead.

--Kurt

Forwarded conversation
Subject: [arc-discuss] a few questions about the spec
-= -----------------------

From: Gene Shuman via arc-discuss <arc-discuss@dm= arc.org>
Date: Wed, Jan 11, 2017 at 12:50 AM
To: arc-discuss@dmarc.org

=
Hi All,=C2=A0

I have a few f= airly straightforward questions about the current spec I'm wondering if= somebody can help me out with:

- Can messages wit= h violations in their ARC sets(duplicate/malformed i=3D values, etc), still= be considered valid, assuming they pass the chain validation algorithm und= er the given ordering?=C2=A0 I think the language implies so, although its = a bit unclear. =C2=A0

- Similarly, can messages wi= th completely duplicate ARC sets still be considered valid?
<= br>
- Can we include previous Arc-Message-Signatures in newer mes= sage signature hashes?=C2=A0 Only Arc-Seals are expressly forbidden?
<= div>
----------
From: Murray S. Kucherawy via arc-d= iscuss <a= rc-discuss@dmarc.org>
Date: Wed, Jan 11, 2017 at 12:57 AM<= br>To: Gene Shuman <gene@valimail.c= om>
Cc: ARC Discussion <arc-discuss@dmarc.org>


= On Tue, Jan 10, 2017 at 11:20 AM, Gene Shuman via arc-disc= uss <arc-discuss@dmarc.org> wrote:
- Can messages with violations in their = ARC sets(duplicate/malformed i=3D values, etc), still be considered valid, = assuming they pass the chain validation algorithm under the given ordering?= =C2=A0 I think the language implies so, although its a bit unclear. =C2=A0<= div>
- Similarly, can messages with completely duplicate ARC = sets still be considered valid?

=
I would consider both of these to be errors.
=C2=A0
- Can we include previous Arc-Message-Signatures in newer message si= gnature hashes?=C2=A0 Only Arc-Seals are expressly forbidden?

I think not, in the same way that DKI= M-Signatures don't sign other DKIM-Signatures.

-MSK <= br>

----------
From: Gene Shuman vi= a arc-discuss <arc-discuss@dmarc.org>
Date: Wed, Jan 11, 2017 at 1:= 03 AM
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: ARC Discussion <arc-discuss@dmarc.org>
<= br>
I would expect the first two cases to be err= ors as well, however the spec somewhat unclearly implies otherwise:
5.2.1.=C2=A0 Handling Violations in the AR= C Sets=C2=A0
When orderin= g the ARC header field sets, if there are gross
violations of this protocol (e.g., such = as duplicated instance
numbers), such header field set(s) MUST be ordered as follows wh= en
analyzing = for validity or subsequent signing:

I would also expect people not to sign message sign= atures, however I don't think it's explicitly forbidden anywhere.

----------
From: Murray S. Kucherawy via ar= c-discuss <arc-discuss@dmarc.org>
Date: Wed, Jan 11, 2017 at 5:57 A= M
To: Gene Shuman <gene@valimail= .com>
Cc: ARC Discussion <arc-discuss@dmarc.org>


I agree, that section needs work.=C2=A0 To me it's a contra= diction to provide a workaround to something that constitutes a "viola= tion" or a "gross violation".=C2=A0 At that point the valida= tion chain should be considered broken, and that's that.

O= thers: Is there some reason we're doing contortions in these cases to g= et such messages to validate?=C2=A0 I'm not sure the paragraph at the e= nd of 5.2.1 provides enough value to offset the additional complexity.
<= br>
-MSK

----------
From: Gene Shuman via arc-discuss<= /b> <arc-disc= uss@dmarc.org>
Date: Wed, Jan 11, 2017 at 7:13 AM
To: &= quot;Murray S. Kucherawy" <s= uperuser@gmail.com>
Cc: ARC Discussion <arc-discuss@dmarc.org>


<= div dir=3D"ltr">It would make sense that a gross violation would imply cv= =3Dfail, and that the ordering shouldn't provide a workaround.=C2=A0 I = do understand that their still needs to a consistient way of generating sig= natures for broken messages however.=C2=A0 Thinking a bit more about this r= aises a few more questions about pathological cases:

- w= hen implementing the ordering in [5.2.1] for signing, do we include ARC hea= der fields with invalid or non-existent values of i=3D? =C2=A0missing, i=3D= ;, i=3D-1;, i=3Dstring; are all cases that need to be addressed.=C2=A0 Easi= est would be just to not include them. =C2=A0
- Section [5.2.1] s= ays to remove fully duplicate sets, but doesn't mention fully duplicate= instances.=C2=A0 In the case that we're computing, say AS(2), and are = provided with AS(1), AS(1), AMS(1), AAR(1), where the first two AS(1)'s= are identical, are both included in the AS(2) signature calculation?=C2=A0= If so, in the order I've specified, or is the order something like AS(= 1), AMS(1), AAR(1), AS(1).=C2=A0 This is unclear.=C2=A0 Is the case that wi= thin an arc set, all AS's come before all AMS's, etc?
In general though, I think this section could use a non trivial= update to language.=C2=A0 If we can solidify the clarifications, I'd b= e happy to suggest some changes. =C2=A0

Regards,
=3DGene

----------
= Suggestion from S. Jones to move to dmarc-wg elided here.
----------
= From: John Levine via arc-discuss <arc-discuss@dmarc.org>
Date:= Fri, Jan 13, 2017 at 3:00 AM
To: arc-discuss@dmarc.org


In a= rticle <CAL0qLwZa45bxp=3DoztB-MYPPayZGVTmqSvSdCG_gpZNo6y+u6fw@ma= il.gmail.com> you write:

>Others: Is there some reason we're doing contortions in these cases= to get
>such messages to validate?=C2=A0 I'm not sure the paragraph at the = end of 5.2.1
>provides enough value to offset the additional complexity.

The usual advice in the standards world is to tell people how to
interoperate, and if you want to interoperate, you follow the rules.

There are certainly places where we have workarounds for backward
compatibility.=C2=A0 But ARC is new.=C2=A0 There's no existing broken implementations to compatible with.=C2=A0 My advice would be to strip out 5.2.1.=C2=A0 If an MTA is putting on broken ARC headers, the solution is to=
tell the MTA authors to fix it.

R's,
John


--001a113cda12fcdd260546346263-- From nobody Wed Jan 18 14:46:49 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E041294F4 for ; Wed, 18 Jan 2017 14:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 WR2_sOiw-TqI for ; Wed, 18 Jan 2017 14:46:45 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003: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 7B7C4129422 for ; Wed, 18 Jan 2017 14:46:45 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id w204so15339420oiw.0 for ; Wed, 18 Jan 2017 14:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=GKKnurD6C4VOiIoQ8MCjpx87MAe6QnshrarSOGz6prQ=; b=KDy/WIhqDhWLnDeUeh9dNKJH3BHg06+SRokTY7YUmV/mGaBOveHyeAzqz6u3VnXRfO GzoTu9UGVdG9gr5EjxNA1+S09ssHJ9C5dUn/YCsvcDLPP7iK0JGKH/WzfO32pvRDGbxg FveM1hiEN0EMD7TjeLpMzbL33fyTvsyiX7cE23jCLTdWbVjJKu8wYiNSW6Jgm9st1isU ytl7drCJGy0LAYPUKcdEDIRKpZFWAWi6z522W/xj14cQb0lMurmcHmawyfyvvIrk8zd0 EQb0sl8n0OSde2RYDFmNdXz1TUXGVjxdDhRvVARl6tg/xxO09cnyHuBnlWa75S/nzHL7 p7oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GKKnurD6C4VOiIoQ8MCjpx87MAe6QnshrarSOGz6prQ=; b=q2460ZaDfTpvOAcKKjSfWrZx3rnYCB+n0oJUpPfkI2I0ei7hbIH9Pv7O2gw8c9kc/S bDpNfA0Pmlb3KglzFhpmPIHPHRCQ5XglaBZBG+qJ2hwlxdBQOKXxg36RvFZtJztYR3KY aM4s79LkjGZiaR1UKY60ThxfrzsmcEUlPbzFMOeVVNnq4+HmO4UdpTIGDRXvFUG4rt3L 6gdVqbcpiSKIDOilqbLuhWIv/RjTYhIItnblVBm1qKIZYJ0Ohyx6CkoAB7hhyh5pZftu 00xNIt7rwGlr0j3jVdt6clz8GIlI1x9AP0+R0YTfpa95YEwnYGLBmM9KBf/t6UF4Um2g EqsQ== X-Gm-Message-State: AIkVDXLy1aRhKZ746USy4dQZ8vuD9VoyQisXX6Bw0fL1BlgANJL0q4sayaRFfxDNbqUXqbkrTHNXP/tq+qKDEw== X-Received: by 10.202.4.84 with SMTP id 81mr2685569oie.127.1484779604568; Wed, 18 Jan 2017 14:46:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.14.6 with HTTP; Wed, 18 Jan 2017 14:46:44 -0800 (PST) From: Gene Shuman Date: Wed, 18 Jan 2017 14:46:44 -0800 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=001a113c0e80e6826a054666300c Archived-At: Subject: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 22:46:48 -0000 --001a113c0e80e6826a054666300c Content-Type: text/plain; charset=UTF-8 Hello, This is something of a continuation of my other email wrt section [5.2.1] of the draft. I've discovered an even larger range of indeterminate cases wrt to this section, and any attempt to rectify this within the given framework seems to get fairly messy. Basically, there is a large class of input headers that aren't covered by the current language, and cant be signed. The basic problem is that for a large range of invalid messages, the notion of arc set is not well defined. The standard notion of arc set is all fields with identical i= tag. This notion breaks down when you have violations such as duplicate i= values. The only way we can recover our notion of arc sets at this point is to define arc sets *logically* as contiguous blocks of arc headers(AS, AMS, AAR) in the input emails. Section [5.2.1] seems to be operating tacitly under this revised definition, and given that the ordering it specifies makes sense. However if we have further degeneracy wherein we can no longer logically form arc sets, either because of missing or invalid i= values, or intermixed/incomplete sets, the ordering in section is no longer applicable, and we're left with a huge gap. I think its clear that we fail all of these messages. But for signing, we need to specify an ordering on these pathological arc headers, as section [5.2.1] only applies when you can logically define arc sets. We also probably need this ordering to downgrade to that in section [5.2.1] when applicable, and to the defacto ordering in the standard case. The obvious solution here is to simply sign *all *arc headers under all sealing/validation operations in a bottom up order, regardless of the validity/ordering of the headers in the email. Reasons that this is good: - This is the simplest language - This probably has the simplest implementations - Assuming validly signed inputs this defaults to the ordering in section [5.1.1.3] - This also defaults to section [5.2.1], in the slightly less valid, but still broken state, apart from the alphabetical ordering clause - I think this is basically what's implicitly intended throughout the draft. The only other way I can see to approach this issue is to continue down the path of [5.2.1] and define an additional ordering on these pathological cases. It seems wrong to me to force implementors to provide whatever weird sorting functionality this would be, just for the sake of signing pathological examples, so I recommend against this approach. So I think the universal bottom up ordering is the way to go. Anybody have any opinions here? I'm happy to take the lead on proposing changes to the draft. Regards, =Gene --001a113c0e80e6826a054666300c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

This is something of a continuat= ion of my other email wrt section [5.2.1] of the draft.=C2=A0 I've disc= overed an even larger range of indeterminate cases wrt to this section, and= any attempt to rectify this within the given framework seems to get fairly= messy.=C2=A0 Basically, there is a large class of input headers that aren&= #39;t covered by the current language, and cant be signed. =C2=A0

The basic problem is that for a large range of invalid mess= ages, the notion of arc set is not well defined.=C2=A0 The standard notion = of arc set is all fields with identical i=3D tag.=C2=A0 This notion breaks = down when you have violations such as duplicate i=3D values.=C2=A0 The only= way we can recover our notion of arc sets at this point is to define arc s= ets logically=C2=A0as contiguous blocks of arc headers(AS, AMS, AAR)= in the input emails.=C2=A0 Section [5.2.1] seems to be operating tacitly u= nder this revised definition, and given that the ordering it specifies make= s sense.

However if we have further degeneracy whe= rein we can no longer logically form arc sets, either because of missing or= invalid i=3D values, or intermixed/incomplete sets, the ordering in sectio= n is no longer applicable, and we're left with a huge gap.=C2=A0

I think its clear that we fail all of these messages= .=C2=A0 But for signing, we need to specify an ordering on these pathologic= al arc headers, as section [5.2.1] only applies when you can logically defi= ne arc sets. We also probably need this ordering to downgrade to that in se= ction [5.2.1] when applicable, and to the defacto ordering in the standard = case. =C2=A0

The obvious solution here is to simpl= y sign all arc headers under all sealing/validation operations in a = bottom up order, regardless of the validity/ordering of the headers in the = email.=C2=A0 Reasons that this is good:
- This is the simplest la= nguage
- This probably has the simplest implementations
- Assuming validly signed inputs this defaults to the ordering in section = [5.1.1.3]
- This also defaults to section [5.2.1], in the slightl= y less valid, but still broken state, apart from the alphabetical ordering = clause
- =C2=A0I think this is basically what's implicitly in= tended throughout the draft.

The only other way I = can see to approach this issue is to continue down the path of [5.2.1] and = define an additional ordering on these pathological cases.=C2=A0 It seems w= rong to me to force implementors to provide whatever weird sorting function= ality this would be, just for the sake of signing pathological examples, so= I recommend against this approach.

So I think the= universal bottom up ordering is the way to go.=C2=A0 Anybody have any opin= ions here?=C2=A0 I'm happy to take the lead on proposing changes to the= draft.

Regards,
=3DGene

<= /div>
--001a113c0e80e6826a054666300c-- From nobody Wed Jan 18 15:05:36 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B869E1295C4 for ; Wed, 18 Jan 2017 15:05:34 -0800 (PST) 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 e-hI9M5050Y1 for ; Wed, 18 Jan 2017 15:05:33 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54A91294BD for ; Wed, 18 Jan 2017 15:05:32 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id k127so18534339vke.0 for ; Wed, 18 Jan 2017 15:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tfCZsBWm66GvJHfRoQKpBbBxhPuzJrZUpU5Ha0V0kxA=; b=H1dNrXqZsX7ypDf9pLv4H46Lf8hPOKqRcnW3Fl6TuwDBYyCzNETuKEu8XsAkzkNaWA D9UjMJUgGcBUOS4EhRS8nMTty67MA2aL6Ew+FuU9yEik21m9bbE2xRtzbNuTIJ8yiKzg 20fcWypbBs6FIA3wu4NuZ7nW7D6ykRTt5LhcDhlSxHofXKJtm8w7WwzgBPxbW2iYkdkR P1IwY9wJlUPmZi9AmrbxUEBHt+NvR+Vpy1h24RqpYKpeaFObCiydaDXEfG5L+WOMvOkC 6ADa50aBB9B+jWeVErZfWFEfXQdlO6/dFcVmusfRtRXTfL6rX69Nzif4H3vsWXUfKf+5 coHw== 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=tfCZsBWm66GvJHfRoQKpBbBxhPuzJrZUpU5Ha0V0kxA=; b=A4DY/DYcod7TPLrrHFyccq2w3Aia1jJGsSfUqFdM+4ZTNZiR671gs7ecu25FWiHQzJ t+bx3pR921QIYKMvGmESSMdX7Pr+ZXuPKY29PgIm/gMn8pGVUgL18WRYbJ1bWU0eLAiG WFgZA0rL3C4COkjfxkuQD5cbMThFgg1fZlDgWLy+mx1Ssl5v5FQ2Z7b+dfeVP+ov6IuE 5ZcGbXOWrnjKWIsIALGk/tXA5IYlNQuotnciyewybo44HZF8wv3oFKlWg0UIUc3PVWUf SIDh1NRQAYb96kVkuKV0r5oG7qJrevNoZrqmZ5GJv/9nXkAdahPzIZOGrr8GbIIumjEf NymQ== X-Gm-Message-State: AIkVDXLaVQY3Rd/zmgb1nruRyzFwyq6x77byohSYtpKqrr69Ulxt3/5IAXTWZUXbcUybPflXZh9jiy4WEP8VhA== X-Received: by 10.31.138.9 with SMTP id m9mr2431700vkd.110.1484780731889; Wed, 18 Jan 2017 15:05:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.150 with HTTP; Wed, 18 Jan 2017 15:05:31 -0800 (PST) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 18 Jan 2017 15:05:31 -0800 Message-ID: To: Gene Shuman Content-Type: multipart/alternative; boundary=001a1144fcc217ff1f0546667442 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 23:05:34 -0000 --001a1144fcc217ff1f0546667442 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 18, 2017 at 2:46 PM, Gene Shuman wrote: > I think its clear that we fail all of these messages. But for signing, we > need to specify an ordering on these pathological arc headers, as section > [5.2.1] only applies when you can logically define arc sets. We also > probably need this ordering to downgrade to that in section [5.2.1] when > applicable, and to the defacto ordering in the standard case. > > The obvious solution here is to simply sign *all *arc headers under all > sealing/validation operations in a bottom up order, regardless of the > validity/ordering of the headers in the email. Reasons that this is good: > - This is the simplest language > - This probably has the simplest implementations > - Assuming validly signed inputs this defaults to the ordering in section > [5.1.1.3] > - This also defaults to section [5.2.1], in the slightly less valid, but > still broken state, apart from the alphabetical ordering clause > - I think this is basically what's implicitly intended throughout the > draft. > > The only other way I can see to approach this issue is to continue down > the path of [5.2.1] and define an additional ordering on these pathological > cases. It seems wrong to me to force implementors to provide whatever > weird sorting functionality this would be, just for the sake of signing > pathological examples, so I recommend against this approach. > > So I think the universal bottom up ordering is the way to go. Anybody > have any opinions here? I'm happy to take the lead on proposing changes to > the draft. > This is also what I had in mind. If I receive a bunch of ARC Sets that are not all pristine at least in terms of being complete (exactly one of each of the ARC header fields) and/or there are gaps in the instance sequence, then the chain is de facto invalid and I should report it as such using "cv=fail" when generating my own seal. I suggest we don't even attempt the crypto operations to verify any of the existing seals or AMS fields. There's some history of being gentle or forgiving in the email space, and it has never served us well. (See RFC7103, for example.) We shouldn't subject ARC to such vagueries, especially when people are betting on it solving a lot of problems. -MSK --001a1144fcc217ff1f0546667442 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 18, 2017 at 2:46 PM, Gene Shuman <gene@valima= il.com> wrote:
I think its clea= r that we fail all of these messages.=C2=A0 But for signing, we need to spe= cify an ordering on these pathological arc headers, as section [5.2.1] only= applies when you can logically define arc sets. We also probably need this= ordering to downgrade to that in section [5.2.1] when applicable, and to t= he defacto ordering in the standard case.=C2=A0

The obvious= solution here is to simply sign all arc headers under all sealing/v= alidation operations in a bottom up order, regardless of the validity/order= ing of the headers in the email.=C2=A0 Reasons that this is good:
- This is the simplest language
- This probably has the simplest= implementations
- Assuming validly signed inputs this defaults t= o the ordering in section [5.1.1.3]
- This also defaults to secti= on [5.2.1], in the slightly less valid, but still broken state, apart from = the alphabetical ordering clause
- =C2=A0I think this is basicall= y what's implicitly intended throughout the draft.

=
The only other way I can see to approach this issue is to continue dow= n the path of [5.2.1] and define an additional ordering on these pathologic= al cases.=C2=A0 It seems wrong to me to force implementors to provide whate= ver weird sorting functionality this would be, just for the sake of signing= pathological examples, so I recommend against this approach.
So I think the universal bottom up ordering is the way to go.= =C2=A0 Anybody have any opinions here?=C2=A0 I'm happy to take the lead= on proposing changes to the draft.

=
This is also what I had in mind.=C2=A0 If I receive a bunch of ARC Set= s that are not all pristine at least in terms of being complete (exactly on= e of each of the ARC header fields) and/or there are gaps in the instance s= equence, then the chain is de facto invalid and I should report it as such = using "cv=3Dfail" when generating my own seal.=C2=A0 I suggest we= don't even attempt the crypto operations to verify any of the existing= seals or AMS fields.

There's some history of being g= entle or forgiving in the email space, and it has never served us well.=C2= =A0 (See RFC7103, for example.)=C2=A0 We shouldn't subject ARC to such = vagueries, especially when people are betting on it solving a lot of proble= ms.

-MSK
--001a1144fcc217ff1f0546667442-- From nobody Thu Jan 19 00:56:02 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3A41293EE for ; Thu, 19 Jan 2017 00:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jW4FvQtzUc4O for ; Thu, 19 Jan 2017 00:56:00 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 E499E127ABE for ; Thu, 19 Jan 2017 00:55:59 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id 73so27426874otj.0 for ; Thu, 19 Jan 2017 00:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UdmcAyj7ts8XJEWaD9y/jH1FALmYt+KG/j3lSiG2V40=; b=O/9QW473QDzLZsJRc5t6XklyFQM3WrX+E/ErPGWDhkqfUQAcNQa5sdHv2lky21IJX+ qdgMCTt1FZulenuvJ++J6pRnobc8nAaVz87ZnYClNVsD/UzV8HmhD9GOpSXTH3f7hWge mOPo/xRwm8yCzT0Emmdb4fJ3NH9ffhde4MF7g= 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=UdmcAyj7ts8XJEWaD9y/jH1FALmYt+KG/j3lSiG2V40=; b=Wd6d5ZaaC1HTjQlHz77nocjATD181LGYFDlNHS56F0Yme7VJsleZXkN9q0SAWjaQQW uAKEBo/uYqPlAPb9IuwnMRErPFoaqsRnzRlQ/e5FIPCLyRpK0wBFZlF5CpWlp4oQ2nqT YNSBfcZEqVPhtKbtaC/5CoTSwanClkhJeDbBNvpPnmL0fCT5IBadyxkeCVFclM9N0ypH XB+j23zQTw5MiP0dWwewvcuN705kPQ1bcSVpbcx+OKhl7KeFF4vopUfsOkeuXDVyR7ri 3sIHm9wcOPPjP5imuCBiKF5Ubz7zRkXm0vLOA+CiuZL/b/X6HAu7LF8lx4z77Pug/Cis mwvQ== X-Gm-Message-State: AIkVDXIBBnhFNyvCpHorZeReMfl5+43aIS5ZKTTOQhIC9rXjLsfboe3oyq1ior+Yod6Z3RvlMOfd2iOgYAbHzg== X-Received: by 10.157.63.188 with SMTP id r57mr3505828otc.78.1484816159181; Thu, 19 Jan 2017 00:55:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.184.69 with HTTP; Thu, 19 Jan 2017 00:55:58 -0800 (PST) In-Reply-To: References: From: Kurt Andersen Date: Thu, 19 Jan 2017 14:25:58 +0530 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11459e14b9bfa005466eb32f Archived-At: Cc: "dmarc@ietf.org" , Gene Shuman Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 08:56:01 -0000 --001a11459e14b9bfa005466eb32f Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 4:35 AM, Murray S. Kucherawy wrote: > On Wed, Jan 18, 2017 at 2:46 PM, Gene Shuman wrote: > >> I think its clear that we fail all of these messages. But for signing, >> we need to specify an ordering on these pathological arc headers, as >> section [5.2.1] only applies when you can logically define arc sets. We >> also probably need this ordering to downgrade to that in section [5.2.1] >> when applicable, and to the defacto ordering in the standard case. >> > The intent of section 5.2.1 was never to deal with pathological cases. It was to deal with somewhat broken MTAs that do stupid things like reordering headers in alphabetical order or slightly broken implementations which might replicate headers. I'm OK with a general approach of declaring all such broken implementations as being "beyond redemption". We should probably focus on a clear way to demarcate such a condition when it is processed by a conformant handler and move on. Gene, if you have wording suggestions in mind, those will be gratefully received; otherwise I'll take a swing at restructuring the section while I'm in flight on Saturday. One of the questions that comes to mind is "what should the good actor do with all the pathological junk?" Should we specify some sort of debridement handling? Cheers, Kurt --001a11459e14b9bfa005466eb32f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 19, 2017 at 4:35 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On W= ed, Jan 18, 2017 at 2:46 PM, Gene Shuman <gene@valimail.com>= wrote:
I think its clear that we fail all of= these messages.=C2=A0 But for signing, we need to specify an ordering on t= hese pathological arc headers, as section [5.2.1] only applies when you can= logically define arc sets. We also probably need this ordering to downgrad= e to that in section [5.2.1] when applicable, and to the defacto ordering i= n the standard case. =C2=A0

The intent of section 5.2.1 was never to deal with pa= thological cases. It was to deal with somewhat broken MTAs that do stupid t= hings like reordering headers in alphabetical order or slightly broken impl= ementations which might replicate headers.=C2=A0

I= 'm OK with a general approach of declaring all such broken implementati= ons as being "beyond redemption". We should probably focus on a c= lear way to demarcate such a condition when it is processed by a conformant= handler and move on.=C2=A0

Gene, if you have word= ing suggestions in mind, those will be gratefully received; otherwise I'= ;ll take a swing at restructuring the section while I'm in flight on Sa= turday. One of the questions that comes to mind is "what should the go= od actor do with all the pathological junk?" Should we specify some so= rt of debridement handling?

Cheers,
=C2= =A0 Kurt
--001a11459e14b9bfa005466eb32f-- From nobody Thu Jan 19 07:32:26 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BC412896F for ; Thu, 19 Jan 2017 07:32:25 -0800 (PST) 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 rbHgVieSp82d for ; Thu, 19 Jan 2017 07:32:23 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3FC129420 for ; Thu, 19 Jan 2017 07:32:23 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id x75so32571137vke.2 for ; Thu, 19 Jan 2017 07:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LrUV7SVK9DLpd1vm/7wvf9eaUb4rhnVfJ+ue2J1W4l0=; b=N+uMHosSAgZy/SpJCn1CinOo4MtgLzS2Q/IxOoUAzBSZMcSKBxpvkE3/7IRh1owSQ5 vWuX06Wu05B51FjK3Oj/deYQgHMqw2sryASWHpiP3ouMR5DFeRANjFGXB3ZWaI1cu1OW RkeRKcOBO/imN9Mkqmtmqlqwj1KP1hop76kfrmmmPWCyL4Qr8bSu33N0pbVlCaw0IVUu 2Os0Y5Qy4+6tAkHcX2zSJsv6AFNux9Y4OkXybGZMlCjHAhdEh244mMe+g6RXmKH7+i3F uQPERxHmSdSPAooJEyxnK34+VEfAfNryeofTYXEO46Z85hx8Bk2H7lJXlJ1SDzzHNv02 Lyeg== 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=LrUV7SVK9DLpd1vm/7wvf9eaUb4rhnVfJ+ue2J1W4l0=; b=eKEOCZx404I0aPNVGWl/V+dWZ9qYVKIbOd7v5MgRbbUCXRANnJF5FHYSD6Adx8Plz/ E7ntSo2m5I8RPWDfkH2rJ+dZ2mv8GpsUHR4vw3W1UeNnCRNa1ZP4nv+Gqo4IsXw06dNQ 7a5zKJx2PNeDbw5wp6gDn4g98rL0McUp50jDkcy+shMbO2/SlMVTS7GuLbV+lW1Iv6fD gIdNdaOfSikiGm7ZwS4Zlac6i7cczlF5FLlrxzOfyvfpj8leAAnlZgi1N/4pFVNBjZ3r aCUaMVcyLKU84YUa0Bxfkqc3myt8v2q0LXHRstXAOknPD9p+CV6/6XhR8PrCcWh1tHLi CF7g== X-Gm-Message-State: AIkVDXLfJ4V6H01eFPg3SRiWfUiIMD/OhLFdNafNJ3/caTLBFYpQNXNLYZiUydepzs4M8vpnxLKYW7qSvPjvcw== X-Received: by 10.31.134.200 with SMTP id i191mr4793294vkd.57.1484839942859; Thu, 19 Jan 2017 07:32:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.150 with HTTP; Thu, 19 Jan 2017 07:32:22 -0800 (PST) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Thu, 19 Jan 2017 07:32:22 -0800 Message-ID: To: Kurt Andersen Content-Type: multipart/alternative; boundary=001a114395ba57b6b70546743dc4 Archived-At: Cc: "dmarc@ietf.org" , Gene Shuman Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 15:32:25 -0000 --001a114395ba57b6b70546743dc4 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen wrote: > > The intent of section 5.2.1 was never to deal with pathological cases. It > was to deal with somewhat broken MTAs that do stupid things like reordering > headers in alphabetical order or slightly broken implementations which > might replicate headers. > > Reordering shouldn't be a problem for us because it's easy to search through a relatively short list for an ARC field bearing a particular "i=" value. If the only thing that ever happens is reordering, we should still be fine (a la DKIM's "h" tag). Duplication is arguably fine as long as the duplicate is identical to the original, but I think once you have to go so far as to evaluate that, the chain has actually been directly affected, and it's fine to give up. -MSK --001a114395ba57b6b70546743dc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen <kurta@dr= kurt.com> wrote:

The int= ent of section 5.2.1 was never to deal with pathological cases. It was to d= eal with somewhat broken MTAs that do stupid things like reordering headers= in alphabetical order or slightly broken implementations which might repli= cate headers.=C2=A0


<= /div>
Reordering shouldn't be a problem for us because it's eas= y to search through a relatively short list for an ARC field bearing a part= icular "i=3D" value.=C2=A0 If the only thing that ever happens is= reordering, we should still be fine (a la DKIM's "h" tag).
Duplication is arguably fine as long as the duplicate is i= dentical to the original, but I think once you have to go so far as to eval= uate that, the chain has actually been directly affected, and it's fine= to give up.

-MSK
--001a114395ba57b6b70546743dc4-- From nobody Thu Jan 19 11:24:39 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E53B1294DB for ; Thu, 19 Jan 2017 11:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.71 X-Spam-Level: X-Spam-Status: No, score=0.71 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jp-PBJL_64Ja for ; Thu, 19 Jan 2017 11:24:35 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46CC129407 for ; Thu, 19 Jan 2017 11:24:35 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id 73so39683476otj.0 for ; Thu, 19 Jan 2017 11:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=enc2GGyK+KkJOgJBgua2CeozxjbEDChZBpvDP+9JAkk=; b=NeCj+IqfxPPI+9g+DIMEI+gOMrMw1o08JIvASiUtJElvoRcXCPgUQeBkGoEC9ZlFno B3GdN+srGhQiP806KYJ8DokjjIEXpvG+VcjzpnnCBSxVUZZjTQeSuddH6eMr9RcM/ihk zxRmtSQk38D/8zlrv1I+KEdE/m2krKkbO+KX/EJGFV2473r7V4C87pOHRDGlJcj/VG7U hll+z2zKYC8+DnSk3lpTyA7bEl7xgLJXl5vtPHSfxBiH92evX1QTvmBvc8mX3CiDQX8K rNlQAs9q/NYmGARAFn0bUu2yiPbCFv2uU5aWyuDpVnuC1bNghQas55/gsOu9ILp07x6s kSJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=enc2GGyK+KkJOgJBgua2CeozxjbEDChZBpvDP+9JAkk=; b=VRjyq6uasycejd3MlR2BoR+7YP2f2ljQr/3VUarSdjNkEGaYJZcw8cbOrESX1ZqXmJ RQO6ZGIKdrRYfHW5xwaXDEPeNMds28atlCL1CT7llwEY0Tf8ULOBAbFLsR6TSmJyGMA7 oNclySxEzhOfo2Kc/PGStNIr/EmGessqoGN0CAxyohbaoK2/GDMVOwDnxM3zHGqKVyHK 7j+3WNCvxY3GFt7QEepTuqYRUOo/UzbIacnKHRYJy6vSOQ0FQskamnGwrYAd88oXhmen UyRh/cM6afRz22Q6vPlNNApBl8XlbDOmucrP21M4mpeVj0RSkboqTLIVA12StelMO+/G 4j0A== X-Gm-Message-State: AIkVDXLrFyiET20gPeJJoiGVgyeGYw6l140IiwL5Wd6xpsyRSlv7GXV7ze5QKazK0mTE4O6sfYM3mWztHZ+ndQ== X-Received: by 10.157.43.117 with SMTP id f50mr5779754otd.77.1484853875065; Thu, 19 Jan 2017 11:24:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.14.6 with HTTP; Thu, 19 Jan 2017 11:24:34 -0800 (PST) From: Gene Shuman Date: Thu, 19 Jan 2017 11:24:34 -0800 Message-ID: To: dmarc@ietf.org, ARC Discussion , technical@mailman.m3aawg.org Content-Type: multipart/alternative; boundary=001a113eddccc45fe10546777b07 Archived-At: Subject: [dmarc-ietf] Announcement and request for feedback: ARC Test Suite X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:24:38 -0000 --001a113eddccc45fe10546777b07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, We=E2=80=99re very pleased to release our language-agnostic ARC Test Suite = to the group: https://github.com/ValiMail/arc_test_suite The test suite can be run against any ARC implementation given certain minimum requirements. It has been validated against a working Python ARC implementation, originally developed by Brandon Long and subsequently modified and merged into dkimpy by ourselves and Scott Kitterman. We=E2=80=99re releasing this test suite to 1) make it easier for everyone i= n the community to consistently validate their ARC functionality, 2) help the community in advance of the February 24th interop, and 3) get feedback on the test suite to make it as robust as possible for everyone and resolve any ambiguities in the specification. The test suite format was taken from the OpenSPF test suite and and consists of two sections, one for the generation of ARC header fields, the other for their validation. Test suite runners exist for Python, and we=E2= =80=99d be happy to accept contribution for other languages. The suite is intended to be comprehensive. As of today, the only portion of the ARC draft that the suite does not cover is an open issue regarding handling pathological headers not covered under section 5.2.1. We're seeking clarity on this on the dmarc-ietf list because the behavior in this case is not well-defined. Once resolved, we=E2=80=99ll update the test suit= e accordingly. If you have any questions or would like to contribute to the suite, please feel free to reach out via one of the mailing lists or by opening an issue on the Github repo. We=E2=80=99d love your feedback. Thank you! Gene, Peter, and Seth ValiMail --001a113eddccc45fe10546777b07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi All,


We=E2=80=99re very pleased to release our lang= uage-agnostic ARC Test Suite to the group: https://gi= thub.com/ValiMail/arc_test_suite


The test suite can be run aga= inst any ARC implementation given certain minimum requirements.=C2=A0 It ha= s been validated against a working Python ARC implementation, originally de= veloped by Brandon Long and subsequently modified and merged into dkimpy by= ourselves and Scott Kitterman.


We=E2=80=99re releasing this test = suite to 1) make it easier for everyone in the community to consistently va= lidate their ARC functionality, 2) help the community in advance of the Feb= ruary 24th interop, and 3) get feedback on the test suite to make it as rob= ust as possible for everyone and resolve any ambiguities in the specificati= on.


The test suite format was taken from the OpenSPF test suite an= d and consists of two sections, one for the generation of ARC header fields= , the other for their validation.=C2=A0 Test suite runners exist for Python= , and we=E2=80=99d be happy to accept contribution for other languages.


The suite is intended to be comprehensive.=C2=A0 As of today, the onl= y portion of the ARC draft that the suite does not cover is an open issue r= egarding handling pathological headers not covered under section 5.2.1. We&= #39;re seeking clarity on this on the dmarc-ietf list because the behavior = in this case is not well-defined. Once resolved, we=E2=80=99ll update the t= est suite accordingly.


If you have any questions or would like to = contribute to the suite, please feel free to reach out via one of the maili= ng lists or by opening an issue on the Github repo.=C2=A0 We=E2=80=99d love= your feedback. Thank you!


Gene, Peter, and Seth

ValiMail
--001a113eddccc45fe10546777b07-- From nobody Thu Jan 19 11:46:32 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51963129497 for ; Thu, 19 Jan 2017 11:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wUUwqnEhVO5a for ; Thu, 19 Jan 2017 11:46:30 -0800 (PST) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::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 D8AE012943B for ; Thu, 19 Jan 2017 11:46:29 -0800 (PST) Received: by mail-ot0-x233.google.com with SMTP id 104so40034034otd.3 for ; Thu, 19 Jan 2017 11:46:29 -0800 (PST) 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=DahqWipAChk2qDYFj0qwWCgT+gnVhrwLcMABw4lsbBo=; b=XbXjTTUCcYq0RAZyG3B6Ynmqg9lJcaBhXTHHeRm609T9tNU81BF91skMmqlkCkAK+O QaP5nDDosym/SqXxWkVUFTQHSFf2tcMTawPrRfCc+M0XowNzLV7qUUGna3ymofRowusl o2TPm3UjCZ6tSW1uJm/lldoG8bCIoxhR+C6eRuTctifXOFKRAM2A/DMeldXI3TUruKF9 kDeY7g0E+zDX+f5B7JKugxDAmV/iqW0TQN3ze4m9b10WselW5oKxOXTbk4NCO8Efrg9I sBVNv2W+SnVHVB18HbJb0ol3FSk4VueuT3mALqzHzz3g5G6qhBVcyxT7l6rYALb0Re8/ pj4Q== 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=DahqWipAChk2qDYFj0qwWCgT+gnVhrwLcMABw4lsbBo=; b=RvFnAp0q+n/mJWAL2vHJ0qsKCbRAE2844vvwEBxenbSwXbmuEemhvGaEfynKJA3RWF MTZ/q/RJEUGSWNyu/qFMzGLPQG/IhklILQqBodn704mHHCKE23pqlPvG9uSCxZx4e/40 7m4lPtsRlt5oYzLmPfwj7LvSC6Hbv4Zz9n/hDS0/2B82E63Ria9K31vOkqkKiV+MlfKz J/+niLllo/2Fs3cezI0+7mXnGzLpr/z/9DM1LOEA8JXOkdiHn27VgFh/xDNdeq8cM69t +egaQkV+KGsfGXU2vcUWwo8pKZBvNQ11NrFnEv0H9idUMoA6chXmZJKMiaSI+D2rCYWp YoOQ== X-Gm-Message-State: AIkVDXJW032Hk07rBTORs6G4TDKbQmF5Cidc8qYy2gXRBNjuj+oNLOqf1j9gE4DCTL3fx1h82q2vWNQq7lrJxw== X-Received: by 10.157.43.117 with SMTP id f50mr5832267otd.77.1484855189351; Thu, 19 Jan 2017 11:46:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.14.6 with HTTP; Thu, 19 Jan 2017 11:46:29 -0800 (PST) In-Reply-To: References: From: Gene Shuman Date: Thu, 19 Jan 2017 11:46:29 -0800 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a113eddcc1abae7054677ca99 Archived-At: Cc: "dmarc@ietf.org" , Kurt Andersen Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:46:31 -0000 --001a113eddcc1abae7054677ca99 Content-Type: text/plain; charset=UTF-8 OK great, I think we're on the same page. Focusing on what good actors should do with malformed arc sets is exactly the question. If we do want to keep them around & continue the chain, making sure that we fail, I still suggest the bottom up order for signing. Stripping out the malformed arc sets and restarting the chain, possibly with something like a new CV_Invalid is another possibility. This is an interesting idea, that I think I like, but do we suspect we would be removing information that somebody might find useful? Regards, =Gene On Thu, Jan 19, 2017 at 7:32 AM, Murray S. Kucherawy wrote: > On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen wrote: > >> >> The intent of section 5.2.1 was never to deal with pathological cases. It >> was to deal with somewhat broken MTAs that do stupid things like reordering >> headers in alphabetical order or slightly broken implementations which >> might replicate headers. >> >> > Reordering shouldn't be a problem for us because it's easy to search > through a relatively short list for an ARC field bearing a particular "i=" > value. If the only thing that ever happens is reordering, we should still > be fine (a la DKIM's "h" tag). > > Duplication is arguably fine as long as the duplicate is identical to the > original, but I think once you have to go so far as to evaluate that, the > chain has actually been directly affected, and it's fine to give up. > > -MSK > --001a113eddcc1abae7054677ca99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK great, I think we're on the same page.=C2=A0 Focusi= ng on what good actors should do with malformed arc sets is exactly the que= stion.=C2=A0 If we do want to keep them around & continue =C2=A0the cha= in, making sure that we fail, I still suggest the bottom up order for signi= ng.=C2=A0 Stripping out the malformed arc sets and restarting the chain, po= ssibly with something like a new CV_Invalid is another possibility.=C2=A0 T= his is an interesting idea, that I think I like, but do we suspect we would= be removing information that somebody might find useful? =C2=A0

Regards,
=3DGene
<= br>
On Thu, Jan 19, 2017 at 7:32 AM, Murray S. Ku= cherawy <superuser@gmail.com> wrote:
On Thu, Jan 19, 2017 at 12:= 55 AM, Kurt Andersen <kurta@drkurt.com> wrote:

The intent of section 5.2.1 was never t= o deal with pathological cases. It was to deal with somewhat broken MTAs th= at do stupid things like reordering headers in alphabetical order or slight= ly broken implementations which might replicate headers.=C2=A0


Reordering shou= ldn't be a problem for us because it's easy to search through a rel= atively short list for an ARC field bearing a particular "i=3D" v= alue.=C2=A0 If the only thing that ever happens is reordering, we should st= ill be fine (a la DKIM's "h" tag).

Duplicat= ion is arguably fine as long as the duplicate is identical to the original,= but I think once you have to go so far as to evaluate that, the chain has = actually been directly affected, and it's fine to give up.

-MSK
=

--001a113eddcc1abae7054677ca99-- From nobody Thu Jan 19 11:48:11 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E7D1293DA for ; Thu, 19 Jan 2017 11:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 2rUquhQdp8JQ for ; Thu, 19 Jan 2017 11:48:08 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65875126CD8 for ; Thu, 19 Jan 2017 11:48:08 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id f9so40101166otd.1 for ; Thu, 19 Jan 2017 11:48:08 -0800 (PST) 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=WRrN7PrkVS+PZxi0jaJORG98YchCJvTurSychqjfhiU=; b=AgCSTEEZzIOWrPoHLHR4nU5uIPOAAHwK5tqSTeaiTYtdV7bROiFmK06BXj3WD+aJGN YuNzQtnvR3Lh3/jOmN+bVBPK88L48A5sEKx/iaEmlV2HVTgScv7KILv2tv1fC/5sRbWX 33wPZAy6e8oYd9uUer666fjMFvUD8KI7B93Cf70Dzth5PZhREknmebnKKve8zbMkPzX6 Kt7DoHve8ENoDAsXybn61SVrYh31RVGS+J8fmKFD1j1VpYMYy7UnQavFtDlzyFGOl1K4 zOKKaTNnvi/o/ixj+Kq0Ky9jZJ+bgre9uDXaVWbnOp7oZnrR4mX+Izekcpn6JEwrmzrG nPWg== 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=WRrN7PrkVS+PZxi0jaJORG98YchCJvTurSychqjfhiU=; b=MvHjpnPGq9KluGcvFcxTDqTGd4czJe7QRjEWgYJazXgIwG8oCWkDXfUiWNMti/9j2U v2WrUEhfJfdh1SmWQsYOONcq2rfdFVep5Ps8CGcEYguT5+A2nIP7Xb7HYwlvlfh1q2qu 5VYeI0Jn27k3LGK9YhouXdcIx0/+584Rk1iccxpX9kHvszzxVpn1rjbciGH8hkU6Y6VN jeyqplSzRSo+3uQUHwepBZznHBQcGcjjxhyIXmIzh6tKej0DZa6pLEiFDqssddoeEyfu wfFdKVVWcPafItUje3bfTzxWFYR3xxN8tPJ7824GOuwxaEJuX63JLHGQll8FuUkEtrXZ vybg== X-Gm-Message-State: AIkVDXLi3Wyv7J8YNqjKcV4avSyImoYSBwcUs/T0ntOwH1QtA9uXuxlzzU2S+UFUYxgm6imW4EgM6VFDnx7/Yg== X-Received: by 10.157.17.218 with SMTP id y26mr5788610oty.101.1484855287828; Thu, 19 Jan 2017 11:48:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.14.6 with HTTP; Thu, 19 Jan 2017 11:48:07 -0800 (PST) In-Reply-To: References: From: Gene Shuman Date: Thu, 19 Jan 2017 11:48:07 -0800 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=94eb2c1901e8f97a46054677cf77 Archived-At: Cc: "dmarc@ietf.org" , Kurt Andersen Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:48:10 -0000 --94eb2c1901e8f97a46054677cf77 Content-Type: text/plain; charset=UTF-8 Or maybe we even continue the chain with a cv=CV_Invalid, which implies that b= is empty or missing as it can't be generated. On Thu, Jan 19, 2017 at 11:46 AM, Gene Shuman wrote: > OK great, I think we're on the same page. Focusing on what good actors > should do with malformed arc sets is exactly the question. If we do want > to keep them around & continue the chain, making sure that we fail, I > still suggest the bottom up order for signing. Stripping out the malformed > arc sets and restarting the chain, possibly with something like a new > CV_Invalid is another possibility. This is an interesting idea, that I > think I like, but do we suspect we would be removing information that > somebody might find useful? > > Regards, > =Gene > > On Thu, Jan 19, 2017 at 7:32 AM, Murray S. Kucherawy > wrote: > >> On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen wrote: >> >>> >>> The intent of section 5.2.1 was never to deal with pathological cases. >>> It was to deal with somewhat broken MTAs that do stupid things like >>> reordering headers in alphabetical order or slightly broken implementations >>> which might replicate headers. >>> >>> >> Reordering shouldn't be a problem for us because it's easy to search >> through a relatively short list for an ARC field bearing a particular "i=" >> value. If the only thing that ever happens is reordering, we should still >> be fine (a la DKIM's "h" tag). >> >> Duplication is arguably fine as long as the duplicate is identical to the >> original, but I think once you have to go so far as to evaluate that, the >> chain has actually been directly affected, and it's fine to give up. >> >> -MSK >> > > --94eb2c1901e8f97a46054677cf77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Or maybe we even continue the chain with a cv=3DCV_Invalid= , which implies that b=3D is empty or missing as it can't be generated.= =C2=A0

On T= hu, Jan 19, 2017 at 11:46 AM, Gene Shuman <gene@valimail.com> wrote:
OK great, I thi= nk we're on the same page.=C2=A0 Focusing on what good actors should do= with malformed arc sets is exactly the question.=C2=A0 If we do want to ke= ep them around & continue =C2=A0the chain, making sure that we fail, I = still suggest the bottom up order for signing.=C2=A0 Stripping out the malf= ormed arc sets and restarting the chain, possibly with something like a new= CV_Invalid is another possibility.=C2=A0 This is an interesting idea, that= I think I like, but do we suspect we would be removing information that so= mebody might find useful? =C2=A0

Regards,
=3DG= ene

On Thu, Jan 19, 2017 at 7:32 AM, Murr= ay S. Kucherawy <superuser@gmail.com> wrote:
On Thu, Jan 19, 2017 at 12:55 A= M, Kurt Andersen <kurta@drkurt.com> wrote:

The intent of section 5.2.1 was never to deal with pat= hological cases. It was to deal with somewhat broken MTAs that do stupid th= ings like reordering headers in alphabetical order or slightly broken imple= mentations which might replicate headers.=C2=A0

<= /div>

Reordering shouldn't be a = problem for us because it's easy to search through a relatively short l= ist for an ARC field bearing a particular "i=3D" value.=C2=A0 If = the only thing that ever happens is reordering, we should still be fine (a = la DKIM's "h" tag).

Duplication is arguably= fine as long as the duplicate is identical to the original, but I think on= ce you have to go so far as to evaluate that, the chain has actually been d= irectly affected, and it's fine to give up.

-MSK


--94eb2c1901e8f97a46054677cf77-- From nobody Thu Jan 19 18:18:33 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23D4129408 for ; Thu, 19 Jan 2017 18:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8U4roqEdqdV for ; Thu, 19 Jan 2017 18:18:30 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045A11293E9 for ; Thu, 19 Jan 2017 18:18:29 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id 65so46382475otq.2 for ; Thu, 19 Jan 2017 18:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i4/IO64gXIg/ZWJE4niqZXcyTJ91y/7SfvFVotCYMSI=; b=FD/5TGCbV+Mqmas+fgvRaZxVMQkINR2ojNONYJB3nUHgl0uPV2Ensbxb0q/Nu35WUk TWdiYIrWQCZP2bJPgP/IEeZOj8qtYQfROF1lnTKCMJU/o30TzEzcB6pv3ckedYyJp2GG qxnYVsmzL+KaJymXDeNvWtK9gS7pQtAiNxaOg= 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=i4/IO64gXIg/ZWJE4niqZXcyTJ91y/7SfvFVotCYMSI=; b=agdZ7BDvq2PyCtfQxB4MyLEt6dYZ4TddPefaolRrAW3tQ8UL5+YTzM7WzkNnb3Ibhb EtYC6HdjtgdNXBoweR4htANZFCPIKKJHyM41yWaaqVf1YCQHFJbisfYPwbsbnNnMDYfG 3ck4hh18Tx5e5cuG2/IKW+fx8ccpJM+7QDtYAvByFtANztoZp9dDTrOTJS9RiP+a7gNq i+1zmOc627ow5/7NbH67dJhqipneRTDwWL8WF2Tbp6Rpr1Nbjvtg1gTWY49jB8lB3XKb CZvvSbjPsJ5yvGjqNOUj0drLGgDAFMQrfyBm1+sR9O4Fiy7cUoonJe8acN/a2s0dJtdx 7WAw== X-Gm-Message-State: AIkVDXKcTPcCEAyDorfxUQIBLNP5ll+cP/D9cWeEuHEMwQFpr1erOpRYKCFUAT0C8hFrm+RRXwl1uSTUeynRXg== X-Received: by 10.157.32.135 with SMTP id x7mr5550431ota.35.1484878709283; Thu, 19 Jan 2017 18:18:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.184.69 with HTTP; Thu, 19 Jan 2017 18:18:28 -0800 (PST) In-Reply-To: References: From: Kurt Andersen Date: Fri, 20 Jan 2017 07:48:28 +0530 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=94eb2c03307400770205467d44f9 Archived-At: Cc: "dmarc@ietf.org" , Gene Shuman Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 02:18:31 -0000 --94eb2c03307400770205467d44f9 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 9:02 PM, Murray S. Kucherawy wrote: > On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen wrote: > >> >> The intent of section 5.2.1 was never to deal with pathological cases. It >> was to deal with somewhat broken MTAs that do stupid things like reordering >> headers in alphabetical order or slightly broken implementations which >> might replicate headers. >> >> Duplication is arguably fine as long as the duplicate is identical to the > original, but I think once you have to go so far as to evaluate that, the > chain has actually been directly affected, and it's fine to give up. > Gene's suggestions (omitted from this due to top posting) about creating a new "invalid" CV tag value seems like a reasonable response to a badly broken (structurally) ARC chain. Since we are _a priori_ only interested in good chains I don't think that adding this creates any exploits for bad actors since a malicious intermediary can destroy/corrupt/etc an ARC chain any which way. I'm more concerned about pathologies that could be introduced in the quest to affix an ARC set with i=(previous + 1) when the "previous" value is malicious (not a number, too big a number, etc). In some sense, we almost need an "end of chain, don't waste your time any further" signal. --Kurt --94eb2c03307400770205467d44f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 19, 2017 at 9:02 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen <kurta@drkurt.= com> wrote:

The intent of section 5.2.1 was never to deal with pathological cases.= It was to deal with somewhat broken MTAs that do stupid things like reorde= ring headers in alphabetical order or slightly broken implementations which= might replicate headers.=C2=A0

Duplication is arguably fine as long as the duplicate is iden= tical to the original, but I think once you have to go so far as to evaluat= e that, the chain has actually been directly affected, and it's fine to= give up.

Gene'= s suggestions (omitted from this due to top posting) about creating a new &= quot;invalid" CV tag value seems like a reasonable response to a badly= broken (structurally) ARC chain. Since we are _a priori_ only interested i= n good chains I don't think that adding this creates any exploits for b= ad actors since a malicious intermediary can destroy/corrupt/etc an ARC cha= in any which way.

I'm more concerned about pat= hologies that could be introduced in the quest to affix an ARC set with i= =3D(previous + 1) when the "previous" value is malicious (not a n= umber, too big a number, etc). In some sense, we almost need an "end o= f chain, don't waste your time any further" signal.

=
--Kurt=C2=A0
--94eb2c03307400770205467d44f9-- From sklist@kitterman.com Fri Jan 20 11:23:52 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8BD12947D for ; Fri, 20 Jan 2017 11:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3VdNrfOcFni for ; Fri, 20 Jan 2017 11:23:51 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27589129461 for ; Fri, 20 Jan 2017 11:23:51 -0800 (PST) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7CA9DC4022B for ; Fri, 20 Jan 2017 13:23:48 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1484940228; bh=LupTXTcSdiUydYQeVVVZqrw2wpgE87oj3QkgcROvVc4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=sMv7boofekK0fROqf+Ppe4qOirTepszvA7clus3hDfWaNsMGppqGiookMdJffn3ou nFCdRGybpZ5P39tDQJzAHx94waC12ul9xmOWS8FP6oLVmnP+HJBpdvVq42LO1UXXB/ uEYQxx6eGDEeuKuWlqC9YLGxWw6PD+DbQaNPpVCg= From: Scott Kitterman To: "dmarc@ietf.org" Date: Fri, 20 Jan 2017 14:23:48 -0500 Message-ID: <10036332.AbsS0sHdB9@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-106-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" Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 19:23:53 -0000 On Friday, January 20, 2017 07:48:28 AM Kurt Andersen wrote: > On Thu, Jan 19, 2017 at 9:02 PM, Murray S. Kucherawy > > wrote: > > On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen wrote: > >> The intent of section 5.2.1 was never to deal with pathological cases. It > >> was to deal with somewhat broken MTAs that do stupid things like > >> reordering > >> headers in alphabetical order or slightly broken implementations which > >> might replicate headers. > >> > >> Duplication is arguably fine as long as the duplicate is identical to the > > > > original, but I think once you have to go so far as to evaluate that, the > > chain has actually been directly affected, and it's fine to give up. > > Gene's suggestions (omitted from this due to top posting) about creating a > new "invalid" CV tag value seems like a reasonable response to a badly > broken (structurally) ARC chain. Since we are _a priori_ only interested in > good chains I don't think that adding this creates any exploits for bad > actors since a malicious intermediary can destroy/corrupt/etc an ARC chain > any which way. > > I'm more concerned about pathologies that could be introduced in the quest > to affix an ARC set with i=(previous + 1) when the "previous" value is > malicious (not a number, too big a number, etc). In some sense, we almost > need an "end of chain, don't waste your time any further" signal. I'm not on the ARC list, so I'll pile on this thread here... I understand the minimum key size in the draft is 512 bits. I'm not planning on releasing any software that supports key sizes less than 1024, so I guarantee you interoperability problems for small keys. For those that may have forgotten, I'll pass on a reminder of how well 512 bit keys work even half a decade ago: https://www.wired.com/2012/10/dkim-vulnerability-widespread/ Scott K From nobody Fri Jan 20 11:46:29 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60C21270B4 for ; Fri, 20 Jan 2017 11:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 t5ofbbBtOtFk for ; Fri, 20 Jan 2017 11:46:25 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E19126D74 for ; Fri, 20 Jan 2017 11:46:24 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id 65so63050828otq.2 for ; Fri, 20 Jan 2017 11:46:24 -0800 (PST) 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=J5WEdvNxHHK/8VwraQg2lAYSImVFZNWfJpfgCobFDPM=; b=TaZkHoVmkP1yg3LNOrMz3zdxllDKk4/pQ9p9ihhv0LtSOGBLHQYjT1mdkgYLcMmA39 mLfq9pmSNW5tcl6gRUK2gB9lx6ZJ1TSk9JPXp4UTYSoJjSjJgc1K9I2b1njo7CGTThbB cgqmca4hkVn7oFsWq3aUxGdN7LtHx1ks3K+BYYPXUiYfN/5jO1RVdE3W/mzD5e9wUhlY uMm93MQ04X1kVChFbWLPqPLxhwyLCBopujf94JpAc+9WEG1zaiVAlukDhd0j0tQRQEow 0omIFQRVA5X0ziK0f3luZ4ub8u4EXkCbqySsi6b4QVE/GhJSE514nZHIPFghV6u5QS2r rTPg== 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=J5WEdvNxHHK/8VwraQg2lAYSImVFZNWfJpfgCobFDPM=; b=pZMhv5vgHgJ1SnTCb81+IYMNjos+/OssehCAszOyayesP37ETqKGkjc40meDUp4tAN a2O0wSU7FVvXykXo1Uip+9e2NDD1R1NARnpQqG6UXUIeoJW20GfFfj5oocm/oMTZxixY 7zwbaxLyAUezae4U6GN+5EidskfySCDhZvjZAe5sEoJnSnOnllUdKypdJJLTXrA/XIR/ a6Y5FSWcWZ5ZBqFPa2oljJAipsf1Jz5dcxMHLC2CyXHDeBKwvDqzRLN5J0tK7mJ6j/Uw KYkkpttYcS8bBN/Bu7X5Nqk8NU+msICObTQwK5YiHlFLNLqauFcvOt6yQmKbyLQgBjq+ T/kg== X-Gm-Message-State: AIkVDXKaL51zZXHm/2I3aZSEZrMp964suQ+Kzrf7EDshLVd318FgfnTSO8bIr18r6cbVWxgAPtDHLKij13l3Aw== X-Received: by 10.157.17.218 with SMTP id y26mr8703925oty.101.1484941583926; Fri, 20 Jan 2017 11:46:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.14.6 with HTTP; Fri, 20 Jan 2017 11:46:23 -0800 (PST) In-Reply-To: <10036332.AbsS0sHdB9@kitterma-e6430> References: <10036332.AbsS0sHdB9@kitterma-e6430> From: Gene Shuman Date: Fri, 20 Jan 2017 11:46:23 -0800 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=94eb2c1901e89f68ee05468be72a Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 19:46:28 -0000 --94eb2c1901e89f68ee05468be72a Content-Type: text/plain; charset=UTF-8 Kurt, I think terminating the chain with a cv=invalid is a good approach. The general idea being that if there is any seal found with cv=invalid then validation fails & we don't continue the chain. When a good intermediary finds an invalid chain, a seal is affixed(no need for AMS, or AAR), with the cv=invalid value. Im assuming we no longer require the a,b,d,s tags at this point, as they're irrelevant. Or do we even want to consider having a 4th type of header field(ARC-ChainInvalid?), possibly with identifying or failure information, just so were not modifying AS too much? Are there any security concerns with either of these approaches that need to addressed? An open question then is what constitutes an invalid set. I would suggest that only the cases of duplicated or malformed/invalid i= values are invalid sets. Missing/incomplete sets fail, and mis-ordered sets are handled normally. +++1 wrt Scott's comment about 512 bit keys. We inherit this requirement from the DKIM spec, but imho it is not reasonable. If this is worth discussing, perhaps we should move it to another thread? Regards, =Gene On Fri, Jan 20, 2017 at 11:23 AM, Scott Kitterman wrote: > On Friday, January 20, 2017 07:48:28 AM Kurt Andersen wrote: > > On Thu, Jan 19, 2017 at 9:02 PM, Murray S. Kucherawy < > superuser@gmail.com> > > > > wrote: > > > On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen > wrote: > > >> The intent of section 5.2.1 was never to deal with pathological > cases. It > > >> was to deal with somewhat broken MTAs that do stupid things like > > >> reordering > > >> headers in alphabetical order or slightly broken implementations which > > >> might replicate headers. > > >> > > >> Duplication is arguably fine as long as the duplicate is identical to > the > > > > > > original, but I think once you have to go so far as to evaluate that, > the > > > chain has actually been directly affected, and it's fine to give up. > > > > Gene's suggestions (omitted from this due to top posting) about creating > a > > new "invalid" CV tag value seems like a reasonable response to a badly > > broken (structurally) ARC chain. Since we are _a priori_ only interested > in > > good chains I don't think that adding this creates any exploits for bad > > actors since a malicious intermediary can destroy/corrupt/etc an ARC > chain > > any which way. > > > > I'm more concerned about pathologies that could be introduced in the > quest > > to affix an ARC set with i=(previous + 1) when the "previous" value is > > malicious (not a number, too big a number, etc). In some sense, we almost > > need an "end of chain, don't waste your time any further" signal. > > I'm not on the ARC list, so I'll pile on this thread here... > > I understand the minimum key size in the draft is 512 bits. I'm not > planning > on releasing any software that supports key sizes less than 1024, so I > guarantee you interoperability problems for small keys. > > For those that may have forgotten, I'll pass on a reminder of how well 512 > bit > keys work even half a decade ago: > > https://www.wired.com/2012/10/dkim-vulnerability-widespread/ > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --94eb2c1901e89f68ee05468be72a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kurt, I think terminating the chain with a cv=3Dinvalid is= a good approach.=C2=A0 The general idea being that if there is any seal fo= und with cv=3Dinvalid then validation fails & we don't continue the= chain.=C2=A0 When a good intermediary finds an invalid chain, a seal is af= fixed(no need for AMS, or AAR), with the cv=3Dinvalid value.=C2=A0 Im assum= ing we no longer require the a,b,d,s tags at this point, as they're irr= elevant.=C2=A0 Or do we even want to consider having a 4th type of header f= ield(ARC-ChainInvalid?), possibly with identifying or failure information, = just so were not modifying AS too much? Are there any security concerns wit= h either of these approaches that need to addressed?

An = open question then is what constitutes an invalid set.=C2=A0 I would sugges= t that only the cases of duplicated or malformed/invalid i=3D values are in= valid sets.=C2=A0 Missing/incomplete sets fail, and mis-ordered sets are ha= ndled normally.

+++1 wrt Scott's comment about= 512 bit keys.=C2=A0 We inherit this requirement from the DKIM spec, but im= ho it is not reasonable.=C2=A0 If this is worth discussing, perhaps we shou= ld move it to another thread?

Regards,
= =3DGene

On Fri, Jan 20, 2017 at 11:23 AM, Scott Kitterman <<= a href=3D"mailto:sklist@kitterman.com" target=3D"_blank">sklist@kitterman.c= om> wrote:
On Friday, January 20, 2017 07:48:28 AM Kurt Andersen wrote:
> On Thu, Jan 19, 2017 at 9:02 PM, Murray S. Kucherawy <superuser@gmail.com>
>
> wrote:
> > On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen <kurta@drkurt.com> wrote:
> >> The intent of section 5.2.1 was never to deal with pathologic= al cases. It
> >> was to deal with somewhat broken MTAs that do stupid things l= ike
> >> reordering
> >> headers in alphabetical order or slightly broken implementati= ons which
> >> might replicate headers.
> >>
> >> Duplication is arguably fine as long as the duplicate is iden= tical to the
> >
> > original, but I think once you have to go so far as to evaluate t= hat, the
> > chain has actually been directly affected, and it's fine to g= ive up.
>
> Gene's suggestions (omitted from this due to top posting) about cr= eating a
> new "invalid" CV tag value seems like a reasonable response = to a badly
> broken (structurally) ARC chain. Since we are _a priori_ only interest= ed in
> good chains I don't think that adding this creates any exploits fo= r bad
> actors since a malicious intermediary can destroy/corrupt/etc an ARC c= hain
> any which way.
>
> I'm more concerned about pathologies that could be introduced in t= he quest
> to affix an ARC set with i=3D(previous + 1) when the "previous&qu= ot; value is
> malicious (not a number, too big a number, etc). In some sense, we alm= ost
> need an "end of chain, don't waste your time any further"= ; signal.

I'm not on the ARC list, so I'll pile on this thread here...=

I understand the minimum key size in the draft is 512 bits.=C2=A0 I'm n= ot planning
on releasing any software that supports key sizes less than 1024, so I
guarantee you interoperability problems for small keys.

For those that may have forgotten, I'll pass on a reminder of how well = 512 bit
keys work even half a decade ago:

https://www.wired.com/2012/10/dkim-= vulnerability-widespread/

Scott K

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

--94eb2c1901e89f68ee05468be72a-- From nobody Fri Jan 20 11:58:22 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9C31270B4 for ; Fri, 20 Jan 2017 11:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulbJsCXlAJfj for ; Fri, 20 Jan 2017 11:58:18 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DD6126D74 for ; Fri, 20 Jan 2017 11:58:18 -0800 (PST) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id v0KJw6nj024758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 20 Jan 2017 11:58:11 -0800 (PST) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com v0KJw6nj024758 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1484942292; bh=n9DkSsNwjKbibqaX9nC/2u1eKRbHHLPCbzqQ2sBTgqI=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pnScxBrifA3phhxR94/Tc7mK3rAft1t1pCLxeVMQ2uyoREQmSRwFbxttE9r4RVFph HyowTrvnBibX0abNpIC3qqipWUZEOkIBaC4Ealuef7uW1QPPQJRpheo+2bIfWAr5sI VHrebUk/kiBVtSTI/rgz4X/X2gRDUztTayzEnS0/zXl0d975P9fbz0ghlW4BhC14Qh 68f2tuPeyGQdWyPCvqnPs1j23njWfkSTT1bKeLU5nO5z/XSq83fkFqVrPZIN9aqG+1 gf9iT9nsPvOYGzw5cwcOTqJtUCVyI1Rt9vIDMh+zf2b0PlZPgKtGl1gzvhJjWUcB5M esScb+56HDTsw== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] To: dmarc@ietf.org References: <10036332.AbsS0sHdB9@kitterma-e6430> From: Steven M Jones Organization: Crash Computing Message-ID: <67d2c039-d05f-3ad8-fbd1-fa5be92b5800@crash.com> Date: Fri, 20 Jan 2017 11:58:08 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <10036332.AbsS0sHdB9@kitterma-e6430> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Fri, 20 Jan 2017 11:58:12 -0800 (PST) Archived-At: Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 19:58:20 -0000 On 01/20/2017 11:23, Scott Kitterman wrote: > > I'm not on the ARC list, so I'll pile on this thread here... This is the right place for anything constructive regarding the specification, so no problem regarding any other lists. > I understand the minimum key size in the draft is 512 bits. I'm not pl= anning=20 > on releasing any software that supports key sizes less than 1024, so I = > guarantee you interoperability problems for small keys. +1 -- no need for weak keys. 1) Do we have a normative reference within the RFC framework for key lengths for different crypto systems, and can we simply invoke that reference rather than including a hard figure in this spec? 2) Does such a reference still consider 1k keys as acceptable at this time? Is there a schedule for periodic review? --S. From nobody Fri Jan 20 12:31:02 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB17129444 for ; Fri, 20 Jan 2017 12:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moHB-Q03MWo8 for ; Fri, 20 Jan 2017 12:30:59 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC65B129440 for ; Fri, 20 Jan 2017 12:30:59 -0800 (PST) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 50246C401DD for ; Fri, 20 Jan 2017 14:30:58 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1484944258; bh=sAfeHKYyIzr0c+nFesELEbhkdC8LZWKIe+Gnd2rBgDc=; h=From:To:Subject:Date:From; b=NiFfmz2R0Vc6pD91thV/jL5HWiSlLfGG+iQSoXwkQajzjzCAgmsOW9pSdoMci6oN+ p6TC1FXo6NbvjWX1MaiJ7LG6WyNpozR5za6Nh6x8GeP8jPL2kz86vml5PLyWPzGWTq f3Aq3QBXcawP3pd5I/SCDkzC1YKYyS6lx6EyIGgU= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 20 Jan 2017 15:30:58 -0500 Message-ID: <6039311.QYNoohHPCE@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-106-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] ARC Minimum Key Sizes X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 20:31:01 -0000 On Friday, January 20, 2017 you wrote: > On 01/20/2017 11:23, Scott Kitterman wrote: > > I'm not on the ARC list, so I'll pile on this thread here... > > This is the right place for anything constructive regarding the > specification, so no problem regarding any other lists. > > > I understand the minimum key size in the draft is 512 bits. I'm not > > planning > > on releasing any software that supports key sizes less than 1024, so I > > guarantee you interoperability problems for small keys. > > +1 -- no need for weak keys. > > 1) Do we have a normative reference within the RFC framework for key > lengths for different crypto systems, and can we simply invoke that > reference rather than including a hard figure in this spec? > > 2) Does such a reference still consider 1k keys as acceptable at this > time? Is there a schedule for periodic review? > > --S. > +++1 wrt Scott's comment about 512 bit keys. We inherit this requirement > from the DKIM spec, but imho it is not reasonable. If this is worth > discussing, perhaps we should move it to another thread? > > Regards, > =Gene OK, Since I wasn't off topic after all, here's a new thread... I believe we've looked for such a reference before and not found a good one. The IETF BCP is from 2004: https://tools.ietf.org/html/rfc3766 Operationally, 1024 is the minimum key size recommendation I generally see for DKIM today. NIST recommends 2048 bits, SHA-256 only for US goverment use [1]. Scott K [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177.pdf From nobody Fri Jan 20 14:17:29 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FE11294D2 for ; Fri, 20 Jan 2017 14:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 3Ll_jhTeyE5Q for ; Fri, 20 Jan 2017 14:17:26 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE291294C5 for ; Fri, 20 Jan 2017 14:17:25 -0800 (PST) Received: (qmail 17941 invoked from network); 20 Jan 2017 22:17:25 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 20 Jan 2017 22:17:25 -0000 Date: 20 Jan 2017 22:17:02 -0000 Message-ID: <20170120221702.42527.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <67d2c039-d05f-3ad8-fbd1-fa5be92b5800@crash.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: smj@crash.com Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 22:17:27 -0000 >1) Do we have a normative reference within the RFC framework for key >lengths for different crypto systems, and can we simply invoke that >reference rather than including a hard figure in this spec? There's RFC 3766, but it's over a decade old and has rules for how to figure out how long a key you need, not the actual sizes. This NIST publication seems relevant: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf The tables on pages 52 and 53 suggest that we use 2K keys and sha256 hashes. >2) Does such a reference still consider 1k keys as acceptable at this >time? Is there a schedule for periodic review? No. See the document. R's, John From nobody Fri Jan 20 15:41:35 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFBE1295EF for ; Fri, 20 Jan 2017 15:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 837fNuENM5qD for ; Fri, 20 Jan 2017 15:41:32 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383881295ED for ; Fri, 20 Jan 2017 15:41:32 -0800 (PST) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7916DC401DD for ; Fri, 20 Jan 2017 17:41:30 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1484955690; bh=u73QCEs2OM4u1F2fUdUnpfKqW6aXQ6PozJc+/jqJxPQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=unZ3G5fWgA22ANXgaNtD0TN3IuGqDXF4OxjlqnAi9Te8iZ93r0eHBem+EB/FTsYBw BoJGnKz863guKIeROjwa5SkAwXYOxDqUs8HCe3l9SHAPZXjYjyqK2hTRdfl+tCvM7Z 8DR8GL6U1rhjKnY4cGofuPMd9R/sGwL12DcT6r34= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 20 Jan 2017 18:41:30 -0500 Message-ID: <13626399.50m8abrgpf@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-106-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <6039311.QYNoohHPCE@kitterma-e6430> References: <6039311.QYNoohHPCE@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] ARC Minimum Key Sizes X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 23:41:34 -0000 On Friday, January 20, 2017 03:30:58 PM Scott Kitterman wrote: > On Friday, January 20, 2017 you wrote: > > On 01/20/2017 11:23, Scott Kitterman wrote: > > > I'm not on the ARC list, so I'll pile on this thread here... > > > > This is the right place for anything constructive regarding the > > specification, so no problem regarding any other lists. > > > > > I understand the minimum key size in the draft is 512 bits. I'm not > > > planning > > > on releasing any software that supports key sizes less than 1024, so I > > > guarantee you interoperability problems for small keys. > > > > +1 -- no need for weak keys. > > > > 1) Do we have a normative reference within the RFC framework for key > > lengths for different crypto systems, and can we simply invoke that > > reference rather than including a hard figure in this spec? > > > > 2) Does such a reference still consider 1k keys as acceptable at this > > time? Is there a schedule for periodic review? > > > > --S. > > > > +++1 wrt Scott's comment about 512 bit keys. We inherit this requirement > > from the DKIM spec, but imho it is not reasonable. If this is worth > > discussing, perhaps we should move it to another thread? > > > > Regards, > > =Gene > > OK, Since I wasn't off topic after all, here's a new thread... > > I believe we've looked for such a reference before and not found a good one. > The IETF BCP is from 2004: https://tools.ietf.org/html/rfc3766 > > Operationally, 1024 is the minimum key size recommendation I generally see > for DKIM today. NIST recommends 2048 bits, SHA-256 only for US goverment > use [1]. > > > Scott K > [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177.pdf Moving John Levine's reply into this thread and then replying further: On Friday, January 20, 2017 10:17:02 PM John Levine wrote: > >1) Do we have a normative reference within the RFC framework for key > >lengths for different crypto systems, and can we simply invoke that > >reference rather than including a hard figure in this spec? > > There's RFC 3766, but it's over a decade old and has rules for how to > figure out how long a key you need, not the actual sizes. > > This NIST publication seems relevant: > > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf > > The tables on pages 52 and 53 suggest that we use 2K keys and sha256 hashes. > >2) Does such a reference still consider 1k keys as acceptable at this > >time? Is there a schedule for periodic review? > > No. See the document. > > R's, > John Large keys like 2048 present other potential operational problems. Here's a 2048 bit, sha-256 key record: default._domainkey IN TXT ( "v=DKIM1; h=sha-256; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5nzBQiwX1l4QDoE1glqw+93aMMp9hVVg8KYP3z43GTNScXda0mLAPoScWc1EHnm37TCdWj57F0CYjZhvsX0EnkRpibYCEX/AZ2xLmwE7XcMXWWYjlUCK/BfFhuCUOEDbokjRCJ/ULbVUZfC8I8QZFdhqno987m26UhayLT3iNboj+v4mqUdYkVg6FmNRZRdDhxJYDSosT9j2Y" "2eaSVsQ5Pvyt2ZzOjHJ9eXujw6/DKR2WGVEIIX+3sKqeH7tDbeXulzv102HP1fmoE6sKgPRevIHKoMfFagNyXXkqxmyRY/jV+yZGGz7RZEpNApv7pyBtfG0bz7cTwVX4QvP/8MUQIDAQAB" ) I'm sure that will get line wrapped into illegibility, so I'll make the actual point: It's longer than will fit in a single TXT string. While there is nothing wrong with that from a DNS standards or even a core DNS operational perspective, it is not rare that DNS provisioning systems don't support this. I don't want to make it so secure it's deployability is severely hampered. I would suggest MUST at least 1024 bit, SHOULD 2048 bits. I think MUST sha-256 is also a good idea. Approximately the last thing we should be doing now is rolling out new protocols using sha-1. Scott K From nobody Fri Jan 20 16:08:38 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C1D129619 for ; Fri, 20 Jan 2017 16:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 YzcjSUCJiAOF for ; Fri, 20 Jan 2017 16:08:34 -0800 (PST) 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 5C357129613 for ; Fri, 20 Jan 2017 16:08:34 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id j126so6377324qkf.1 for ; Fri, 20 Jan 2017 16:08:34 -0800 (PST) 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=fndUKq7TL/RA5jZdIYh2ZE26KLXsecWJUt3SktCKDDQ=; b=U1XYojbZoPzaf0Uz50OgtOo395QsMGGvPyWhPzXwF5z2SS3GrZ6aX/D9dxqZ/rTHU8 hgPWaPJsVjJTdEQ8VuLjlpOxcF0qgmDxcU+7pDL6+BAlB815onhh9kFg/9fCO6UhHymb TsRG5lkWtOnDXY9nD8jdsl50L9oR6A6jJ6KDpXDsgM7eKonxOYaCN7tTsAzAzMUd+H4H bw421CWIaKzwnaXMJqOQih8Keq25b1AY4agU5Wthe1tlInrFRFw7lxRvo4igZsoAo7Ce PwO9RhjBs44UTzu6gwk8PSCJSVRA4raLJx8Pobd8GlZpBJ6I6y2Z0RsvgB0835MKXyI9 3rLQ== 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=fndUKq7TL/RA5jZdIYh2ZE26KLXsecWJUt3SktCKDDQ=; b=p7MDAU34E85BINMk+EeBbinYawZqOtS92H4L4SCyWmtpnhgj+TbcIe0mxanAt0BUA9 MMDfII9grU1ph+rtXVgshha7Wlme3cS7fRZneF7EIQkicu1t+Ri33Atihgera4DH4Vls Gn3kC7AJMM9ZpDfIMdtISg/hrZe+//PQjI+/LrXEjGg7aGkaXcGFWV2Ybmc7Vz/lBVaX gJulkn38ESCfVTEVWXPa7I/6qOqKj7VjbSk+7RWfoR6UtCBAcvEcClJlCGxNAzZYEfgI 72BTxcphCdG9cInyqipEBNAFsGq1jHDN/NiZu2Nbht7Qm2iJQASa66gIfB101bwOs33t bC0A== X-Gm-Message-State: AIkVDXKefi0zIaFxvGEks1mDgsH0jqDgqzP4UcBI8zi+4iCfF+7V/59xYGCtLeqz0DHMrT2fIcsO9rgU7TPt6w== X-Received: by 10.200.55.5 with SMTP id o5mr14361088qtb.248.1484957313367; Fri, 20 Jan 2017 16:08:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.129.247 with HTTP; Fri, 20 Jan 2017 16:08:32 -0800 (PST) In-Reply-To: <13626399.50m8abrgpf@kitterma-e6430> References: <6039311.QYNoohHPCE@kitterma-e6430> <13626399.50m8abrgpf@kitterma-e6430> From: Peter Goldstein Date: Fri, 20 Jan 2017 16:08:32 -0800 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a1140a8262b96cd05468f9172 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] ARC Minimum Key Sizes X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 00:08:37 -0000 --001a1140a8262b96cd05468f9172 Content-Type: text/plain; charset=UTF-8 I think Scott's point about operational options is well taken. Google ran into some operational issues with some DNS vendors when they attempted to make all new G Suite DKIM keys 2048 - they rolled back to making 2048 bit keys the default, but allowing 1024 bit keys as an option. The MUST/SHOULD language suggested makes sense. And we definitely don't need to roll out new protocols using SHA-1. I would suggest some related language for verifiers. Something like what's found in the DKIM spec, but with updated bit sizes: Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits, and they MAY be able to validate signatures with larger keys. At a minimum I think we should require verifiers to be able to support 4096 bit keys (and potentially 8192 bit). There's no reason verifiers shouldn't be able to support longer key sizes, and this adds some future proofing to the specification. Best, Peter On Fri, Jan 20, 2017 at 3:41 PM, Scott Kitterman wrote: > On Friday, January 20, 2017 03:30:58 PM Scott Kitterman wrote: > > On Friday, January 20, 2017 you wrote: > > > On 01/20/2017 11:23, Scott Kitterman wrote: > > > > I'm not on the ARC list, so I'll pile on this thread here... > > > > > > This is the right place for anything constructive regarding the > > > specification, so no problem regarding any other lists. > > > > > > > I understand the minimum key size in the draft is 512 bits. I'm not > > > > planning > > > > on releasing any software that supports key sizes less than 1024, so > I > > > > guarantee you interoperability problems for small keys. > > > > > > +1 -- no need for weak keys. > > > > > > 1) Do we have a normative reference within the RFC framework for key > > > lengths for different crypto systems, and can we simply invoke that > > > reference rather than including a hard figure in this spec? > > > > > > 2) Does such a reference still consider 1k keys as acceptable at this > > > time? Is there a schedule for periodic review? > > > > > > --S. > > > > > > +++1 wrt Scott's comment about 512 bit keys. We inherit this > requirement > > > from the DKIM spec, but imho it is not reasonable. If this is worth > > > discussing, perhaps we should move it to another thread? > > > > > > Regards, > > > =Gene > > > > OK, Since I wasn't off topic after all, here's a new thread... > > > > I believe we've looked for such a reference before and not found a good > one. > > The IETF BCP is from 2004: https://tools.ietf.org/html/rfc3766 > > > > Operationally, 1024 is the minimum key size recommendation I generally > see > > for DKIM today. NIST recommends 2048 bits, SHA-256 only for US goverment > > use [1]. > > > > > > Scott K > > [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ > NIST.SP.800-177.pdf > > Moving John Levine's reply into this thread and then replying further: > > On Friday, January 20, 2017 10:17:02 PM John Levine wrote: > > >1) Do we have a normative reference within the RFC framework for key > > >lengths for different crypto systems, and can we simply invoke that > > >reference rather than including a hard figure in this spec? > > > > There's RFC 3766, but it's over a decade old and has rules for how to > > figure out how long a key you need, not the actual sizes. > > > > This NIST publication seems relevant: > > > > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ > NIST.SP.800-57pt1r4.pdf > > > > The tables on pages 52 and 53 suggest that we use 2K keys and sha256 > hashes. > > >2) Does such a reference still consider 1k keys as acceptable at this > > >time? Is there a schedule for periodic review? > > > > No. See the document. > > > > R's, > > John > > Large keys like 2048 present other potential operational problems. Here's > a > 2048 bit, sha-256 key record: > > default._domainkey IN TXT ( "v=DKIM1; h=sha-256; k=rsa; " > "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5nzBQiwX1l4QDoE > 1glqw+93aMMp9hVVg8KYP3z43GTNScXda0mLAPoScWc1EHnm37TCdWj57F0CYjZhvs > X0EnkRpibYCEX/AZ2xLmwE7XcMXWWYjlUCK/BfFhuCUOEDbokjRCJ/ > ULbVUZfC8I8QZFdhqno987m26UhayLT3iNboj+v4mqUdYkVg6FmNRZRdDhxJYDSosT9j2Y" > "2eaSVsQ5Pvyt2ZzOjHJ9eXujw6/DKR2WGVEIIX+ > 3sKqeH7tDbeXulzv102HP1fmoE6sKgPRevIHKoMfFagNyXXkqxmyRY/jV+ > yZGGz7RZEpNApv7pyBtfG0bz7cTwVX4QvP/8MUQIDAQAB" > ) > > I'm sure that will get line wrapped into illegibility, so I'll make the > actual > point: It's longer than will fit in a single TXT string. While there is > nothing wrong with that from a DNS standards or even a core DNS operational > perspective, it is not rare that DNS provisioning systems don't support > this. > I don't want to make it so secure it's deployability is severely hampered. > > I would suggest MUST at least 1024 bit, SHOULD 2048 bits. I think MUST > sha-256 is also a good idea. Approximately the last thing we should be > doing > now is rolling out new protocols using sha-1. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a1140a8262b96cd05468f9172 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think Scott's point about operational options is wel= l taken.=C2=A0 Google ran into some operational issues with some DNS vendor= s when they attempted to make all new G Suite DKIM keys 2048 - they rolled = back to making 2048 bit keys the default, but allowing 1024 bit keys as an = option.

The MUST/SHOULD language=C2=A0suggested makes sense.=C2=A0 An= d we definitely don't need to roll out new protocols using SHA-1.

I wo= uld suggest some related language for verifiers.=C2=A0 Something like what&= #39;s found in the DKIM spec, but with updated bit sizes:

Verifiers MUST be able to validat=
e signatures with
   keys ranging from 1024 bits to 4096 bits, and they MAY be able to
   validate signatures with larger keys.
At a minimum I think we should require veri= fiers to be able to support 4096 bit keys (and potentially 8192 bit).=C2=A0= There's no reason verifiers shouldn't be able to support longer ke= y sizes, and this adds some future proofing to the specification.

Best,

Peter
 --f403045e34b45faef10546b5d24f-- From nobody Sun Jan 22 13:48:33 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A643F1293E1 for ; Sun, 22 Jan 2017 13:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfVwvBDzN8c5 for ; Sun, 22 Jan 2017 13:48:29 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32081293DC for ; Sun, 22 Jan 2017 13:48:29 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id 104so90565417otd.3 for ; Sun, 22 Jan 2017 13:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=foXV8+yMqgLQUpfQsHurORilgq3pQdYdvM8tFcJH98A=; b=PBa+4ye09qY4UQqMe0YuBzcOUZTWxVROxmFffIW1qzK34RQwAKR3whp8pHJSj4N5+g 53ipECyd/+CHOHeIM/7XN3Ap27x+nTDup6Y+HKkjdB1+73uD58lzM5aJjWQYjNmpiT0X M+YWcKH9MkgasbkcShEAi2QaAj53VqTcFZ/p4= 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=foXV8+yMqgLQUpfQsHurORilgq3pQdYdvM8tFcJH98A=; b=TSBicjgv4hHAFQY0HElSz+i1ef1NJNrvPGXUlWRON4QFDYgBdPSdKC47i4/SU1ovd8 AlfmL2e+y7yJBEWlMMpRdnVu0kjJlLxoHxTVGJyh0m4J59MxMjDpSL0EFE1tpjCJOlYk ndBkYGNJZ7zD8DEvLbiTvHMuRnwrgi6L/vdnPHSmbXjH+13uhBRFj8T68sF/2G2xCRz7 fmxiCs9l8X+xHqM+zXZeg4WLJWoXLmlCh6cefK5izuhKDEteV5yfRxA1ANKJtsXkRFRq BLs6a+/5L9m5nBLAtEB3lILhs2alPltSnFpqWTOso/aG24I/6/vg1ykE+//mx8ksxy8h l5XA== X-Gm-Message-State: AIkVDXKpaoAI6hUW7xTAatLB5wKBNrdoRsGBvohkkmRfoGB/MNFKOkFAL8FMyke7u91UBGghqLYHIjM6hKx1DQ== X-Received: by 10.157.63.188 with SMTP id r57mr11406164otc.78.1485121709009; Sun, 22 Jan 2017 13:48:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.184.69 with HTTP; Sun, 22 Jan 2017 13:48:28 -0800 (PST) In-Reply-To: <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> References: <10036332.AbsS0sHdB9@kitterma-e6430> <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> From: Kurt Andersen Date: Sun, 22 Jan 2017 13:48:28 -0800 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11459e14ea03410546b5d713 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 21:48:31 -0000 --001a11459e14ea03410546b5d713 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 22, 2017 at 1:18 PM, Scott Kitterman wrote: > > On January 22, 2017 3:30:14 PM EST, Kurt Andersen > wrote: > >On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein > >wrote: > > > >> > >> . . . ARC . . . inherits . . . from the DKIM RFC. The DKIM RFC > >explicitly > >> requires verifiers to validate signatures with bit sizes ranging from > >512 > >> bits to 2048 bits. > >> > >> There is a separate effort going on in the context of the UTA working > >group to address technologically obsolete encryption strength > >recommendations that have appeared over time in a variety of different > >RFCs. I don't think that adding yet another independent reference is a > >good > >idea and I am strongly opposed to trying to torque the ARC requirements > >to > >be different from DKIM. > > > >If Scott is planning to make dkimpy non-conformant to the DKIM spec, I > >think that is regrettable, but I don't see that making the problem > >worse with ARC "going its own way" helps anyone. > > > >--Kurt > > No responsible operator has used the RFC minimum DKIM key sizes for a long > time. They were trivial to bypass half a decade ago. No one has ever > complained about 1024 bits default minimum being too big. I did once get a > complaint about the Debian opendkim package suggesting the minimum should > be 2048 bits. > > Maybe some other working group will accomplish something someday is not a > good reason to perpetuate obsolete crypto in this one. > > Scott K I agree with your points, but don't you think it would be better to "fix" the DKIM spec than to have ARC "do its own thing" which does not address the weakness still enshrined in the DKIM spec? --Kurt --001a11459e14ea03410546b5d713 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jan 22, 2017 at 1:18 PM, Scott Kitterman <sklist@kitterman.com= > wrote:

On January 22, 2017 3:30:14 PM EST, Kurt Andersen <kurta@drkurt.com> wrote:
>On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein <peter@valimail.com>
>wrote:
>
>>
>> . . . ARC . . . inherits . . . from the DKIM RFC.=C2=A0 The DKIM R= FC
>explicitly
>> requires verifiers to validate signatures with bit sizes ranging f= rom
>512
>> bits to 2048 bits.
>>
>> There is a separate effort going on in the context of the UTA work= ing
>group to address technologically obsolete encryption strength
>recommendations that have appeared over time in a variety of different<= br> >RFCs. I don't think that adding yet another independent reference i= s a
>good
>idea and I am strongly opposed to trying to torque the ARC requirements=
>to
>be different from DKIM.
>
>If Scott is planning to make dkimpy non-conformant to the DKIM spec, I<= br> >think that is regrettable, but I don't see that making the problem<= br> >worse with ARC "going its own way" helps anyone.
>
>--Kurt

No responsible operator has used the RFC minimum DKIM key sizes= for a long time. They were trivial to bypass half a decade ago.=C2=A0 No o= ne has ever complained about 1024 bits default minimum being too big.=C2=A0= I did once get a complaint about the Debian opendkim package suggesting th= e minimum should be 2048 bits.

Maybe some other working group will accomplish something someday is not a g= ood reason to perpetuate obsolete crypto in this one.

Scott K

I agree with your points, but don't you think it would be= better to "fix" the DKIM spec than to have ARC "do its own = thing" which does not address the weakness still enshrined in the DKIM= spec?

--Kurt=C2=A0
--001a11459e14ea03410546b5d713-- From nobody Sun Jan 22 14:25:49 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEAB129A57 for ; Sun, 22 Jan 2017 14:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 peYFZA7qy0Ty for ; Sun, 22 Jan 2017 14:25:46 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C4B129A42 for ; Sun, 22 Jan 2017 14:25:46 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id l7so94978021qtd.1 for ; Sun, 22 Jan 2017 14:25:46 -0800 (PST) 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=UFwvoOun92HhZqAPo9fph0FtMDYApdbXV9CzYCji+7M=; b=D1DFp+ENlq3o/SnNdaXXZlh5XOBaR3ZfJVz8PMOxT2/r0Un5NIJfqFtOYjme0CbzUR 9D2pnLLu0gUOl0LBljzi7GJuifyx4skwl5p89Vn6KeQUX1ppZ1EOOzPom989FmpI8Upy 2EvOKLoHTX+VxCrUut7wUrojvrvSxTZOmhVX6qCwgSk4/3rj1P6oZFO4xj38W3SZBBI0 bV7HCo9u93XiGIu7gljOD97VFBHIW4tvea7ytcLczTe0L8N/p43NB8XSzkbZsLQQYIX6 dhidp0iP1I3NlLe07uavL6Yz4C7sN5wiSBz21CX/huReznz2dvWgB0Yh5nbA8qgcFM6E wBgQ== 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=UFwvoOun92HhZqAPo9fph0FtMDYApdbXV9CzYCji+7M=; b=fURU7ycxKWJZKyco6KPTdXTJiOU95GWtFAcnNvd5fh6qO5MRVlHkrqxkVOXvwap3YZ fla2/PuhGw+Z71LWVBFhanTTqLk8xeBMkVd/D7svaHBfvRKoFOHXWepc9DsoDrx4CbSs giRHLgw3SZ0oa9sP6zUKl5ntcHq89t+ZH8J0FYTtXnPmDfq5J9qGZgkhmuPXRI5L93VF A6c0oOmq2VhAKbjzuVMN2ay3tc+JYEbNrCYjmUR8ccLxtU5rYd9iGpy+PWm6IkCvRm23 JsGab0BT8U/13HnGj903Vqmvo4hivzx/og3RT6iRnGBR/xCoOYAQ0ikD8v9xSjlZXrKe A2iQ== X-Gm-Message-State: AIkVDXJ+fe84YoRg03LImHEUw0NHl1OrdHEK/GIwGq6pektVrfq0DIio53BOScRIbXCoXBRXiaGcG9zQ/KBbDQ== X-Received: by 10.200.49.106 with SMTP id h39mr23028149qtb.257.1485123945290; Sun, 22 Jan 2017 14:25:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.129.247 with HTTP; Sun, 22 Jan 2017 14:25:44 -0800 (PST) In-Reply-To: References: <10036332.AbsS0sHdB9@kitterma-e6430> <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> From: Peter Goldstein Date: Sun, 22 Jan 2017 14:25:44 -0800 Message-ID: To: Kurt Andersen Content-Type: multipart/alternative; boundary=001a1142d35c34f20f0546b65d8e Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 22:25:49 -0000 --001a1142d35c34f20f0546b65d8e Content-Type: text/plain; charset=UTF-8 Kurt, I agree that the best approach would be to update the DKIM spec to reflect modern cryptographic realities. I actually broached this topic on the IETF DKIM mailing list a couple of months ago. The thread quickly evolved into a discussion about using even shorter key sizes (768 bit) to avoid the long term verifiability of emails, and address associated privacy concerns. There did not seem to be a lot of support for raising the bit size requirements. That said, perhaps others would have more success. If we can drive this change to RFC 6376, that would be great. If not, I think it's important that we make appropriate cryptographic recommendations for ARC. Not only because of the security implications, but also because I can't imagine that ISPs that don't currently accept DKIM keys smaller than 1024 bits (e.g. Google) will accept ARC signatures with such keys. It needs to be made clear somewhere - the RFC, the usage guide, wherever - that 512 bit keys just won't work. There's a similar issue around the use of SHA-1. How would you suggest we drive a revision to RFC 6376 to address this issue? Thanks. Best, Peter On Sun, Jan 22, 2017 at 1:48 PM, Kurt Andersen wrote: > On Sun, Jan 22, 2017 at 1:18 PM, Scott Kitterman > wrote: > >> >> On January 22, 2017 3:30:14 PM EST, Kurt Andersen >> wrote: >> >On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein >> >wrote: >> > >> >> >> >> . . . ARC . . . inherits . . . from the DKIM RFC. The DKIM RFC >> >explicitly >> >> requires verifiers to validate signatures with bit sizes ranging from >> >512 >> >> bits to 2048 bits. >> >> >> >> There is a separate effort going on in the context of the UTA working >> >group to address technologically obsolete encryption strength >> >recommendations that have appeared over time in a variety of different >> >RFCs. I don't think that adding yet another independent reference is a >> >good >> >idea and I am strongly opposed to trying to torque the ARC requirements >> >to >> >be different from DKIM. >> > >> >If Scott is planning to make dkimpy non-conformant to the DKIM spec, I >> >think that is regrettable, but I don't see that making the problem >> >worse with ARC "going its own way" helps anyone. >> > >> >--Kurt >> >> No responsible operator has used the RFC minimum DKIM key sizes for a >> long time. They were trivial to bypass half a decade ago. No one has ever >> complained about 1024 bits default minimum being too big. I did once get a >> complaint about the Debian opendkim package suggesting the minimum should >> be 2048 bits. >> >> Maybe some other working group will accomplish something someday is not a >> good reason to perpetuate obsolete crypto in this one. >> >> Scott K > > > I agree with your points, but don't you think it would be better to "fix" > the DKIM spec than to have ARC "do its own thing" which does not address > the weakness still enshrined in the DKIM spec? > > --Kurt > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a1142d35c34f20f0546b65d8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kurt,

I agree that the best approach wo= uld be to update the DKIM spec to reflect modern cryptographic realities.

I actually broached this topic on the IETF DKIM mai= ling list a couple of months ago.=C2=A0 The thread quickly evolved into a d= iscussion about using even shorter key sizes (768 bit) to avoid the long te= rm verifiability of emails, and address associated privacy concerns.=C2=A0 = There did not seem to be a lot of support for raising the bit size requirem= ents.=C2=A0 That said, perhaps others would have more success.
If we can drive this change to RFC 6376, that would be great.= =C2=A0 If not, I think it's important that we make appropriate cryptogr= aphic recommendations for ARC.=C2=A0 Not only because of the security impli= cations, but also because I can't imagine that ISPs that don't curr= ently accept DKIM keys smaller than 1024 bits (e.g. Google) will accept ARC= signatures with such keys.=C2=A0 It needs to be made clear somewhere - the= RFC, the usage guide, wherever - that 512 bit keys just won't work.=C2= =A0 There's a similar issue around the use of SHA-1.

How would you suggest we drive a revision to RFC 6376 to address thi= s issue?

Thanks.

Best,

Peter


On Sun, Jan 22, 2017= at 1:48 PM, Kurt Andersen <kurta@drkurt.com> wrote:
On Sun, Jan 22, 2017 at 1:18 PM, Sco= tt Kitterman <sklist@kitterman.com> wrote:

On January 22, 2017 3:30:14 PM EST, Kurt Andersen <kurta@drkurt.com> wrote:
>On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein <peter@valimail.com>
>wrote:
>
>>
>> . . . ARC . . . inherits . . . from the DKIM RFC.=C2=A0 The DKIM R= FC
>explicitly
>> requires verifiers to validate signatures with bit sizes ranging f= rom
>512
>> bits to 2048 bits.
>>
>> There is a separate effort going on in the context of the UTA work= ing
>group to address technologically obsolete encryption strength
>recommendations that have appeared over time in a variety of different<= br> >RFCs. I don't think that adding yet another independent reference i= s a
>good
>idea and I am strongly opposed to trying to torque the ARC requirements=
>to
>be different from DKIM.
>
>If Scott is planning to make dkimpy non-conformant to the DKIM spec, I<= br> >think that is regrettable, but I don't see that making the problem<= br> >worse with ARC "going its own way" helps anyone.
>
>--Kurt

No responsible operator has used the RFC minimum DKIM key sizes= for a long time. They were trivial to bypass half a decade ago.=C2=A0 No o= ne has ever complained about 1024 bits default minimum being too big.=C2=A0= I did once get a complaint about the Debian opendkim package suggesting th= e minimum should be 2048 bits.

Maybe some other working group will accomplish something someday is not a g= ood reason to perpetuate obsolete crypto in this one.

Scott K

I agree with your points, but don't you think it = would be better to "fix" the DKIM spec than to have ARC "do = its own thing" which does not address the weakness still enshrined in = the DKIM spec?

--Kurt=C2=A0

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




--
=
=


3D"logo

Bringing Trust to Email

Peter Goldstein | CTO &a= mp; Co-Founder

peter@valimail.com

+1.415.793.5783<= /span>
--001a1142d35c34f20f0546b65d8e-- From nobody Sun Jan 22 15:42:59 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A49129490 for ; Sun, 22 Jan 2017 15:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Pkd0TfCfUMZt for ; Sun, 22 Jan 2017 15:42:57 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37232129488 for ; Sun, 22 Jan 2017 15:42:56 -0800 (PST) Received: (qmail 2254 invoked from network); 22 Jan 2017 23:42:55 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 Jan 2017 23:42:55 -0000 Date: 22 Jan 2017 23:42:33 -0000 Message-ID: <20170122234233.59586.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: kurta@drkurt.com Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 23:42:58 -0000 In article you write: >> No responsible operator has used the RFC minimum DKIM key sizes for a long >> time. They were trivial to bypass half a decade ago. No one has ever >> complained about 1024 bits default minimum being too big. ... >I agree with your points, but don't you think it would be better to "fix" >the DKIM spec than to have ARC "do its own thing" which does not address >the weakness still enshrined in the DKIM spec? Only if we want to stall ARC for a couple of years while we have unproductive arguments about what it means to update the DKIM spec and whether key lengths are the only thing we want to twiddle. While ARC signatures are a lot like DKIM signatures, they're not DKIM signatures. A spec that says "ARC signatures are created the same way as DKIM signatures except that keys MUST be at least 1024 bits" is no harder to implement than one that says they're just the same, and is likely to match what people do in practice anyway. I looked at the current version of dkimpy (0.5.6) and found that by default it requires a minimum key length of 1024 which you can override with a larger or smaller size if you want. If Scott says nobody's ever complained about it, I believe him. R's, John From nobody Sun Jan 22 15:50:40 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD80F1294B5 for ; Sun, 22 Jan 2017 15:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tchx8PwZbVwV for ; Sun, 22 Jan 2017 15:50:36 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B101D1294BD for ; Sun, 22 Jan 2017 15:50:36 -0800 (PST) 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 5C6C0C401BA; Sun, 22 Jan 2017 17:50:35 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1485129035; bh=7oQbM5jfWf56jxF/tFsbCXdz4ANrC0ZgVh/isMQV5Kw=; h=Date:In-Reply-To:References:Subject:To:From:From; b=RP4fGtO22LoqS41ultPz34uPrA6ujIwNSRqm+R7iSzJVkOs7AWpcfPfg6Wgb60KuY 8AvQ5jAGCxEoZ8cAhavysrae7rQwASozQvSs8sd0xmkPxMOql6yDYgg3g5kXbdrZSE dbhOKiH6J6DwO0aFkMZtVrOIVYRSwMDM3ptHirF8= Date: Sun, 22 Jan 2017 23:49:22 +0000 In-Reply-To: References: <10036332.AbsS0sHdB9@kitterma-e6430> <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 23:50:39 -0000 On January 22, 2017 4:48:28 PM EST, Kurt Andersen wro= te: >On Sun, Jan 22, 2017 at 1:18 PM, Scott Kitterman >wrote: > >> >> On January 22, 2017 3:30:14 PM EST, Kurt Andersen >> wrote: >> >On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein > >> >wrote: >> > >> >> >> >> =2E =2E =2E ARC =2E =2E =2E inherits =2E =2E =2E from the DKIM RFC= =2E The DKIM RFC >> >explicitly >> >> requires verifiers to validate signatures with bit sizes ranging >from >> >512 >> >> bits to 2048 bits=2E >> >> >> >> There is a separate effort going on in the context of the UTA >working >> >group to address technologically obsolete encryption strength >> >recommendations that have appeared over time in a variety of >different >> >RFCs=2E I don't think that adding yet another independent reference is >a >> >good >> >idea and I am strongly opposed to trying to torque the ARC >requirements >> >to >> >be different from DKIM=2E >> > >> >If Scott is planning to make dkimpy non-conformant to the DKIM spec, >I >> >think that is regrettable, but I don't see that making the problem >> >worse with ARC "going its own way" helps anyone=2E >> > >> >--Kurt >> >> No responsible operator has used the RFC minimum DKIM key sizes for a >long >> time=2E They were trivial to bypass half a decade ago=2E No one has ev= er >> complained about 1024 bits default minimum being too big=2E I did once >get a >> complaint about the Debian opendkim package suggesting the minimum >should >> be 2048 bits=2E >> >> Maybe some other working group will accomplish something someday is >not a >> good reason to perpetuate obsolete crypto in this one=2E >> >> Scott K > > >I agree with your points, but don't you think it would be better to >"fix" >the DKIM spec than to have ARC "do its own thing" which does not >address >the weakness still enshrined in the DKIM spec? In theory, sure=2E In practice it's just a variation on waiting for someo= ne else to do the work=2E Additionally, DKIM will have an added burden of = gaining community consensus that the security benefits of the change are im= portant enough to break backward compatibility over=2E This is not a kind of decision the IETF is great at getting done with any = rapidity=2E ARC, on the other hand, has no backward compatibility legacy to get caught= by, unless we screw it up now=2E Scott K From nobody Sun Jan 22 17:29:12 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C8612954E for ; Sun, 22 Jan 2017 17:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 PY2dKuyVkngO for ; Sun, 22 Jan 2017 17:29:09 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F81E129542 for ; Sun, 22 Jan 2017 17:29:09 -0800 (PST) Received: (qmail 15880 invoked from network); 23 Jan 2017 01:29:07 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jan 2017 01:29:07 -0000 Date: 23 Jan 2017 01:28:45 -0000 Message-ID: <20170123012845.59827.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: peter@valimail.com Subject: Re: [dmarc-ietf] DKIM update, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 01:29:11 -0000 >How would you suggest we drive a revision to RFC 6376 to address this issue? As you saw, anything in the IETF that smells of crypto tends to go into the weeds with the crypto fad du jour. If you want to do this, I'd suggest an update with a very small focus: 1) Add a new signature algorithm, probably ECDSA, since it has good support in OpenSSL. 2) Deprecate 512 and 1024 bit DSA keys, and recommend 2K bit DSA or 320 bit ECDSA keys. The reason for ECDSA is that the keys are much smaller. A 160 bit ECDSA key is about as strong as a 1024 bit DSA key, so the equivalent of a 4K DSA key is only 640 bits and will fit easily into a single TXT record string. Make it clear that the scope of this update is only the crypto, so we can more easily chase away people who want DKIM to do something it doesn't. R's, John PS: Although it would be entirely appropriate to ask them "where were you when we were writing the last two specs?" people tend not to respond well. From nobody Sun Jan 22 19:17:49 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85DA12957C for ; Sun, 22 Jan 2017 19:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qd-PhT4C2ZAp for ; Sun, 22 Jan 2017 19:17:46 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86414129564 for ; Sun, 22 Jan 2017 19:17:46 -0800 (PST) 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 C27DEC4022B; Sun, 22 Jan 2017 21:17:44 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1485141464; bh=Px2PAUA6eNov6M8YM8efnfZVkIWl/EXviU7xaasmKhE=; h=Date:In-Reply-To:References:Subject:To:From:From; b=soXXeNdWPz/Mnx9qAqZeer/EpBOFkYKxJvsWXaivU0CCDN6Punj69UIvXIRNMPGlC tk5cXZQrPhN1Q+M/jX5X0A0XkAH/SV9P2iSfc6fRBsNSgyxlMV4Qe7W/9GuIHW8Cdn p4Ov9c47Dt5wfykKiOnUNEU97mglDocjSR85bHn8= Date: Mon, 23 Jan 2017 03:17:44 +0000 In-Reply-To: References: <10036332.AbsS0sHdB9@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <1C071BA2-AE2B-4213-B5BD-273781566A1D@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 03:17:48 -0000 On January 22, 2017 3:30:14 PM EST, Kurt Andersen wro= te: >On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein >wrote: > >> >> =2E =2E =2E ARC =2E =2E =2E inherits =2E =2E =2E from the DKIM RFC=2E = The DKIM RFC >explicitly >> requires verifiers to validate signatures with bit sizes ranging from >512 >> bits to 2048 bits=2E >> >> There is a separate effort going on in the context of the UTA working >group to address technologically obsolete encryption strength >recommendations that have appeared over time in a variety of different >RFCs=2E I don't think that adding yet another independent reference is a >good >idea and I am strongly opposed to trying to torque the ARC requirements >to >be different from DKIM=2E FYI, I did go review the UTA charter and anything DKIM related is out of s= cope for that working group=2E It's limited to TLS=2E Scott K >If Scott is planning to make dkimpy non-conformant to the DKIM spec, I >think that is regrettable, but I don't see that making the problem >worse >with ARC "going its own way" helps anyone=2E > >--Kurt From nobody Sun Jan 22 22:02:07 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7D6129AEB for ; Sun, 22 Jan 2017 22:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4Pyqd1Wcj1h for ; Sun, 22 Jan 2017 22:02:03 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538DA129AE4 for ; Sun, 22 Jan 2017 22:02:03 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id v200so129074892ywc.3 for ; Sun, 22 Jan 2017 22:02:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=84jynuoPEHpEAOOZ9CrKkhdyYOcydCoxlhjVBCwmm3E=; b=GqWVLiNT09p4OfMfOV7AE1tmFuZoatehK70kSjRKNWVcibjs/dxiyFljrZYEo7h6mD Dc/5ZnL+KtoNdJOKUU6B0mBZ3A3uch8iANgsJijARc2phkgf3S+H3Lw/3w18pIusRBKj Q05ax7ZHUisgfJDvdkK1gM9FtX1OPAzFR2tk1zuGGbJYcqVEea5eRWcaVUKbEh97Bzct vw32CDOM4vJEEqcuVSutV50cyIoC3Whx9aNRVf6tdEi5Z5k1xVZqhbv/jdzLGbN7d3Av 9fddisgMRJn6Cjumj9M1zqPu+i3W4+Id+XvQKH587lSTs5+72CbD0V4TaKXrQaeUUkQt GUcw== 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=84jynuoPEHpEAOOZ9CrKkhdyYOcydCoxlhjVBCwmm3E=; b=Q/hbgi8uWHeam9MPz7sS9GEN95xwVH34ckhkeBG8xmxFLkuTbH+5AC+k53J2tZ+Hmf j/QoQVsqEPRyJbmWVAxiAwsCMhId7Y7EPvSghFPUUyuZjO6p9iyX8UDQlW+4ev+j9BG/ Sz2cHjVnLOFJwig68Spv/Hfy9APhL1/EPEVTrg9jSBXC6h6334px7c5ct5yw+nJb0qUx 7mCQdMAIEo3oni3+oX6ZJsguzL49wa4pRDen5t6H34EmNQO4i/r/wOYgEpSni++W3VDX K5xZFW8recOAXtWwuoSJ4PhwWIqqRryCaZXuSsl3Vv6b9v+gqbmbZOY36hAICnC+qR4O wfBg== X-Gm-Message-State: AIkVDXJRLxDnYIGdOvPktV1Y+xHHtMzXGV5OU/l7T+RsLI7bRtKsxxRQSUbD6fcugAzmoIf9LcDB+h15JmkCFwnT X-Received: by 10.129.141.68 with SMTP id w4mr20687038ywj.269.1485151322366; Sun, 22 Jan 2017 22:02:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.8.198 with HTTP; Sun, 22 Jan 2017 22:02:00 -0800 (PST) In-Reply-To: References: <10036332.AbsS0sHdB9@kitterma-e6430> From: Brandon Long Date: Sun, 22 Jan 2017 22:02:00 -0800 Message-ID: To: Gene Shuman Content-Type: multipart/alternative; boundary=f403045ef410025d660546bcbde8 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 06:02:05 -0000 --f403045ef410025d660546bcbde8 Content-Type: text/plain; charset=UTF-8 I don't think I see the point. If the chain is invalid, it's invalid. Your local AuthRes header can say arc=fail. If you forward, you can either strip the invalid chain or leave it as is, any other receiver will also quickly determine the chain is invalid. Trying to figure out some signing order for pathological cases seems unnecessary. What's the point of passing my failure status on? Brandon On Fri, Jan 20, 2017 at 11:46 AM, Gene Shuman wrote: > Kurt, I think terminating the chain with a cv=invalid is a good approach. > The general idea being that if there is any seal found with cv=invalid then > validation fails & we don't continue the chain. When a good intermediary > finds an invalid chain, a seal is affixed(no need for AMS, or AAR), with > the cv=invalid value. Im assuming we no longer require the a,b,d,s tags at > this point, as they're irrelevant. Or do we even want to consider having a > 4th type of header field(ARC-ChainInvalid?), possibly with identifying or > failure information, just so were not modifying AS too much? Are there any > security concerns with either of these approaches that need to addressed? > > An open question then is what constitutes an invalid set. I would suggest > that only the cases of duplicated or malformed/invalid i= values are > invalid sets. Missing/incomplete sets fail, and mis-ordered sets are > handled normally. > > +++1 wrt Scott's comment about 512 bit keys. We inherit this requirement > from the DKIM spec, but imho it is not reasonable. If this is worth > discussing, perhaps we should move it to another thread? > > Regards, > =Gene > > On Fri, Jan 20, 2017 at 11:23 AM, Scott Kitterman > wrote: > >> On Friday, January 20, 2017 07:48:28 AM Kurt Andersen wrote: >> > On Thu, Jan 19, 2017 at 9:02 PM, Murray S. Kucherawy < >> superuser@gmail.com> >> > >> > wrote: >> > > On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen >> wrote: >> > >> The intent of section 5.2.1 was never to deal with pathological >> cases. It >> > >> was to deal with somewhat broken MTAs that do stupid things like >> > >> reordering >> > >> headers in alphabetical order or slightly broken implementations >> which >> > >> might replicate headers. >> > >> >> > >> Duplication is arguably fine as long as the duplicate is identical >> to the >> > > >> > > original, but I think once you have to go so far as to evaluate that, >> the >> > > chain has actually been directly affected, and it's fine to give up. >> > >> > Gene's suggestions (omitted from this due to top posting) about >> creating a >> > new "invalid" CV tag value seems like a reasonable response to a badly >> > broken (structurally) ARC chain. Since we are _a priori_ only >> interested in >> > good chains I don't think that adding this creates any exploits for bad >> > actors since a malicious intermediary can destroy/corrupt/etc an ARC >> chain >> > any which way. >> > >> > I'm more concerned about pathologies that could be introduced in the >> quest >> > to affix an ARC set with i=(previous + 1) when the "previous" value is >> > malicious (not a number, too big a number, etc). In some sense, we >> almost >> > need an "end of chain, don't waste your time any further" signal. >> >> I'm not on the ARC list, so I'll pile on this thread here... >> >> I understand the minimum key size in the draft is 512 bits. I'm not >> planning >> on releasing any software that supports key sizes less than 1024, so I >> guarantee you interoperability problems for small keys. >> >> For those that may have forgotten, I'll pass on a reminder of how well >> 512 bit >> keys work even half a decade ago: >> >> https://www.wired.com/2012/10/dkim-vulnerability-widespread/ >> >> Scott K >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --f403045ef410025d660546bcbde8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think I see the point.

If t= he chain is invalid, it's invalid.=C2=A0 Your local AuthRes header can = say arc=3Dfail.=C2=A0 If you forward, you can either strip the invalid chai= n or leave it as is, any other receiver will also quickly determine the cha= in is invalid.

Trying to figure out some signing o= rder for pathological cases seems unnecessary.

Wha= t's the point of passing my failure status on?

Brandon

On Fri, Jan 20, 2017 at 11:46 AM, Gene Shuman <gene@valimail.com>= ; wrote:
Kurt, I = think terminating the chain with a cv=3Dinvalid is a good approach.=C2=A0 T= he general idea being that if there is any seal found with cv=3Dinvalid the= n validation fails & we don't continue the chain.=C2=A0 When a good= intermediary finds an invalid chain, a seal is affixed(no need for AMS, or= AAR), with the cv=3Dinvalid value.=C2=A0 Im assuming we no longer require = the a,b,d,s tags at this point, as they're irrelevant.=C2=A0 Or do we e= ven want to consider having a 4th type of header field(ARC-ChainInvalid?), = possibly with identifying or failure information, just so were not modifyin= g AS too much? Are there any security concerns with either of these approac= hes that need to addressed?

An open question then is wha= t constitutes an invalid set.=C2=A0 I would suggest that only the cases of = duplicated or malformed/invalid i=3D values are invalid sets.=C2=A0 Missing= /incomplete sets fail, and mis-ordered sets are handled normally.

+++1 wrt Scott's comment about 512 bit keys.=C2=A0 We i= nherit this requirement from the DKIM spec, but imho it is not reasonable.= =C2=A0 If this is worth discussing, perhaps we should move it to another th= read?

Regards,
=3DGene

On Fri, Jan 20, 2017 at 11:23 AM, Scott Kitterman <skl= ist@kitterman.com> wrote:
<= span>On Friday, January 20, 2017 07:48:28 AM Kurt Andersen wrote:
> On Thu, Jan 19, 2017 at 9:02 PM, Murray S. Kucherawy <superuser@gmail.com>
>
> wrote:
> > On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen <kurta@drkurt.com> wrote: > >> The intent of section 5.2.1 was never to deal with pathologic= al cases. It
> >> was to deal with somewhat broken MTAs that do stupid things l= ike
> >> reordering
> >> headers in alphabetical order or slightly broken implementati= ons which
> >> might replicate headers.
> >>
> >> Duplication is arguably fine as long as the duplicate is iden= tical to the
> >
> > original, but I think once you have to go so far as to evaluate t= hat, the
> > chain has actually been directly affected, and it's fine to g= ive up.
>
> Gene's suggestions (omitted from this due to top posting) about cr= eating a
> new "invalid" CV tag value seems like a reasonable response = to a badly
> broken (structurally) ARC chain. Since we are _a priori_ only interest= ed in
> good chains I don't think that adding this creates any exploits fo= r bad
> actors since a malicious intermediary can destroy/corrupt/etc an ARC c= hain
> any which way.
>
> I'm more concerned about pathologies that could be introduced in t= he quest
> to affix an ARC set with i=3D(previous + 1) when the "previous&qu= ot; value is
> malicious (not a number, too big a number, etc). In some sense, we alm= ost
> need an "end of chain, don't waste your time any further"= ; signal.

I'm not on the ARC list, so I'll pile on this thread here...=

I understand the minimum key size in the draft is 512 bits.=C2=A0 I'm n= ot planning
on releasing any software that supports key sizes less than 1024, so I
guarantee you interoperability problems for small keys.

For those that may have forgotten, I'll pass on a reminder of how well = 512 bit
keys work even half a decade ago:

https://www.wired.com/2012/10/dkim-= vulnerability-widespread/

Scott K

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


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


--f403045ef410025d660546bcbde8-- From nobody Mon Jan 23 02:31:50 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BAF129B09 for ; Mon, 23 Jan 2017 02:31:49 -0800 (PST) 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 HHURFjQ7I9Bt for ; Mon, 23 Jan 2017 02:31:47 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828B01294F8 for ; Mon, 23 Jan 2017 02:31:47 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id x75so87560971vke.2 for ; Mon, 23 Jan 2017 02:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JEI9tqHYZWmUWPUG8yVa9wVkOENdWev+0hsLr+XJzYI=; b=CAHtvjlp19mHClG+fC/i1xJ5hLbtOngUv007aejg6OtdAuRcit72NqXjrHyDBXcZwH NlrtyRwQ4gLR5ZQj7bED7oU4vTyk4mO/NMfa7jFzqxY6g91cyC6aJYt+9sBY1zcw/Oba 02kRiRfhY8f9958YRtPAEpgNyNuJlOVWmr8Oij37roLev9p5CMil8f1SAkvCTnjWNI7C 6WK/n8/8S++QNernLor72585e+9suwNEp+w60CXBzvwIWT2fkFqzXDKzJE/J6toVpdmY fYSmjlu6YvBE3kUWbbc7l7oDzhoycXwb2CU/xCJ1Rd3ecHmEronVzakiLp8sAJ4kxVbM EI3w== 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=JEI9tqHYZWmUWPUG8yVa9wVkOENdWev+0hsLr+XJzYI=; b=fpqCm43jhNcJLhFu/nUYk6H2NbwOhitve+QZw7s/SIR8ngG/rmDGJQxaHWdZ5Q1804 XN0qzK3ZNdEfsJ2SjY8PQhwNSwmT71CrvPEY2Td6SJPmH8GKI0Fxw2CykRGNqpd2/Tsa g1e6+Ah8mY7FugEExkIPdPEDfcjq/9qaEoo4HqQoHV7AEpmQWs8WupfKSpP7nooF4+K+ Mkx4ApXw8hYGi9TOCoeyl359vzuqpuMlfnl3ykJYFFxTaYmSFmmkZy06xStssry4Eoht +Daa1pieWOlYgv6+3LMdU5Zr8PnqfI9yjeUtQF2LYcwWrabDmGkYw0TylkYGeGYD2l5R 9sIg== X-Gm-Message-State: AIkVDXJmTz09L6vDQLakqYjGxErfDJtCJ3QK7jRLaFl3al73TliCkNgw1kxtzV5Y2B6nho5YTB0MNgfAYsvZbg== X-Received: by 10.31.11.11 with SMTP id 11mr13483060vkl.141.1485167506526; Mon, 23 Jan 2017 02:31:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.150 with HTTP; Mon, 23 Jan 2017 02:31:45 -0800 (PST) In-Reply-To: References: <10036332.AbsS0sHdB9@kitterma-e6430> <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> From: "Murray S. Kucherawy" Date: Mon, 23 Jan 2017 02:31:45 -0800 Message-ID: To: Peter Goldstein Content-Type: multipart/alternative; boundary=001a114580a2a896220546c081b1 Archived-At: Cc: Scott Kitterman , "dmarc@ietf.org" , Kurt Andersen Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 10:31:49 -0000 --001a114580a2a896220546c081b1 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 22, 2017 at 2:25 PM, Peter Goldstein wrote: > Kurt, > > I agree that the best approach would be to update the DKIM spec to reflect > modern cryptographic realities. > I'd like to come up with something better than updating DKIM every time there's new advice on key sizes, etc. Doing one update that points to the best current advice, and then letting that other thing get updated whenever, would be better. Otherwise at some point we'll need to update DKIM and ARC, and then DKIM, ARC, and the next thing, etc. etc. But is there such a reference? > I actually broached this topic on the IETF DKIM mailing list a couple of > months ago. The thread quickly evolved into a discussion about using even > shorter key sizes (768 bit) to avoid the long term verifiability of emails, > and address associated privacy concerns. There did not seem to be a lot of > support for raising the bit size requirements. That said, perhaps others > would have more success. > I'd do an "updates" draft, but I'd like to resolve the above question first. > How would you suggest we drive a revision to RFC 6376 to address this > issue? > On ietf-dkim, not here. :-) -MSK --001a114580a2a896220546c081b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jan 22, 2017 at 2:25 PM, Peter Goldstein <peter@= valimail.com> wrote:
Kurt,
=
I agree that the best approach would be to update the DKIM s= pec to reflect modern cryptographic realities.

I'd like to come up with something better than updating= DKIM every time there's new advice on key sizes, etc.=C2=A0 Doing one = update that points to the best current advice, and then letting that other = thing get updated whenever, would be better.=C2=A0 Otherwise at some point = we'll need to update DKIM and ARC, and then DKIM, ARC, and the next thi= ng, etc. etc.

But is there such a reference?
=C2=A0
I actually broached this t= opic on the IETF DKIM mailing list a couple of months ago.=C2=A0 The thread= quickly evolved into a discussion about using even shorter key sizes (768 = bit) to avoid the long term verifiability of emails, and address associated= privacy concerns.=C2=A0 There did not seem to be a lot of support for rais= ing the bit size requirements.=C2=A0 That said, perhaps others would have m= ore success.

I'd do an &quo= t;updates" draft, but I'd like to resolve the above question first= .
=C2=A0
How would = you suggest we drive a revision to RFC 6376 to address this issue?

On ietf-dkim, not here.=C2=A0 :-)

-MSK
--001a114580a2a896220546c081b1-- From nobody Mon Jan 23 02:41:35 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D39129B15 for ; Mon, 23 Jan 2017 02:41:34 -0800 (PST) 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 4YXP80bKzSyn for ; Mon, 23 Jan 2017 02:41:33 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224CC1294F8 for ; Mon, 23 Jan 2017 02:41:33 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id r136so87721206vke.1 for ; Mon, 23 Jan 2017 02:41:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z/dtrjXf05QBmfZIjMpPuDw9x8Ozu44xqUj2HVkRrEU=; b=uDbNhtKbEyUj09Y+HGEq0Ps9X7ZSfUuZO9XdRLn9b7HzkgSMNC5MUsFIELNYq7xDGk ISIthFTckzSKFM/BdWNQhcQNuDcQfak5YgyNcj6VXwLQ/L6rVMkj5KkUmSILbPNSojBT jAS+P4SqVw+CF1731ikvMcKjtKl2uQScB8zP1241A53dhEHuXIpCr1+X1vTaxw/Hh6kB giW4wPCecVr1HRvLnx66yrFSWuTeVjXHFeoKRNSPo+xJ5idZhxAKhlC5paAoOS53cFIS Chwe0Ilshd6iTlGllMEHUzuoXy86OwA6WxjEUCeEsx/LG4pZ+P9OoB84J+F6EBKllhEX 6ZkA== 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=Z/dtrjXf05QBmfZIjMpPuDw9x8Ozu44xqUj2HVkRrEU=; b=DkpvdOYbOfCvvNWAvQ+43o0cdfIV0LqI5sfskkshYYk6OVzfRskz2UpEk8G3JVP+V8 BFcjSLsto0SU6xkPKVVe/mMkBWvuDW21Wdm36IiQG4t4qzjQYc5C+Gs9XStSxdjV+ua0 ZtvKQCUfpe9nQ1jsOmvbibhCtu2QhfWHjgqtUhMOpWNyO+hB71vsSJZQQ52MnVv4QFWg T0xCG6fu+M4hhTSPGvBHX04fyZV/aF7VuSRk6WUl54C9Ul4fWOvhpl3Ut7Cq8PWw3o/N 9HuirOlK4ea6OciWZLazW1lktc4dWsRkv9JLwIXE7sFLty0j83x09A8udPSoCtQFeMOZ 5CPA== X-Gm-Message-State: AIkVDXLkIPLlg32GvqyXK82NH7THtz6wQbcIMeuffRKQ/B5z25DB+EvXg56WctGRS1nhT0zpZWV+d3WIEvktDg== X-Received: by 10.31.11.11 with SMTP id 11mr13497604vkl.141.1485168092165; Mon, 23 Jan 2017 02:41:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.150 with HTTP; Mon, 23 Jan 2017 02:41:31 -0800 (PST) In-Reply-To: <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> References: <10036332.AbsS0sHdB9@kitterma-e6430> <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> From: "Murray S. Kucherawy" Date: Mon, 23 Jan 2017 02:41:31 -0800 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a114580a290bc290546c0a4b4 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 10:41:34 -0000 --001a114580a290bc290546c0a4b4 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 22, 2017 at 1:18 PM, Scott Kitterman wrote: > No responsible operator has used the RFC minimum DKIM key sizes for a long > time. They were trivial to bypass half a decade ago. No one has ever > complained about 1024 bits default minimum being too big. I did once get a > complaint about the Debian opendkim package suggesting the minimum should > be 2048 bits. > As I recall there are issues using keys bigger than 1024 bits because construction and/or correct interpretation of TXT records that contain keys of that size or bigger has been problematic due to DNS provisioning software that does the former wrong and DKIM verifiers that do the latter wrong. To my knowledge, nobody has ever shown evidence that the larger keys are too computationally expensive to be used, or that any of the other things mentioned in Section 3.3.3 of RFC6376 are actually a problem. If we can nail those issues down, I think a lot of the practical resistance goes away, and ARC can easily say ">= 1024" or whatever we want and be done with it. -MSK --001a114580a290bc290546c0a4b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jan 22, 2017 at 1:18 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
<= div class=3D"h5">No responsible operator has used the RFC minimum DKIM key = sizes for a long time. They were trivial to bypass half a decade ago.=C2=A0= No one has ever complained about 1024 bits default minimum being too big.= =C2=A0 I did once get a complaint about the Debian opendkim package suggest= ing the minimum should be 2048 bits.

<= /div>
As I recall there are issues using keys bigger than 1024 bits bec= ause construction and/or correct interpretation of TXT records that contain= keys of that size or bigger has been problematic due to DNS provisioning s= oftware that does the former wrong and DKIM verifiers that do the latter wr= ong.=C2=A0 To my knowledge, nobody has ever shown evidence that the larger = keys are too computationally expensive to be used, or that any of the other= things mentioned in Section 3.3.3 of RFC6376 are actually a problem.
If we can nail those issues down, I think a lot of the practic= al resistance goes away, and ARC can easily say ">=3D 1024" or= whatever we want and be done with it.

-MSK
--001a114580a290bc290546c0a4b4-- From nobody Mon Jan 23 02:43:40 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D1E129B15 for ; Mon, 23 Jan 2017 02:43:38 -0800 (PST) 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 ZiuDqP4HQ359 for ; Mon, 23 Jan 2017 02:43:37 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115B21294F8 for ; Mon, 23 Jan 2017 02:43:37 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id k127so87597539vke.0 for ; Mon, 23 Jan 2017 02:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yl3FPPLT3LVLQeLLtXxbwc5GGW/zWAxjIFHZbD2pk34=; b=kkqSS4foVCy4Q5zWhOopZr0PPe2cp3tKCCPLuhFGanFasLFHWBxXxer9XbiPrv/o+u aZX9D5VgNBSntWh1wBfjJSqQ5WmQMAQ3/FcMSarZpjeAHeFNHO+uCKAr35Rs4R5yoJug Ql6ASPpKYEN07ioYeCeFsFJT2khDcVyrZ6Cow6ymUzvzL+jxe3TKaFew0py4uu2akzEB Qowsfw+SdjCm7S/Gj5TI8x48VqgvFSvPTln2L4NlS74MKNya5vpud2i77b5fAWxqZik+ CGE6Sp4MkSwds+qhzf7pkZltzCOniDm2hnEecXrGl2AG6hR+Hg8FzDSwqn126ZztFdqp 4i4A== 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=yl3FPPLT3LVLQeLLtXxbwc5GGW/zWAxjIFHZbD2pk34=; b=lvb6NibOL7BZ4rsuUx7yHSJhRrK5R5uTmVmywhipV+MOOtaINpHWUJgxlPvZcI58Pa hEDZkHnO91yVh9Z/VLjks70S/QiuoSG6eSC8R3XpKhUrlqM0y4V9oaIMPjs1w4++wcC5 eJ0kl9vkm42ivy0PRwJgmy2Vk/2F3eFL3FfRAf0zU7TJPNJZZuHFA1kL9c/gggPVb0LC QbZsXLch6UHVe22sBzEAAtpuLF2zcx4wCETW+SvsQy7dO/8NKB34zL0FymtmJ1On9XZX DcwaOrVLQNwCOfo6cmbWmLP7hI/xbJ52yN0wmVdZyD6y9+0WQ/nt5AVdzf52k8OViPtz g72A== X-Gm-Message-State: AIkVDXLWu+E3pkQx2NxZf2NfPFm5yiAnegPTz5mBk8bs7GEkX3YaqlQCFDepUdP5ZsfR2ugkfFlRm8OVb+4EwQ== X-Received: by 10.31.138.9 with SMTP id m9mr10906776vkd.110.1485168216077; Mon, 23 Jan 2017 02:43:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.150 with HTTP; Mon, 23 Jan 2017 02:43:35 -0800 (PST) In-Reply-To: References: <10036332.AbsS0sHdB9@kitterma-e6430> <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> From: "Murray S. Kucherawy" Date: Mon, 23 Jan 2017 02:43:35 -0800 Message-ID: To: Kurt Andersen Content-Type: multipart/alternative; boundary=001a1144fcc2f37b3c0546c0ab23 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 10:43:38 -0000 --001a1144fcc2f37b3c0546c0ab23 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 22, 2017 at 1:46 PM, Kurt Andersen wrote: > > Don't you think it would be better to "fix" the DKIM spec than to have ARC > "do its own thing"? > > I would argue that we're not chartered to update DKIM for this purpose, though I'm happy to do that as an individual submission if we can get consensus on what it should say. -MSK --001a1144fcc2f37b3c0546c0ab23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jan 22, 2017 at 1:46 PM, Kurt Andersen <ka= ndersen@linkedin.com> wrote:

Don't you think it would be better to "fix&q= uot; the DKIM spec than to have ARC "do its own thing"?

<= /div>

I would argue tha= t we're not chartered to update DKIM for this purpose, though I'm h= appy to do that as an individual submission if we can get consensus on what= it should say.

-MSK
--001a1144fcc2f37b3c0546c0ab23-- From nobody Mon Jan 23 02:45:08 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2AC1294F8 for ; Mon, 23 Jan 2017 02:45:06 -0800 (PST) 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 w1bVVWRHkaQ0 for ; Mon, 23 Jan 2017 02:45:05 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE37129B11 for ; Mon, 23 Jan 2017 02:45:05 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id t8so87724673vke.3 for ; Mon, 23 Jan 2017 02:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=De1F3/XHMqmmsiKqaBmoHmOtwgwOATHbPvatujRJxog=; b=NLqKOFL29TeyHdh9at4NhL7ZiGGBrFd391yQZHhR2b60k7/Z0QEKuwPAGBOCsyFIW+ VPJUt8BNTmDDG9/P68C8/NPd2F5ZpmskCxiqE/ZZeG16CxQxLcpevtXUOWad3C9NpHGM YuwJK7LaX9Qm2XKFbiJPr1q7JsHujZOoTraED4bq6m1jbriCRwmLYZ7f0DyjjkXu1Xbl T5BOhXCMbXSbkMkCtaYhy1QOYbjcP6V4X3B0Ai8Aj8DPB9JjYkAw3xv2gLqO2FQzjwNK nStr1wVXL677TnIO5DRGbz3NSRgeRm+KiDZcbOGq2leNYb4jY+wxTHhsnKkrxZyBzGIc NVfA== 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=De1F3/XHMqmmsiKqaBmoHmOtwgwOATHbPvatujRJxog=; b=WPzLR9ShzEgfwSCUmMcSeJgKLwQNNftd+znEjSK3WDM8eo8IfJEjyWv8oY7hllpxDV PjfD1/R0AUlldlNvVJGTQKHFl60QZKsbtYaRBnhkmLgVDkaxfjElkFEjQwGzTAc2IMvL KqWoGONLbdUMXt98XQjuHHL4iBIQv8hl515oUd8HUUFirHwZKNUYEPSEssz339uXAQWy Ai73eSMx7f9dMbov9gFcs86VHLK+oXEzXnbnAKe7j01GCfPQlqOCg4qK3nkOWL+tjNFV 3Nxjud/2ac2PniKIB8znuSfHayhvez4dK0mCjrv4NXtvWaNvRf0sIvA3/cTwLnrwPzAf IIeQ== X-Gm-Message-State: AIkVDXLt43yOcA3WPQJZXigD8tMZqhES1EK1GSeBmZjFfm4NV1IYvPDu96sPl6MF3LUFCXog2KevScuBoJovMg== X-Received: by 10.31.133.16 with SMTP id h16mr3839875vkd.26.1485168304482; Mon, 23 Jan 2017 02:45:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.150 with HTTP; Mon, 23 Jan 2017 02:45:03 -0800 (PST) In-Reply-To: References: <10036332.AbsS0sHdB9@kitterma-e6430> <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> From: "Murray S. Kucherawy" Date: Mon, 23 Jan 2017 02:45:03 -0800 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11c0081a386dc40546c0b139 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 10:45:06 -0000 --001a11c0081a386dc40546c0b139 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 22, 2017 at 3:49 PM, Scott Kitterman wrote: > > In theory, sure. In practice it's just a variation on waiting for someone > else to do the work. Additionally, DKIM will have an added burden of > gaining community consensus that the security benefits of the change are > important enough to break backward compatibility over. > > Actually that didn't come up on the ietf-dkim thread Peter referenced at all. I don't imagine that by itself would be an issue. -MSK --001a11c0081a386dc40546c0b139 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jan 22, 2017 at 3:49 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
<= div class=3D"h5">
In theory, sure.=C2=A0 In practice it's just a variation on= waiting for someone else to do the work.=C2=A0 Additionally, DKIM will hav= e an added burden of gaining community consensus that the security benefits= of the change are important enough to break backward compatibility over.

Actually that didn't come up on th= e ietf-dkim thread Peter referenced at all.=C2=A0 I don't imagine that = by itself would be an issue.

-MSK
--001a11c0081a386dc40546c0b139-- From nobody Mon Jan 23 07:08:05 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252DA129620 for ; Mon, 23 Jan 2017 07:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 3Dki-zgPdhTM for ; Mon, 23 Jan 2017 07:08:02 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC4D12961D for ; Mon, 23 Jan 2017 07:08:01 -0800 (PST) Received: (qmail 10071 invoked from network); 23 Jan 2017 15:08:00 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jan 2017 15:08:00 -0000 Date: 23 Jan 2017 15:07:38 -0000 Message-ID: <20170123150738.63563.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: blong@google.com Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 15:08:03 -0000 In article you write: >Trying to figure out some signing order for pathological cases seems >unnecessary. > >What's the point of passing my failure status on? I agree. We don't have legacy code to work around, so we should concentrate on getting things to work correctly. R's, John From nobody Mon Jan 23 07:39:58 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296C412963B for ; Mon, 23 Jan 2017 07:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2bCIM3oRZFX for ; Mon, 23 Jan 2017 07:39:56 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [IPv6:2001:470:1:6d::9a]) by ietfa.amsl.com (Postfix) with ESMTP id 208C412963A for ; Mon, 23 Jan 2017 07:39:56 -0800 (PST) Received: from susuwatari.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 2D6072337B for ; Mon, 23 Jan 2017 07:40:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1485186001; bh=PdMhCTHxgQK31VozVfd0p8wC/GFA7CD9EFHJ7LEga3I=; h=From:Subject:Date:References:To:In-Reply-To:From; b=Mo3IT7TSV5E79hoNLXsL5pBAsWI95360r+otYnyLzBYskcZfFTtJ0ZGbnxz7fDkPR nCRnKPZahiSxGbWZkG5oBcRe8deCms4MTOurwRWbm1ceFHa/w0JUATBzUOfcln/Qtn Ow3hiLiHFusRsjzMUjRcf+R2hz7Ds1UvVyYM0LWs= From: Steve Atkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 23 Jan 2017 07:39:52 -0800 References: <10036332.AbsS0sHdB9@kitterma-e6430> <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> To: "dmarc@ietf.org" In-Reply-To: Message-Id: <2B76A336-DA9E-4DAF-832D-FF10B4D8EC1B@wordtothewise.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 15:39:57 -0000 > On Jan 23, 2017, at 2:41 AM, Murray S. Kucherawy = wrote: >=20 > As I recall there are issues using keys bigger than 1024 bits because = construction and/or correct interpretation of TXT records that contain = keys of that size or bigger has been problematic due to DNS provisioning = software that does the former wrong and DKIM verifiers that do the = latter wrong. To my knowledge, nobody has ever shown evidence that the = larger keys are too computationally expensive to be used, or that any of = the other things mentioned in Section 3.3.3 of RFC6376 are actually a = problem. Yup. > If we can nail those issues down, I think a lot of the practical = resistance goes away, and ARC can easily say ">=3D 1024" or whatever we = want and be done with it. Fixing the DNS provision software everywhere isn't going to be trivial = (and there's even a slight question of what fixing it means - a TXT = record contains multiple strings and that DKIM concatenates them into a = single one is a DKIM thing, not a DNS TXT thing). Continuing to push for = that is a good thing, but it's going to take time. But fixing that isn't required for 1024 bit keys and I don't see any = good reason not to say ">=3D 1024 bits" today. Cheers, Steve= From nobody Mon Jan 23 07:49:53 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F480129644 for ; Mon, 23 Jan 2017 07:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 MpjI-1Z0BMPS for ; Mon, 23 Jan 2017 07:49:51 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C941295E3 for ; Mon, 23 Jan 2017 07:49:51 -0800 (PST) Received: (qmail 15556 invoked from network); 23 Jan 2017 15:49:50 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jan 2017 15:49:50 -0000 Date: 23 Jan 2017 15:49:28 -0000 Message-ID: <20170123154928.63663.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 15:49:52 -0000 In article you write: >I'd like to come up with something better than updating DKIM every time >there's new advice on key sizes, etc. Doing one update that points to the >best current advice, and then letting that other thing get updated >whenever, would be better. Otherwise at some point we'll need to update >DKIM and ARC, and then DKIM, ARC, and the next thing, etc. etc. > >But is there such a reference? I'm pretty sure there isn't. Having checked with Paul Hoffman last night, I have a slightly different version of the suggestion I made. The first is that ARC says that keys SHOULD be 2K and MUST be at least 1K. We understand the only likely deviation from the SHOULD to be due to DNS crudware that can't provision larger keys. Given the short lifetime of ARC signatures, this is cryptographically defensible. The second is to add a more modern signing algorithm. Paul suggests EdDSA with the ED25519 profile. It was designed by well-known civilian cryptographers with no help from the NSA, and there is a high quality reference implementation that everyone likes. A 256 bit EdDSA key is about as strong as a 3000 bit RSA key and the crypto operations are faster, so that's the last signing algorithm we're likely to need. For coding purposes, the minimum key size is just a parameter, and I would be astonished if changing the key size added as much as two lines of code to the implementations. Changing algorithms turns out not to be much harder -- the DKIM or ARC application calls signing and verification routines from a crypto library, and a different algorithm just means calling a different routine. A practical issue is that the most popular crypto library, OpenSSL, hasn't added EdDSA yet. They're currently on 1.0.2, and say it's supposed to be in 1.1.1 which will be released when it's released. So I'd suggest adding EdDSA to the spec, but not expect people to implement it yet. Then we can back-port the change into DKIM with what I hope would be a two-page update. This suggests a tweak to the ARC spec that we should make anyway. The way you do an algorithm migration, like the one we did from rsa-sha1 to rsa-sha256 is to put two signatures on the message for a while, one with the old algorithm and one with the new one. So a validator ignores signatures with algorithms it doesn't understand, and if there are two valid signatures with the same i=N using different algorithms, just pick one. R's, John From nobody Mon Jan 23 07:52:31 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB2C12964C for ; Mon, 23 Jan 2017 07:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 hRkncUkpMX1B for ; Mon, 23 Jan 2017 07:52:29 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C54129637 for ; Mon, 23 Jan 2017 07:52:29 -0800 (PST) Received: (qmail 15851 invoked from network); 23 Jan 2017 15:52:28 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jan 2017 15:52:28 -0000 Date: 23 Jan 2017 15:52:06 -0000 Message-ID: <20170123155206.63686.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 15:52:30 -0000 >As I recall there are issues using keys bigger than 1024 bits because >construction and/or correct interpretation of TXT records that contain keys >of that size or bigger has been problematic due to DNS provisioning >software that does the former wrong and DKIM verifiers that do the latter >wrong. I entirely believe that the provisioning crudware gets it wrong, but I haven't heard of verifiers that don't handle multiple TXT strings. Are you thinking of any specific ones? I also agree that none of the other alleged issues are issues, although I still think that migrating to EdDSA would be a good idea. R's, John From nobody Mon Jan 23 07:59:40 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D4412963C for ; Mon, 23 Jan 2017 07:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyvZkp6IJXM4 for ; Mon, 23 Jan 2017 07:59:37 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 8217E129637 for ; Mon, 23 Jan 2017 07:59:37 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id w204so82514501oiw.0 for ; Mon, 23 Jan 2017 07:59:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cYc9Jis60I4+2N7hvcFe47sSAA0+3Hj1E5t2b1IunvE=; b=PSh8uCtDcIr0a1rWtvIcmjobrgIVowsxxD4EI3mK4ConkK8Y1f0xU4udtsHN5y3xB/ vJtOMiGqHWSY3DPN86GGFD+GXmBL5TgsS3/pIf4bnD87x9N1Ydq6yzI+PkRj6ueMBfOa 6gpEKBl1g6YEP3TKxSKBlWc2sSVyUli8X7nQs= 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=cYc9Jis60I4+2N7hvcFe47sSAA0+3Hj1E5t2b1IunvE=; b=e05it/14KMDLHQiYMfBRoO2BWMugv/4sVLhIgLjSQbExTppdx4Q/s3IHGzGrXC5g7D a6VsOMXKCtXW9QPO8CrinOlZZeK53yUBetgc0YEKCoFEpZjW8XR7hAZgy1/X1PuRqeIo nkTmSaGUzXOEiYjqAic459czPp0h7cCLoevJqTSOLE0VbVMfkWc02UCJGCWHFGvx/Ycn cAPK5Ikn9CC6DHrBh1WwvaN1nmNEnUrz+5p/rfLy9AaymOtbqFOndYRfQHm41zztKqB5 7s1f47WDJAlAIrshpfSW42mnjRmclBthuhA4hWQbpNxn73ZP/yPISfvzAhtKQEBBLGVs 5w/A== X-Gm-Message-State: AIkVDXLsEN5cj+k/cccyC04vjutvUX8ch+spsM0gutOjqXjaE4RV0oQM2u4jWiPz4EwabHsERB4TyPtMr3lf0Q== X-Received: by 10.202.244.22 with SMTP id s22mr15075076oih.190.1485187176701; Mon, 23 Jan 2017 07:59:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.184.69 with HTTP; Mon, 23 Jan 2017 07:59:36 -0800 (PST) In-Reply-To: <20170123154928.63663.qmail@ary.lan> References: <20170123154928.63663.qmail@ary.lan> From: Kurt Andersen Date: Mon, 23 Jan 2017 07:59:36 -0800 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a1135124a17b68b0546c516a1 Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 15:59:39 -0000 --001a1135124a17b68b0546c516a1 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 23, 2017 at 7:49 AM, John Levine wrote: > > The first is that ARC says that keys SHOULD be 2K and MUST be at least > 1K. > OK, I'm convinced. I'll add that info in and also update the usage doc with additional explanation. > This suggests a tweak to the ARC spec that we should make anyway. The > way you do an algorithm migration, like the one we did from rsa-sha1 > to rsa-sha256 is to put two signatures on the message for a while, one > with the old algorithm and one with the new one. So a validator > ignores signatures with algorithms it doesn't understand, and if there > are two valid signatures with the same i=N using different algorithms, > just pick one. > This sounds like something that we should definitely add so that there is clarity, but it does add a situation where cv=unknown might happen if the previous step only signed with an algorithm that was not understood. --Kurt --001a1135124a17b68b0546c516a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 23, 2017 at 7:49 AM, John Levine <johnl@taugh.com> wro= te:

The first is that ARC says that keys SHOULD be 2K and MUST be at least
1K.=C2=A0

OK, I'm convinced. I'= ;ll add that info in and also update the usage doc with additional explanat= ion.
=C2=A0
This suggests a t= weak to the ARC spec that we should make anyway.=C2=A0 The
way you do an algorithm migration, like the one we did from rsa-sha1
to rsa-sha256 is to put two signatures on the message for a while, one
with the old algorithm and one with the new one.=C2=A0 So a validator
ignores signatures with algorithms it doesn't understand, and if there<= br> are two valid signatures with the same i=3DN using different algorithms, just pick one.

This sounds like somethi= ng that we should definitely add so that there is clarity, but it does add = a situation where cv=3Dunknown might happen if the previous step only signe= d with an algorithm that was not understood.

--Kur= t=C2=A0
--001a1135124a17b68b0546c516a1-- From nobody Mon Jan 23 08:05:25 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9720129661 for ; Mon, 23 Jan 2017 08:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXSn3e7mUdPM for ; Mon, 23 Jan 2017 08:05:22 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88301129656 for ; Mon, 23 Jan 2017 08:05:22 -0800 (PST) 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 6F860C4022B; Mon, 23 Jan 2017 10:05:20 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1485187520; bh=MZN9ylVhuhKY+FAmLrhm0DnBrewLJ4waxei6IP4uMGI=; h=Date:In-Reply-To:References:Subject:To:From:From; b=wr77gFE9mMbnFnAgbHRKdQmGj1gvupIfZRaqEeTK88Zft8vwFLqCwwQj6QLIjOjUv pfZZBljPLAtijqA/iopKGzwVruZ+zM9DWbLfMjBf40R6pvnIqXeOIK62LF0gyEiQq3 Mlll3hFvcRrmIAzpZhnjm80A1zJzkCNBveslSdZY= Date: Mon, 23 Jan 2017 16:05:04 +0000 In-Reply-To: <20170123155206.63686.qmail@ary.lan> References: <20170123155206.63686.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <50FC0AEB-C690-4F18-970A-BEFDF4262BFC@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 16:05:24 -0000 On January 23, 2017 10:52:06 AM EST, John Levine wrote= : >>As I recall there are issues using keys bigger than 1024 bits because >>construction and/or correct interpretation of TXT records that contain >keys >>of that size or bigger has been problematic due to DNS provisioning >>software that does the former wrong and DKIM verifiers that do the >latter >>wrong=2E > >I entirely believe that the provisioning crudware gets it wrong, but I >haven't heard of verifiers that don't handle multiple TXT strings=2E > >Are you thinking of any specific ones? In the context of SPF, this has been an occasional problem=2E Despite RFC= 7208 (and RFC 4408 and I think all the non-IETF specs that came before) sp= ecifically specifying that multiple TXT strings should be concatenated, I'v= e seen cases where some implementation insisted a space be added between th= e strings=2E It's been awhile since I've seen this, so it may not be a problem anymore= =2E There is no obviously correct thing that someone won't screw up=2E It's probably better to specify how to put multiple strings together=2E R= FC 7208 has words that can probably be reused without modification=2E Scott K From nobody Mon Jan 23 08:12:52 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AA312966D for ; Mon, 23 Jan 2017 08:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=0r0IXh23; dkim=pass (1536-bit key) header.d=taugh.com header.b=p8wmApgh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AK-0gUmVlFI for ; Mon, 23 Jan 2017 08:12:49 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6234812965F for ; Mon, 23 Jan 2017 08:12:49 -0800 (PST) Received: (qmail 19087 invoked from network); 23 Jan 2017 16:12:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4a8d.58862b80.k1701; bh=twgFsIp2CmzSjz3/v4MbRdIa5QNQA21KPVmzMbSsxk8=; b=0r0IXh23t2nZXjwp7LJZJBsgWB0cUi0CtlRRKAzZ60bLVIsv6yLfNtTPdHGhaHn1K+01jevcFIJU+JlNfJK2E7fW+HuC67QUO24rCXzvCv1FG/HMNNu6+GL6wkYRtEhPtuUfDWUcEzP3s/3Pb7p+utzOXrXIKkfSYbVCWJASjTItUIY/QcU88/7I7nC/1fRudzvFJwhQgMc0b3rFxfJIC4jChSPDU+3XmgsX3rz3Z7o+NESrWRCE1Ax3kq+EOc0+ 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=4a8d.58862b80.k1701; bh=twgFsIp2CmzSjz3/v4MbRdIa5QNQA21KPVmzMbSsxk8=; b=p8wmApghdHSmVRY2BmdOYoJFQRMGKYCqSDq1mw5oaz1A3VaGm2w2uf61mOmiQu2SckMWG6iR99QIcb5yi29DoryJwVNzr+h1oBvyks0QGXT2j5UMGo+la6f/5I+Zjj3Edf8S1sgS7PPAD1goRueBAt34UEE+q0wsaEK9f6piETX49uXm74bCnjfvRp9iD13i9zXSZgtakUAhuB0cDj68NjFKAsWHH/jBgxg6UpvyFo0cXzXqFSvWj6DX7Vc3ncm3 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.0/X.509/SHA1) via TCP6; 23 Jan 2017 16:12:48 -0000 Date: 23 Jan 2017 11:12:48 -0500 Message-ID: From: "John R Levine" To: "Kurt Andersen" In-Reply-To: References: <20170123154928.63663.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 16:12:51 -0000 > This sounds like something that we should definitely add so that there is > clarity, but it does add a situation where cv=unknown might happen if the > previous step only signed with an algorithm that was not understood. Right -- you can't tell a signature with an unknown algorithm with one that's just fake. 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 Jan 23 09:08:52 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7916D12967C for ; Mon, 23 Jan 2017 09:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 zbWGWNCg9MCG for ; Mon, 23 Jan 2017 09:08:49 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7B3129672 for ; Mon, 23 Jan 2017 09:08:48 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id l7so135211782qtd.1 for ; Mon, 23 Jan 2017 09:08:48 -0800 (PST) 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=TjEo4BliIXHsRQTyFAs7EXvSn0KHqRyS1emC0f2y+T0=; b=PXRkJJOMLJJDFEbb/0m49anlJTCPuiEKK1rV8Oi08gT48j2l/AmUIIulxVPbXriRKD sJGc5zGPSvz1z0OH3EFeyLmDYLFRS1QmbCrOyR3xPjrvGolHZZX85VKPMetN31qudYjf kqEJukhc1ncLVetZ0qG7JL6aPQcZIBBQMKmsBxRc6242dlIUs+PZK4J/2qnFaL/0mi5K 79eXFFoW8BSw8wZ2ZC0vQ/jaKP12aKegt6mPIyx1h+ufp+YICw2on9r6aTK1TW05IgAZ pQWj7NKbx5rhHyluampXfPm48v7yW2/VmJshHeIVWHnHhQwJun8zo63BcS5ezN389+Ln blaQ== 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=TjEo4BliIXHsRQTyFAs7EXvSn0KHqRyS1emC0f2y+T0=; b=SrSqyQs9PbqX0UI23cdUE2gY23qcSe2t/S2WNMsgHKEcxgfbMy4+cTMJqCmsHDJmPN GjDSj1vInr+jB9xsA3d3oz2r0FaYc+T2FL+aOmunz3icwtnHMkWj7CiwJN0X8p/TfmYb mYmYN6KCcX9ZQMHhJ5/4HfCzPXYvGerlxVSEGFpkmLAKj+L8SnmAVo5+kw1CLawB3kLR It/TtFPfLT2TCyNncBW9OBdsoeOYpUS1gNGsrswqjWhy6NJb/Sct90f61F/R8iCga0eo fDL0SZUzDHZQQYUa197/HeNXtLAcSVq72omrkOhT8DlCQ1KR7szNbpSu4iJ43MyfJDaV RF0Q== X-Gm-Message-State: AIkVDXJJDDFeuz8MjoDw9RyCKPiesXPHZaxt2nGqHn/qu+sfnjGOP6JgUZ1iB3Z8gRNhBuKCECdAr5x12NGsPQ== X-Received: by 10.237.53.201 with SMTP id d9mr25843205qte.235.1485191327808; Mon, 23 Jan 2017 09:08:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.129.247 with HTTP; Mon, 23 Jan 2017 09:08:47 -0800 (PST) In-Reply-To: <20170123154928.63663.qmail@ary.lan> References: <20170123154928.63663.qmail@ary.lan> From: Peter Goldstein Date: Mon, 23 Jan 2017 09:08:47 -0800 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a11c02be084a61e0546c60dca Archived-At: Cc: dmarc@ietf.org, Murray superuser Kucherawy Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 17:08:51 -0000 --001a11c02be084a61e0546c60dca Content-Type: text/plain; charset=UTF-8 > > The first is that ARC says that keys SHOULD be 2K and MUST be at least > 1K. We understand the only likely deviation from the SHOULD to be due > to DNS crudware that can't provision larger keys. Given the short > lifetime of ARC signatures, this is cryptographically defensible. +1, with the suggested modification that ARC says that keys SHOULD be 2K or larger. Verifiers should be required to support keys from 1024 bits up to some larger value like 4096 bits, to give some future proofing for anyone who really, really wants to use RSA. As John notes, there's not much difference between handling 2K, 4K, or 8K keys from an implementation standpoint. > The second is to add a more modern signing algorithm. Paul suggests > EdDSA with the ED25519 profile. It was designed by well-known > civilian cryptographers with no help from the NSA, and there is a high > quality reference implementation that everyone likes. A 256 bit EdDSA > key is about as strong as a 3000 bit RSA key and the crypto operations > are faster, so that's the last signing algorithm we're likely to need. I strongly support the idea of adding a more modern signing algorithm as part of ARC (and ideally eventually backport support to DKIM). RSA and DSA are no longer state of the art. The specific suggestion he conveys from Paul (EdDSA with the ED25519 profile) sounds in line with current best practices, and is widely used and supported ( https://ianix.com/pub/ed25519-deployment.html). And the smaller key size obviously helps mitigate the broader DNS TXT record length concern. This suggests a tweak to the ARC spec that we should make anyway. The > way you do an algorithm migration, like the one we did from rsa-sha1 > to rsa-sha256 is to put two signatures on the message for a while, one > with the old algorithm and one with the new one. So a validator > ignores signatures with algorithms it doesn't understand, and if there > are two valid signatures with the same i=N using different algorithms, > just pick one. +1 Best, Peter On Mon, Jan 23, 2017 at 7:49 AM, John Levine wrote: > In article gmail.com> you write: > >I'd like to come up with something better than updating DKIM every time > >there's new advice on key sizes, etc. Doing one update that points to the > >best current advice, and then letting that other thing get updated > >whenever, would be better. Otherwise at some point we'll need to update > >DKIM and ARC, and then DKIM, ARC, and the next thing, etc. etc. > > > >But is there such a reference? > > I'm pretty sure there isn't. > > Having checked with Paul Hoffman last night, I have a slightly different > version of the suggestion I made. > > The first is that ARC says that keys SHOULD be 2K and MUST be at least > 1K. We understand the only likely deviation from the SHOULD to be due > to DNS crudware that can't provision larger keys. Given the short > lifetime of ARC signatures, this is cryptographically defensible. > > The second is to add a more modern signing algorithm. Paul suggests > EdDSA with the ED25519 profile. It was designed by well-known > civilian cryptographers with no help from the NSA, and there is a high > quality reference implementation that everyone likes. A 256 bit EdDSA > key is about as strong as a 3000 bit RSA key and the crypto operations > are faster, so that's the last signing algorithm we're likely to need. > > For coding purposes, the minimum key size is just a parameter, and I > would be astonished if changing the key size added as much as two > lines of code to the implementations. Changing algorithms turns out > not to be much harder -- the DKIM or ARC application calls signing and > verification routines from a crypto library, and a different algorithm > just means calling a different routine. > > A practical issue is that the most popular crypto library, OpenSSL, > hasn't added EdDSA yet. They're currently on 1.0.2, and say it's > supposed to be in 1.1.1 which will be released when it's released. > So I'd suggest adding EdDSA to the spec, but not expect people to > implement it yet. Then we can back-port the change into DKIM with > what I hope would be a two-page update. > > This suggests a tweak to the ARC spec that we should make anyway. The > way you do an algorithm migration, like the one we did from rsa-sha1 > to rsa-sha256 is to put two signatures on the message for a while, one > with the old algorithm and one with the new one. So a validator > ignores signatures with algorithms it doesn't understand, and if there > are two valid signatures with the same i=N using different algorithms, > just pick one. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a11c02be084a61e0546c60dca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The first is that ARC says that keys SHOULD be 2K = and MUST be at least
1K.=C2=A0 W= e understand the only likely deviation from the SHOULD to be due
= to DNS crudware that can't provision l= arger keys.=C2=A0 Given the short
lifetime of ARC signatures, this is cryptographically defensible.<= /blockquote>

+1, with the suggested modification that ARC = says that keys SHOULD be 2K or larger.

Verifi= ers should be required to support keys from 1024 bits up to some larger val= ue like 4096 bits, to give some future proofing for anyone who really, real= ly wants to use RSA. =C2=A0 As John notes, there's not much difference = between handling 2K, 4K, or 8K keys from an implementation standpoint.
=C2=A0
= The second is to add a more modern signing= algorithm.=C2=A0 Paul suggests
= EdDSA with the ED25519 profile.=C2=A0 It was designed by well-known
civilian cryptographers with no help fr= om the NSA, and there is a high
= quality reference implementation that everyone likes.=C2=A0 A 256 bit EdDSA=
key is about as strong as a 300= 0 bit RSA key and the crypto operations
are faster, so that's the last signing algorithm we're like= ly to need.

I strongly support the i= dea of adding a more modern signing algorithm as part of ARC (and ideally e= ventually backport support to DKIM).=C2=A0 RSA and DSA are no longer state = of the art.=C2=A0 The specific suggestion he conveys from Paul (EdDSA with the ED25519 profile)=C2=A0sounds in= line with current best practices, and is widely used and supported (https://ianix.com/pub/e= d25519-deployment.html).=C2=A0 And the smaller key size obviously helps= mitigate the broader DNS TXT record length concern.
This suggests a tweak to the ARC spec that we should make an= yway.=C2=A0 The
way you do an al= gorithm migration, like the one we did from rsa-sha1
to rsa-sha256 is to put two signatures on the message= for a while, one
with the old a= lgorithm and one with the new one.=C2=A0 So a validator
ignores signatures with algorithms it doesn't u= nderstand, and if there
are two = valid signatures with the same i=3DN using different algorithms,
= just pick one.
+1

Best,

Peter

On Mon, Jan 23, 2017 at 7:49 AM, John Levine <johnl@taugh.c= om> wrote:
In article <CAL0qLwbYXLn1Z8QHEg=3DZnn3Os5BC4WnTtHXAgkAECuKsLqfVWQ@mail.gmail.com> you write:
>I'd like to come up with something better than updating DKIM every = time
>there's new advice on key sizes, etc.=C2=A0 Doing one update that p= oints to the
>best current advice, and then letting that other thing get updated
>whenever, would be better.=C2=A0 Otherwise at some point we'll need= to update
>DKIM and ARC, and then DKIM, ARC, and the next thing, etc. etc.
>
>But is there such a reference?

I'm pretty sure there isn't.

Having checked with Paul Hoffman last night, I have a slightly different version of the suggestion I made.

The first is that ARC says that keys SHOULD be 2K and MUST be at least
1K.=C2=A0 We understand the only likely deviation from the SHOULD to be due=
to DNS crudware that can't provision larger keys.=C2=A0 Given the short=
lifetime of ARC signatures, this is cryptographically defensible.

The second is to add a more modern signing algorithm.=C2=A0 Paul suggests EdDSA with the ED25519 profile.=C2=A0 It was designed by well-known
civilian cryptographers with no help from the NSA, and there is a high
quality reference implementation that everyone likes.=C2=A0 A 256 bit EdDSA=
key is about as strong as a 3000 bit RSA key and the crypto operations
are faster, so that's the last signing algorithm we're likely to ne= ed.

For coding purposes, the minimum key size is just a parameter, and I
would be astonished if changing the key size added as much as two
lines of code to the implementations.=C2=A0 Changing algorithms turns out not to be much harder -- the DKIM or ARC application calls signing and
verification routines from a crypto library, and a different algorithm
just means calling a different routine.

A practical issue is that the most popular crypto library, OpenSSL,
hasn't added EdDSA yet.=C2=A0 They're currently on 1.0.2, and say i= t's
supposed to be in 1.1.1 which will be released when it's released.
So I'd suggest adding EdDSA to the spec, but not expect people to
implement it yet.=C2=A0 Then we can back-port the change into DKIM with
what I hope would be a two-page update.

This suggests a tweak to the ARC spec that we should make anyway.=C2=A0 The=
way you do an algorithm migration, like the one we did from rsa-sha1
to rsa-sha256 is to put two signatures on the message for a while, one
with the old algorithm and one with the new one.=C2=A0 So a validator
ignores signatures with algorithms it doesn't understand, and if there<= br> are two valid signatures with the same i=3DN using different algorithms, just pick one.

R's,
John

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



--
=
=


3D"logo

Bringing Trust to= Email

Peter Goldstei= n | CTO & Co-Founder

peter@valimail.= com

+1.415.793.57= 83
<= /div>
--001a11c02be084a61e0546c60dca-- From nobody Mon Jan 23 09:50:17 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26E41296D4 for ; Mon, 23 Jan 2017 09:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tnpi.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaxftlQ2xSLD for ; Mon, 23 Jan 2017 09:50:14 -0800 (PST) Received: from mail.theartfarm.com (mail.theartfarm.com [66.128.51.165]) by ietfa.amsl.com (Postfix) with SMTP id 1191C1296C2 for ; Mon, 23 Jan 2017 09:50:13 -0800 (PST) Received: (qmail 7111 invoked by uid 89); 23 Jan 2017 17:50:11 -0000 Received: from unknown (HELO mail.theartfarm.com) (172.16.15.9) by mail.theartfarm.com with SMTP; 23 Jan 2017 17:50:11 -0000 Authentication-Results: mail.theartfarm.com; iprev=pass; auth=pass (cram-md5); spf=fail smtp.mailfrom=tnpi.net Received-SPF: Fail (mail.theartfarm.com: domain of tnpi.net does not designate 50.170.76.253 as permitted sender) receiver=mail.theartfarm.com; identity=mailfrom; client-ip=66.128.51.165; helo=mattbook.simerson.net; envelope-from= Received-SPF: None (mail.theartfarm.com: domain of mattbook.simerson.net does not designate 50.170.76.253 as permitted sender) receiver=mail.theartfarm.com; identity=helo; client-ip=50.170.76.253; helo=mattbook.simerson.net; envelope-from= Received: from mattbook.simerson.net (c-50-170-76-253.hsd1.wa.comcast.net [50.170.76.253]) by mail.theartfarm.com (Haraka/2.8.12) with ESMTPSA id EBE21A9C-662A-49A9-980B-DC167A4DF05B.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Mon, 23 Jan 2017 09:50:09 -0800 From: Matt Simerson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 23 Jan 2017 09:50:02 -0800 References: <20170123154928.63663.qmail@ary.lan> To: dmarc@ietf.org In-Reply-To: <20170123154928.63663.qmail@ary.lan> Message-Id: <8F72566F-2350-4FB1-BD82-75DEAF0608DE@tnpi.net> X-Mailer: Apple Mail (2.3259) X-Haraka-p0f: os="Mac OS X " link_type="Ethernet or modem" distance=8 total_conn=1 X-Haraka-GeoIP: NA, US, WA, Seattle, 2696km X-Haraka-GeoIP-Received: 50.170.76.253:US X-Haraka-ASN: 7922 X-Haraka-FCrDNS: c-50-170-76-253.hsd1.wa.comcast.net X-Spam-ASN: X-Spam-DCC: sonic.net: spamassassin 1156; Body=1 Fuz1=1 Fuz2=1 X-Haraka-Karma: score: 11, good: 90, bad: 31, connections: 123, history: 59, awards: 116, 021, 133, 163, 150, 182, pass:relaying DKIM-Signature: v=1; a=rsa-sha256; bh=y0LDAJnZhzoHMt3/dyjIv0WQ3HobVcqhNfh6d1TOZds=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=xvDHCgsB2hVeS2qmRyMDN7ksObuPwUq5lD+F6/3K8RfNyLC34q3r7QV/F+yYhzFqfKoPs/O9RX7ImdE0jlHAe1Uy7VDFsfBBQQJt8cbB1M6mQna9o246kUT/8zaolfuPrQAWHbm/kfeT/4XIdqPEd/zqaKmQhT8K48C6WjMON17BgEM8iU4w8GY69B7q/m2DthRIu6041BI7xnWITemZdhut1Iq5dTQLt302oMG4lSIU2fS0b6XKWAPKA/IECil1iLhrR1YnBfjpE0WZdsSQaqFWBsufEvQ+wwpXo7WK4iu6V+TOfhLHHluuKMRtsTaDjtQSD/dnNhHGUXK5DZs0tg== Archived-At: Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 17:50:15 -0000 > On Jan 23, 2017, at 7:49 AM, John Levine wrote: >=20 > In article = = you write: >> I'd like to come up with something better than updating DKIM every = time >> there's new advice on key sizes, etc. Doing one update that points = to the >> best current advice, and then letting that other thing get updated >> whenever, would be better. Yes. Thank you. Yes. >> Otherwise at some point we'll need to update >> DKIM and ARC, and then DKIM, ARC, and the next thing, etc. etc. >>=20 >> But is there such a reference? >=20 > I'm pretty sure there isn=E2=80=99t. https://www.keylength.com/en/ Use this site to determine what cipher suite and key length you need to = meet [NIST/ANSSI/IAD-NSA/=E2=80=A6BSI] minimum level of security.=20 See also: https://wiki.mozilla.org/Security/Server_Side_TLS from the = fine folks at https://cipherli.st. It=E2=80=99s a list of ciphers and = key lengths that have no known (public) vulnerabilities. For at least = the past few years, it has been kept impeccably up-to-date. > The first is that ARC says that keys SHOULD be 2K and MUST be at least > 1K. We understand the only likely deviation from the SHOULD to be due > to DNS crudware that can't provision larger keys. Given the short > lifetime of ARC signatures, this is cryptographically defensible. Given the half-life of IETF documents, I think this advice is still prey = to the =E2=80=9Cthat cipher suite / key length isn=E2=80=99t secure any = more=E2=80=9D problem as the existing documents. Instead, I think = something like this is more appropriate: Keys SHOULD meet the minimum NIST and/or BSI recommendations = (see https://www.keylength.com/). In 2017, the minimum bit length for = factoring modulus keys is 2048, for elliptical curve is 256 and for = hashes (SHA-*) is 256. The minimum numbers are stated and their shelf life is implied. To be = secure after 2017, implementers will have to do a little bit of homework = to look up key lengths, but that=E2=80=99s really no different than = before. At least now we=E2=80=99re providing a reference. We should recommend secure defaults and let users of DNS crudware = harangue their vendors or find new ones that can support publishing = secure keys. We=E2=80=99re also foreshadowing long key lengths next = year. > The second is to add a more modern signing algorithm. Paul suggests > EdDSA with the ED25519 profile. +1 > It was designed by well-known > civilian cryptographers with no help from the NSA, and there is a high > quality reference implementation that everyone likes. A 256 bit EdDSA > key is about as strong as a 3000 bit RSA key and the crypto operations > are faster, so that's the last signing algorithm we're likely to need. LOL. EC is currently quite robust but let=E2=80=99s not forget that we = are but one novel new attack away from those faster crypto operations = becoming a liability. Then we=E2=80=99ll all be jacking up our EC key = lengths to compensate. Matt= From nobody Mon Jan 23 10:39:07 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041A912978B for ; Mon, 23 Jan 2017 10:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H003xRkH13tk for ; Mon, 23 Jan 2017 10:39:04 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BD8129785 for ; Mon, 23 Jan 2017 10:39:04 -0800 (PST) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 80CF1C40242 for ; Mon, 23 Jan 2017 12:39:03 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1485196743; bh=/q86hYLxWe6pqdCoTt84uWpMs6Lb9gRFpwVV+m/6k8U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Fbdn3isKwV3t6nHb0yvBDlxkY78KfBQbnQUlAIpPoWDUJg2fElfN0Ip9U9rhsMrWv 0yTOsr4+g2RXeZBibndO39FsjCchocuI5GuyPK4UheOwY5ehZKVgTbjbaIqeYMfdD+ 6m8PBoqX0A33pfgpV1cVQZZTWlFBxU2uWB5bWoyY= From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 23 Jan 2017 13:39:03 -0500 Message-ID: <3176450.D4QEWlYblX@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-106-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20170123154928.63663.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 18:39:06 -0000 On Monday, January 23, 2017 07:59:36 AM Kurt Andersen wrote: > On Mon, Jan 23, 2017 at 7:49 AM, John Levine wrote: > > The first is that ARC says that keys SHOULD be 2K and MUST be at least > > 1K. > > OK, I'm convinced. I'll add that info in and also update the usage doc with > additional explanation. In case you want a reference, I just rediscovered this: http://www.kb.cert.org/vuls/id/268267 That's, I believe, where the current minimum comes from. Scott K From nobody Mon Jan 23 10:48:28 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C8612978C for ; Mon, 23 Jan 2017 10:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8ckiJcDkPAT for ; Mon, 23 Jan 2017 10:48:25 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7CC129771 for ; Mon, 23 Jan 2017 10:48:25 -0800 (PST) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id F2481C40242 for ; Mon, 23 Jan 2017 12:48:24 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1485197305; bh=q0CpAIabbHlH2ZSqSCDfAZEucQnJPwgAjSBqHQV2GKg=; h=From:To:Subject:Date:From; b=gOGUzDscbUoWa8czC4yhqhtB2ibFgXvdZPh/z8nyqxb65VsyHE2LwEnsR5zBJPplT VZrg1F/qAmSSdEv0Whwqx0aOcysB8vszmfpidnxBVCIVqvjHpwjbz4EzOMql7RsQCp 3K5IwphMBCLLpSHD1yd8ouz/r6gcIL4hFU80Xh0s= From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 23 Jan 2017 13:48:24 -0500 Message-ID: <2364156.S6dzM0ubLe@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-106-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] ARC capable version of dkimpy released X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 18:48:27 -0000 I've convinced myself that the ARC support in dkimpy works well enough to merit a release. Thanks to Brandon Long and Gene Shuman for all the heavy lifting they did to accomplish this. It can be downloaded either from pypi [1] or Launchpad [2]. Bug reports should go to the dkimpy bug tracker [3] and not here (mailing lists are horrible bug trackers). Scott K [1] https://pypi.python.org/pypi/dkimpy/0.6.0 [2] https://launchpad.net/dkimpy/0.6/0.6.0 [3] https://bugs.launchpad.net/dkimpy/+filebug From nobody Mon Jan 23 10:55:50 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28791297A8 for ; Mon, 23 Jan 2017 10:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 631A36yJW2-P for ; Mon, 23 Jan 2017 10:55:47 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501711297C1 for ; Mon, 23 Jan 2017 10:55:46 -0800 (PST) Received: (qmail 41332 invoked from network); 23 Jan 2017 18:55:45 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jan 2017 18:55:45 -0000 Date: 23 Jan 2017 18:55:23 -0000 Message-ID: <20170123185523.64081.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <8F72566F-2350-4FB1-BD82-75DEAF0608DE@tnpi.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: matt@tnpi.net Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 18:55:49 -0000 >We should recommend secure defaults and let users of DNS crudware harangue their vendors or find new ones that >can support publishing secure keys. We’re also foreshadowing long key lengths next year. Having been dealing with the crudware argument for a very long time* I can tell you that the chances of getting all the crudware fixed anytime soon are negligible, and nobody's going to change registrars because they can't publish 2K keys. That's why I suggested we add EdDSA. It's, ah, crudware resistant. R's, John * - see draft-levine-dnsextlang-09 From nobody Mon Jan 23 10:59:19 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6441112967E for ; Mon, 23 Jan 2017 10:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 xubLiqElAiTP for ; Mon, 23 Jan 2017 10:59:16 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36EB3129496 for ; Mon, 23 Jan 2017 10:59:16 -0800 (PST) Received: (qmail 41946 invoked from network); 23 Jan 2017 18:59:14 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jan 2017 18:59:14 -0000 Date: 23 Jan 2017 18:58:52 -0000 Message-ID: <20170123185852.64105.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <50FC0AEB-C690-4F18-970A-BEFDF4262BFC@kitterman.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 18:59:18 -0000 >It's been awhile since I've seen this, so it may not be a problem anymore. There is no obviously correct >thing that someone won't screw up. > >It's probably better to specify how to put multiple strings together. RFC 7208 has words that can probably be >reused without modification. Might as well use section 3.6.2.2. from RFC 6376, since the ARC keys are so similar to DKIM keys. I don't ever recall hearing about this problem with DKIM. I've been publishing multi-string keys for years and never had reports of breakage. R's, John From nobody Mon Jan 23 22:36:33 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E407129570 for ; Mon, 23 Jan 2017 22:36:32 -0800 (PST) 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 B2btkxp7BXCv for ; Mon, 23 Jan 2017 22:36:31 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21C7126CD8 for ; Mon, 23 Jan 2017 22:36:30 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id r136so106077464vke.1 for ; Mon, 23 Jan 2017 22:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RboYOn8ZT6ZNQFg93IhxYxIOIzsvqPYZ46HF4ux5mTc=; b=oSYjddP0u2iEVRk/Bpq2DqpbNWTv6wYA0jej6HV5FEfIHMbfC904PiyrWFY9+3VHHX ycDyPpz9jcewosLX6Zn1LbQGhrjD6BBlxnPegaqhS/nupTdoVSTfa/+b99wIP0yuGtPg jz8/UpUsUUyDmCgraxKFYcaukeoiMF2LJ+83VBvLrfW9rUuJtF3EapxVT6pyk2f13bkj NXPSSL7LOMJwX7bJ9PKAs7yYoXilXF2lJpe2JVEtPFfgysJ2TgZ/Nlai6BXVzxYcM0uv q4RSIOdJhprEK0pLj7WHSHl1asykOUn4p9Gv2zsRDfAjCEOaqRCrLez3pmrtCtpSXSoP jx7g== 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=RboYOn8ZT6ZNQFg93IhxYxIOIzsvqPYZ46HF4ux5mTc=; b=BPoG7Nr38/Fo6rKIr1cV5jKO++Rtk2IKFZXS3xqhzkilcGjgydgPil9KjSTTvoyb3Y A6DXrPaVVYbRX45dtLPQbVsmxFaOm8HpLNb+ZDnvmIP9nwwwYO6WO+4bDCO0cu9ivkXE H8EMC4ZpbRwiSme0iVjNH9X7310C+fzi5ywt+scnYtomtp3CwfmVLzyUn2xZd3EDs9Ap if8BltjOpKTSBX8b3iSSSua+edDWj1KbSqMW/IrhW03CsWqVR85LwXt3kIklv9/g/pI9 phUTfnZEye9taGfGUNaFgibxXo9L01+gTeC+LAraL5dfL2hFgeqgYcxCl4RV1YtqtW8B un5g== X-Gm-Message-State: AIkVDXJbacbjB9jGTz8pupEZjKEB5C+SKKYmGKnLmsmD0RQrSaVaXVecLB5tJWq7iSo9xQJgNskcF89qeCH+yA== X-Received: by 10.31.128.78 with SMTP id b75mr15119590vkd.174.1485239789604; Mon, 23 Jan 2017 22:36:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.150 with HTTP; Mon, 23 Jan 2017 22:36:28 -0800 (PST) In-Reply-To: <8F72566F-2350-4FB1-BD82-75DEAF0608DE@tnpi.net> References: <20170123154928.63663.qmail@ary.lan> <8F72566F-2350-4FB1-BD82-75DEAF0608DE@tnpi.net> From: "Murray S. Kucherawy" Date: Mon, 23 Jan 2017 22:36:28 -0800 Message-ID: To: Matt Simerson Content-Type: multipart/alternative; boundary=001a1142a4041108a90546d15673 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 06:36:32 -0000 --001a1142a4041108a90546d15673 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 23, 2017 at 9:50 AM, Matt Simerson wrote: > > LOL. EC is currently quite robust but let=E2=80=99s not forget that we ar= e but one > novel new attack away from those faster crypto operations becoming a > liability. Then we=E2=80=99ll all be jacking up our EC key lengths to com= pensate. > The last time I broached the topic of adding EC to DKIM, I was told there's no way that could proceed because EC was heavily encumbered by IPR claims. Is that no longer the case? -MSK --001a1142a4041108a90546d15673 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 23, 2017 at 9:50 AM, Matt Simerson <matt@tnpi.n= et> wrote:

LOL. EC is currently quite robust but let=E2=80=99s not forget that = we are but one novel new attack away from those faster crypto operations be= coming a liability. Then we=E2=80=99ll all be jacking up our EC key lengths= to compensate.

The last tim= e I broached the topic of adding EC to DKIM, I was told there's no way = that could proceed because EC was heavily encumbered by IPR claims.=C2=A0 I= s that no longer the case?

-MSK
--001a1142a4041108a90546d15673-- From nobody Mon Jan 23 22:38:37 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154FD12956E for ; Mon, 23 Jan 2017 22:38:37 -0800 (PST) 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 MC827U2zxDu2 for ; Mon, 23 Jan 2017 22:38:35 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1C5126CD8 for ; Mon, 23 Jan 2017 22:38:35 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id k127so105871104vke.0 for ; Mon, 23 Jan 2017 22:38:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5ZpgyHBgFxceaOSI7YWj5Xx5S0rtXs4qpPFB8CI8KQ4=; b=JdHDMOxwdepsuOXXXTmCK3pS7A3iJTL11FbUr+cBzrFNELWu+tAj29DVwtY0T6oLL5 mAMHAY2B7cSR3P+SIHz3fSjNuxwCT3VFkWVQBg80WjPJhv0rCTGdkKY1oZ5YTHw32nZS h66/GG6xbBlXtLwH0H5zfNY8BlSmAm3W1+3iuSShH72UjZj7pblAD3+XAvEZ5da4cQll 4xzLwcz5WBI0TrGKf+rHsxXXKrUABWxTpIAmu3O+BQeNSByhvrNHVH57EdCELVhRAiHN 1du1u7OJAjVyx9gQiR7fXP/aMcoLKwJp6N7M2a6UQqUyXBGmgKAiRLLRqVk5wqTQ9iZw 1IpA== 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=5ZpgyHBgFxceaOSI7YWj5Xx5S0rtXs4qpPFB8CI8KQ4=; b=HrNoyXE/oXOqpYeUFv0fkcc7sdXQxzaGTS6tN7czeq2hhmRImDFxC/8NJY1u4kOL8C kXVPLUlt37F5rJP6d1TbridtXs6KiLzOTBHYUVvJnvckTvgBE1RO+o3xGHG007c63XeA /7isSWF9DUhwA7QKRQ2KF39xwmyWqNrtXeDPWONSk7UGlpM2HQ7ILAiOjqNGw8DGIrkI 3k5Hyfi9gxH++JEdZF3bD+I29zJZlIT7BC0FxmagikHCU35EGg6iKvuyuXGM7rA/+6Vj WK0dCkwJHDdX5SLvYIuRJfQ3pGSMZ4yynq8/0xZ5fAbHXMeEb7SEyZmlIGRHrnpEJQQU 3nRg== X-Gm-Message-State: AIkVDXJy/BXfQeKvvLBGeV/PIm0EKKKX3pW9dVPTK7/SNJqy98NJfycLm08B0Us2lFms2g0RbG/KUaK5iYR7EQ== X-Received: by 10.31.134.200 with SMTP id i191mr15653895vkd.57.1485239914417; Mon, 23 Jan 2017 22:38:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.150 with HTTP; Mon, 23 Jan 2017 22:38:33 -0800 (PST) In-Reply-To: <20170123185852.64105.qmail@ary.lan> References: <50FC0AEB-C690-4F18-970A-BEFDF4262BFC@kitterman.com> <20170123185852.64105.qmail@ary.lan> From: "Murray S. Kucherawy" Date: Mon, 23 Jan 2017 22:38:33 -0800 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a114395ba81557a0546d15dc0 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 06:38:37 -0000 --001a114395ba81557a0546d15dc0 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 23, 2017 at 10:58 AM, John Levine wrote: > >It's been awhile since I've seen this, so it may not be a problem > anymore. There is no obviously correct > >thing that someone won't screw up. > > > >It's probably better to specify how to put multiple strings together. > RFC 7208 has words that can probably be > >reused without modification. > > Might as well use section 3.6.2.2. from RFC 6376, since the ARC keys > are so similar to DKIM keys. > > I don't ever recall hearing about this problem with DKIM. I've been > publishing multi-string keys for years and never had reports of > breakage. > It's been a long time since I've seen this problem in either the DKIM or SPF contexts (or any other), but it has happened, especially ten-ish years ago when they were both much younger. -MSK --001a114395ba81557a0546d15dc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 23, 2017 at 10:58 AM, John Levine <johnl@taugh.= com> wrote:
>It's been a= while since I've seen this, so it may not be a problem anymore.=C2=A0 T= here is no obviously correct
>thing that someone won't screw up.
>
>It's probably better to specify how to put multiple strings togethe= r.=C2=A0 RFC 7208 has words that can probably be
>reused without modification.

Might as well use section 3.6.2.2. from RFC 6376, since the ARC keys=
are so similar to DKIM keys.

I don't ever recall hearing about this problem with DKIM.=C2=A0 I'v= e been
publishing multi-string keys for years and never had reports of
breakage.

It's been a long time sin= ce I've seen this problem in either the DKIM or SPF contexts (or any ot= her), but it has happened, especially ten-ish years ago when they were both= much younger.

-MSK
--001a114395ba81557a0546d15dc0-- From nobody Tue Jan 24 11:44:39 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5181296B4 for ; Tue, 24 Jan 2017 11:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FrY1oUbjK0r for ; Tue, 24 Jan 2017 11:44:38 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B704A1296AF for ; Tue, 24 Jan 2017 11:44:37 -0800 (PST) Received: (qmail 64319 invoked from network); 24 Jan 2017 19:44:36 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 24 Jan 2017 19:44:36 -0000 Date: 24 Jan 2017 19:44:14 -0000 Message-ID: <20170124194414.68968.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 19:44:39 -0000 In article you write: >The last time I broached the topic of adding EC to DKIM, I was told there's >no way that could proceed because EC was heavily encumbered by IPR claims. >Is that no longer the case? RFC 7479 adds Ed25519 to SSH and has no IPR disclosures. Dan Bernstein is the primary author of Ed25519 and he's said it has no patent problems: https://cr.yp.to/ecdh/patents.html R's, John From nobody Tue Jan 24 15:44:55 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E62129596 for ; Tue, 24 Jan 2017 15:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ0pFdQDiz_Y for ; Tue, 24 Jan 2017 15:44:51 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712F812959C for ; Tue, 24 Jan 2017 15:44:51 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id v200so1761776ywc.3 for ; Tue, 24 Jan 2017 15:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c/dP1lkOqGUKOIHc0kvfFW1ZNJtMjpxlQmjo5XqADrA=; b=duhP9X3Lh48mCB4TeOOhDpMKc54F6pVFys6fzH35OEnJkbz3jdAthI5tFFUf/9k7TS 3CKB6GNd9K6RzL3+WZXi3e0kRh+VrFWSNuOD8NI6Lfit9p2s1wdjrXgWbSrBkVVaQ/No S6TOP76zk6T+icfrBCj5WxbTFcvGGVEU8mfeRppubJN/w/UZ+A79Ql37rdQzDbuua6Q4 TgfB/SnUKHi1yQH47tPYETTdZQKHgJn2pRkdDVk6RQPjiknYy9PUOL8EcMeW71ro88d8 chdAbhavaiQI6cVM24RAfdhYDsihnmkIwX6vLBF4sX+S/a9puXbK6GvVkH4WGqXuFvCa pcmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c/dP1lkOqGUKOIHc0kvfFW1ZNJtMjpxlQmjo5XqADrA=; b=udGiF0v9OY7LYLAhgeP4j2Ft81SEXdzHnbYDCUTZL0D/9erPukDNb4niuUrczmttX+ 3qgw00HDcuQfNJlEog4fjfRP6SztZHLL1W5Ex/+LbFm/n6b6vx1m/ei1abYArha2CQ1V jyxw3T8lsbZGCgUyMXzxZA+di5GzpjZhJ6iuywN1B295CD7i1Oewap72mHv0qhTCk1Nl a55iBmiezMjtvFIoUc3jHNmq0CtnwQQsnjJ62ebHsoKulCHrW/ppyE8fugDKtjrk4PFA P9s4ka0zeIt8hez/W2f4ZJICNoKf9kS2QebhfhFQDEvEZwIT2arP0WuSpoAAhSllIpsP okAQ== X-Gm-Message-State: AIkVDXJtohUhKqJnbmCi3d+nmnWZltC20WDpW49vEjF8kDFH76Vsj9QrHd6tP8DMpd4sMC7Q8vpbUZt0bOmyZ2Y8 X-Received: by 10.13.232.201 with SMTP id r192mr27636809ywe.232.1485301490519; Tue, 24 Jan 2017 15:44:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.8.198 with HTTP; Tue, 24 Jan 2017 15:44:49 -0800 (PST) In-Reply-To: References: <50FC0AEB-C690-4F18-970A-BEFDF4262BFC@kitterman.com> <20170123185852.64105.qmail@ary.lan> From: Brandon Long Date: Tue, 24 Jan 2017 15:44:49 -0800 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=94eb2c086f22baa3710546dfb393 Archived-At: Cc: Scott Kitterman , "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 23:44:54 -0000 --94eb2c086f22baa3710546dfb393 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 23, 2017 at 10:38 PM, Murray S. Kucherawy wrote: > On Mon, Jan 23, 2017 at 10:58 AM, John Levine wrote: > >> >It's been awhile since I've seen this, so it may not be a problem >> anymore. There is no obviously correct >> >thing that someone won't screw up. >> > >> >It's probably better to specify how to put multiple strings together. >> RFC 7208 has words that can probably be >> >reused without modification. >> >> Might as well use section 3.6.2.2. from RFC 6376, since the ARC keys >> are so similar to DKIM keys. >> >> I don't ever recall hearing about this problem with DKIM. I've been >> publishing multi-string keys for years and never had reports of >> breakage. >> > > It's been a long time since I've seen this problem in either the DKIM or > SPF contexts (or any other), but it has happened, especially ten-ish years > ago when they were both much younger. > We went to 2048 bit keys in 2012, after doing some tests (and being at 1536 for a bit), but haven't had any reported problems. I think people who care about DKIM will fix what they need to, not sure if ARC will be more widely used than DKIM. I'm not opposed to requiring support for different encryption algorithms, but we really need to clean up and understand exactly how we handle migration to a new algorithm, probably with a section in the draft specific to it with an example. Brandon --94eb2c086f22baa3710546dfb393 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 23, 2017 at 10:38 PM, Murray S. Kucherawy <superuser@gma= il.com> wrote:
On Mon, Jan 23, 2017 at 10:58 AM, John Levine <johnl@t= augh.com> wrote:
&= gt;It's been awhile since I've seen this, so it may not be a proble= m anymore.=C2=A0 There is no obviously correct
>thing that someone won't screw up.
>
>It's probably better to specify how to put multiple strings togethe= r.=C2=A0 RFC 7208 has words that can probably be
>reused without modification.

Might as well use section 3.6.2.2. from RFC 6376, since the ARC keys=
are so similar to DKIM keys.

I don't ever recall hearing about this problem with DKIM.=C2=A0 I'v= e been
publishing multi-string keys for years and never had reports of
breakage.

It's been a long t= ime since I've seen this problem in either the DKIM or SPF contexts (or= any other), but it has happened, especially ten-ish years ago when they we= re both much younger.

We went to 2048 bit keys in 2012, after doing some tests (and being at 1= 536 for a bit), but haven't had any reported problems.=C2=A0 I think pe= ople who care about DKIM will fix what they need to, not sure if ARC will b= e more widely used than DKIM.

I'm not opposed = to requiring support for different encryption algorithms, but we really nee= d to clean up and understand exactly how we handle migration to a new algor= ithm, probably with a section in the draft specific to it with an example.<= /div>

Brandon=C2=A0
--94eb2c086f22baa3710546dfb393-- From nobody Tue Jan 24 15:51:24 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99221295AD for ; Tue, 24 Jan 2017 15:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=cVUUvpzu; dkim=pass (1536-bit key) header.d=taugh.com header.b=ui1j8cJx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2X4wxFo6Bv6 for ; Tue, 24 Jan 2017 15:51:22 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF75129580 for ; Tue, 24 Jan 2017 15:51:22 -0800 (PST) Received: (qmail 2552 invoked from network); 24 Jan 2017 23:51:21 -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=9f6.5887e879.k1701; bh=nYR6hWzpLYrLNCK9SabkXFHekM+4zoP18qpIyT49r8w=; b=cVUUvpzu0cBpnlzZ11YiBtbaj/QKqZgztVpvMsHGmcx8OzJ+h0cLtYCvqqwVDZKlYkirQ0wRrqKaCZ6Q9fgK8L/eDrrz08KxdhK7qvkGce0zXJoJhT8X5JdaWZp5htT30u+X9TwJToF+ILLsBf9niVuCtTFVon5MydNbYwY81X4zTN0aooYAUeqxRMcJgFmaaaqHNy+cj2i8ll1qZ5RjBn5dytJKCtqpEjaTAlob26r0n5T/wejspugLu8cx2SiH 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=9f6.5887e879.k1701; bh=nYR6hWzpLYrLNCK9SabkXFHekM+4zoP18qpIyT49r8w=; b=ui1j8cJxqpFU4/8kjBlu5S3IUVzqlMtjKdfaH0jw79erAvBAv8PjqJOIzjuD292CQ6GXOxUBlgpQFm9JUPEYWkd+vqSBk/hZPiDTLN2IAWJYHnsuHPNr08CKM0GxSlDX2X/o9V33pMNRkM9Gm3xvqKg6IoaZsQ8i9GDKlvTXeL/21Unj26/UZW6kGnB1lazklIHSljXXrjIOIlndW66au0WtGycwIceM2dAC87FhSljCramo8y1+wrB/7kkAvMe1 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.0/X.509/SHA1) via TCP6; 24 Jan 2017 23:51:21 -0000 Date: 24 Jan 2017 18:51:20 -0500 Message-ID: From: "John R Levine" To: "Brandon Long" In-Reply-To: References: <50FC0AEB-C690-4F18-970A-BEFDF4262BFC@kitterman.com> <20170123185852.64105.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 23:51:24 -0000 On Tue, 24 Jan 2017, Brandon Long wrote: > I'm not opposed to requiring support for different encryption algorithms, > but we really need to clean up and understand exactly how we handle > migration to a new algorithm, probably with a section in the draft specific > to it with an example. Fortunately, we have experience migrating from SHA1 to SHA256 hashes with DKIM. Basically, as soon as you have support for the new algorithm, you start signing with both old and new. After a while (likely a year or more) you try dropping the old signatures and see if your verification rates drop. I'd think that DMARC reports would be useful here. Eventually the verification rates are close enough that you stop using the old algorithm. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Jan 25 07:42:20 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F21129999 for ; Wed, 25 Jan 2017 07:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 EuWcxtjIC3fi for ; Wed, 25 Jan 2017 07:42:15 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 5FD7012984C for ; Wed, 25 Jan 2017 07:42:15 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id x49so23334275qtc.2 for ; Wed, 25 Jan 2017 07:42:15 -0800 (PST) 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=dn4V2ijRISO1EEk1XqrFgfG61pbytBjp7PFKhzL2jsU=; b=JbZfNb+bRSYbG0G0Eqa7f2AB4k8QGeV+ixP2LoXLd/FWAZBmssXD6Y7MyGIJZH3HOK fRw98zwubMUqon/unrFnrj1Qar2nbJYHl+nXoWCKdqQ2pHIYmfTCJ8f51g8zOJo4Hcto 6yba+1BJdbcTOMaKCj5vQVdgrB06li6wpw3oHHrtroxYF7TReJLH4Th3imwzoZLcTH7R Ab9ppMhUFVTWQmjLr7xjc8sfMyx319FSEx3FWYhlpx1Bazq4YI2YKTj5FQZUciTH9r/N wCmj13/xqhZmoN1I1JAORZWlON1lrHn1lBSPvZW2a3iSt/Tu2nY/1HFXYVnJwC5vvx4l Z/cQ== 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=dn4V2ijRISO1EEk1XqrFgfG61pbytBjp7PFKhzL2jsU=; b=JSCk93/eWyhpR+NTk2rBnpxXaRZP4uwuMDQccDxVamTbtZBad/sQoupv1vNBu1Bfbd U99Skqb1DgKcBDvAUE03IMrGGN91pEYcG5Q+TbkOSskfrZ7RJSzVqXdkOA13UYZY0QmQ 1OyESCZK+3qzmxKtmnk/Rzaillgw/7PJXeopUgd6/b0rC+skTNkKuGDwzTYaM94EUoWc ua/xaMDUXmOmnpj4ozTMTymLA7hfhP6oH4c1k1vIJj1k/wb/Sp0S63s+pywCAedxBZPC onDDBydQRZPmIhmE76kfmeKV7saFzCJfDI9Nf2icpL083xg7UHIUsPjBZde3ji1qJWAE /QnQ== X-Gm-Message-State: AIkVDXL9lsxs1M3KY7l14phzOGgfzBAf3ev7r98RMJv3XVnfuqMaIqi/ZrM453GK6rpHzJ3UvTYmohq/LrHiOA== X-Received: by 10.200.37.125 with SMTP id 58mr35474380qtn.232.1485358934240; Wed, 25 Jan 2017 07:42:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.129.247 with HTTP; Wed, 25 Jan 2017 07:42:13 -0800 (PST) In-Reply-To: <20170124194414.68968.qmail@ary.lan> References: <20170124194414.68968.qmail@ary.lan> From: Peter Goldstein Date: Wed, 25 Jan 2017 07:42:13 -0800 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a1141079aa3e60e0546ed13ce Archived-At: Cc: dmarc@ietf.org, Murray superuser Kucherawy Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 15:42:18 -0000 --001a1141079aa3e60e0546ed13ce Content-Type: text/plain; charset=UTF-8 And as a timely item on this topic, RFC 8032 (Edwards-Curve Digital Signature Algorithm) was just published - https://tools.ietf.org/html/rfc8032 It was specifically published to facilitate adoption in the Internet community. The RFC makes no mention of any IPR claims as far as I can tell from a quick read. Best, Peter On Tue, Jan 24, 2017 at 11:44 AM, John Levine wrote: > In article pWNCrD5+yg@mail.gmail.com> you write: > >The last time I broached the topic of adding EC to DKIM, I was told > there's > >no way that could proceed because EC was heavily encumbered by IPR claims. > >Is that no longer the case? > > RFC 7479 adds Ed25519 to SSH and has no IPR disclosures. > > Dan Bernstein is the primary author of Ed25519 and he's said it has no > patent problems: > > https://cr.yp.to/ecdh/patents.html > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a1141079aa3e60e0546ed13ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And as a timely item on this topic, RFC 8032 (Edwards-Curv= e Digital Signature Algorithm) was just published -=C2=A0https://tools.ietf.org/html/rfc8032
It was specifically published to facilitate a= doption in the Internet community.=C2=A0 The RFC makes no mention of any IP= R claims as far as I can tell from a quick read.

B= est,

Peter
<= br>
On Tue, Jan 24, 2017 at 11:44 AM, John Levine= <johnl@taugh.com> wrote:
In article <CAL0qLwZH=3DcxA5hyvktOR85dJ0useF5ska29dL= 6N=3DpWNCrD5+yg@mail.gm= ail.com> you write:
>The last time I broached the topic of adding EC to DKIM, I was told the= re's
>no way that could proceed because EC was heavily encumbered by IPR clai= ms.
>Is that no longer the case?

RFC 7479 adds Ed25519 to SSH and has no IPR disclosures.

Dan Bernstein is the primary author of Ed25519 and he's said it has no<= br> patent problems:

https://cr.yp.to/ecdh/patents.html

R's,
John

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



--
=
=


3D"logo

Bringing Trust to= Email

Peter Goldstei= n | CTO & Co-Founder

peter@valimail.= com

+1.415.793.57= 83
<= /div>
--001a1141079aa3e60e0546ed13ce-- From nobody Wed Jan 25 10:39:59 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F389C129AD5 for ; Wed, 25 Jan 2017 10:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsLrjU8klchR for ; Wed, 25 Jan 2017 10:39:55 -0800 (PST) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65388129AD4 for ; Wed, 25 Jan 2017 10:39:55 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id f67so16369047ybc.2 for ; Wed, 25 Jan 2017 10:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ffXWHH+S1iMaHaH+15Z9IgV1vktZ2G6bdADWawPFr4c=; b=BYrgSOaig2llhwESVw89vShjG06DczhxhAZvA5doIwzFUgdig9MNri8lKL41M/ZNCg Hzzo0xhgU8na9aSEP/9K6YCuqz1U4WVRYc1xPy8jo8uv2WCQef2vaacnS3sZ5JN2JTxp c7u608P0k5W7qPqyL4soyPgC4K1Tuj3HW+pRo2G6Euh4D5tf0XHMNpX0nfCObXtIY4cR 2mU5N/Eb6Y4ftXgyC7er6FQVUYh/OH6UeSp+1extCatO20M4C95P+u72CLMvspXZL4D6 gCm2ZLFCg9fDQVuuAB63J4In54hxqOinV95rJ0LEf5XITM7lOXFduzg7VoDBZexMI/BS Od1Q== 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=ffXWHH+S1iMaHaH+15Z9IgV1vktZ2G6bdADWawPFr4c=; b=sanXJAWcVKEAOk3UxMJckpC0+jWN53VPNdkS34N3wmCW4Ocb6EToTQFQ/WW9Wb9ejm Rjt9OSyYR3zYfiNm54G3aQLy1DnxGaS8Izo003uJkWv727inStLLS5yQmiCzs9oAi3lL /njT43UO1T//ud1QZOOhUjkBXG0IQxBNFW5oSSi1Fg7XOdPI4csQxq1ylU34JEgz+X4y uM6Vc7u0Z8yuLLLzdfBeU3x8x2G/MKmt+nDR/lInYptNdOWnYFuchgRiQIhctYhS+ZtT DEWv+rGNFrjlhM7dty55r0UiVK3N6AvKG9lfaNV2vgCMMhZn6eEs0tX/+Uww9a9xKPp3 CdhA== X-Gm-Message-State: AIkVDXLaQtPO0v1UG6gnF6AJGySXe6EMqVNop1pg2zm6GdIA2ui+Dr6agga7HAMbFsjJxohYmt51nNoc9KeXvfoz X-Received: by 10.129.39.214 with SMTP id n205mr30571695ywn.304.1485369594488; Wed, 25 Jan 2017 10:39:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.8.198 with HTTP; Wed, 25 Jan 2017 10:39:53 -0800 (PST) Received: by 10.37.8.198 with HTTP; Wed, 25 Jan 2017 10:39:53 -0800 (PST) In-Reply-To: References: <50FC0AEB-C690-4F18-970A-BEFDF4262BFC@kitterman.com> <20170123185852.64105.qmail@ary.lan> From: Brandon Long Date: Wed, 25 Jan 2017 10:39:53 -0800 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a1141ead60aa2bd0546ef8f61 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 18:39:58 -0000 --001a1141ead60aa2bd0546ef8f61 Content-Type: text/plain; charset=UTF-8 On Jan 24, 2017 3:51 PM, "John R Levine" wrote: On Tue, 24 Jan 2017, Brandon Long wrote: > I'm not opposed to requiring support for different encryption algorithms, > but we really need to clean up and understand exactly how we handle > migration to a new algorithm, probably with a section in the draft specific > to it with an example. > Fortunately, we have experience migrating from SHA1 to SHA256 hashes with DKIM. Basically, as soon as you have support for the new algorithm, you start signing with both old and new. After a while (likely a year or more) you try dropping the old signatures and see if your verification rates drop. I'd think that DMARC reports would be useful here. Eventually the verification rates are close enough that you stop using the old algorithm. Sure, with dkim. With arc, it's a bit more complicated, we need to understand exactly how to sign the chain if there are multiple AMS and AS headers. We probably want text about what happens if only one verifies as well, and whether a hop should continue signing both paths or just one. Brandon --001a1141ead60aa2bd0546ef8f61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 24, 2017 3:51 PM, "John R Levine" <johnl@taugh.com> wrote:
On Tue, 24 Jan 201= 7, Brandon Long wrote:
I'm not opposed to requiring support for different encryption algorithm= s,
but we really need to clean up and understand exactly how we handle
migration to a new algorithm, probably with a section in the draft specific=
to it with an example.

Fortunately, we have experience migrating from SHA1 to SHA256 hashes with D= KIM.

Basically, as soon as you have support for the new algorithm, you start sig= ning with both old and new.=C2=A0 After a while (likely a year or more) you= try dropping the old signatures and see if your verification rates drop. I= 'd think that DMARC reports would be useful here.=C2=A0 Eventually the = verification rates are close enough that you stop using the old algorithm.<= br>

Sure, with dkim. With arc, it's a bit more complicated, we need to= understand exactly how to sign the chain if there are multiple AMS and AS = headers.=C2=A0 We probably want text about what happens if only one verifie= s as well, and whether a hop should continue signing both paths or just one= .

Brandon
--001a1141ead60aa2bd0546ef8f61-- From nobody Wed Jan 25 11:58:04 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB04129B86 for ; Wed, 25 Jan 2017 11:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=teamaol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6jHj2PD72O0 for ; Wed, 25 Jan 2017 11:57:46 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BB4129B6A for ; Wed, 25 Jan 2017 11:57:46 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id k15so35970119qtg.3 for ; Wed, 25 Jan 2017 11:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamaol.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xmcWvcXTsjhkj0Qd93Ri8Y9VevCliyeZY2QSHT+ALSY=; b=RhaZ5Dhs4WXt9sB9tg0wQ/F8Y4mAXN1hZ/RAALMFWxbAZ72hTEcDhwxMdbtqWkm4Hu jSzS/8bP0cOny2WAjEaq7MZ8roar/TtT4NkW2Y22pf33mBZaf/GL12Y16T7RhUPGghCv TRx0QYTYkAhCKatrTt3XkJHZXqKq//PGQa/a5iybUMVuCXrp9ptTjb72jQvtTbgc2vwY Lvl2XB/lXmZc4JO4nr2Ur9mf+8FgevRTFFRcd/OLkJEaVMMebmLIfxe9F9HeDRlnYbiR M3WbRbFZQm+UF78mZl61Mtm0J/WkC26srkHRmkkviiZAtqVOwY8R8HS+vhQXLvtVg7SS KqaQ== 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=xmcWvcXTsjhkj0Qd93Ri8Y9VevCliyeZY2QSHT+ALSY=; b=mp8NZx3R0Cc5/8+jkqMw+kgATnx/I+PGVhprjzLMPDDLEZydcekK20ajjlMhDn5vj2 +ZBAcR78iUrG4vgtYl01RidpuZvYZrI57g+snoC0tFvLtNUDLZXIg1Wa2EaQUR4S9F4/ tlyy60teqBoPfiLsUeepEn/amPKKgondZshJ5o+CAKUKSgeOEsStaEN3NGiT9nwpcF5E +sFyLSZ9Nf85U+8HsdA8D8RzecMfQPMHrrGaOmiDafHtPOFwudkcS0zaOFDQa24eAO8e QCITFV/rd1/fyE+HLmhZXot/zlpbISPSYSa7/dyjtyEk/8+WokKkSN0SKcDYYFebUwJ0 EQ6A== X-Gm-Message-State: AIkVDXIA2s+SxBOUDhr0So0JcYA8zSxcPLh0RNxkP+vmcN2oKgpmydd3VGEzfLLswwlcTD70HNvcoL1B5kL/rGiS X-Received: by 10.200.40.177 with SMTP id i46mr35287581qti.279.1485374265807; Wed, 25 Jan 2017 11:57:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.42.45 with HTTP; Wed, 25 Jan 2017 11:57:45 -0800 (PST) In-Reply-To: References: <50FC0AEB-C690-4F18-970A-BEFDF4262BFC@kitterman.com> <20170123185852.64105.qmail@ary.lan> From: Paul Rock Date: Wed, 25 Jan 2017 14:57:45 -0500 Message-ID: To: Brandon Long Content-Type: multipart/alternative; boundary=001a1141b62878f72b0546f0a5b0 Archived-At: Cc: dmarc , John Levine Subject: Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 19:57:56 -0000 --001a1141b62878f72b0546f0a5b0 Content-Type: text/plain; charset=UTF-8 I see a rabbit hole here... So you're transitioning, so you sign twice (one with your old, one with your new) before you send to me.... and hey, I'm not the end point either, so I need to forward it along, but I'm also transitioning, so I sign both of yours, twice? I would kind of have to, wouldn't I? as I have no idea what downstream supports before I send to the next hop... On Wed, Jan 25, 2017 at 1:39 PM, Brandon Long wrote: > > > On Jan 24, 2017 3:51 PM, "John R Levine" wrote: > > On Tue, 24 Jan 2017, Brandon Long wrote: > >> I'm not opposed to requiring support for different encryption algorithms, >> but we really need to clean up and understand exactly how we handle >> migration to a new algorithm, probably with a section in the draft >> specific >> to it with an example. >> > > Fortunately, we have experience migrating from SHA1 to SHA256 hashes with > DKIM. > > Basically, as soon as you have support for the new algorithm, you start > signing with both old and new. After a while (likely a year or more) you > try dropping the old signatures and see if your verification rates drop. > I'd think that DMARC reports would be useful here. Eventually the > verification rates are close enough that you stop using the old algorithm. > > > Sure, with dkim. With arc, it's a bit more complicated, we need to > understand exactly how to sign the chain if there are multiple AMS and AS > headers. We probably want text about what happens if only one verifies as > well, and whether a hop should continue signing both paths or just one. > > Brandon > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- PAUL ROCK Principal Software Engineer | AOL Mail P: 703-265-5734 | C: 703-980-8380 AIM: paulsrock 22070 Broderick Dr.| Dulles, VA | 20166-9305 --001a1141b62878f72b0546f0a5b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see a rabbit hole here... So you're transitioning, s= o you sign twice (one with your old, one with your new) before you send to = me.... and hey, I'm not the end point either, so I need to forward it a= long, but I'm also transitioning, so I sign both of yours, twice? I wou= ld kind of have to, wouldn't I? as I have no idea what downstream suppo= rts before I send to the next hop...=C2=A0
=
On Wed, Jan 25, 2017 at 1:39 PM, Brandon Lon= g <blong@google.com> wrote:

On Jan 24, 2017 3:51 PM, "John R Levine&qu= ot; <johnl@taugh.co= m> wrote:
On Tue, 24 Ja= n 2017, Brandon Long wrote:
I'm not opposed to requiring support for different encryption algorithm= s,
but we really need to clean up and understand exactly how we handle
migration to a new algorithm, probably with a section in the draft specific=
to it with an example.

Fortunately, we have experience migrating from SHA1 to SHA256 hashes with D= KIM.

Basically, as soon as you have support for the new algorithm, you start sig= ning with both old and new.=C2=A0 After a while (likely a year or more) you= try dropping the old signatures and see if your verification rates drop. I= 'd think that DMARC reports would be useful here.=C2=A0 Eventually the = verification rates are close enough that you stop using the old algorithm.<= br>

Sure, with dkim. With arc, it's a bit more complicated, we = need to understand exactly how to sign the chain if there are multiple AMS = and AS headers.=C2=A0 We probably want text about what happens if only one = verifies as well, and whether a hop should continue signing both paths or j= ust one.

Brandon

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




--
=
PAUL ROCK
Principal Software Engineer | AOL Mai= l
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.<= /font>| Dulles, VA | 20166-9305
=
--001a1141b62878f72b0546f0a5b0-- From nobody Wed Jan 25 17:26:18 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BAA126D74 for ; Wed, 25 Jan 2017 17:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=MTecxMvv; dkim=pass (1536-bit key) header.d=taugh.com header.b=n78e/Sn+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI5A74uaTG9D for ; Wed, 25 Jan 2017 17:26:15 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75054129410 for ; Wed, 25 Jan 2017 17:26:15 -0800 (PST) Received: (qmail 87004 invoked from network); 26 Jan 2017 01:26:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=153da.58895036.k1701; bh=UcQ8REwJtJZ+PeYV/RN2Sd/JVXqzj9iJA3dnic89Wdw=; b=MTecxMvv2VdHC2fS944+RkbDwECRP/yx+87Pk+XGoxTPCa3fcyZE6sTbeddGLv7VUp2IRJYAcAqShcVLTV9DYh9GtBNlZJCq2+2pSdcCQRhCwRsLNtx3KMXmE2x65q//fKJ+489O+7PCErDDcRu0jQKoVoYP7mD3chczqcQvCpJF55QAChZSBhEwUYr/0HqZU2TpOzmHC8KXqPeZX1jllHv+nZ10Ax1Ea6nIUDeTZMtcHgW1YjMhKhLZDOl/8yJW 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=153da.58895036.k1701; bh=UcQ8REwJtJZ+PeYV/RN2Sd/JVXqzj9iJA3dnic89Wdw=; b=n78e/Sn++jnJXEY9qc+6FrndGcxMDExYUlUcmPJLmbZ3/ISAgsz0lw1rx8Ji7sAOEflhg3vFbPZ+TBp+2dUimlo6AYAcUhV6+bIAVEixHHgb4Oddh727rxTh642XutBqJ38sdMVAFLrO2QuD+qf8yxldo1BucuKL+ddbRMfvMzgCzC2NG8NaF7Mnibw/v1kSoJCOWMULwzXEdCCmkUql2oSynsEUGjGQPs2kMu+7a9JXApxxaxUuTkrps5CpFh7N 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.0/X.509/SHA1) via TCP6; 26 Jan 2017 01:26:14 -0000 Date: 25 Jan 2017 20:26:24 -0500 Message-ID: From: "John R Levine" To: "Brandon Long" In-Reply-To: References: <50FC0AEB-C690-4F18-970A-BEFDF4262BFC@kitterman.com> <20170123185852.64105.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 01:26:17 -0000 > Sure, with dkim. With arc, it's a bit more complicated, we need to > understand exactly how to sign the chain if there are multiple AMS and AS > headers. We probably want text about what happens if only one verifies as > well, and whether a hop should continue signing both paths or just one. All quite reasonable. Only one verifies: that's fine, the other is likely an algorithm you don't handle (yet). This is inherited from DKIM, a broken signature is the same as no signature and doesn't imply anything bad. What to sign: just one. It occurs to me that this is kind of fragile, since if you just sign one, it has to be the one that is farther down. I'm wondering if we should suggest that if there are two signatures for the same thing, discard the one you didn't use. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Jan 25 17:27:37 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1275126D74 for ; Wed, 25 Jan 2017 17:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=IaE8zhxL; dkim=pass (1536-bit key) header.d=taugh.com header.b=A67hnTdG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RqCoIo36_Yv for ; Wed, 25 Jan 2017 17:27:34 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14E312942F for ; Wed, 25 Jan 2017 17:27:34 -0800 (PST) Received: (qmail 87109 invoked from network); 26 Jan 2017 01:27:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15443.58895085.k1701; bh=7O2CWqLAF9xnTwO/HTJrAB122DInIZNDUGio00yWlc8=; b=IaE8zhxLN1QvZ9v/I9IFn07XlJBZ1WQbl6QGiV1RYBtqNC3EfR6KlL5JyR0rAahT4mJHXkz6nBpkmZ3GlbQ4m5PlWE2r4sRWtTEIyEgpN000CC/0gFhDu87W8XLYBhxpPIRLJ2HgGb9IejwqhZYnuEcQ8IdUmHvVbrpsC6bc81RxgNXcyY5tR6Ur+9pa+lNZJP5RDyr/MozaXOcxKipG+0y8jV9FXhBOx4QJzl5FFK2cD8k4JT+0+GakWlPrVxE+ 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=15443.58895085.k1701; bh=7O2CWqLAF9xnTwO/HTJrAB122DInIZNDUGio00yWlc8=; b=A67hnTdGrJEpMhBIzVbh+XZMpa16KNhmVZOifwNliJ1WM55OgCqQ+GcS6tYbC/TSm9+/GnYfgRYVk1xh573a6Y4fn26b2ZGq/aY6TZx68Sx6pX0JdPt8dOYTUMuVck6twftkyD4SKBRRpXcvZFyZ741Jrc9ZL+Erh12DEUGFhnOwGLAxPwMqrXtvOlRLLZpCffr0hys98eVeOM1vFgJJo8fQNXPQ1rpKwMO0fUViUcxDJ3CMeBEg3ixmUyX0hGBH 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.0/X.509/SHA1) via TCP6; 26 Jan 2017 01:27:33 -0000 Date: 25 Jan 2017 20:27:43 -0500 Message-ID: From: "John R Levine" To: "Paul Rock" In-Reply-To: References: <50FC0AEB-C690-4F18-970A-BEFDF4262BFC@kitterman.com> <20170123185852.64105.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 01:27:35 -0000 > I see a rabbit hole here... So you're transitioning, so you sign twice (one > with your old, one with your new) before you send to me.... and hey, I'm > not the end point either, so I need to forward it along, but I'm also > transitioning, so I sign both of yours, twice? I would kind of have to, > wouldn't I? No, you just sign one. See the previous message. We might as well figure this out now, because even if we only have one signing alg and one hash alg now, sooner or later we'll have to add other ones. R's, John From nobody Wed Jan 25 18:07:07 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EE912943F for ; Wed, 25 Jan 2017 18:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9FT-jc1VqRw for ; Wed, 25 Jan 2017 18:07:05 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::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 4304B129410 for ; Wed, 25 Jan 2017 18:07:05 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id f67so26139188ybc.2 for ; Wed, 25 Jan 2017 18:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tu19vX3aJO00imu4Ru5akD03eKz4qs1TcHdpgyfxV5w=; b=gaq8jmHxC6UrtItEGOG7fiaPd4/l/T5Kkls7NBx0pcZSNAJfJSkHg9frndZY4ZvsEi wIFPCeaTAE/GVO6LTlIQYiIoLJOa7ysfbSm6gnvMqhmaiPtbD9xpxKI05D2yN1qkPNwW gknbynBS/HNaNBMKIXtG3SX7liKPD0yOBt6JweorlK592rIIuPXHQ/t3g+lRZNjCp/QS lu82EQiokJpxfSik9Uietc+fJKKQhgTo53LHdUu6S1C5QmMvMwlH8mlF2Of8G277FoTQ /FNyGJq6jrz+As6CITUH2JpXqiknd7ZlKN3D3/gL54JneVfN4IouILe1IP4jC7F7SnCK Gt5g== 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=Tu19vX3aJO00imu4Ru5akD03eKz4qs1TcHdpgyfxV5w=; b=Q1Hf7KX5FfceqGDq5MATFoXiZja9ASXJxqowzidF4xYzyGfsmAQXnAgJcdF5xIOXXa jPaaeTgx8Qu3yXParlmfnLom9djLPYIGD/yDCER7B7CQdoz3rsFneu/pAeJoRlpB5/SV iVyx5lJ4s1Hg7nWr7y60qWGdNdP7hQ9lG48zkinsQNYIK4dK+jSllQ/eqrOyyg2Zo7tz UBBdclCauT5Q2UtTZfctzVR8EKmU9zmcC9La5L4dTzSvV6NudGV9+ZTQcrI0jyr83Z2x eU658N47zNh/MR9lWarEzeUpnHC0fmIUb/hsSN+sECJsXtuCVmjYmX6vlVEisRZjGvqM 4yrg== X-Gm-Message-State: AIkVDXIO6evcZlCQ00hmSk9P8D4RKLxd6PQPAQwdDwrR+qkbRb6ckIvXOVj/+8a7YuBBo49PnYL9TJrpy0iGgpJo X-Received: by 10.13.254.66 with SMTP id o63mr347161ywf.318.1485396424368; Wed, 25 Jan 2017 18:07:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.8.198 with HTTP; Wed, 25 Jan 2017 18:07:03 -0800 (PST) In-Reply-To: References: <50FC0AEB-C690-4F18-970A-BEFDF4262BFC@kitterman.com> <20170123185852.64105.qmail@ary.lan> From: Brandon Long Date: Wed, 25 Jan 2017 18:07:03 -0800 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=94eb2c0800103a20e40546f5ce9f Archived-At: Cc: Paul Rock , dmarc Subject: Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 02:07:06 -0000 --94eb2c0800103a20e40546f5ce9f Content-Type: text/plain; charset=UTF-8 On Wed, Jan 25, 2017 at 5:27 PM, John R Levine wrote: > I see a rabbit hole here... So you're transitioning, so you sign twice (one >> with your old, one with your new) before you send to me.... and hey, I'm >> not the end point either, so I need to forward it along, but I'm also >> transitioning, so I sign both of yours, twice? I would kind of have to, >> wouldn't I? >> > > No, you just sign one. See the previous message. > > We might as well figure this out now, because even if we only have one > signing alg and one hash alg now, sooner or later we'll have to add other > ones. Signing one seems wrong, ie if the arc-seal only signs a single arc-message-signature at a given hop, then the other signature can't be verified, and if I can't handle the algorithm of the one that's covered, then I can't verify the chain. WIth AMS, we have an h header, so theoretically you'd just include the multiple headers and h= ordering takes over. The problem is for the Arc-Seal header where the h field is implicit, we'd need to have a sort order for each AMS and AS header within a hop. It could be the order in the headers, it could be sort order by the algorithm field, or something else. Brandon --94eb2c0800103a20e40546f5ce9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 25, 2017 at 5:27 PM, John R Levine <johnl@taugh.com><= /span> wrote:
I see a rabbit hole here... So you're transitioning, so you sign twice = (one
with your old, one with your new) before you send to me.... and hey, I'= m
not the end point either, so I need to forward it along, but I'm also transitioning, so I sign both of yours, twice? I would kind of have to,
wouldn't I?

 No, you just sign one.=C2=A0 See the previous message.

We might as well figure this out now, because even if we only have one sign= ing alg and one hash alg now, sooner or later we'll have to add other o= nes.

Signing one seems wrong, ie if the arc= -seal only signs a single arc-message-signature at a given hop, then the ot= her signature can't be verified, and if I can't handle the algorith= m of the one that's covered, then I can't verify the chain.

WIth AMS, we have an h header, so theoretically you'd= just include the multiple headers and h=3D ordering takes over.
=
The problem is for the Arc-Seal header where the h field is = implicit, we'd need to have a sort order for each AMS and AS header wit= hin a hop.=C2=A0 It could be the order in the headers, it could be sort ord= er by the algorithm field, or something else.

Bran= don

--94eb2c0800103a20e40546f5ce9f-- From nobody Wed Jan 25 20:23:38 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F5412944C for ; Wed, 25 Jan 2017 20:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=edX8+XyL; dkim=pass (1536-bit key) header.d=taugh.com header.b=BHrsvdA0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQFkx-hBdJEE for ; Wed, 25 Jan 2017 20:23:35 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9EC9129428 for ; Wed, 25 Jan 2017 20:23:34 -0800 (PST) Received: (qmail 4091 invoked from network); 26 Jan 2017 04:23:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=ff9.588979c5.k1701; bh=Dz4WfjXwJtg/QUKfs02zdkvrHND0urLW15WjflRfJYM=; b=edX8+XyLfARjcASOhpvc5Uj56mB+6wsri0/SlxDA++c3/W4hDKr5FUyVGz5wbJM8J5TUQgxod0JPAL67QASmupKKHJAIlOfU+KMdTLNTkdKQrjVCO9xUojs+UjRFOnBTtAB+ylr3eiW8rEzBbnKy4elyt5S5gzCJ9kZ0eQYCXh11IqebjoG5LYGMjyf0sA6O9FGZ6GIB2RHy2eDzoFcfiixbM3YB6dJZL5eTnnNrYm/HwMjJVsvRrPcOoxgGFsOj 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=ff9.588979c5.k1701; bh=Dz4WfjXwJtg/QUKfs02zdkvrHND0urLW15WjflRfJYM=; b=BHrsvdA0WCitTs2w2dz2ISRUtxtm7lF0Kv1hKN/KSXLftQc1fEiWS8o5ngn0ZDmBdBQtMTPu9Qw6csIr6l/LsdV9Hnz95/5jsR9TB0xPk/+3hrLeAjpzXe4lJHY3PkboBiqVwP8xIIvL25P2Cr+p+CZxh1W66sRHbuTJ9JUDmPdv0W4q+WnAsFuWcatA/OxrwK8A/YvGhmRdDJpp8UeRJ0VCXDTFp0ll1Z+IHEhuTwUoq9saT8B0j0tcZy5LxyXi 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.0/X.509/SHA1) via TCP6; 26 Jan 2017 04:23:33 -0000 Date: 25 Jan 2017 23:23:33 -0500 Message-ID: From: "John R Levine" To: "Brandon Long" In-Reply-To: References: <50FC0AEB-C690-4F18-970A-BEFDF4262BFC@kitterman.com> <20170123185852.64105.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 04:23:36 -0000 > Signing one seems wrong, ie if the arc-seal only signs a single > arc-message-signature at a given hop, then the other signature can't be > verified, and if I can't handle the algorithm of the one that's covered, > then I can't verify the chain. Currently away on a trip, I'll take a closer look when I get home this weekend and see if I can make a clearer proposal. R's, John From nobody Mon Jan 30 10:24:56 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFAE129A6D for ; Mon, 30 Jan 2017 10:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 F1zSXnUcqm8A for ; Mon, 30 Jan 2017 10:24:52 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47846129A74 for ; Mon, 30 Jan 2017 10:24:52 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id 32so90031010oth.3 for ; Mon, 30 Jan 2017 10:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=UD4fGiEJwgFBSD3xsYenr1M5f8KhuCLWWFVhgFvY8j0=; b=b8QNqwXbHwaghKd0RoufJl/BA7VEZgzTzQSAgI1osDvUjnOXJqQ6iUCi9buHf+/vq8 UU0+CvVs9+RPHmtjYH8TrjnyM2oPMhn8wlsC/LVVyWlIM9tqTx0d4uHncVhunuRw8ewS Nz77d1mtJ7A5AwFWzVwnpRlXAfvP0nl0DG3Wc/8eV6Z9egw6QQQgRo7eACGsJ4CI1T4O wfE0GXYfGjXhcwdCP4vEVMi0KMLuX7ZpixCFaBlC4sx6rw+RCcemHl7b/UTJslc/Xi4G QV0MmP0cFvGWlcUfxzO3IMRRXioM35NQIny1+qWqCcSBhNoVp/P5NSxakq2X+U3yCvVJ AWYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UD4fGiEJwgFBSD3xsYenr1M5f8KhuCLWWFVhgFvY8j0=; b=cMUIoxrLht2XtrQDjJkkP0AgdnblCoowcMvG8PiyvHN7i7ymFLHcqEZDsGmAegkCFh EIL+/hl5m+I2dkLLm/YYlUA7En5S3Ppk+wLHJtm+H85C6DA1PVHBWTjGISsJk7MVzPNw ufuwoPojhfSyVWrTPKqtM6K1UuX/PKjkl7Kc6WxpjDo938risMTCce76ZYqkCekOdjt7 jRyXsbRMvbUMG59xD9uITAsUVMGomXxlc3CPJg6RTBEAAb4t/SYDPbdhSWfrNIkTQpPQ lhsOqNvfn8USaD08Mgifo7SKphssUG+D2BoR3+BC/hDnT1/VvJ97i6kq44ux8KrZN4Z1 tn4w== X-Gm-Message-State: AIkVDXKzzxbZLAKClWZe9xFv2HgT4RRPzKqsY1auFBZUiDRG2a89zHCN8os39EEE3Ds1Mg09yOWgU/vIWal4Nw== X-Received: by 10.157.43.117 with SMTP id f50mr12546392otd.77.1485800691456; Mon, 30 Jan 2017 10:24:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.14.6 with HTTP; Mon, 30 Jan 2017 10:24:51 -0800 (PST) From: Gene Shuman Date: Mon, 30 Jan 2017 10:24:51 -0800 Message-ID: To: dmarc@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dmarc-ietf] invalid ARC chains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 18:24:54 -0000 Extricating this discussion from the one about key sizes. We left off at discussing whether we should implement something like a cv=invalid for arc chains that are no longer well defined. Brandon, I think you had the last response, and suggested that receivers just refuse to continue to process invalid chains? This seems plausible, and might be simpler. I have no strong opinions one way or the other, although I think I slightly prefer the cv=invalid state, as it strictly defines what receivers are to do with invalid chains. Regardless, I still stand by the fact that section 5.2.1 needs to go & that we should probably explicitly codify what constitutes an invalid arc chain. Regards, =Gene From nobody Mon Jan 30 14:59:06 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC0B129657 for ; Mon, 30 Jan 2017 14:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.519 X-Spam-Level: X-Spam-Status: No, score=-7.519 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linkedin.com header.b=3leSRUP3; dkim=pass (1024-bit key) header.d=linkedin.com header.b=ajNC5wB/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DOuNnCWiABE for ; Mon, 30 Jan 2017 14:59:03 -0800 (PST) Received: from mail521.linkedin.com (mail521.linkedin.com [108.174.6.121]) (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 0397D12963D for ; Mon, 30 Jan 2017 14:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1485817142; bh=mjVeV8X4twKkhJ9xiqzCusgSclZP5v617z1XA01RpcU=; h=MIME-Version:From:Date:Subject:To:Content-Type; b=3leSRUP38I8HXNKZubXtfOj6mzKYGdJRjlUrOeBZ8u3pwlW70OjP6Q2PzRS0DUjTG rYaGBGSu6hMhX07l8xj+R9/gDh2EuCOalkl/NuZGLdkN7utbjYYBZxcV38r4aumiaR QCWmOgtIIWIFEe0H3NdMaREyR3cKxexiZCpWL4m0= Authentication-Results: mail521.prod.linkedin.com x-tls.subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com"; auth=pass (cipher=ECDHE-RSA-AES128-GCM-SHA256) Authentication-Results: mail521.prod.linkedin.com; iprev=pass policy.iprev="2607:f8b0:400c:c05::248"; spf=softfail smtp.mailfrom="kandersen@linkedin.com" smtp.helo="mail-vk0-x248.google.com"; dkim=pass header.d=linkedin.com; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" key.length="128" tls.v="tlsv1.2" cert.client="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com" cert.clientissuer="C=US,O=Google Inc,CN=Google Internet Authority G2" Received: from [2607:f8b0:400c:c05::248] ([2607:f8b0:400c:c05::248.35320] helo=mail-vk0-x248.google.com) by mail521.prod.linkedin.com (envelope-from ) (ecelerity 3.6.21.53563 r(Core:3.6.21.0)) with ESMTPS (cipher=ECDHE-RSA-AES128-GCM-SHA256 subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com") id CD/57-04529-635CF885; Mon, 30 Jan 2017 22:59:02 +0000 Received: by mail-vk0-x248.google.com with SMTP id 78so197905083vkj.2 for ; Mon, 30 Jan 2017 14:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mjVeV8X4twKkhJ9xiqzCusgSclZP5v617z1XA01RpcU=; b=ajNC5wB/0iPvd7gklG1X7rxk9ur3vkV5z04b6WF14vB4RctJC/+T9ugICZFIUCvwn2 P15E1Ex53r4lyNQd6zx22m3UMS8t1j+/iBhscBqIIoVzyUIY8N8Bwqn7nSfuCPcvS7ul YI9yQBIeuINRnu+fRJEMP3Lgvh1GOkHpDgTbQ= 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=mjVeV8X4twKkhJ9xiqzCusgSclZP5v617z1XA01RpcU=; b=qchTozqhCZgpDRL05f8YPMUs+hYSDofyZxeq6FU+cgMHW+3n0hgXgVG77GDyl8urVP CA/BoXKSl3A8rN/ecfNoeq6YbLkeUXs5ui+xeV9nEkRWxuKTcNAJg5/X+y6dgYUrqBnk WqYGdArs8YtimbL2zHJ4DHH/kjp1jCzvVJeb4vHISnVcsvj5z5ubA7n4fQbLkxFcUDLY qDBZO9+XznAOOYr9TsfKkLsTgGPbhrRDHGt7O8kRosDkz55DEQOprlT9c0ub16APif5Z PZNZ5U6+O/sWi1KuqjvwU6dl5FnO5YjlxKE69sCTL9OpqSgaQcOkWdxYhiJ7uzD4R02M IO2g== X-Gm-Message-State: AIkVDXJneZkHOb8EkmHQST4MPA5UgPRIR78kU0Yan+oOsnKBj7vs30Qbg3Krra/Iqr40E2Qgf/pS2sD8mapW1hoFkzRmmIUEyzr3KzMXBtbU/24bPqZDgIVh28pk4IBXbZvrbAfc6+XqrGPa3zSVXU+YDWL9 X-Received: by 10.31.84.68 with SMTP id i65mr9617728vkb.23.1485817141681; Mon, 30 Jan 2017 14:59:01 -0800 (PST) X-Received: by 10.31.84.68 with SMTP id i65mr9617715vkb.23.1485817141384; Mon, 30 Jan 2017 14:59:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.33.79 with HTTP; Mon, 30 Jan 2017 14:59:00 -0800 (PST) In-Reply-To: References: From: Kurt Andersen Date: Mon, 30 Jan 2017 14:59:00 -0800 Message-ID: To: Gene Shuman Content-Type: multipart/alternative; boundary=001a114e503aea37e3054757c214 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] invalid ARC chains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 22:59:04 -0000 --001a114e503aea37e3054757c214 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 30, 2017 at 10:24 AM, Gene Shuman wrote: > Extricating this discussion from the one about key sizes. We left off > at discussing whether we should implement something like a cv=invalid > for arc chains that are no longer well defined. > > Brandon, I think you had the last response, and suggested that > receivers just refuse to continue to process invalid chains? This > seems plausible, and might be simpler. I have no strong opinions one > way or the other, although I think I slightly prefer the cv=invalid > state, as it strictly defines what receivers are to do with invalid > chains. > > Regardless, I still stand by the fact that section 5.2.1 needs to go & > that we should probably explicitly codify what constitutes an invalid > arc chain. > I don't think that 5.2.1 needs to be deleted, just significantly refactored (which I plan to do next weekend). I think that having a participating receiver mark an chain as "broken beyond repair" (aka = invalid) is a beneficial terminal state beyond which no other mediators should perform any further ARC machinations. It's certainly possible that a malicious mediator could essentially break every ARC chain that it sees, but that's no different than what can happen today and also is a situation that we are not trying to solve. --Kurt --001a114e503aea37e3054757c214 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 30, 2017 at 10:24 AM, Gene Shuman <gene@valimail.com> wrote:
Extricating this discussion from= the one about key sizes.=C2=A0 We left off
at discussing whether we should implement something like a cv=3Dinvalid
for arc chains that are no longer well defined.

Brandon, I think you had the last response, and suggested that
receivers just refuse to continue to process invalid chains?=C2=A0 This
seems plausible, and might be simpler.=C2=A0 I have no strong opinions one<= br> way or the other, although I think I slightly prefer the cv=3Dinvalid
state, as it strictly defines what receivers are to do with invalid
chains.

Regardless, I still stand by the fact that section 5.2.1 needs to go &<= br> that we should probably explicitly codify what constitutes an invalid
arc chain.

I don't think that 5.2.1= needs to be deleted, just significantly refactored (which I plan to do nex= t weekend).=C2=A0

I think that having a participat= ing receiver mark an chain as "broken beyond repair" (aka =3D inv= alid) is a beneficial terminal state beyond which no other mediators should= perform any further ARC machinations. It's certainly possible that a m= alicious mediator could essentially break every ARC chain that it sees, but= that's no different than what can happen today and also is a situation= that we are not trying to solve.

--Kurt

--001a114e503aea37e3054757c214--

On Fri, Jan 20, 2017 at 3:4= 1 PM, Scott Kitterman <sklist@kitterman.com> wrote:
On Fri= day, January 20, 2017 03:30:58 PM Scott Kitterman wrote:
> On Friday, January 20, 2017 you wrote:
> > On 01/20/2017 11:23, Scott Kitterman wrote:
> > > I'm not on the ARC list, so I'll pile on this thread= here...
> >
> > This is the right place for anything constructive regarding the > > specification, so no problem regarding any other lists.
> >
> > > I understand the minimum key size in the draft is 512 bits.= =C2=A0 I'm not
> > > planning
> > > on releasing any software that supports key sizes less than = 1024, so I
> > > guarantee you interoperability problems for small keys.
> >
> > +1 -- no need for weak keys.
> >
> > 1) Do we have a normative reference within the RFC framework for = key
> > lengths for different crypto systems, and can we simply invoke th= at
> > reference rather than including a hard figure in this spec?
> >
> > 2) Does such a reference still consider 1k keys as acceptable at = this
> > time? Is there a schedule for periodic review?
> >
> > --S.
> >
> > +++1 wrt Scott's comment about 512 bit keys.=C2=A0 We inherit= this requirement
> > from the DKIM spec, but imho it is not reasonable.=C2=A0 If this = is worth
> > discussing, perhaps we should move it to another thread?
> >
> > Regards,
> > =3DGene
>
> OK, Since I wasn't off topic after all, here's a new thread...=
>
> I believe we've looked for such a reference before and not found a= good one.
> The IETF BCP is from 2004: https://tools.ietf.org/html/= rfc3766
>
> Operationally, 1024 is the minimum key size recommendation I generally= see
> for DKIM today.=C2=A0 NIST recommends 2048 bits, SHA-256 only for US g= overment
> use [1].
>
>
> Scott K
> [1] http://nvlpubs.nist= .gov/nistpubs/SpecialPublications/NIST.SP.800-177.pdf

Moving John Levine's reply into this thread and then replyi= ng further:

On Friday, January 20, 2017 10:17:02 PM John Levine wrote:
> >1) Do we have a normative reference within the RFC framework for k= ey
> >lengths for different crypto systems, and can we simply invoke tha= t
> >reference rather than including a hard figure in this spec?
>
> There's RFC 3766, but it's over a decade old and has ru= les for how to
> figure out how long a key you need, not the actual sizes.
>
> This NIST publication seems relevant:
>
> http://nvlpubs.nist= .gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
>
> The tables on pages 52 and 53 suggest that we use 2K keys and sha256 h= ashes.
> >2) Does such a reference still consider 1k keys a= s acceptable at this
> >time? Is there a schedule for periodic review?
>
> No.=C2=A0 See the document.
>
> R's,
> John

Large keys like 2048 present other potential operational problems.=C2=A0 He= re's a
2048 bit, sha-256 key record:

default._domainkey=C2=A0 =C2=A0 =C2=A0 IN=C2=A0 =C2=A0 =C2=A0 TXT=C2=A0 =C2= =A0 =C2=A0( "v=3DDKIM1; h=3Dsha-256; k=3Drsa; "
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "p=3DMIIBIjANBgkqhkiG9w0BAQEFA= AOCAQ8AMIIBCgKCAQEAy5nzBQiwX1l4QDoE1glqw+93aMMp9hVVg8KYP3z43= GTNScXda0mLAPoScWc1EHnm37TCdWj57F0CYjZhvsX0EnkRpibYCEX/AZ2xL= mwE7XcMXWWYjlUCK/BfFhuCUOEDbokjRCJ/ULbVUZfC8I8QZFdhqno987m26UhayL= T3iNboj+v4mqUdYkVg6FmNRZRdDhxJYDSosT9j2Y"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "2eaSVsQ5Pvyt2ZzOjHJ9eXujw6/DK= R2WGVEIIX+3sKqeH7tDbeXulzv102HP1fmoE6sKgPRevIHKoMfFagNyXXkqxmyRY/= jV+yZGGz7RZEpNApv7pyBtfG0bz7cTwVX4QvP/8MUQIDAQAB"
)

I'm sure that will get line wrapped into illegibility, so I'll make= the actual
point:=C2=A0 It's longer than will fit in a single TXT string.=C2=A0 Wh= ile there is
nothing wrong with that from a DNS standards or even a core DNS operational=
perspective, it is not rare that DNS provisioning systems don't support= this.
I don't want to make it so secure it's deployability is severely ha= mpered.

I would suggest MUST at least 1024 bit, SHOULD 2048 bits.=C2=A0 I think MUS= T
sha-256 is also a good idea.=C2=A0 Approximately the last thing we should b= e doing
now is rolling out new protocols using sha-1.

Scott K

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



--
=
=


3D"logo

Bringing Trust to= Email

Peter Goldstei= n | CTO & Co-Founder

peter@valimail.= com

+1.415.793.57= 83
<= /div>
--001a1140a8262b96cd05468f9172-- From nobody Sat Jan 21 16:12:53 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B021E129543 for ; Sat, 21 Jan 2017 16:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjqT7UMkugVa for ; Sat, 21 Jan 2017 16:12:50 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5567129545 for ; Sat, 21 Jan 2017 16:12:50 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id 104so80169780otd.3 for ; Sat, 21 Jan 2017 16:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TNiJ4CItLrEBl+J3YPmHszoUnSD2Eqkvmwwz4N5JDKY=; b=G51HT8eHFjgAne2t/Z0uBXq+683unf5peWyJAicDm6HnTnMw6oHpK+tNXct/rBm1G3 g8YIRZK7lJBXTW7q15ytRgiTOlekEgkQv1Z+nzYhohzuAiV3kyuiTDpxAD5/p4VUgEKu QHioeulhq14KLvNHn3QN4vAJ3TaVeWyWfZ5SU= 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=TNiJ4CItLrEBl+J3YPmHszoUnSD2Eqkvmwwz4N5JDKY=; b=Zd+W3p5GGa2kb0WyaDP2v6sWjLHvu0pk3ooZ5DLk7h45mYXF01z0xSiPMJxlsBdCJp Yfg9eh2Hvskgs6dbpA4HOE8siDxsvU7OhbSSuI+6t79cKO6Onw/p3hCpNf/MN74RY22J 9zOxtiAS/4LcibzZ7xhdhlvMFIpzFbGfJqWNzlLVKrIQX1LX/gISUrTMUHDzPu1rsl9b q2yro8Q0aMVgybSAZj/WN/RIZFYFFkTmkwWmkzLj/HZlIPyZUN2owY6oZFB3Q7bkMw9X bLRVzxCbY4+BuZ7qPbl8aqgqxZJtnbtV7M3lwGNSquX5q1iWZ5qdJxaRORLEm6yWqtwl O/sA== X-Gm-Message-State: AIkVDXIvfVAbItzvRQVTwZzeny+f8eRZ1Ez32rfDFf6ttaWn6eX/WGC2wwkyfoSEvaMd8h1OpNPg4figPrh6bQ== X-Received: by 10.157.4.141 with SMTP id 13mr11703030otm.243.1485043969987; Sat, 21 Jan 2017 16:12:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.184.69 with HTTP; Sat, 21 Jan 2017 16:12:49 -0800 (PST) Received: by 10.202.184.69 with HTTP; Sat, 21 Jan 2017 16:12:49 -0800 (PST) In-Reply-To: <10036332.AbsS0sHdB9@kitterma-e6430> References: <10036332.AbsS0sHdB9@kitterma-e6430> From: Kurt Andersen Date: Sun, 22 Jan 2017 05:42:49 +0530 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=94eb2c0956804eb42f0546a3be45 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 00:12:53 -0000 --94eb2c0956804eb42f0546a3be45 Content-Type: text/plain; charset=UTF-8 On Jan 20, 2017 11:23, "Scott Kitterman" wrote: I understand the minimum key size in the draft is 512 bits. There is nothing in the ARC spec about key sizes. --Kurt --94eb2c0956804eb42f0546a3be45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Jan 20, 2017 11:23, "Scott Kitterman" <sklist@kitterman.com> wrote:
I un= derstand the minimum key size in the draft is 512 bits.
<= /div>

There is nothing i= n the ARC spec about key sizes.

--Kurt
--94eb2c0956804eb42f0546a3be45-- From nobody Sat Jan 21 16:39:41 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FF812954A for ; Sat, 21 Jan 2017 16:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 C4FRxL3wd2E9 for ; Sat, 21 Jan 2017 16:39:38 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB34129543 for ; Sat, 21 Jan 2017 16:39:37 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id x49so76506808qtc.2 for ; Sat, 21 Jan 2017 16:39:37 -0800 (PST) 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=1wnXNuAUlYxCKXqRnEIcd1owJ6W9qJ/I1IK4ymUloCQ=; b=Evd2UM+Hqq0tRL7K+v0xm5CBg7k0DhXR7ebc5KQePBBItZHUulvjwKXFT6bIRxIQnO 7hTxnetTqx5eHEH//JzY0uA/N5RksDo3ID6iLxkYmEwHpMFdXbBtd6P3JXtq7WAjMg0/ TGMQV+qMqpcbGaG4d5igFMJ9JbwiikOxf7V9tZgPMdkOyVDGJtD9a4pMjGLx5psFgWnk CpXlCQsKkB/vcu+Z0Fhc2296C5bgR4ze6RDfavZ+N9vtM51TafV0oRnnjOX1h411UwN9 f4cYRPNDQYvSO5b2he40s1t1TqdkWvis44akYZZUJ7ib+Zx57tS59Hsm3jrs1LR5LFvf rjsQ== 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=1wnXNuAUlYxCKXqRnEIcd1owJ6W9qJ/I1IK4ymUloCQ=; b=DJFyi9tOx5yye4AEpFY+GBhJTYW8Yasb4psybquKiST+2VNwwFSHC19EVXcYGlOR1B kLechfN4PQUtIRNZaPonV2HNmcEY+SL7b1bCz73DQtQ3UVucVeJxAWyJLBJpoW3MJMbq oEprRCi+CDT0QkJo8mdt7Oru/MZl5xnckCjtTNjlmTymM51k5HGskRexZQiFORJPdUq5 lORONAVDaVI2zFzP4Dk9ON/0tMhshY0aqvGMglxYqNbuCDQibo97t4TZ4IcNbYHkVGm4 gNPYRJKzrCpvtPoq8K107M2MAbEFDhJArCsmvQhgnc+G5FIXYAJ2pPa2KFu3uzLHr3/F JwYw== X-Gm-Message-State: AIkVDXI3s/GZlbMg/s2y61JSvUWGkrJ8S/aetK8XSymAMiOk1lXb5eyZkwbfItdEPujN8Z1EI/UErK45nOEzkw== X-Received: by 10.200.55.5 with SMTP id o5mr18178623qtb.248.1485045576608; Sat, 21 Jan 2017 16:39:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.129.247 with HTTP; Sat, 21 Jan 2017 16:39:36 -0800 (PST) In-Reply-To: References: <10036332.AbsS0sHdB9@kitterma-e6430> From: Peter Goldstein Date: Sat, 21 Jan 2017 16:39:36 -0800 Message-ID: To: Kurt Andersen Content-Type: multipart/alternative; boundary=001a1140a82611c41e0546a41e26 Archived-At: Cc: dmarc@ietf.org, Scott Kitterman , Gene Shuman Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 00:39:40 -0000 --001a1140a82611c41e0546a41e26 Content-Type: text/plain; charset=UTF-8 >From the ARC spec: 5.3 . Key Management and Binding The public keys for ARC header fields follow the same requirements and semantics as those for DKIM-Signatures, described in Section 3.6 of [RFC6376] . Operators may use distinct selectors for the ARC header fields at their own discretion. >From the DKIM spec (RFC 6376) 3.3.3 . Key Sizes Selecting appropriate key sizes is a trade-off between cost, performance, and risk. Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for long-lived keys. Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys. Verifier policies may use the length of the signing key as one metric for determining whether a signature is acceptable. and 3.3 . Signing and Verification Algorithms DKIM supports multiple digital signature algorithms. Two algorithms are defined by this specification at this time: rsa-sha1 and rsa- sha256. Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers MUST implement both rsa-sha1 and rsa-sha256. While admittedly the ARC RFC points to a different section of RFC 6376 (3.6), the statement beginning of section 5.3 certainly reads like it inherits public key requirements and semantics from the DKIM RFC. The DKIM RFC explicitly requires verifiers to validate signatures with bit sizes ranging from 512 bits to 2048 bits. If the key sizes recommendation is not intended to be inherited from RFC 6376, then that should probably be explicitly called out and the appropriate key guidelines defined. Best, Peter On Sat, Jan 21, 2017 at 4:12 PM, Kurt Andersen wrote: > > On Jan 20, 2017 11:23, "Scott Kitterman" wrote: > > I understand the minimum key size in the draft is 512 bits. > > > There is nothing in the ARC spec about key sizes. > > --Kurt > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a1140a82611c41e0546a41e26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From the ARC spec:

5.3.  Key Management and =
Binding


   The public keys for ARC header fields follow the same requirements
   and semantics as those for DKIM-Signatures, described in Section=C2=A03.6
   of [RFC6376].  Operators may use distinct selectors for the ARC
   header fields at their own discretion.

From the DKIM spec (RFC 6376)

3.3.3.  Key Sizes
=


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

and
3.3.  Signing and V=
erification Algorithms


   DKIM supports multiple digital signature algorithms.  Two algorithms
   are defined by this specification at this time: rsa-sha1 and rsa-
   sha256.  Signers MUST implement and SHOULD sign using rsa-sha256.
   Verifiers MUST implement both rsa-sha1 and rsa-sha256.


While admittedly the ARC RFC= points to a different section of RFC 6376 (3.6), the statement beginning o= f section 5.3 certainly reads like it inherits public key requirements and = semantics from the DKIM RFC.=C2=A0 The DKIM RFC explicitly requires verifie= rs to validate signatures with bit sizes ranging from 512 bits to 2048 bits= .

If the key sizes recommendation is not intended = to be inherited from RFC 6376, then that should probably be explicitly call= ed out and the appropriate key guidelines defined.

Best,

Peter




On Sat, Jan 21, 2017 at 4:12 PM, Kurt A= ndersen <kurta@drkurt.com> wrote:

On Jan 20, 2017 11:23, "Scott Ki= tterman" <sklist@kitterman.com> wrote:
I understand the minimum key size in the draft is 512 bits.

= There is nothing in the ARC spec about key sizes.

--= Kurt
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc




--
=
=


3D"logo

Bringing Trust to Email

Peter Goldstein | CTO &a= mp; Co-Founder

peter@valimail.com

+1.415.793.5783<= /span>
--001a1140a82611c41e0546a41e26-- From nobody Sat Jan 21 20:10:06 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E491295A5 for ; Sat, 21 Jan 2017 20:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.658 X-Spam-Level: X-Spam-Status: No, score=-4.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpnOF1ahlpOt for ; Sat, 21 Jan 2017 20:10:02 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D2E1294D8 for ; Sat, 21 Jan 2017 20:10:01 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id u68so79045678ywg.0 for ; Sat, 21 Jan 2017 20:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iVXBxhasFOEydWvj4+pgtdUWsFKH/oLm4vCusVA00KU=; b=dPteEfg3EjFsJi6KxZBxUm6ri4ZXSv7B0LdYrBNlMqBwmU1Ll0buzAF1z1tes8nVeA Yp8RZ/71J5KduMVllNhPZo5ekrXtZ5Zmx47qSllDOuFWBJomrvI2icS2HQwWhFfq/U+n toxq/BeYKOyWkSVaqp5sn1/KhpxLnSpkKiFFEFQQ5tj8CVrQe1nAqqBDXpa0/KIivCq+ w81IFygEsi8JawMNhgUbzm18YTVMHfQb9pbwuuZY+ljK5NbvWoebHOFv+4dXBW56s45L 6/94qCBlZNpUAOeYw1F7/1/t4BTnNzaVSd1cgMJ72QOMuDgaWHHvFlVZyXExehkCYBZU Na+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iVXBxhasFOEydWvj4+pgtdUWsFKH/oLm4vCusVA00KU=; b=pBC24b+Ijs5wjEQimOG4qKU8MULn10e50OFC/fd2m3Il/qfjb2xWMpl+HU2rLNzVjq e2NliQbscd5hEtpVFnQROEKJ2bRzlY7RrVKsm6VdNKXyftnWYJAh76UPr8sG9A/BMEjN GcjSq+OFCqsGzt9GCGbG3Sr5J2DQMJuGW8DXdbSt80D5bpTHqTtAEIsJ8qDw2z6WEJrT BnsLp7wThiq6SaOix54FoWudSHUlUe4g1mOoktRPBx9uu6OQ+i8sKG4HR6ZJX3Adrxzj 4Nznhg2SjAA5bXSbv1kntedyIQRc+q4nRXp+nE2dgQL+XCQZ0GNDKOpbizh2iC+ByaMD Sysw== X-Gm-Message-State: AIkVDXJDbDZSJLRFCnAGLGZ3G7d5shzlK4pFXBALKaQJ8paMZBdzX1RbE5ll9WziC/PAedBEZE7tE2LGx5hY86Pa X-Received: by 10.13.254.66 with SMTP id o63mr19168476ywf.318.1485058200701; Sat, 21 Jan 2017 20:10:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.8.198 with HTTP; Sat, 21 Jan 2017 20:09:59 -0800 (PST) Received: by 10.37.8.198 with HTTP; Sat, 21 Jan 2017 20:09:59 -0800 (PST) In-Reply-To: References: <6039311.QYNoohHPCE@kitterma-e6430> <13626399.50m8abrgpf@kitterma-e6430> From: Brandon Long Date: Sat, 21 Jan 2017 20:09:59 -0800 Message-ID: To: Peter Goldstein Content-Type: multipart/alternative; boundary=94eb2c0800108680320546a70ecb Archived-At: Cc: dmarc@ietf.org, Scott Kitterman Subject: Re: [dmarc-ietf] ARC Minimum Key Sizes X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 04:10:04 -0000 --94eb2c0800108680320546a70ecb Content-Type: text/plain; charset=UTF-8 On Jan 20, 2017 4:08 PM, "Peter Goldstein" wrote: I think Scott's point about operational options is well taken. Google ran into some operational issues with some DNS vendors when they attempted to make all new G Suite DKIM keys 2048 - they rolled back to making 2048 bit keys the default, but allowing 1024 bit keys as an option. Yeah, it turns out virtually all DNS registrars with website editors fail to handle long TXT records as of about 6 months ago. Brandon The MUST/SHOULD language suggested makes sense. And we definitely don't need to roll out new protocols using SHA-1. I would suggest some related language for verifiers. Something like what's found in the DKIM spec, but with updated bit sizes: Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits, and they MAY be able to validate signatures with larger keys. At a minimum I think we should require verifiers to be able to support 4096 bit keys (and potentially 8192 bit). There's no reason verifiers shouldn't be able to support longer key sizes, and this adds some future proofing to the specification. Best, Peter On Fri, Jan 20, 2017 at 3:41 PM, Scott Kitterman wrote: > On Friday, January 20, 2017 03:30:58 PM Scott Kitterman wrote: > > On Friday, January 20, 2017 you wrote: > > > On 01/20/2017 11:23, Scott Kitterman wrote: > > > > I'm not on the ARC list, so I'll pile on this thread here... > > > > > > This is the right place for anything constructive regarding the > > > specification, so no problem regarding any other lists. > > > > > > > I understand the minimum key size in the draft is 512 bits. I'm not > > > > planning > > > > on releasing any software that supports key sizes less than 1024, so > I > > > > guarantee you interoperability problems for small keys. > > > > > > +1 -- no need for weak keys. > > > > > > 1) Do we have a normative reference within the RFC framework for key > > > lengths for different crypto systems, and can we simply invoke that > > > reference rather than including a hard figure in this spec? > > > > > > 2) Does such a reference still consider 1k keys as acceptable at this > > > time? Is there a schedule for periodic review? > > > > > > --S. > > > > > > +++1 wrt Scott's comment about 512 bit keys. We inherit this > requirement > > > from the DKIM spec, but imho it is not reasonable. If this is worth > > > discussing, perhaps we should move it to another thread? > > > > > > Regards, > > > =Gene > > > > OK, Since I wasn't off topic after all, here's a new thread... > > > > I believe we've looked for such a reference before and not found a good > one. > > The IETF BCP is from 2004: https://tools.ietf.org/html/rfc3766 > > > > Operationally, 1024 is the minimum key size recommendation I generally > see > > for DKIM today. NIST recommends 2048 bits, SHA-256 only for US goverment > > use [1]. > > > > > > Scott K > > [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST. > SP.800-177.pdf > > Moving John Levine's reply into this thread and then replying further: > > On Friday, January 20, 2017 10:17:02 PM John Levine wrote: > > >1) Do we have a normative reference within the RFC framework for key > > >lengths for different crypto systems, and can we simply invoke that > > >reference rather than including a hard figure in this spec? > > > > There's RFC 3766, but it's over a decade old and has rules for how to > > figure out how long a key you need, not the actual sizes. > > > > This NIST publication seems relevant: > > > > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST. > SP.800-57pt1r4.pdf > > > > The tables on pages 52 and 53 suggest that we use 2K keys and sha256 > hashes. > > >2) Does such a reference still consider 1k keys as acceptable at this > > >time? Is there a schedule for periodic review? > > > > No. See the document. > > > > R's, > > John > > Large keys like 2048 present other potential operational problems. Here's > a > 2048 bit, sha-256 key record: > > default._domainkey IN TXT ( "v=DKIM1; h=sha-256; k=rsa; " > "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5nzBQiwX1l4Q > DoE1glqw+93aMMp9hVVg8KYP3z43GTNScXda0mLAPoScWc1EHnm37TCdWj57 > F0CYjZhvsX0EnkRpibYCEX/AZ2xLmwE7XcMXWWYjlUCK/BfFhuCUOEDbokjR > CJ/ULbVUZfC8I8QZFdhqno987m26UhayLT3iNboj+v4mqUdYkVg6FmNRZRdDhxJYDSosT9j2Y" > "2eaSVsQ5Pvyt2ZzOjHJ9eXujw6/DKR2WGVEIIX+3sKqeH7tDbeXulzv102H > P1fmoE6sKgPRevIHKoMfFagNyXXkqxmyRY/jV+yZGGz7RZEpNApv7pyBtfG0 > bz7cTwVX4QvP/8MUQIDAQAB" > ) > > I'm sure that will get line wrapped into illegibility, so I'll make the > actual > point: It's longer than will fit in a single TXT string. While there is > nothing wrong with that from a DNS standards or even a core DNS operational > perspective, it is not rare that DNS provisioning systems don't support > this. > I don't want to make it so secure it's deployability is severely hampered. > > I would suggest MUST at least 1024 bit, SHOULD 2048 bits. I think MUST > sha-256 is also a good idea. Approximately the last thing we should be > doing > now is rolling out new protocols using sha-1. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 <(415)%20793-5783> _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --94eb2c0800108680320546a70ecb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 20, 2017 4:08 PM, "Peter Goldstein" <peter@valimail.com> wrote:
I think Scott's= point about operational options is well taken.=C2=A0 Google ran into some = operational issues with some DNS vendors when they attempted to make all ne= w G Suite DKIM keys 2048 - they rolled back to making 2048 bit keys the def= ault, but allowing 1024 bit keys as an option.

Yeah, it turns out vi= rtually all DNS registrars with website editors fail to handle long TXT rec= ords as of about 6 months ago.

Brandon


The MUST/SHOULD language=C2=A0suggested makes sense.=C2=A0 And w= e definitely don't need to roll out new protocols using SHA-1.

I would= suggest some related language for verifiers.=C2=A0 Something like what'= ;s found in the DKIM spec, but with updated bit sizes:

= 
Verifiers MUST b=
e able to validate signatures with
   keys ranging from 1024 bits to 4096 bits, and they MAY be able to
   validate signatures with larger keys.
At a minimum I think we should require verifiers to be able= to support 4096 bit keys (and potentially 8192 bit).=C2=A0 There's no = reason verifiers shouldn't be able to support longer key sizes, and thi= s adds some future proofing to the specification.

= Best,

Peter
=

On Fri, Jan 20, 2= 017 at 3:41 PM, Scott Kitterman <sklist@kitterman.com> wr= ote:
On Friday, January 20, 2017 03:= 30:58 PM Scott Kitterman wrote:
> On Friday, January 20, 2017 you wrote:
> > On 01/20/2017 11:23, Scott Kitterman wrote:
> > > I'm not on the ARC list, so I'll pile on this thread= here...
> >
> > This is the right place for anything constructive regarding the > > specification, so no problem regarding any other lists.
> >
> > > I understand the minimum key size in the draft is 512 bits.= =C2=A0 I'm not
> > > planning
> > > on releasing any software that supports key sizes less than = 1024, so I
> > > guarantee you interoperability problems for small keys.
> >
> > +1 -- no need for weak keys.
> >
> > 1) Do we have a normative reference within the RFC framework for = key
> > lengths for different crypto systems, and can we simply invoke th= at
> > reference rather than including a hard figure in this spec?
> >
> > 2) Does such a reference still consider 1k keys as acceptable at = this
> > time? Is there a schedule for periodic review?
> >
> > --S.
> >
> > +++1 wrt Scott's comment about 512 bit keys.=C2=A0 We inherit= this requirement
> > from the DKIM spec, but imho it is not reasonable.=C2=A0 If this = is worth
> > discussing, perhaps we should move it to another thread?
> >
> > Regards,
> > =3DGene
>
> OK, Since I wasn't off topic after all, here's a new thread...=
>
> I believe we've looked for such a reference before and not found a= good one.
> The IETF BCP is from 2004: https://tools.ietf.org/html/rfc3766
>
> Operationally, 1024 is the minimum key size recommendation I generally= see
> for DKIM today.=C2=A0 NIST recommends 2048 bits, SHA-256 only for US g= overment
> use [1].
>
>
> Scott K
> [1] http://nvlpubs.nist= .gov/nistpubs/SpecialPublications/NIST.SP.800-177.pdf

Moving John Levine's reply into this thread and then replyi= ng further:

On Friday, January 20, 2017 10:17:02 PM John Levine wrote:
> >1) Do we have a normative reference within the RFC framework for k= ey
> >lengths for different crypto systems, and can we simply invoke tha= t
> >reference rather than including a hard figure in this spec?
>
> There's RFC 3766, but it's over a decade old and has ru= les for how to
> figure out how long a key you need, not the actual sizes.
>
> This NIST publication seems relevant:
>
> http://nvlpubs.nist= .gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
>
> The tables on pages 52 and 53 suggest that we use 2K keys and sha256 h= ashes.
> >2) Does such a reference still consider 1k keys as acceptabl= e at this
> >time? Is there a schedule for periodic review?
>
> No.=C2=A0 See the document.
>
> R's,
> John

Large keys like 2048 present other potential operational problems.=C2=A0 He= re's a
2048 bit, sha-256 key record:

default._domainkey=C2=A0 =C2=A0 =C2=A0 IN=C2=A0 =C2=A0 =C2=A0 TXT=C2=A0 =C2= =A0 =C2=A0( "v=3DDKIM1; h=3Dsha-256; k=3Drsa; "
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "p=3DMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5nzBQiwX1l4QDoE1glqw+93aMMp9hVVg8KYP3z43GTNSc= Xda0mLAPoScWc1EHnm37TCdWj57F0CYjZhvsX0EnkRpibYCEX/AZ2xLmwE7XcMXWW= YjlUCK/BfFhuCUOEDbokjRCJ/ULbVUZfC8I8QZFdhqno987m26UhayLT3iNboj+v4= mqUdYkVg6FmNRZRdDhxJYDSosT9j2Y"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "2eaSVsQ5Pvyt2ZzOjHJ9eXujw6/DK= R2WGVEIIX+3sKqeH7tDbeXulzv102HP1fmoE6sKgPRevIHKoMfFagNyXXkqxmyRY/= jV+yZGGz7RZEpNApv7pyBtfG0bz7cTwVX4QvP/8MUQIDAQAB"
)

I'm sure that will get line wrapped into illegibility, so I'll make= the actual
point:=C2=A0 It's longer than will fit in a single TXT string.=C2=A0 Wh= ile there is
nothing wrong with that from a DNS standards or even a core DNS operational=
perspective, it is not rare that DNS provisioning systems don't support= this.
I don't want to make it so secure it's deployability is severely ha= mpered.

I would suggest MUST at least 1024 bit, SHOULD 2048 bits.=C2=A0 I think MUS= T
sha-256 is also a good idea.=C2=A0 Approximately the last thing we should b= e doing
now is rolling out new protocols using sha-1.

Scott K

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



<= font color=3D"#888888">--


<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertic= al-align:baseline;white-space:pre-wrap;background-color:transparent">3D"logo

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

peter@valimail.com

+1.415.793.5783

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


--94eb2c0800108680320546a70ecb-- From nobody Sun Jan 22 12:30:18 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEA01299BA for ; Sun, 22 Jan 2017 12:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9DfuBXUcA-s for ; Sun, 22 Jan 2017 12:30:16 -0800 (PST) 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 E9EBA1299B8 for ; Sun, 22 Jan 2017 12:30:15 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id j15so70032358oih.2 for ; Sun, 22 Jan 2017 12:30:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xDPWPwhcB9/wlO+LP+JIIWkdTktQ7o5jXHIN4cUMBpM=; b=KgCq5xr7e4v0paCaDu+lojmgAcHu/5lN/v5dvu/LHml+eYXNweQRrsviuZeknRRXm8 /OMn2PyMu14dXxyptH73yMLjCFhXeBxv0z8v0FbiUrOqskNmJmlTLCLLtCtS3ssrUext 1+qQL63owyoMOcSLQ3lHidvvCu1sbR2Tt4+tg= 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=xDPWPwhcB9/wlO+LP+JIIWkdTktQ7o5jXHIN4cUMBpM=; b=hcrfl0qN5z0SIMVZHWD8ytHPMeoVo+0mOCrCbq1n/UXEEHNeOKELcMUO8o0b1hxRiN OWxb7j9moQvpD+ezIfr8CBIngMZ5O95Ec5LApAD+HU1lw5BG3tu06rYhzc8wrtSx4+sr +NaXvGQ29Vl7Dc7iaOgAj2Y2/jUs4Gwe001dqlZdy9DIi4QdssjhWZPRshbVpP1gKioK SDUW1QN6U6Hj6PjWpHfr0kOcC2OolKhyAAGwrzOHDW9SOAHRkQ5yhS9r0SOWixO3InCV usOzADc/7LT1g0ofrLG9KMmKeyjuLgvL8TNda0ChqiuZHnPA4AujtCcNxE9hMPMLtlnd 4y5Q== X-Gm-Message-State: AIkVDXLhARP2Axk2/SUQ6232HxVWibCCN3hbpBgT1qE0ah3oAUoG0d1aQ+7zSh4oaM2p0f0FptAflxXkp3sRpw== X-Received: by 10.202.90.135 with SMTP id o129mr3287951oib.69.1485117015135; Sun, 22 Jan 2017 12:30:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.184.69 with HTTP; Sun, 22 Jan 2017 12:30:14 -0800 (PST) In-Reply-To: References: <10036332.AbsS0sHdB9@kitterma-e6430> From: Kurt Andersen Date: Sun, 22 Jan 2017 12:30:14 -0800 Message-ID: To: Peter Goldstein Content-Type: multipart/alternative; boundary=001a113d54fe23e2c00546b4c05f Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman , Gene Shuman Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 20:30:17 -0000 --001a113d54fe23e2c00546b4c05f Content-Type: text/plain; charset=UTF-8 On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein wrote: > > . . . ARC . . . inherits . . . from the DKIM RFC. The DKIM RFC explicitly > requires verifiers to validate signatures with bit sizes ranging from 512 > bits to 2048 bits. > > There is a separate effort going on in the context of the UTA working group to address technologically obsolete encryption strength recommendations that have appeared over time in a variety of different RFCs. I don't think that adding yet another independent reference is a good idea and I am strongly opposed to trying to torque the ARC requirements to be different from DKIM. If Scott is planning to make dkimpy non-conformant to the DKIM spec, I think that is regrettable, but I don't see that making the problem worse with ARC "going its own way" helps anyone. --Kurt --001a113d54fe23e2c00546b4c05f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jan 21, 2017 at 4:39 PM, Peter Goldstein <peter@valimail.com>= wrote:

. . . ARC . . . inherits . . . from the DKIM RFC.=C2=A0 The= DKIM RFC explicitly requires verifiers to validate signatures with bit siz= es ranging from 512 bits to 2048 bits.

There is a separate effort going on in the context of the UTA= working group to address technologically obsolete encryption strength reco= mmendations that have appeared over time in a variety of different RFCs. I = don't think that adding yet another independent reference is a good ide= a and I am strongly opposed to trying to torque the ARC requirements to be = different from DKIM.

If Scott is planning to make = dkimpy non-conformant to the DKIM spec, I think that is regrettable, but I = don't see that making the problem worse with ARC "going its own wa= y" helps anyone.

--Kurt=C2=A0

=
--001a113d54fe23e2c00546b4c05f-- From nobody Sun Jan 22 13:18:20 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077D61299F5 for ; Sun, 22 Jan 2017 13:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW-1MCAYjlam for ; Sun, 22 Jan 2017 13:18:17 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A860C12007C for ; Sun, 22 Jan 2017 13:18:17 -0800 (PST) Received: from [10.3.27.246] (unknown [166.170.33.246]) (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 16C85C4022B; Sun, 22 Jan 2017 15:18:14 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1485119894; bh=iXt/ThFViBY2V6ovQUUf7IMVR6PaVEtPHiVotXM/dBw=; h=Date:In-Reply-To:References:Subject:To:From:From; b=S/a0T71bHi6tppFKEQOCtbomveW53qP27ugvnqE/NqW25X8668qxr6qQmh+GZGyV+ l0t0kFKjzcE9zd9DfXygcg8GIEmqtHMeY/pSAxE3ArpE3nL1reiwKl5IwpW1JZ1s3n xMp1/qrrfnIOFU7sHQEzw1nveSFQDG/LikRCTvWw= Date: Sun, 22 Jan 2017 21:18:08 +0000 In-Reply-To: References: <10036332.AbsS0sHdB9@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 21:18:19 -0000 On January 22, 2017 3:30:14 PM EST, Kurt Andersen wro= te: >On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein >wrote: > >> >> =2E =2E =2E ARC =2E =2E =2E inherits =2E =2E =2E from the DKIM RFC=2E = The DKIM RFC >explicitly >> requires verifiers to validate signatures with bit sizes ranging from >512 >> bits to 2048 bits=2E >> >> There is a separate effort going on in the context of the UTA working >group to address technologically obsolete encryption strength >recommendations that have appeared over time in a variety of different >RFCs=2E I don't think that adding yet another independent reference is a >good >idea and I am strongly opposed to trying to torque the ARC requirements >to >be different from DKIM=2E > >If Scott is planning to make dkimpy non-conformant to the DKIM spec, I >think that is regrettable, but I don't see that making the problem >worse >with ARC "going its own way" helps anyone=2E > >--Kurt No responsible operator has used the RFC minimum DKIM key sizes for a long= time=2E They were trivial to bypass half a decade ago=2E No one has ever = complained about 1024 bits default minimum being too big=2E I did once get= a complaint about the Debian opendkim package suggesting the minimum shoul= d be 2048 bits=2E Maybe some other working group will accomplish something someday is not a = good reason to perpetuate obsolete crypto in this one=2E Scott K From nobody Sun Jan 22 13:47:00 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643A3128E19 for ; Sun, 22 Jan 2017 13:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 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_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linkedin.com header.b=cZjFwRpV; dkim=pass (1024-bit key) header.d=linkedin.com header.b=WGJwtJ3k Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39jJp-6jmrlV for ; Sun, 22 Jan 2017 13:46:58 -0800 (PST) Received: from mail522.linkedin.com (mail522.linkedin.com [108.174.6.122]) (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 0D95E1293D8 for ; Sun, 22 Jan 2017 13:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1485121616; bh=7p1eZDOQ4T0twWF+K3lvqOBPfmebnEmUf42sG6UfyNg=; h=MIME-Version:From:Date:Subject:To:Content-Type; b=cZjFwRpVGiUihOsdngIuQ/Y7B0F/zZZoZJ6in3xQt2vc2s0MXjYuu6vQq/vtMv9fY /YJJBZbSb+Otvc5atW5PeN+CYsxvNL1nIpx17crvC3oZMgwZOSVPWI/bG8UQuhuHO1 UApqk/gHlWmXj0EVntgqYBBb7+OIyxfu2/XrqukM= Authentication-Results: mail522.prod.linkedin.com x-tls.subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com"; auth=pass (cipher=ECDHE-RSA-AES128-GCM-SHA256) Authentication-Results: mail522.prod.linkedin.com; iprev=pass policy.iprev="2607:f8b0:400c:c08::248"; spf=softfail smtp.mailfrom="kandersen@linkedin.com" smtp.helo="mail-ua0-x248.google.com"; dkim=pass header.d=linkedin.com; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" key.length="128" tls.v="tlsv1.2" cert.client="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com" cert.clientissuer="C=US,O=Google Inc,CN=Google Internet Authority G2" Received: from [2607:f8b0:400c:c08::248] ([2607:f8b0:400c:c08::248.34719] helo=mail-ua0-x248.google.com) by mail522.prod.linkedin.com (envelope-from ) (ecelerity 3.6.21.53563 r(Core:3.6.21.0)) with ESMTPS (cipher=ECDHE-RSA-AES128-GCM-SHA256 subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com") id 64/90-02468-05825885; Sun, 22 Jan 2017 21:46:56 +0000 Received: by mail-ua0-x248.google.com with SMTP id a88so82489708uaa.1 for ; Sun, 22 Jan 2017 13:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7p1eZDOQ4T0twWF+K3lvqOBPfmebnEmUf42sG6UfyNg=; b=WGJwtJ3ktDI81v/aju2ge7WFid0n1q24ODPYLNCvNTE3Ofjx/qIAZBExw3od9/Gi1T 9l5bkmH5ylkxuz9eA3L0OHDpD/kt4veed36o7bCujP+FQ6thPINIhUXyWfkMNqz/XkMn dGXHQw6qIuFsF8nT4AceLwSYqhSi4D3TSYGV0= 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=7p1eZDOQ4T0twWF+K3lvqOBPfmebnEmUf42sG6UfyNg=; b=Ykn14zcDyg40Held7FEPHE57fs/pTFNLlPyerBPSUbHl0uCIq4NJeskWM+Vxqb0Lai jP+xdU7XElsjFnBgehLgtZnKJmRJ7J/I9DCqairgZK0bz5wOYGM8ADgPx318Oxt/C4S2 qHRIw7QoVf9Kf2W4g43wZByYr8AJTm9KgPaS5m49vPnZAbNyMbPts+RR43GkCBaZXhbL vCKP77a8dTr2pbxiITeduCMqn8L2SBacITMCgc4FcCH0/83QxBM/yy/GqCO7R/9QhEcY IEZgUIRN/lHJyGmw5mnmqfrY4Bsy0BhPVh+li3qSoZ98r508B4RU7UJeU4UVD6r1YB6f Vtlw== X-Gm-Message-State: AIkVDXKT+7FljSfQWQiGx+K8WpXSqeW5ge7Q2v9lkYhy89l/HkKA42M7o2MLZKFwM4iAlJH8mCUFL+xqSiJeYEmWWP5KqVq2k6YXqCkaZB4m9FFcaoSH5rR3fjtS7gSTs61e6HP2yGGM8JZjVRmTzgDyvrJg X-Received: by 10.159.48.69 with SMTP id i5mr13462001uab.121.1485121616305; Sun, 22 Jan 2017 13:46:56 -0800 (PST) X-Received: by 10.159.48.69 with SMTP id i5mr13461991uab.121.1485121616051; Sun, 22 Jan 2017 13:46:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.33.79 with HTTP; Sun, 22 Jan 2017 13:46:53 -0800 (PST) In-Reply-To: <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> References: <10036332.AbsS0sHdB9@kitterma-e6430> <543A1C76-9155-4267-ADDF-B2619E5F96DE@kitterman.com> From: Kurt Andersen Date: Sun, 22 Jan 2017 13:46:53 -0800 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=f403045e34b45faef10546b5d24f Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Section [5.2.1] of the ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 21:46:59 -0000 --f403045e34b45faef10546b5d24f Content-Type: text/plain; charset=UTF-8 On Sun, Jan 22, 2017 at 1:18 PM, Scott Kitterman wrote: > > > On January 22, 2017 3:30:14 PM EST, Kurt Andersen > wrote: > >On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein > >wrote: > > > >> > >> . . . ARC . . . inherits . . . from the DKIM RFC. The DKIM RFC > >explicitly > >> requires verifiers to validate signatures with bit sizes ranging from > >512 > >> bits to 2048 bits. > >> > >> There is a separate effort going on in the context of the UTA working > >group to address technologically obsolete encryption strength > >recommendations that have appeared over time in a variety of different > >RFCs. I don't think that adding yet another independent reference is a > >good > >idea and I am strongly opposed to trying to torque the ARC requirements > >to > >be different from DKIM. > > > >If Scott is planning to make dkimpy non-conformant to the DKIM spec, I > >think that is regrettable, but I don't see that making the problem > >worse > >with ARC "going its own way" helps anyone. > > > >--Kurt > > No responsible operator has used the RFC minimum DKIM key sizes for a long > time. They were trivial to bypass half a decade ago. No one has ever > complained about 1024 bits default minimum being too big. I did once get a > complaint about the Debian opendkim package suggesting the minimum should > be 2048 bits. > > Maybe some other working group will accomplish something someday is not a > good reason to perpetuate obsolete crypto in this one. > > Scott K > Don't you think it would be better to "fix" the DKIM spec than to have ARC "do its own thing"? --Kurt --f403045e34b45faef10546b5d24f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jan 22, 2017 at 1:18 PM, Scott Kitterman <sklist@kitterman.com= > wrote:
=


On January 22, 2017 3:30:14 PM EST, Kurt Andersen <kurta@drkurt.com> wrote:
>On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein <peter@valimail.com>
>wrote:
>
>>
>> . . . ARC . . . inherits . . . from the DKIM RFC.=C2=A0 The DKIM R= FC
>explicitly
>> requires verifiers to validate signatures with bit sizes ranging f= rom
>512
>> bits to 2048 bits.
>>
>> There is a separate effort going on in the context of the UTA work= ing
>group to address technologically obsolete encryption strength
>recommendations that have appeared over time in a variety of different<= br> >RFCs. I don't think that adding yet another independent reference i= s a
>good
>idea and I am strongly opposed to trying to torque the ARC requirements=
>to
>be different from DKIM.
>
>If Scott is planning to make dkimpy non-conformant to the DKIM spec, I<= br> >think that is regrettable, but I don't see that making the problem<= br> >worse
>with ARC "going its own way" helps anyone.
>
>--Kurt

No responsible operator has used the RFC minimum DKIM key sizes= for a long time. They were trivial to bypass half a decade ago.=C2=A0 No o= ne has ever complained about 1024 bits default minimum being too big.=C2=A0= I did once get a complaint about the Debian opendkim package suggesting th= e minimum should be 2048 bits.

Maybe some other working group will accomplish something someday is not a g= ood reason to perpetuate obsolete crypto in this one.

Scott K
=

Don't you= think it would be better to "fix" the DKIM spec than to have ARC= "do its own thing"?

--Kurt