From nobody Fri Jan 19 16:35:42 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A56B12E854; Fri, 19 Jan 2018 16:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owjhcP_PRasm; Fri, 19 Jan 2018 16:35:37 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C987B12E867; Fri, 19 Jan 2018 16:35:23 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5693EB816DC; Fri, 19 Jan 2018 16:35:15 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dcrup@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180120003515.5693EB816DC@rfc-editor.org> Date: Fri, 19 Jan 2018 16:35:15 -0800 (PST) Archived-At: Subject: [Dcrup] =?utf-8?q?RFC_8301_on_Cryptographic_Algorithm_and_Key_Usa?= =?utf-8?q?ge_Update_to_DomainKeys_Identified_Mail_=28DKIM=29?= X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2018 00:35:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8301 Title: Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) Author: S. Kitterman Status: Standards Track Stream: IETF Date: January 2018 Mailbox: scott@kitterman.com Pages: 5 Characters: 10075 Updates: RFC 6376 I-D Tag: draft-ietf-dcrup-dkim-usage-06.txt URL: https://www.rfc-editor.org/info/rfc8301 DOI: 10.17487/RFC8301 The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms. This document is a product of the DKIM Crypto Update Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sun Jan 21 00:22:08 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAEE127369 for ; Sun, 21 Jan 2018 00:22:07 -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 AhPv0ZXBy-AF for ; Sun, 21 Jan 2018 00:22:03 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 5BEDD127241 for ; Sun, 21 Jan 2018 00:22:03 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id t79so6929104lfe.3 for ; Sun, 21 Jan 2018 00:22:03 -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; bh=EaJ7TRNcyFgxvhk7UvBeRuQSweYAs8Xa8Zy0fgPxMPc=; b=JdB106gw0QoyFgROLqgDCH1aEJJgMAS/GevRQ07fpPnMRfi33/QQtTNjOZVL0RRW5T 9Dyy0e6rk9t01RG7r5MFgpJxRljofbHGNxcU4jxDQUeNF/ADH7dbMXVvZeJ/FIh/V61n TyHzgSNT5gN/bMAOsM7i93Betw6tFO5YACPJfwopMrdvav5SpE0k66UJ36Keil13ux70 +JCe2QnAHLFoR3Wk3ls+c37McFG/Sw8iv1r1WwdVWdsbSchnbq475gDI/6GPxxbOlgwU 2KQDtGMh5tq6BVUIJQXCyXlx6o6TlS3ui6TnQxeEZVXhj07lkc0ChwKAx8lbJ4jwfI2I Fv5Q== 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=EaJ7TRNcyFgxvhk7UvBeRuQSweYAs8Xa8Zy0fgPxMPc=; b=sfvsf95hTksPetms753WAO0jTKJjhS6lT+pAVuTsBVgaLiQiZLgUi7PCDGM3/SlBCF NrOwu0PlcTfIrQnSsdExjllOp8ki/HHdqBFKD9CWTjvEpuzCCMpmMvVhft82sKctcFHL jpBHtiSGHB7wlA8Z4PYD2vLA6mPk5iidFggw+Pc9M5YBDKTrI1wzHpDbaQLB8yBrOa9Z 0AVbJ9WPOMp52gKalrEFn6OWd6qv5UnHflX9lnTGx0UP8k/CZQFlxiJpweiRpHyHO8m0 b3PEz6q37nz54hkcRqYKSkR/lWKvKpCBtBAI9UQaWD6a0IDLXBhX5u4wdmW6h5/Cosx8 abjw== X-Gm-Message-State: AKwxytdIr/eE3Qn6fOMc6q+tN11ocUeVTZ9rkqH+/WDl5drjib9571Nt tER4T4ohY+w6BxT5BBELTagkV7tEp0hr6PyBMxjNzQ== X-Google-Smtp-Source: AH8x2271i58vr3YE0pDM/y9PnLj+pmw5MLRTf3VlUNwHn/kEbsFMZjtOkyKLcWgLVAetO49qoBlwZzJGs8qNF8ORhKg= X-Received: by 10.25.21.163 with SMTP id 35mr1375827lfv.2.1516522921165; Sun, 21 Jan 2018 00:22:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.101.74 with HTTP; Sun, 21 Jan 2018 00:21:59 -0800 (PST) In-Reply-To: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> From: "Murray S. Kucherawy" Date: Sun, 21 Jan 2018 00:21:59 -0800 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114076700288a405634502cf" Archived-At: Subject: [Dcrup] Fwd: Review of: draft-ietf-dcrup-dkim-crypto-07 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 08:22:07 -0000 --001a114076700288a405634502cf Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message ---------- From: Dave Crocker Date: Sat, Jan 20, 2018 at 9:04 PM Subject: Review of: draft-ietf-dcrup-dkim-crypto-07 To: "Murray S. Kucherawy" , John Levine < johnl@taugh.com> (Please redistribute as needed. I'm not subscribed to dcrup. /d) Review of: A new cryptographic signature method for DKIM I-D: draft-ietf-dcrup-dkim-crypto-07 Reviewed by: D. Crocker Review date: 20 Jan 2018 Summary: The document specifies an additional signing algorithm for DKIM. The document is well-organized and generally well-written. It probably could be used in its current form, although some minor tweaks have been suggested, with the intent of adding clarity for a less-experienced reader. Detail: Abstract > > DKIM was designed to allow new cryptographic algorithms to be added. > This document adds a new signing algorithm. > First sentence is superfluous. I Suggest simply: This document adds a new signing algorithm to DKIM. 1. Introduction > > Discussion Venue: Discussion about this draft is directed to the > dcrup@ietf.org [1] mailing list. > > DKIM [RFC6376] signs e-mail messages, by creating hashes of the > message headers and body and signing the header hash with a digital > signature. Message recipients fetch the signature verification key > from the DNS where it is stored in a TXT record. The defining > documents specify a single signing algorithm, RSA [RFC3447], and > recommend key sizes of 1024 to 2048 bits. > Given that this is a cursory summary, the "where it is stored in a TXT record" is an odd and somewhat distracting bit of detail. This document adds a new stronger signing algorithm, Edwards-Curve > Digital Signature Algorithm using the Curve25519 curve (ed25519), > which has much shorter keys than RSA for similar levels of security. > 3. Ed25519-SHA256 Signing Algorithm > > The ed25519-sha256 signing algorithm computes a message hash as > defined in section 3 of [RFC6376], and signs it with the Hash variant > of Ed25519, as defined in in RFC 8032 section 5.1 [RFC8032]. The > as defined in in RFC 8032 section 5.1 [RFC8032]. -> as defined in section 5.1 of [RFC8032]. signing algorithm is HashEdDSA. (Even though the input to the > (Even though the input to the -> Even though the input to the... This seems a significant enough point to warrant some visual highlighting. signing algorithm has already been hashed, the PureEdDSA which does > not do an additional hash is not widely implemented, and the extra > hash causes no problems other than an insignificant slowdown.) The > an insignificant slowdown.) -> negligible incremental computational overhead.) DNS record for the verification public key MUST have a "k=ed25519" > The DNS record... ->

The DNS record The sentence switches to a significantly different issue and includes a normative point, where the previous text had had none. So, again, worth some visual emphasis. tag to indicate that the key is an Ed25519 rather than RSA key. > Stylistically, I'm not fond of using normative terms for what is simply straight definition. That is, k= is simply definitional. The provided k= value defined here specifies use of the algorithm. (Yes, I know that MUST is popular for such things. But consider a specification for arithmetic operators and having the spec say that a "+" MUST be used for addition and a "*" MUST be used for multiplication, and... So I suggest simple declarative language rather than invoking the god of MUST.) Note: since Ed25519 keys are 256 bits long, DNS key record data will > A quick scan of RFC 8302 doesn't make it obvious to me which ED25519 key is meant (public vs. private) and where it says they are 256 bits. So please cite the specific section/subsection that is being referenced here. generally fit in a single 255 byte TXT string, and will work even > with DNS provisioning software that doesn't handle multi-string TXT > records. > > 4. Signature and key syntax > > The syntax of DKIM signatures and DKIM keys are updated as follows. > > 4.1. Signature syntax > > The syntax of DKIM algorithm tags in section 3.5 of [RFC6376] is > updated by adding this rule to the existing rule for sig-a-tag-k: > > ABNF: > > sig-a-tag-k =/ "ed25519" > Strictly speaking, I believe this is meant to modify an existing rule, rather than add a new one. So perhaps: by adding this rule to the existing rule for sig-a-tag-k: -> by modifying the rule sig-a-tag-k to add the indicated alternative: 4.2. Key syntax > > The syntax of DKIM key tags in section 3.6.1 of [RFC6376] is updated > by adding this rule to the existing rule for key-k-tag-type: > > ABNF: > > key-k-tag-type =/ "ed25519" > similar comment as above. 5. Key and algorithm choice and strength > > Section 3.3 of [RFC6376] describes DKIM's hash and signature > algorithms. It is updated as follows: > It is updated as follows: -> It is updated by adding the following sentence to the first paragraph. > Signers SHOULD implement and versifiers MUST implement the > ed25519-sha256 algorithm. > > > > > > Levine Expires June 4, 2018 [Page 3] > > Internet-Draft DKIM Crypto Update December 2017 > > > 6. Transition Considerations > > For backward compatibility, signers MAY add multiple signatures that > This appears to be claiming to invent the ability to do multiple signatures, along with giving permission to use it. Since that ability already exists and is permitted anytime, the phrasing and use of MAY is problematic here. I believe what is intended is: For backward compatibility until support of the new algorithms is sufficiently widespread, signers might choose to add multiple signatures, using old and new signing algorithms. use old and new signing algorithms. Since there can only be a single > key record in the DNS for each selector, the signatures will have to > use different selectors, although they can use the same d= and i= > identifiers. > Truly trivial nit: i= is irrelevant to the receiver. 7. Security Considerations > > Ed25519 is a widely used cryptographic technique, so the security of > DKIM signatures using new signing algorithms should be at least as > good as those using old algorithms. > using new -> using these new d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --001a114076700288a405634502cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded messag= e ----------
From: Dave Crocker <dcrocker@bbiw.net&= gt;
Date: Sat, Jan 20, 2018 at 9:04 PM
Subject: Review of: dra= ft-ietf-dcrup-dkim-crypto-07
To: "Murray S. Kucherawy" <superuser@gmail.com>, John Levin= e <johnl@taugh.com>

(Please redistribute as needed. I'm not subscribed to dcrup. /d)


Review of:=C2=A0 =C2=A0 A new cryptographic signature method for DKIM
I-D:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-dcrup-dkim-crypto-07=

Reviewed by:=C2=A0 D. Crocker
Review date:=C2=A0 20 Jan 2018


Summary:

The document specifies an additional signing algorithm for DKIM.=C2=A0 The = document is well-organized and generally well-written.=C2=A0 It probably co= uld be used in its current form, although some minor tweaks have been sugge= sted, with the intent of adding clarity for a less-experienced reader.


Detail:

Abstract

=C2=A0 =C2=A0DKIM was designed to allow new cryptographic algorithms to be = added.
=C2=A0 =C2=A0This document adds a new signing algorithm.

First sentence is superfluous.

I Suggest simply:

=C2=A0 =C2=A0 =C2=A0This document adds a new signing algorithm to DKIM.



1.=C2=A0 Introduction

=C2=A0 =C2=A0Discussion Venue:=C2=A0 =C2=A0 Discussion about this draft is = directed to the
=C2=A0 =C2=A0 =C2=A0 dc= rup@ietf.org [1] mailing list.

=C2=A0 =C2=A0DKIM [RFC6376] signs e-mail messages, by creating hashes of th= e
=C2=A0 =C2=A0message headers and body and signing the header hash with a di= gital
=C2=A0 =C2=A0signature.=C2=A0 Message recipients fetch the signature verifi= cation key
=C2=A0 =C2=A0from the DNS where it is stored in a TXT record.=C2=A0 The def= ining
=C2=A0 =C2=A0documents specify a single signing algorithm, RSA [RFC3447], a= nd
=C2=A0 =C2=A0recommend key sizes of 1024 to 2048 bits.

Given that this is a cursory summary, the "where it is stored in a TXT= record" is an odd and somewhat distracting bit of detail.


=C2=A0 =C2=A0This document adds a new stronger signing algorithm, Edwards-C= urve
=C2=A0 =C2=A0Digital Signature Algorithm using the Curve25519 curve (ed2551= 9),
=C2=A0 =C2=A0which has much shorter keys than RSA for similar levels of sec= urity.


3.=C2=A0 Ed25519-SHA256 Signing Algorithm

=C2=A0 =C2=A0The ed25519-sha256 signing algorithm computes a message hash a= s
=C2=A0 =C2=A0defined in section 3 of [RFC6376], and signs it with the Hash = variant
=C2=A0 =C2=A0of Ed25519, as defined in in RFC 8032 section 5.1 [RFC8032].= =C2=A0 The

=C2=A0 =C2=A0as defined in in RFC 8032 section 5.1 [RFC8032].
=C2=A0 =C2=A0->
=C2=A0 =C2=A0as defined in section 5.1 of [RFC8032].


=C2=A0 =C2=A0signing algorithm is HashEdDSA.=C2=A0 (Even though the input t= o the

=C2=A0 =C2=A0(Even though the input to the

=C2=A0 =C2=A0->

=C2=A0 =C2=A0<indented sub-paragraph>

=C2=A0 =C2=A0 =C2=A0 Even though the input to the...

This seems a significant enough point to warrant some visual highlighting.<= br>

=C2=A0 =C2=A0signing algorithm has already been hashed, the PureEdDSA which= does
=C2=A0 =C2=A0not do an additional hash is not widely implemented, and the e= xtra
=C2=A0 =C2=A0hash causes no problems other than an insignificant slowdown.)= =C2=A0 The

=C2=A0 =C2=A0an insignificant slowdown.)
=C2=A0 =C2=A0->
=C2=A0 =C2=A0negligible incremental computational overhead.)


=C2=A0 =C2=A0DNS record for the verification public key MUST have a "k= =3Ded25519"

=C2=A0 =C2=A0The DNS record...
=C2=A0 =C2=A0->
=C2=A0 =C2=A0<p>
=C2=A0 =C2=A0The DNS record

The sentence switches to a significantly different issue and includes a nor= mative point, where the previous text had had none. So, again, worth some v= isual emphasis.


=C2=A0 =C2=A0tag to indicate that the key is an Ed25519 rather than RSA key= .

Stylistically, I'm not fond of using normative terms for what is simply= straight definition.

That is, k=3D is simply definitional.=C2=A0 The provided k=3D value defined= here specifies use of the algorithm. (Yes, I know that MUST is popular for= such things. But consider a specification for arithmetic operators and hav= ing the spec say that a "+" MUST be used for addition and a "= ;*" MUST be used for multiplication, and...=C2=A0 So I suggest simple = declarative language rather than invoking the god of MUST.)



=C2=A0 =C2=A0Note: since Ed25519 keys are 256 bits long, DNS key record dat= a will

A quick scan of RFC 8302 doesn't make it obvious to me which ED25519 ke= y is meant (public vs. private) and where it says they are 256 bits.=C2=A0 = So please cite the specific section/subsection that is being referenced her= e.


=C2=A0 =C2=A0generally fit in a single 255 byte TXT string, and will work e= ven
=C2=A0 =C2=A0with DNS provisioning software that doesn't handle multi-s= tring TXT
=C2=A0 =C2=A0records.

4.=C2=A0 Signature and key syntax

=C2=A0 =C2=A0The syntax of DKIM signatures and DKIM keys are updated as fol= lows.

4.1.=C2=A0 Signature syntax

=C2=A0 =C2=A0The syntax of DKIM algorithm tags in section 3.5 of [RFC6376] = is
=C2=A0 =C2=A0updated by adding this rule to the existing rule for sig-a-tag= -k:

=C2=A0 =C2=A0 =C2=A0 =C2=A0ABNF:

=C2=A0 =C2=A0 =C2=A0 =C2=A0sig-a-tag-k =3D/ "ed25519"

Strictly speaking, I believe this is meant to modify an existing rule, rath= er than add a new one.=C2=A0 So perhaps:

=C2=A0 =C2=A0by adding this rule to the existing rule for sig-a-tag-k:
=C2=A0 =C2=A0->
=C2=A0 =C2=A0by modifying the rule sig-a-tag-k to add the indicated alterna= tive:


4.2.=C2=A0 Key syntax

=C2=A0 =C2=A0The syntax of DKIM key tags in section 3.6.1 of [RFC6376] is u= pdated
=C2=A0 =C2=A0by adding this rule to the existing rule for key-k-tag-type:
=C2=A0 =C2=A0 =C2=A0 =C2=A0ABNF:

=C2=A0 =C2=A0 =C2=A0 =C2=A0key-k-tag-type=C2=A0 =3D/ "ed25519"

similar comment as above.


5.=C2=A0 Key and algorithm choice and strength

=C2=A0 =C2=A0Section 3.3 of [RFC6376] describes DKIM's hash and signatu= re
=C2=A0 =C2=A0algorithms.=C2=A0 It is updated as follows:

=C2=A0 =C2=A0It is updated as follows:
=C2=A0 =C2=A0->
=C2=A0 =C2=A0It is updated by adding the following sentence to the first pa= ragraph.



=C2=A0 =C2=A0Signers SHOULD implement and versifiers MUST implement the
=C2=A0 =C2=A0ed25519-sha256 algorithm.





Levine=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires June 4, 2018=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 [Page 3]
=0C
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DKIM Crypto U= pdate=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 December 2017


6.=C2=A0 Transition Considerations

=C2=A0 =C2=A0For backward compatibility, signers MAY add multiple signature= s that

This appears to be claiming to invent the ability to do multiple signatures= , along with giving permission to use it.=C2=A0 Since that ability already = exists and is permitted anytime, the phrasing and use of MAY is problematic= here.

I believe what is intended is:

=C2=A0 =C2=A0For backward compatibility until support of the new algorithms= is sufficiently widespread, signers might choose to add multiple signature= s, using old and new signing algorithms.


=C2=A0 =C2=A0use old and new signing algorithms.=C2=A0 Since there can only= be a single
=C2=A0 =C2=A0key record in the DNS for each selector, the signatures will h= ave to
=C2=A0 =C2=A0use different selectors, although they can use the same d=3D a= nd i=3D
=C2=A0 =C2=A0identifiers.

Truly trivial nit:=C2=A0 i=3D is irrelevant to the receiver.


7.=C2=A0 Security Considerations

=C2=A0 =C2=A0Ed25519 is a widely used cryptographic technique, so the secur= ity of
=C2=A0 =C2=A0DKIM signatures using new signing algorithms should be at leas= t as
=C2=A0 =C2=A0good as those using old algorithms.

=C2=A0 =C2=A0using new=C2=A0 ->=C2=A0 using these new


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--001a114076700288a405634502cf-- From nobody Sun Jan 21 09:44:21 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C562126D73 for ; Sun, 21 Jan 2018 09:44:03 -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=YJ7dIJGc; dkim=pass (1536-bit key) header.d=taugh.com header.b=uEQlh5fz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB7W3N_S8gjF for ; Sun, 21 Jan 2018 09:44:00 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31E3124D37 for ; Sun, 21 Jan 2018 09:44:00 -0800 (PST) Received: (qmail 92734 invoked from network); 21 Jan 2018 17:43:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16a3c.5a64d15f.k1801; bh=1kLBD7hVlLlP7HqLer1sqfxhB6gyUykyqkSUQRlfEOo=; b=YJ7dIJGc8ah+BZbX2fMIPAF2w4dzdLw+9k3TJNRpL6aztX1OWeXwnHGnBPueyB7IAKXFnDeE7a0+p0bqKSOGOmMRcWR6+PAg8tW3y/lIAdm1817rZSoWWtlh64B4UVQk7PHckQjqa620cawFhs3l67gp7/A5cfW22hiNShmi+FJyTBIAobf9BFdm2DQx22GvBS3LKDCRXeEgBIXAwOa51oqNF3LzcLwWrPtNHE3C1tkgR8IAI/d/aIHjzbT3LP9D 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=16a3c.5a64d15f.k1801; bh=1kLBD7hVlLlP7HqLer1sqfxhB6gyUykyqkSUQRlfEOo=; b=uEQlh5fz3n5PlpYntBG9qnM1l2+Bx9B+RGvXJBMa1FxSGNHfNCvernnKxdszQSMoxYEqAbBZn+HEm7NJ6MAAkIsJylfekKZgimjdQc/14Z2iHugXkKo08nRgIiUj7FzDFyMpdekzYPMMxs092ShHd3F3I/xOwyruMdo/lr2wg98YkimBTDxcgnUcOqliHsizyMHegvo19aJXzKOUno3AorNMW0a8R/ML3bWwkbyCwrYQta3eswuFDr4We09uibcK Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 21 Jan 2018 17:43:59 -0000 Date: 21 Jan 2018 12:43:58 -0500 Message-ID: From: "John R Levine" To: "Dave Crocker" Cc: "Murray S. Kucherawy" , dcrup@ietf.org In-Reply-To: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] Review of: draft-ietf-dcrup-dkim-crypto-07 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 17:44:18 -0000 Thanks, this mostly seems reasonable. Some of the minor copy edits I'd rather leave for the editors so they make it match the style book. One gaping hole we have left to fill is the format for ed25519 keys in DNS records. For RSA keys, everyone uses base64 encoded ASN.1 keys, but at this point different libraries use different forms for ed25519. Since the keys are fixed length and fixed format, the extra cruft from ASN.1 is not helpful, and it'd require putting an ASN.1 decoder into the dkim library if the crypto library it calls doesn't use ASN.1. Scott K and I have been scratching our heads about this for a while but haven't come up with any great inspiration. R's, John On Sat, 20 Jan 2018, Dave Crocker wrote: > (Please redistribute as needed. I'm not subscribed to dcrup. /d) > > > Review of: A new cryptographic signature method for DKIM > I-D: draft-ietf-dcrup-dkim-crypto-07 > > Reviewed by: D. Crocker > Review date: 20 Jan 2018 > > > Summary: > > The document specifies an additional signing algorithm for DKIM. The > document is well-organized and generally well-written. It probably could be > used in its current form, although some minor tweaks have been suggested, > with the intent of adding clarity for a less-experienced reader. > > > Detail: > >> Abstract >> >> DKIM was designed to allow new cryptographic algorithms to be added. >> This document adds a new signing algorithm. > > First sentence is superfluous. > > I Suggest simply: > > This document adds a new signing algorithm to DKIM. > > > >> 1. Introduction >> >> Discussion Venue: Discussion about this draft is directed to the >> dcrup@ietf.org [1] mailing list. >> >> DKIM [RFC6376] signs e-mail messages, by creating hashes of the >> message headers and body and signing the header hash with a digital >> signature. Message recipients fetch the signature verification key >> from the DNS where it is stored in a TXT record. The defining >> documents specify a single signing algorithm, RSA [RFC3447], and >> recommend key sizes of 1024 to 2048 bits. > > Given that this is a cursory summary, the "where it is stored in a TXT > record" is an odd and somewhat distracting bit of detail. > > >> This document adds a new stronger signing algorithm, Edwards-Curve >> Digital Signature Algorithm using the Curve25519 curve (ed25519), >> which has much shorter keys than RSA for similar levels of security. > > >> 3. Ed25519-SHA256 Signing Algorithm >> >> The ed25519-sha256 signing algorithm computes a message hash as >> defined in section 3 of [RFC6376], and signs it with the Hash variant >> of Ed25519, as defined in in RFC 8032 section 5.1 [RFC8032]. The > > as defined in in RFC 8032 section 5.1 [RFC8032]. > -> > as defined in section 5.1 of [RFC8032]. > > >> signing algorithm is HashEdDSA. (Even though the input to the > > (Even though the input to the > > -> > > > > Even though the input to the... > > This seems a significant enough point to warrant some visual highlighting. > > >> signing algorithm has already been hashed, the PureEdDSA which does >> not do an additional hash is not widely implemented, and the extra >> hash causes no problems other than an insignificant slowdown.) The > > an insignificant slowdown.) > -> > negligible incremental computational overhead.) > > >> DNS record for the verification public key MUST have a "k=ed25519" > > The DNS record... > -> >

> The DNS record > > The sentence switches to a significantly different issue and includes a > normative point, where the previous text had had none. So, again, worth some > visual emphasis. > > >> tag to indicate that the key is an Ed25519 rather than RSA key. > > Stylistically, I'm not fond of using normative terms for what is simply > straight definition. > > That is, k= is simply definitional. The provided k= value defined here > specifies use of the algorithm. (Yes, I know that MUST is popular for such > things. But consider a specification for arithmetic operators and having the > spec say that a "+" MUST be used for addition and a "*" MUST be used for > multiplication, and... So I suggest simple declarative language rather than > invoking the god of MUST.) > > > >> Note: since Ed25519 keys are 256 bits long, DNS key record data will > > A quick scan of RFC 8302 doesn't make it obvious to me which ED25519 key is > meant (public vs. private) and where it says they are 256 bits. So please > cite the specific section/subsection that is being referenced here. > > >> generally fit in a single 255 byte TXT string, and will work even >> with DNS provisioning software that doesn't handle multi-string TXT >> records. >> >> 4. Signature and key syntax >> >> The syntax of DKIM signatures and DKIM keys are updated as follows. >> >> 4.1. Signature syntax >> >> The syntax of DKIM algorithm tags in section 3.5 of [RFC6376] is >> updated by adding this rule to the existing rule for sig-a-tag-k: >> >> ABNF: >> >> sig-a-tag-k =/ "ed25519" > > Strictly speaking, I believe this is meant to modify an existing rule, rather > than add a new one. So perhaps: > > by adding this rule to the existing rule for sig-a-tag-k: > -> > by modifying the rule sig-a-tag-k to add the indicated alternative: > > >> 4.2. Key syntax >> >> The syntax of DKIM key tags in section 3.6.1 of [RFC6376] is updated >> by adding this rule to the existing rule for key-k-tag-type: >> >> ABNF: >> >> key-k-tag-type =/ "ed25519" > > similar comment as above. > > >> 5. Key and algorithm choice and strength >> >> Section 3.3 of [RFC6376] describes DKIM's hash and signature >> algorithms. It is updated as follows: > > It is updated as follows: > -> > It is updated by adding the following sentence to the first paragraph. > > >> >> Signers SHOULD implement and versifiers MUST implement the >> ed25519-sha256 algorithm. >> >> >> >> >> >> Levine Expires June 4, 2018 [Page 3] >> >> Internet-Draft DKIM Crypto Update December 2017 >> >> >> 6. Transition Considerations >> >> For backward compatibility, signers MAY add multiple signatures that > > This appears to be claiming to invent the ability to do multiple signatures, > along with giving permission to use it. Since that ability already exists > and is permitted anytime, the phrasing and use of MAY is problematic here. > > I believe what is intended is: > > For backward compatibility until support of the new algorithms is > sufficiently widespread, signers might choose to add multiple signatures, > using old and new signing algorithms. > > >> use old and new signing algorithms. Since there can only be a single >> key record in the DNS for each selector, the signatures will have to >> use different selectors, although they can use the same d= and i= >> identifiers. > > Truly trivial nit: i= is irrelevant to the receiver. > > >> 7. Security Considerations >> >> Ed25519 is a widely used cryptographic technique, so the security of >> DKIM signatures using new signing algorithms should be at least as >> good as those using old algorithms. > > using new -> using these new > > > d/ > > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Jan 21 10:56:51 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7DA1270A0 for ; Sun, 21 Jan 2018 10:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rx3N2wj_Ukne for ; Sun, 21 Jan 2018 10:56:48 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869EC127023 for ; Sun, 21 Jan 2018 10:56:48 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0LIpqbh032486; Sun, 21 Jan 2018 18:56:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=5W518zhgwaiG0y6JhrTVIadWdvwAwDkenznC/glqGB0=; b=nAmENF7qF9LjkBh/HdUL1hBec7KI4mC53zMhgsKW1WTMGKIv7LjI+AqA2Zu88NVYIFuR tdMTOWOYV3a60TPzJlAreKHDcvnzu7RF/8MyfNolPLk2zhsCOGgmIxHIFgvajEJbm3Wk /CRih0WL5yLSiWY2l3/RJvAnKiSrm0FVxFY6rxJrEscWzshLuMX85lLmOcbloGrw1lQm 7x42wcZCqFRvC1OrnnI0XXp9eaqLpE4wKDjpyE4IwGO6MosVo/Af1+dmfZmYoKX7TJ2P I9tdEAW/Hw50itT1xrE2ifmmo0wAy1yFJw7z2OJt1+2TiUaTg0yiqoCoPhmdYuojNQoL 2Q== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2fky2a7ddx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Jan 2018 18:56:30 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0LIu23h021632; Sun, 21 Jan 2018 13:56:29 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fm20ebgn3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 21 Jan 2018 13:56:29 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 21 Jan 2018 12:56:27 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Sun, 21 Jan 2018 12:56:26 -0600 From: "Salz, Rich" To: John R Levine , Dave Crocker CC: "dcrup@ietf.org" , "Murray S. Kucherawy" Thread-Topic: [Dcrup] Review of: draft-ietf-dcrup-dkim-crypto-07 Thread-Index: AQHTkt9+a7rb9XRGdUm6a+SFe9a30KN/EeiA Date: Sun, 21 Jan 2018 18:56:25 +0000 Message-ID: <96DD70BC-6F8F-4103-B80B-CA9829BBBDA6@akamai.com> References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.101] Content-Type: text/plain; charset="utf-8" Content-ID: <017A347DDCA9C24887C9E9EEAC7628B1@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-21_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801210275 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-21_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801210274 Archived-At: Subject: Re: [Dcrup] Review of: draft-ietf-dcrup-dkim-crypto-07 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 18:56:51 -0000 QW55IHJlYXNvbiBub3QgdG8gdXNlIHRoZSBiYXNlNjQgb2YgNDAgYnl0ZXMgb2YgdGhlIGtleT8N Cg0KT24gMS8yMS8xOCwgMTI6NDQgUE0sICJKb2huIFIgTGV2aW5lIiA8am9obmxAdGF1Z2guY29t PiB3cm90ZToNCg0KICAgIFRoYW5rcywgdGhpcyBtb3N0bHkgc2VlbXMgcmVhc29uYWJsZS4gIFNv bWUgb2YgdGhlIG1pbm9yIGNvcHkgZWRpdHMgSSdkIA0KICAgIHJhdGhlciBsZWF2ZSBmb3IgdGhl IGVkaXRvcnMgc28gdGhleSBtYWtlIGl0IG1hdGNoIHRoZSBzdHlsZSBib29rLg0KICAgIA0KICAg IE9uZSBnYXBpbmcgaG9sZSB3ZSBoYXZlIGxlZnQgdG8gZmlsbCBpcyB0aGUgZm9ybWF0IGZvciBl ZDI1NTE5IGtleXMgaW4gRE5TIA0KICAgIHJlY29yZHMuICBGb3IgUlNBIGtleXMsIGV2ZXJ5b25l IHVzZXMgYmFzZTY0IGVuY29kZWQgQVNOLjEga2V5cywgYnV0IGF0IA0KICAgIHRoaXMgcG9pbnQg ZGlmZmVyZW50IGxpYnJhcmllcyB1c2UgZGlmZmVyZW50IGZvcm1zIGZvciBlZDI1NTE5LiAgU2lu Y2UgdGhlIA0KICAgIGtleXMgYXJlIGZpeGVkIGxlbmd0aCBhbmQgZml4ZWQgZm9ybWF0LCB0aGUg ZXh0cmEgY3J1ZnQgZnJvbSBBU04uMSBpcyBub3QgDQogICAgaGVscGZ1bCwgYW5kIGl0J2QgcmVx dWlyZSBwdXR0aW5nIGFuIEFTTi4xIGRlY29kZXIgaW50byB0aGUgZGtpbSBsaWJyYXJ5IA0KICAg IGlmIHRoZSBjcnlwdG8gbGlicmFyeSBpdCBjYWxscyBkb2Vzbid0IHVzZSBBU04uMS4NCiAgICAN CiAgICBTY290dCBLIGFuZCBJIGhhdmUgYmVlbiBzY3JhdGNoaW5nIG91ciBoZWFkcyBhYm91dCB0 aGlzIGZvciBhIHdoaWxlIGJ1dCANCiAgICBoYXZlbid0IGNvbWUgdXAgd2l0aCBhbnkgZ3JlYXQg aW5zcGlyYXRpb24uDQogICAgDQogICAgUidzLA0KICAgIEpvaG4NCiAgICANCiAgICANCiAgICBP biBTYXQsIDIwIEphbiAyMDE4LCBEYXZlIENyb2NrZXIgd3JvdGU6DQogICAgDQogICAgPiAoUGxl YXNlIHJlZGlzdHJpYnV0ZSBhcyBuZWVkZWQuIEknbSBub3Qgc3Vic2NyaWJlZCB0byBkY3J1cC4g L2QpDQogICAgPg0KICAgID4NCiAgICA+IFJldmlldyBvZjogICAgQSBuZXcgY3J5cHRvZ3JhcGhp YyBzaWduYXR1cmUgbWV0aG9kIGZvciBES0lNDQogICAgPiBJLUQ6ICAgICAgICAgIGRyYWZ0LWll dGYtZGNydXAtZGtpbS1jcnlwdG8tMDcNCiAgICA+DQogICAgPiBSZXZpZXdlZCBieTogIEQuIENy b2NrZXINCiAgICA+IFJldmlldyBkYXRlOiAgMjAgSmFuIDIwMTgNCiAgICA+DQogICAgPg0KICAg ID4gU3VtbWFyeToNCiAgICA+DQogICAgPiBUaGUgZG9jdW1lbnQgc3BlY2lmaWVzIGFuIGFkZGl0 aW9uYWwgc2lnbmluZyBhbGdvcml0aG0gZm9yIERLSU0uICBUaGUgDQogICAgPiBkb2N1bWVudCBp cyB3ZWxsLW9yZ2FuaXplZCBhbmQgZ2VuZXJhbGx5IHdlbGwtd3JpdHRlbi4gIEl0IHByb2JhYmx5 IGNvdWxkIGJlIA0KICAgID4gdXNlZCBpbiBpdHMgY3VycmVudCBmb3JtLCBhbHRob3VnaCBzb21l IG1pbm9yIHR3ZWFrcyBoYXZlIGJlZW4gc3VnZ2VzdGVkLCANCiAgICA+IHdpdGggdGhlIGludGVu dCBvZiBhZGRpbmcgY2xhcml0eSBmb3IgYSBsZXNzLWV4cGVyaWVuY2VkIHJlYWRlci4NCiAgICA+ DQogICAgPg0KICAgID4gRGV0YWlsOg0KICAgID4NCiAgICA+PiAgQWJzdHJhY3QNCiAgICA+Pg0K ICAgID4+ICAgICBES0lNIHdhcyBkZXNpZ25lZCB0byBhbGxvdyBuZXcgY3J5cHRvZ3JhcGhpYyBh bGdvcml0aG1zIHRvIGJlIGFkZGVkLg0KICAgID4+ICAgICBUaGlzIGRvY3VtZW50IGFkZHMgYSBu ZXcgc2lnbmluZyBhbGdvcml0aG0uDQogICAgPg0KICAgID4gRmlyc3Qgc2VudGVuY2UgaXMgc3Vw ZXJmbHVvdXMuDQogICAgPg0KICAgID4gSSBTdWdnZXN0IHNpbXBseToNCiAgICA+DQogICAgPiAg ICAgVGhpcyBkb2N1bWVudCBhZGRzIGEgbmV3IHNpZ25pbmcgYWxnb3JpdGhtIHRvIERLSU0uDQog ICAgPg0KICAgID4NCiAgICA+DQogICAgPj4gIDEuICBJbnRyb2R1Y3Rpb24NCiAgICA+Pg0KICAg ID4+ICAgICBEaXNjdXNzaW9uIFZlbnVlOiAgICBEaXNjdXNzaW9uIGFib3V0IHRoaXMgZHJhZnQg aXMgZGlyZWN0ZWQgdG8gdGhlDQogICAgPj4gICAgICAgIGRjcnVwQGlldGYub3JnIFsxXSBtYWls aW5nIGxpc3QuDQogICAgPj4NCiAgICA+PiAgICAgREtJTSBbUkZDNjM3Nl0gc2lnbnMgZS1tYWls IG1lc3NhZ2VzLCBieSBjcmVhdGluZyBoYXNoZXMgb2YgdGhlDQogICAgPj4gICAgIG1lc3NhZ2Ug aGVhZGVycyBhbmQgYm9keSBhbmQgc2lnbmluZyB0aGUgaGVhZGVyIGhhc2ggd2l0aCBhIGRpZ2l0 YWwNCiAgICA+PiAgICAgc2lnbmF0dXJlLiAgTWVzc2FnZSByZWNpcGllbnRzIGZldGNoIHRoZSBz aWduYXR1cmUgdmVyaWZpY2F0aW9uIGtleQ0KICAgID4+ICAgICBmcm9tIHRoZSBETlMgd2hlcmUg aXQgaXMgc3RvcmVkIGluIGEgVFhUIHJlY29yZC4gIFRoZSBkZWZpbmluZw0KICAgID4+ICAgICBk b2N1bWVudHMgc3BlY2lmeSBhIHNpbmdsZSBzaWduaW5nIGFsZ29yaXRobSwgUlNBIFtSRkMzNDQ3 XSwgYW5kDQogICAgPj4gICAgIHJlY29tbWVuZCBrZXkgc2l6ZXMgb2YgMTAyNCB0byAyMDQ4IGJp dHMuDQogICAgPg0KICAgID4gR2l2ZW4gdGhhdCB0aGlzIGlzIGEgY3Vyc29yeSBzdW1tYXJ5LCB0 aGUgIndoZXJlIGl0IGlzIHN0b3JlZCBpbiBhIFRYVCANCiAgICA+IHJlY29yZCIgaXMgYW4gb2Rk IGFuZCBzb21ld2hhdCBkaXN0cmFjdGluZyBiaXQgb2YgZGV0YWlsLg0KICAgID4NCiAgICA+DQog ICAgPj4gICAgIFRoaXMgZG9jdW1lbnQgYWRkcyBhIG5ldyBzdHJvbmdlciBzaWduaW5nIGFsZ29y aXRobSwgRWR3YXJkcy1DdXJ2ZQ0KICAgID4+ICAgICBEaWdpdGFsIFNpZ25hdHVyZSBBbGdvcml0 aG0gdXNpbmcgdGhlIEN1cnZlMjU1MTkgY3VydmUgKGVkMjU1MTkpLA0KICAgID4+ICAgICB3aGlj aCBoYXMgbXVjaCBzaG9ydGVyIGtleXMgdGhhbiBSU0EgZm9yIHNpbWlsYXIgbGV2ZWxzIG9mIHNl Y3VyaXR5Lg0KICAgID4NCiAgICA+DQogICAgPj4gIDMuICBFZDI1NTE5LVNIQTI1NiBTaWduaW5n IEFsZ29yaXRobQ0KICAgID4+DQogICAgPj4gICAgIFRoZSBlZDI1NTE5LXNoYTI1NiBzaWduaW5n IGFsZ29yaXRobSBjb21wdXRlcyBhIG1lc3NhZ2UgaGFzaCBhcw0KICAgID4+ICAgICBkZWZpbmVk IGluIHNlY3Rpb24gMyBvZiBbUkZDNjM3Nl0sIGFuZCBzaWducyBpdCB3aXRoIHRoZSBIYXNoIHZh cmlhbnQNCiAgICA+PiAgICAgb2YgRWQyNTUxOSwgYXMgZGVmaW5lZCBpbiBpbiBSRkMgODAzMiBz ZWN0aW9uIDUuMSBbUkZDODAzMl0uICBUaGUNCiAgICA+DQogICAgPiAgICBhcyBkZWZpbmVkIGlu IGluIFJGQyA4MDMyIHNlY3Rpb24gNS4xIFtSRkM4MDMyXS4NCiAgICA+ICAgLT4NCiAgICA+ICAg IGFzIGRlZmluZWQgaW4gc2VjdGlvbiA1LjEgb2YgW1JGQzgwMzJdLg0KICAgID4NCiAgICA+DQog ICAgPj4gICAgIHNpZ25pbmcgYWxnb3JpdGhtIGlzIEhhc2hFZERTQS4gIChFdmVuIHRob3VnaCB0 aGUgaW5wdXQgdG8gdGhlDQogICAgPg0KICAgID4gICAoRXZlbiB0aG91Z2ggdGhlIGlucHV0IHRv IHRoZQ0KICAgID4NCiAgICA+ICAgLT4gDQogICAgPg0KICAgID4gICA8aW5kZW50ZWQgc3ViLXBh cmFncmFwaD4NCiAgICA+DQogICAgPiAgICAgIEV2ZW4gdGhvdWdoIHRoZSBpbnB1dCB0byB0aGUu Li4NCiAgICA+DQogICAgPiBUaGlzIHNlZW1zIGEgc2lnbmlmaWNhbnQgZW5vdWdoIHBvaW50IHRv IHdhcnJhbnQgc29tZSB2aXN1YWwgaGlnaGxpZ2h0aW5nLg0KICAgID4NCiAgICA+DQogICAgPj4g ICAgIHNpZ25pbmcgYWxnb3JpdGhtIGhhcyBhbHJlYWR5IGJlZW4gaGFzaGVkLCB0aGUgUHVyZUVk RFNBIHdoaWNoIGRvZXMNCiAgICA+PiAgICAgbm90IGRvIGFuIGFkZGl0aW9uYWwgaGFzaCBpcyBu b3Qgd2lkZWx5IGltcGxlbWVudGVkLCBhbmQgdGhlIGV4dHJhDQogICAgPj4gICAgIGhhc2ggY2F1 c2VzIG5vIHByb2JsZW1zIG90aGVyIHRoYW4gYW4gaW5zaWduaWZpY2FudCBzbG93ZG93bi4pICBU aGUNCiAgICA+DQogICAgPiAgICBhbiBpbnNpZ25pZmljYW50IHNsb3dkb3duLikNCiAgICA+ICAg LT4NCiAgICA+ICAgIG5lZ2xpZ2libGUgaW5jcmVtZW50YWwgY29tcHV0YXRpb25hbCBvdmVyaGVh ZC4pDQogICAgPg0KICAgID4NCiAgICA+PiAgICAgRE5TIHJlY29yZCBmb3IgdGhlIHZlcmlmaWNh dGlvbiBwdWJsaWMga2V5IE1VU1QgaGF2ZSBhICJrPWVkMjU1MTkiDQogICAgPg0KICAgID4gICAg VGhlIEROUyByZWNvcmQuLi4NCiAgICA+ICAgLT4NCiAgICA+ICAgIDxwPg0KICAgID4gICAgVGhl IEROUyByZWNvcmQNCiAgICA+DQogICAgPiBUaGUgc2VudGVuY2Ugc3dpdGNoZXMgdG8gYSBzaWdu aWZpY2FudGx5IGRpZmZlcmVudCBpc3N1ZSBhbmQgaW5jbHVkZXMgYSANCiAgICA+IG5vcm1hdGl2 ZSBwb2ludCwgd2hlcmUgdGhlIHByZXZpb3VzIHRleHQgaGFkIGhhZCBub25lLiBTbywgYWdhaW4s IHdvcnRoIHNvbWUgDQogICAgPiB2aXN1YWwgZW1waGFzaXMuDQogICAgPg0KICAgID4NCiAgICA+ PiAgICAgdGFnIHRvIGluZGljYXRlIHRoYXQgdGhlIGtleSBpcyBhbiBFZDI1NTE5IHJhdGhlciB0 aGFuIFJTQSBrZXkuDQogICAgPg0KICAgID4gU3R5bGlzdGljYWxseSwgSSdtIG5vdCBmb25kIG9m IHVzaW5nIG5vcm1hdGl2ZSB0ZXJtcyBmb3Igd2hhdCBpcyBzaW1wbHkgDQogICAgPiBzdHJhaWdo dCBkZWZpbml0aW9uLg0KICAgID4NCiAgICA+IFRoYXQgaXMsIGs9IGlzIHNpbXBseSBkZWZpbml0 aW9uYWwuICBUaGUgcHJvdmlkZWQgaz0gdmFsdWUgZGVmaW5lZCBoZXJlIA0KICAgID4gc3BlY2lm aWVzIHVzZSBvZiB0aGUgYWxnb3JpdGhtLiAoWWVzLCBJIGtub3cgdGhhdCBNVVNUIGlzIHBvcHVs YXIgZm9yIHN1Y2ggDQogICAgPiB0aGluZ3MuIEJ1dCBjb25zaWRlciBhIHNwZWNpZmljYXRpb24g Zm9yIGFyaXRobWV0aWMgb3BlcmF0b3JzIGFuZCBoYXZpbmcgdGhlIA0KICAgID4gc3BlYyBzYXkg dGhhdCBhICIrIiBNVVNUIGJlIHVzZWQgZm9yIGFkZGl0aW9uIGFuZCBhICIqIiBNVVNUIGJlIHVz ZWQgZm9yIA0KICAgID4gbXVsdGlwbGljYXRpb24sIGFuZC4uLiAgU28gSSBzdWdnZXN0IHNpbXBs ZSBkZWNsYXJhdGl2ZSBsYW5ndWFnZSByYXRoZXIgdGhhbiANCiAgICA+IGludm9raW5nIHRoZSBn b2Qgb2YgTVVTVC4pDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPj4gICAgIE5vdGU6IHNpbmNl IEVkMjU1MTkga2V5cyBhcmUgMjU2IGJpdHMgbG9uZywgRE5TIGtleSByZWNvcmQgZGF0YSB3aWxs DQogICAgPg0KICAgID4gQSBxdWljayBzY2FuIG9mIFJGQyA4MzAyIGRvZXNuJ3QgbWFrZSBpdCBv YnZpb3VzIHRvIG1lIHdoaWNoIEVEMjU1MTkga2V5IGlzIA0KICAgID4gbWVhbnQgKHB1YmxpYyB2 cy4gcHJpdmF0ZSkgYW5kIHdoZXJlIGl0IHNheXMgdGhleSBhcmUgMjU2IGJpdHMuICBTbyBwbGVh c2UgDQogICAgPiBjaXRlIHRoZSBzcGVjaWZpYyBzZWN0aW9uL3N1YnNlY3Rpb24gdGhhdCBpcyBi ZWluZyByZWZlcmVuY2VkIGhlcmUuDQogICAgPg0KICAgID4NCiAgICA+PiAgICAgZ2VuZXJhbGx5 IGZpdCBpbiBhIHNpbmdsZSAyNTUgYnl0ZSBUWFQgc3RyaW5nLCBhbmQgd2lsbCB3b3JrIGV2ZW4N CiAgICA+PiAgICAgd2l0aCBETlMgcHJvdmlzaW9uaW5nIHNvZnR3YXJlIHRoYXQgZG9lc24ndCBo YW5kbGUgbXVsdGktc3RyaW5nIFRYVA0KICAgID4+ICAgICByZWNvcmRzLg0KICAgID4+DQogICAg Pj4gIDQuICBTaWduYXR1cmUgYW5kIGtleSBzeW50YXgNCiAgICA+Pg0KICAgID4+ICAgICBUaGUg c3ludGF4IG9mIERLSU0gc2lnbmF0dXJlcyBhbmQgREtJTSBrZXlzIGFyZSB1cGRhdGVkIGFzIGZv bGxvd3MuDQogICAgPj4NCiAgICA+PiAgNC4xLiAgU2lnbmF0dXJlIHN5bnRheA0KICAgID4+DQog ICAgPj4gICAgIFRoZSBzeW50YXggb2YgREtJTSBhbGdvcml0aG0gdGFncyBpbiBzZWN0aW9uIDMu NSBvZiBbUkZDNjM3Nl0gaXMNCiAgICA+PiAgICAgdXBkYXRlZCBieSBhZGRpbmcgdGhpcyBydWxl IHRvIHRoZSBleGlzdGluZyBydWxlIGZvciBzaWctYS10YWctazoNCiAgICA+Pg0KICAgID4+ICAg ICAgICAgQUJORjoNCiAgICA+Pg0KICAgID4+ICAgICAgICAgc2lnLWEtdGFnLWsgPS8gImVkMjU1 MTkiDQogICAgPg0KICAgID4gU3RyaWN0bHkgc3BlYWtpbmcsIEkgYmVsaWV2ZSB0aGlzIGlzIG1l YW50IHRvIG1vZGlmeSBhbiBleGlzdGluZyBydWxlLCByYXRoZXIgDQogICAgPiB0aGFuIGFkZCBh IG5ldyBvbmUuICBTbyBwZXJoYXBzOg0KICAgID4NCiAgICA+ICAgIGJ5IGFkZGluZyB0aGlzIHJ1 bGUgdG8gdGhlIGV4aXN0aW5nIHJ1bGUgZm9yIHNpZy1hLXRhZy1rOg0KICAgID4gICAtPg0KICAg ID4gICAgYnkgbW9kaWZ5aW5nIHRoZSBydWxlIHNpZy1hLXRhZy1rIHRvIGFkZCB0aGUgaW5kaWNh dGVkIGFsdGVybmF0aXZlOg0KICAgID4NCiAgICA+DQogICAgPj4gIDQuMi4gIEtleSBzeW50YXgN CiAgICA+Pg0KICAgID4+ICAgICBUaGUgc3ludGF4IG9mIERLSU0ga2V5IHRhZ3MgaW4gc2VjdGlv biAzLjYuMSBvZiBbUkZDNjM3Nl0gaXMgdXBkYXRlZA0KICAgID4+ICAgICBieSBhZGRpbmcgdGhp cyBydWxlIHRvIHRoZSBleGlzdGluZyBydWxlIGZvciBrZXktay10YWctdHlwZToNCiAgICA+Pg0K ICAgID4+ICAgICAgICAgQUJORjoNCiAgICA+Pg0KICAgID4+ICAgICAgICAga2V5LWstdGFnLXR5 cGUgID0vICJlZDI1NTE5Ig0KICAgID4NCiAgICA+IHNpbWlsYXIgY29tbWVudCBhcyBhYm92ZS4N CiAgICA+DQogICAgPg0KICAgID4+ICA1LiAgS2V5IGFuZCBhbGdvcml0aG0gY2hvaWNlIGFuZCBz dHJlbmd0aA0KICAgID4+DQogICAgPj4gICAgIFNlY3Rpb24gMy4zIG9mIFtSRkM2Mzc2XSBkZXNj cmliZXMgREtJTSdzIGhhc2ggYW5kIHNpZ25hdHVyZQ0KICAgID4+ICAgICBhbGdvcml0aG1zLiAg SXQgaXMgdXBkYXRlZCBhcyBmb2xsb3dzOg0KICAgID4NCiAgICA+ICAgIEl0IGlzIHVwZGF0ZWQg YXMgZm9sbG93czoNCiAgICA+ICAgLT4NCiAgICA+ICAgIEl0IGlzIHVwZGF0ZWQgYnkgYWRkaW5n IHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgdG8gdGhlIGZpcnN0IHBhcmFncmFwaC4NCiAgICA+DQog ICAgPg0KICAgID4+DQogICAgPj4gICAgIFNpZ25lcnMgU0hPVUxEIGltcGxlbWVudCBhbmQgdmVy c2lmaWVycyBNVVNUIGltcGxlbWVudCB0aGUNCiAgICA+PiAgICAgZWQyNTUxOS1zaGEyNTYgYWxn b3JpdGhtLg0KICAgID4+DQogICAgPj4NCiAgICA+Pg0KICAgID4+DQogICAgPj4NCiAgICA+PiAg TGV2aW5lICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUgNCwgMjAxOCAgICAgICAgICAg ICAgICAgIFtQYWdlIDNdDQogICAgPj4NCiAgICA+PiAgSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgREtJTSBDcnlwdG8gVXBkYXRlICAgICAgICAgICAgICBEZWNlbWJlciAyMDE3DQogICAgPj4N CiAgICA+Pg0KICAgID4+ICA2LiAgVHJhbnNpdGlvbiBDb25zaWRlcmF0aW9ucw0KICAgID4+DQog ICAgPj4gICAgIEZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCBzaWduZXJzIE1BWSBhZGQgbXVs dGlwbGUgc2lnbmF0dXJlcyB0aGF0DQogICAgPg0KICAgID4gVGhpcyBhcHBlYXJzIHRvIGJlIGNs YWltaW5nIHRvIGludmVudCB0aGUgYWJpbGl0eSB0byBkbyBtdWx0aXBsZSBzaWduYXR1cmVzLCAN CiAgICA+IGFsb25nIHdpdGggZ2l2aW5nIHBlcm1pc3Npb24gdG8gdXNlIGl0LiAgU2luY2UgdGhh dCBhYmlsaXR5IGFscmVhZHkgZXhpc3RzIA0KICAgID4gYW5kIGlzIHBlcm1pdHRlZCBhbnl0aW1l LCB0aGUgcGhyYXNpbmcgYW5kIHVzZSBvZiBNQVkgaXMgcHJvYmxlbWF0aWMgaGVyZS4NCiAgICA+ DQogICAgPiBJIGJlbGlldmUgd2hhdCBpcyBpbnRlbmRlZCBpczoNCiAgICA+DQogICAgPiAgIEZv ciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHVudGlsIHN1cHBvcnQgb2YgdGhlIG5ldyBhbGdvcml0 aG1zIGlzIA0KICAgID4gc3VmZmljaWVudGx5IHdpZGVzcHJlYWQsIHNpZ25lcnMgbWlnaHQgY2hv b3NlIHRvIGFkZCBtdWx0aXBsZSBzaWduYXR1cmVzLCANCiAgICA+IHVzaW5nIG9sZCBhbmQgbmV3 IHNpZ25pbmcgYWxnb3JpdGhtcy4NCiAgICA+DQogICAgPg0KICAgID4+ICAgICB1c2Ugb2xkIGFu ZCBuZXcgc2lnbmluZyBhbGdvcml0aG1zLiAgU2luY2UgdGhlcmUgY2FuIG9ubHkgYmUgYSBzaW5n bGUNCiAgICA+PiAgICAga2V5IHJlY29yZCBpbiB0aGUgRE5TIGZvciBlYWNoIHNlbGVjdG9yLCB0 aGUgc2lnbmF0dXJlcyB3aWxsIGhhdmUgdG8NCiAgICA+PiAgICAgdXNlIGRpZmZlcmVudCBzZWxl Y3RvcnMsIGFsdGhvdWdoIHRoZXkgY2FuIHVzZSB0aGUgc2FtZSBkPSBhbmQgaT0NCiAgICA+PiAg ICAgaWRlbnRpZmllcnMuDQogICAgPg0KICAgID4gVHJ1bHkgdHJpdmlhbCBuaXQ6ICBpPSBpcyBp cnJlbGV2YW50IHRvIHRoZSByZWNlaXZlci4NCiAgICA+DQogICAgPg0KICAgID4+ICA3LiAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMNCiAgICA+Pg0KICAgID4+ICAgICBFZDI1NTE5IGlzIGEgd2lk ZWx5IHVzZWQgY3J5cHRvZ3JhcGhpYyB0ZWNobmlxdWUsIHNvIHRoZSBzZWN1cml0eSBvZg0KICAg ID4+ICAgICBES0lNIHNpZ25hdHVyZXMgdXNpbmcgbmV3IHNpZ25pbmcgYWxnb3JpdGhtcyBzaG91 bGQgYmUgYXQgbGVhc3QgYXMNCiAgICA+PiAgICAgZ29vZCBhcyB0aG9zZSB1c2luZyBvbGQgYWxn b3JpdGhtcy4NCiAgICA+DQogICAgPiAgIHVzaW5nIG5ldyAgLT4gIHVzaW5nIHRoZXNlIG5ldw0K ICAgID4NCiAgICA+DQogICAgPiBkLw0KICAgID4NCiAgICA+DQogICAgDQogICAgUmVnYXJkcywN CiAgICBKb2huIExldmluZSwgam9obmxAdGF1Z2guY29tLCBUYXVnaGFubm9jayBOZXR3b3Jrcywg VHJ1bWFuc2J1cmcgTlkNCiAgICBQbGVhc2UgY29uc2lkZXIgdGhlIGVudmlyb25tZW50IGJlZm9y ZSByZWFkaW5nIHRoaXMgZS1tYWlsLiBodHRwczovL2psLmx5DQogICAgDQogICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBEY3J1cCBtYWlsaW5n IGxpc3QNCiAgICBEY3J1cEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGNydXANCiAgICANCg0K From nobody Sun Jan 21 11:39:36 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E521B127337 for ; Sun, 21 Jan 2018 11:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.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 oZZvgFSgsvJH for ; Sun, 21 Jan 2018 11:39:33 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 91B2F127023 for ; Sun, 21 Jan 2018 11:39:33 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w0LJeIuD007725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 21 Jan 2018 11:40:18 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1516563619; bh=wjGxzNK9Qsv2r19ST1W56Bs2aLyePfMrQP9WKZ0Cl6c=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=RL17EmFucTfOaYRuZj1CuEfNmfWv17pHl5WFFocZT0mhDkjCntl5I3+7b8W9Isk1B OOI/mU04J+krfhldnpCu8TE0rgJJ0Xz6cduxS5fTZwuc/NhF599tewwRgYe8WFKyeN SocX+KT2Hx4HV6YQ0e6Za5m8AEINajdhpYiz3Nrw= To: John R Levine Cc: dcrup@ietf.org References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> Date: Sun, 21 Jan 2018 11:39:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Dcrup] ed25519 in DNS (was: Re: Review of: draft-ietf-dcrup-...) X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 19:39:35 -0000 On 1/21/2018 9:43 AM, John R Levine wrote: > One gaping hole we have left to fill is the format for ed25519 keys in > DNS records.  For RSA keys, everyone uses base64 encoded ASN.1 keys, but > at this point different libraries use different forms for ed25519. > Since the keys are fixed length and fixed format, the extra cruft from > ASN.1 is not helpful, and it'd require putting an ASN.1 decoder into the > dkim library if the crypto library it calls doesn't use ASN.1. On the theory that this bit of convention ought to have applicability far beyond DKIM, I suggest formulating a proposal in a separate document, starting with text along the above lines, that explains what the convention should probably /not/ use, such as ASN.1. The two goals for the convention would seem to be: 1) ensuring text-ness, and 2) compressing if possible. Easiest would be a summary of the existing different forms you cite as already being done and then choosing one you folk think best. Or proffer and alternative with clear, strong arguments for its superiority. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jan 21 12:48:05 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723A61243F3 for ; Sun, 21 Jan 2018 12:48:03 -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=kAv3Mhe0; dkim=pass (1536-bit key) header.d=taugh.com header.b=Famr1yyp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DvXlX26hZSI for ; Sun, 21 Jan 2018 12:48:01 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA75120726 for ; Sun, 21 Jan 2018 12:48:01 -0800 (PST) Received: (qmail 17929 invoked from network); 21 Jan 2018 20:48:00 -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=45f8.5a64fc80.k1801; bh=/k+AchAmVgsaqP2ZXqg2MOncZPiwuGPe1JZb/897Wco=; b=kAv3Mhe0XTEFdLVCN86wfXUNcyiKR8bJS3buzfcabSOzl7BCV7LRqHmlfr3okX2TyoRNaQu7zck4/3rv7i1xEq5GVkvrtvU5ku84TjrLzaeBaydAvTSMTh7cbgYl4O/4YOg97msAXKCdBK7LJj+/1t+yIDPgNEBJWDZ9yZEFmijGQ9ksIhZQw23pEx27lmDZzIif7FOzUdK4m0c36+Nw8ycdTJyeqGKCKcX4y3faaFj72Oyn4lvNrkOo/KzNu7Qo 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=45f8.5a64fc80.k1801; bh=/k+AchAmVgsaqP2ZXqg2MOncZPiwuGPe1JZb/897Wco=; b=Famr1yyp+RPKFrlCY2FitHVIw25TP+f0EnqnXTNHKEyV/CadB12OtvyBQs+TWZLDtXdMpeCQcaIAm9hWoeoGDXVNyfPWVk5THSgz5qF4FOQzTH8nOg3F08blAfjz1jAQ28Ew5+zatoq9tJmvVguhwFF2iKa+xnyP0LQHxTksybf6XC2Kc+V3+DHM3or7d2QpxeI30lPsyfxHs4ZFDUEFzsYp+fy+4uMoJMfR6baG0Uvw581W8aUyajwYp6nukiPV Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 21 Jan 2018 20:47:59 -0000 Date: 21 Jan 2018 15:47:59 -0500 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net Cc: dcrup@ietf.org In-Reply-To: <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1748945906-1516567679=:15446" Archived-At: Subject: Re: [Dcrup] ed25519 in DNS (was: Re: Review of: draft-ietf-dcrup-...) X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 20:48:03 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1748945906-1516567679=:15446 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 21 Jan 2018, Dave Crocker wrote: >> One gaping hole we have left to fill is the format for ed25519 keys in DNS >> records.  For RSA keys, everyone uses base64 encoded ASN.1 keys, but at >> this point different libraries use different forms for ed25519. Since the >> keys are fixed length and fixed format, the extra cruft from ASN.1 is not >> helpful, and it'd require putting an ASN.1 decoder into the dkim library >> if the crypto library it calls doesn't use ASN.1. > > On the theory that this bit of convention ought to have applicability far > beyond DKIM, I suggest formulating a proposal in a separate document, > starting with text along the above lines, that explains what the convention > should probably /not/ use, such as ASN.1. On the principle that we shouldn't solve problems that will likely never arise, I'd rather not. RSA keys use ASN.1 because they do. At some point we will figure out what is the least painful representation for ed25519 keys, but that will depend on what sort of glue code is needed to adapt a key representation to the various libraries. If we ever add another algorithm to DKIM, it'll be another decade from now, and I have no confidence that whatever issues seem important now will still be important then, or that issues in other applications would be the same as the ones we have here. Over in LAMPS they're doing a crypto update with orders of magnitude more algorithms than we'll ever look at. PKIX is, for historical reasons, all ASN.1 all of the time, but those are the people I'd look to if I were wondering about key representations. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-1748945906-1516567679=:15446-- From nobody Sun Jan 21 13:16:22 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E169C1243F3 for ; Sun, 21 Jan 2018 13:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbHGkRhzn0s3 for ; Sun, 21 Jan 2018 13:16:17 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675FC120726 for ; Sun, 21 Jan 2018 13:16:17 -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 18687C4027F for ; Sun, 21 Jan 2018 15:16:16 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1516569376; bh=xyOUvhhpFyBV796V+5fCBEQ1V4SEFM8NEPE5t0BYJ38=; h=From:To:Subject:Date:In-Reply-To:References:From; b=e3rSVuQ3c1VKh8EXq7cH6BGbdhZZ9l/xokJLpBMBm4N9+ERn8uH/KEVUm/Jehqrlo FyvRUd7al6N+Y+1vuhwwfl187qWSN0vIRKJv6juaD3MTIW+XAGZ5tIKGC7nmyAYhNo daq9xDa0JYRHGhU+72SoYQpffMwV1IveKlYJpunY= From: Scott Kitterman To: dcrup@ietf.org Date: Sun, 21 Jan 2018 16:16:16 -0500 Message-ID: <1707459.QODvfERKoP@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-139-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] ed25519 in DNS (was: Re: Review of: draft-ietf-dcrup-...) X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 21:16:21 -0000 On Sunday, January 21, 2018 03:47:59 PM John R Levine wrote: > On Sun, 21 Jan 2018, Dave Crocker wrote: > >> One gaping hole we have left to fill is the format for ed25519 keys in > >> DNS > >> records. For RSA keys, everyone uses base64 encoded ASN.1 keys, but at > >> this point different libraries use different forms for ed25519. Since > >> the > >> keys are fixed length and fixed format, the extra cruft from ASN.1 is > >> not > >> helpful, and it'd require putting an ASN.1 decoder into the dkim library > >> if the crypto library it calls doesn't use ASN.1. > > > > On the theory that this bit of convention ought to have applicability far > > beyond DKIM, I suggest formulating a proposal in a separate document, > > starting with text along the above lines, that explains what the > > convention > > should probably /not/ use, such as ASN.1. > > On the principle that we shouldn't solve problems that will likely never > arise, I'd rather not. RSA keys use ASN.1 because they do. At some point > we will figure out what is the least painful representation for ed25519 > keys, but that will depend on what sort of glue code is needed to adapt a > key representation to the various libraries. If we ever add another > algorithm to DKIM, it'll be another decade from now, and I have no > confidence that whatever issues seem important now will still be important > then, or that issues in other applications would be the same as the ones > we have here. > > Over in LAMPS they're doing a crypto update with orders of magnitude more > algorithms than we'll ever look at. PKIX is, for historical reasons, all > ASN.1 all of the time, but those are the people I'd look to if I were > wondering about key representations. As far as ASN.1 goes, let's not. For this application, it's just pointless complexity as far as I can tell. What I'd used so far for the public key representation is base64 of the public key that PyNaCl spits out (effectively what libsodium produces). I think the binary output is defined by RFC 80322. Running it through base64 gives a consistent, low-overhead ascii friendly representation. I see that Section 7.1 of RFC 8032 gives some examples with public and private keys in ASCII friendly representations. Section 7 explains how they did it. Let's just use that for public and private key representations. Scott K From nobody Sun Jan 21 21:40:12 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D5E126B72 for ; Sun, 21 Jan 2018 21:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.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 8NBrQKFSzLxs for ; Sun, 21 Jan 2018 21:40:09 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 00C121201FA for ; Sun, 21 Jan 2018 21:40:08 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w0M5esDt005777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 21 Jan 2018 21:40:54 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1516599654; bh=Zcsi9BIvun8Mk9UD/HbxsYyKm7SZhzWYhAA6ymQZje4=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=ZsdZ0cdDFLw/HHmMeHW8rVgHs/1zp5Ams7izaqyxbp2ORPVWN/exJCWJOz5zo/aUh jmqZF/BdtxGUk/tyiT0pbxpc7vsjZsfcuZSx/lr4SEhVOhll57WWYmrxr7K8KT3uEm G/pID4VXIfA6OlZMdqrP39uksM3p1xQ6KvqOCK+E= To: John R Levine Cc: dcrup@ietf.org References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 21 Jan 2018 21:40:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dcrup] ed25519 in DNS X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 05:40:10 -0000 On 1/21/2018 12:47 PM, John R Levine wrote: > On Sun, 21 Jan 2018, Dave Crocker wrote: >> On the theory that this bit of convention ought to have applicability >> far beyond DKIM, I suggest formulating a proposal in a separate >> document, starting with text along the above lines, that explains what >> the convention should probably /not/ use, such as ASN.1. > > On the principle that we shouldn't solve problems that will likely never The suggestion wasn't about solving future problems but enabling wider use by separating this bit of specification into an independent document. That makes it easier to re-use by other applications and easier to modify if experience dictates making changes. > arise, I'd rather not.  RSA keys use ASN.1 because they do.  At some > point we will figure out what is the least painful representation for > ed25519 keys, but that will depend on what sort of glue code is needed > to adapt a key representation to the various libraries. I'd think it would mostly depend on the encoding limitations for putting this information into the DNS, since that is the task at hand. > If we ever add > another algorithm to DKIM, it'll be another decade from now, and I have > no confidence that whatever issues seem important now will still be > important then, or that issues in other applications would be the same > as the ones we have here. My suggestion has nothing to do with adding future algorithms, but defining a DNS encoding for this current type of information, for possible use by other applications. > > Over in LAMPS they're doing a crypto update with orders of magnitude > more algorithms than we'll ever look at.  PKIX is, for historical > reasons, all ASN.1 all of the time, but those are the people I'd look to > if I were wondering about key representations. Your sense of the utility of that dependency appears to be different from mine... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jan 22 08:52:14 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A5A127735 for ; Mon, 22 Jan 2018 08:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxv7rFETaGy1 for ; Mon, 22 Jan 2018 08:52:01 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267D7124207 for ; Mon, 22 Jan 2018 08:52:00 -0800 (PST) Received: (qmail 24393 invoked from network); 22 Jan 2018 16:51:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5f47.5a6616af.k1801; bh=+8WxMGprcXI3nS3mYWIbPBSanyjjTL7ZSrMIkA2efbE=; b=fkhlNQG9CoTj8R1lh/MaJ5dgb7C+W1gOttytbp/wRG0PP/DAorN3IY/74c3QVPoGxdXx3cRoOJmtKCQgGtE5szFqvxjjicuFtR3YmDwjWoRr/7SCrKC6HisDT7EOXRUbBf6+cL6+84ocvjp679sWtRC1ynLXB4zavMvNMRTjC9x3bQeartIHg7NLmpasI1FxgpQULO5jAPePAw55e/C26F3nuv/eXBhEH9rhPczJenuMvohK/mtpNeAl5dCbjunJ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 22 Jan 2018 16:51:59 -0000 Date: 22 Jan 2018 11:51:59 -0500 Message-ID: From: "John R. Levine" To: "Scott Kitterman" Cc: dcrup@ietf.org In-Reply-To: <1707459.QODvfERKoP@kitterma-e6430> References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] ed25519 in DNS (was: Re: Review of: draft-ietf-dcrup-...) X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 16:52:03 -0000 > What I'd used so far for the public key representation is base64 of the public > key that PyNaCl spits out (effectively what libsodium produces). I think the > binary output is defined by RFC 80322. Running it through base64 gives a > consistent, low-overhead ascii friendly representation. > > I see that Section 7.1 of RFC 8032 gives some examples with public and private > keys in ASCII friendly representations. Section 7 explains how they did it. > Let's just use that for public and private key representations. The test vectors in section 7.1 are printed in hex, not base64. Since the keys are only 32 bytes, the hex is 64 characters and base64 is 44 characters so they're both pretty small. We should pick one and move on. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jan 22 08:54:26 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72141273B1 for ; Mon, 22 Jan 2018 08:54:24 -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=TS8z9kza; dkim=pass (1536-bit key) header.d=taugh.com header.b=ArcVeSLy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV97xCEFaKqv for ; Mon, 22 Jan 2018 08:54:23 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA29126E64 for ; Mon, 22 Jan 2018 08:54:16 -0800 (PST) Received: (qmail 24712 invoked from network); 22 Jan 2018 16:54:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-id:user-agent; s=6085.5a661738.k1801; bh=DXSGpkf82Lsm/bqkAAipYwlELmjl79Lv96UBoAoOnU8=; b=TS8z9kza6ZWfA/5Gh9IHbs5VB2NZSEbwg8cI2ltE5HY6CA2qjUU6a6XC2ICEa5uNT7tMuGs4nEObG2vP33+y7SPE2OvQc/Tq5U6F7n/EDJQaEmsYb31+K+gZNX+MbtiGFunzy2g7ZTwAiPt/8dTG/s52RQBxDvTzeroJfgXA7IezTNFr9lUNfYR8duKZrzv+47jN/OpiG0rSRZVQ9tKspmeRSDh/ykyHysZVKamH/MFJ8rPaxq9REuyCE0AiDWag 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:content-id:user-agent; s=6085.5a661738.k1801; bh=DXSGpkf82Lsm/bqkAAipYwlELmjl79Lv96UBoAoOnU8=; b=ArcVeSLyrV8ktacz4PJrqFJlKTXLhZRkrVEKo2mnyzOfIxQFgIdBvi9oFznM6rSCRb8RHaSMspXw9R9SswuCCtKF1s/ajLxJL8oRY8sxzb13z7ymO2exj8UIY8bBC8m3gtvo9wf7/F4hwgigNPcd0ymNQch4nxfkzQ4O+hQf0omBaM/BdcTjgxV9xIVHwnONcyzk5ItfS5Bt+DiBkW8yWR69bTKnow+mhj7ulofXEG6+pRNgsjNm07yP3ohHr31k Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 22 Jan 2018 16:54:15 -0000 Date: 22 Jan 2018 11:54:15 -0500 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net Cc: dcrup@ietf.org In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-718487843-1516639488=:17264" Content-ID: Archived-At: Subject: Re: [Dcrup] ed25519 in DNS X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 16:54:25 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-718487843-1516639488=:17264 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Sun, 21 Jan 2018, Dave Crocker wrote: >> arise, I'd rather not.  RSA keys use ASN.1 because they do.  At some point >> we will figure out what is the least painful representation for ed25519 >> keys, but that will depend on what sort of glue code is needed to adapt a >> key representation to the various libraries. > > I'd think it would mostly depend on the encoding limitations for putting this > information into the DNS, since that is the task at hand. This whole exercise started because RSA keys were getting too big to fit into a 255 character text string. But EC keys are so short that any encoding, even one with lots of ASN.1 goop, will fit. The size limit isn't an issue, and I don't know of any other crypto applications where squeezing a text version of the key into 255 chaaracters matters. See the note from Scott about his key experience. We should pick a hex or base64 version of the key, which is very short either way, and be done with it. R's, John PS: > Your sense of the utility of that dependency appears to be different from > mine... No argument there. --0-718487843-1516639488=:17264-- From nobody Mon Jan 22 08:56:04 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51D41273B1 for ; Mon, 22 Jan 2018 08:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rKX3o6Zv-T5 for ; Mon, 22 Jan 2018 08:56:01 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D1D126E64 for ; Mon, 22 Jan 2018 08:56:01 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0MGqkxr001565; Mon, 22 Jan 2018 16:55:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=VGIDpsYAtv0SrmYLY8MRdmei5jf0l2fBbK/0F1BgKlc=; b=Hjc4SQxTSE04IWQHQHOhhz0jjej2uH++QxlnIswncjUZloDV26ffinm0vb5iIKrt5reA 4O5ovYf5RP/Z2N4fZSrcsAutKMKAoJ2HlcHP5ObqvUJJGbZEaG2gDPO85dtF6o9HXU+P x8Qf7PUmrhwnvFVeYTd1Hyh4EgVB/zej5sJ1B26tYPoyijld11XiPx9jn4jVAPdiSjlW RqaVXIEPLFjBLJhua7NYgkJmd3CluY3VxRMb5OMMUGBVXrTDCO2LT2qcqPwMfJJtyU2E 4uvmOtXLDS19FvtMB3UGrY7/0/3IBMD2j8/qpHxXpObun45ATbJhCK2wppRCe2n00TXx Aw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2fky2abunt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Jan 2018 16:55:56 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0MGpjpM027086; Mon, 22 Jan 2018 11:55:56 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fm200d92v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 22 Jan 2018 11:55:56 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 22 Jan 2018 10:55:55 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Mon, 22 Jan 2018 10:55:55 -0600 From: "Salz, Rich" To: "John R. Levine" , Scott Kitterman CC: "dcrup@ietf.org" Thread-Topic: [Dcrup] ed25519 in DNS (was: Re: Review of: draft-ietf-dcrup-...) Thread-Index: AQHTku+TtYgQnHf+dEuKfYrOSAg/iqN/MPSAgAAH5wCAAUh+gIAAARgA Date: Mon, 22 Jan 2018 16:55:54 +0000 Message-ID: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.241] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-22_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801220237 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-22_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=958 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801220237 Archived-At: Subject: Re: [Dcrup] ed25519 in DNS (was: Re: Review of: draft-ietf-dcrup-...) X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 16:56:03 -0000 4p6iIFRoZSB0ZXN0IHZlY3RvcnMgaW4gc2VjdGlvbiA3LjEgYXJlIHByaW50ZWQgaW4gaGV4LCBu b3QgYmFzZTY0LiAgU2luY2UgdGhlIA0KICAgIGtleXMgYXJlIG9ubHkgMzIgYnl0ZXMsIHRoZSBo ZXggaXMgNjQgY2hhcmFjdGVycyBhbmQgYmFzZTY0IGlzIDQ0IA0KICAgIGNoYXJhY3RlcnMgc28g dGhleSdyZSBib3RoIHByZXR0eSBzbWFsbC4gIFdlIHNob3VsZCBwaWNrIG9uZSBhbmQgbW92ZSBv bi4NCg0KV2lsbCB0aGUgYXV0aG9yIG9mIHRoZSBkcmFmdCBwbGVhc2UgcGljayBvbiBhbmQgdXBk YXRlIHRoZSBkcmFmdCBzb29uLiAgSWYgYW55b25lIG9uIHRoZSBXRyBoYXMgZ29vZCByYXRpb25h bGUgZm9yIGRpc2FncmVlaW5nIHdpdGggdGhlIGF1dGhvcuKAmXMgY2hvaWNlLCB0aGluayB0d2lj ZSBhbmQgcG9zdCBpdC4NCg0K From nobody Mon Jan 22 09:08:15 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA46126C89 for ; Mon, 22 Jan 2018 09:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovipQR3wlNdx for ; Mon, 22 Jan 2018 09:08:11 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE5C1241F3 for ; Mon, 22 Jan 2018 09:08:11 -0800 (PST) Received: from [10.9.176.68] (mobile-166-170-33-160.mycingular.net [166.170.33.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7B8CBC400FA; Mon, 22 Jan 2018 11:08:07 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1516640887; bh=8+tOP3EM1/RaahVXBemsr2IC2G8stVez4hX3+446f3c=; h=Date:In-Reply-To:References:Subject:To:From:From; b=M5OtNsBtINiZnYoiGfkKQVdux38xckC4OuTtGtj7nhTiVAmbS/lPxSvyBYUpUq9Jz 9FpAGzOE+HPRsXccHAFzTDioo6Quf6Cjyq06TfWCQUQUg7JOAhnsQSP5yOa/VddABu GTNLPPlxw20O+Pa5Tdm22KHfbIdBhlecy9OHIUzg= Date: Mon, 22 Jan 2018 17:08:03 +0000 In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <84FCB911-8BFD-4DE7-B52D-4B7D17C10F8E@kitterman.com> Archived-At: Subject: Re: [Dcrup] ed25519 in DNS (was: Re: Review of: draft-ietf-dcrup-...) X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 17:08:13 -0000 On January 22, 2018 4:51:59 PM UTC, "John R=2E Levine" = wrote: >> What I'd used so far for the public key representation is base64 of >the public >> key that PyNaCl spits out (effectively what libsodium produces)=2E I >think the >> binary output is defined by RFC 80322=2E Running it through base64 >gives a >> consistent, low-overhead ascii friendly representation=2E >> >> I see that Section 7=2E1 of RFC 8032 gives some examples with public >and private >> keys in ASCII friendly representations=2E Section 7 explains how they >did it=2E >> Let's just use that for public and private key representations=2E > >The test vectors in section 7=2E1 are printed in hex, not base64=2E Sinc= e >the=20 >keys are only 32 bytes, the hex is 64 characters and base64 is 44=20 >characters so they're both pretty small=2E We should pick one and move >on=2E I think either is fine=2E I picked base64 originally because I was alread= y using it, but that doesn't really mean anything=2E Either has good suppo= rt in libraries, which is the main thing=2E "We picked the format used in the examples in RFC 8932 Section 7" seems li= ke a nice rationale to me=2E Let us know what you want to pick? Scott K From nobody Mon Jan 22 09:30:18 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE75129511 for ; Mon, 22 Jan 2018 09:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhcloos.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMSTLRikEDm0 for ; Mon, 22 Jan 2018 09:30:14 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B477127873 for ; Mon, 22 Jan 2018 09:30:14 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 37A791DF40; Mon, 22 Jan 2018 17:30:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1516642213; bh=+w+avJXkoXgZdyrGXF0ZNdJQLWG3oK0OCSNawg5IqxY=; h=From:To:Subject:In-Reply-To:References:Date:From; b=sM2VmNsAJ6HEh9jNf/Chi5FQvKsg56VfCxLsarJSDPqroQzPhGQ7WwfJ4YG/ZNM++ 8RC61yuk11d9/YnkfrYCp/mraWRI8pRUW3vjzwDVjzICRyFZIc2tGfFi7HKyoili+h Q6TCDFZy0qkFg0DJcLDHOmOB1gZ1eFqHyvYArOpQ3vl0+CxTMVf/U8hWEKKAlAZH1A QZPdAHh7c+qKz4zWLMaG+Wnrrzjd+7sSZNlECvAOHCEEQJvfAvfZJ5dloFNqzWHiJg 7Ss3jpheH0VV6CUaUCpOh2Xj7OpBuZbfXmhDGddLtcHarU7o3wPUeCf4AgKWZ7ZKUm wvcI2afta7P9w== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 9A63110A6FF22; Mon, 22 Jan 2018 17:30:06 +0000 (UTC) From: James Cloos To: dcrup@ietf.org In-Reply-To: (Dave Crocker's message of "Sun, 21 Jan 2018 21:40:00 -0800") References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2017 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 22 Jan 2018 12:30:06 -0500 Message-ID: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Dcrup] ed25519 in DNS X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 17:30:16 -0000 [Replying to a random mail in the thread.] The optimal way to encode an eddsa public key in dns is raw binary with either hex, base32 or base64 for the presentation format. But for dkim, since it is stuck with TXT and already uses base64 for k=rsa's p=, then base64 of the raw public key is the answer. In base64 an ed25519 key will take 44 octets. A records like this: v=DKIM1;k=ed25519;p=fjkXkmq6aJiRS2tycuHzHdCYRcA2WWgEs0oh+HoXz2g= [not a real key] is then just 64 octets of content. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jan 22 19:49:44 2018 Return-Path: X-Original-To: dcrup@ietf.org Delivered-To: dcrup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0136B12D948; Mon, 22 Jan 2018 19:49:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dcrup@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151667938196.29540.1414102370133119675@ietfa.amsl.com> Date: Mon, 22 Jan 2018 19:49:42 -0800 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-08.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 03:49:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DKIM Crypto Update WG of the IETF. Title : A new cryptographic signature method for DKIM Author : John Levine Filename : draft-ietf-dcrup-dkim-crypto-08.txt Pages : 6 Date : 2018-01-22 Abstract: This document adds a new signing algorithm to DKIM. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dcrup-dkim-crypto-08 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-crypto-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-crypto-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 22 19:51:07 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984BB12D954 for ; Mon, 22 Jan 2018 19:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2167smLt3Eee for ; Mon, 22 Jan 2018 19:50:58 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DFC12D940 for ; Mon, 22 Jan 2018 19:50:36 -0800 (PST) Received: (qmail 38290 invoked from network); 23 Jan 2018 03:50:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=958e.5a66b10b.k1801; bh=EF+nTOfakBQxSTKeWUjKB8icmkgI7eU77D1LDr/gHyE=; b=VlVw6vzoawTG5Ttk6p9Y9/NKx04q1V73N6lnnGxUEWF47ocxlkwo8hgUg/rdDC5FO3rDKKEdJs0vnYMK9QO3YTOY1oVX7zUdmM0nO5X5Z2MVCBy4abgcy6u/BOYVWdI3Ykq0y5uFEIlnCx+2pFeMzoFPwL9N/z7R4btez9C9GsZb2OzJ37X5s30W9X5Tmhbl/ucYVe5JUjblymQTeydQxjlo2WyMwV+C1mo1vRqS31vHdO1qiCfCKRYxxVc9dS41 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 23 Jan 2018 03:50:35 -0000 Date: 22 Jan 2018 22:50:36 -0500 Message-ID: From: "John R. Levine" To: "Salz, Rich" Cc: "Scott Kitterman" , "dcrup@ietf.org" In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-101701108-1516679436=:20440" Archived-At: Subject: Re: [Dcrup] ed25519 in DNS (was: Re: Review of: draft-ietf-dcrup-...) X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 03:51:03 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-101701108-1516679436=:20440 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > Will the author of the draft please pick on and update the draft soon. If anyone on the WG has good rationale for disagreeing with the author’s choice, think twice and post it. The people have spoken and seem to have said base64. Updated draft posted, also with style edits per Dave's suggestions. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly --0-101701108-1516679436=:20440-- From nobody Mon Jan 22 20:38:47 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C945127333 for ; Mon, 22 Jan 2018 20:38:46 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0IkomzyHER6 for ; Mon, 22 Jan 2018 20:38:43 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F2612D86C for ; Mon, 22 Jan 2018 20:38:43 -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 B4BAFC4020A for ; Mon, 22 Jan 2018 22:38:39 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1516682319; bh=WjdIPMcQXWkONuZZoO1pltxJrA2IBFwMDM9uWePyYfc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QHVJ0aopWeRWH15tcmYj/Wso6kLIJ3nqTNNTYzTpA+NVe+sdh2SUaJfTCRXRtVajm J1AIkNI0RVFve+vh9+plbVbDx0s1vYfM7RrZ/iFYBfiEb03Rd7vOiM7Vwo4FIe7RyC yFvndclAktZqdfmgPI/gtOY8/nx7Cy8HwN1ZOm/E= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 22 Jan 2018 23:38:38 -0500 Message-ID: <2046656.8I2TqWBbc6@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-139-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <2005843.OrHkAfkQ5T@kitterma-e6430> References: <2005843.OrHkAfkQ5T@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 04:38:46 -0000 I know the last call was a long time ago and so it'd be easy to have forgotten, but I think points 1 and 2 are still germane. It would also still be nice to see a sample signature included. Scott K On Friday, December 01, 2017 06:57:31 PM Scott Kitterman wrote: > On Friday, December 01, 2017 11:45:50 AM Murray S. Kucherawy wrote: > > Colleagues, > > > > We hereby begin Working Group Last Call for draft-ietf-dcrup-dkim-crypto, > > to end December 15th. Please review the document and post the (preferably > > at least somewhat detailed) results of your reviews to the list or to the > > chairs and author by end of that day. Assuming no major revisions or > > discussion are needed, we hope to have this shipped to Alexey by the > > beginning of the December holidays. > > I've reviewed the document (and started working on implementation). I think > it is generally ready to go, but I have four comments: > > 1. The existing RFC 6376 signature algorithms specify what to use for hash- > alg. That's missing from the Ed25519-SHA256 definition in section 3. As > implied by the name (and discussed on the list), the hash-alg should be > SHA256. Recommend replacing the leading sentence phrase in section 3 with: > > The Ed25519-SHA256 Signing Algorithm computes a message hash as described in > Section 3.7 of [RFC6376] using SHA-256 [FIPS-180-3-2008] as the hash-alg, > ... > > This matches the way other signing algorithms are described in RFC 6376. > > 2. For clarity, per some of the IETF LC feedback on draft-ietf-dcrup-dkim- > usage, recommend adding after the main body of section 3 and before the > note: > > This is an additional DKIM signature algorithm added to Section 3.3 of > [RFC6376] as envisioned in Section 3.3.4 of [RFC6376]. > > 3. Private key storage format > > Unlike RSA, Ed25519 does not appear to have a standardized textual format. > I think it might make sense to specify that for DKIM Ed25519 purposes the > private key is stored as the base64 encoded output of the RFC 8032 Section > 5.1.5 private key generation processes. This would provide a (slightly) > human readable private key representation that could be used by different > implementations so that operators can safely switch implementations without > regenerating keys and that are more understandable for trouble shooting > purposes. > > 4. Examples > > It would be nice to have at least one signing example for implementers to > use to verify correctness. I currently have either a signing bug or a > verification bug in my work and I'm not sure which. If I had a known > correct example to bounce my signing results against, that would help a > lot. > > Scott K > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup From nobody Mon Jan 22 21:09:55 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE0D127333 for ; Mon, 22 Jan 2018 21:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbFRmgitsA0Q for ; Mon, 22 Jan 2018 21:09:49 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B77126CBF for ; Mon, 22 Jan 2018 21:09:49 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id q194so13438880lfe.13 for ; Mon, 22 Jan 2018 21:09:49 -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=Yz9rzrcJlpa/e1nNYAbmQIun/xkYOKyqsMvN3nrOcNc=; b=GGKmDD99Kq4mxvTutxZWALJhEJjugViTEE+51ycTxGDmTZajEHgkvB+oUQZdQKggzH fvT60RWRifjPVDrTACaWD/qGKvZH0WhS5tjV+kAnd0Do+UV27aWjwU3cOkRlHGD7qJqS k9Ke/rtAGKaZHpiFNRGdTjttF5Ks4ZJ4voNVJCWasm3VQ+8S6KOEuAVgJDvcVkuyX13V R8Gau4AH0vBpPGaqFSN7sENvWp6xkjOQn/UQOpqnhrB5+0gloFallfBVXiqUC3djR+s4 TFenqLoD2Et+CCTdoxkCqiQ8UTGHBn7Q1Un7wetf5WGHvp9c1oVkJ+KPcS6qkvpG4U5t 6n0w== 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=Yz9rzrcJlpa/e1nNYAbmQIun/xkYOKyqsMvN3nrOcNc=; b=uYsGomxG7g+9FgYFDml2BfwWq1BG1LRfpXTX5xImJW3EGSn6dkOy4JC2Ma2HvoTFMn mv78hOMbozOtoUzdTBtle5dOddBt3S87x5y4o4Can0mzJssV5iBPOpuJpJcrlodmKBFm QUZKNVXkXFcDOXluHIzc0GqEpfyuAcYjlnqqckZN0yzRNinxVX8OTe5/wpyCmEYF4bZ+ B1nypWAXECoXumTDwOZE9tAQr5y2+bwXIwCo/cuEWVYMgxon19viTYshZqakDZAmQ85C sYZiz5Jf81D36d8qu/Lro2VzrCx9uOMPXFZYDQwzfEUgQXkks/dDoDZBu7bhHURFqF5J xyYg== X-Gm-Message-State: AKwxytfPF9wDFhBYFo713kfAozmxaDUQuBb6e30O/+uEnPtwlcfePnzP fIbarP7aDKroJoVuzOXZFJmiFBglnv/do+QDtIYLqg== X-Google-Smtp-Source: AH8x226+JvsM8U5hIjRKBoSLh1ILSHj95P2/Pb6/aoQ0ovdl1heRWohc9lO5CDoyfqoCKxmcwgUuSgLCTpoPtJlB6Cw= X-Received: by 10.25.74.87 with SMTP id x84mr573444lfa.109.1516684187387; Mon, 22 Jan 2018 21:09:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.101.74 with HTTP; Mon, 22 Jan 2018 21:09:46 -0800 (PST) In-Reply-To: <2046656.8I2TqWBbc6@kitterma-e6430> References: <2005843.OrHkAfkQ5T@kitterma-e6430> <2046656.8I2TqWBbc6@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 22 Jan 2018 21:09:46 -0800 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1a06c239cbe505636a8e83" Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 05:09:54 -0000 --94eb2c1a06c239cbe505636a8e83 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 22, 2018 at 8:38 PM, Scott Kitterman wrote: > I know the last call was a long time ago and so it'd be easy to have > forgotten, but I think points 1 and 2 are still germane. It would also > still > be nice to see a sample signature included. > Thanks for the reminder. And I'm planning to do a second WGLC since the first one drew exactly one review. Hopefully we get a little more the second time around. -MSK --94eb2c1a06c239cbe505636a8e83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Jan 22, 2018 at 8:38 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
I know the last call wa= s a long time ago and so it'd be easy to have
forgotten, but I think points 1 and 2 are still germane.=C2=A0 It would als= o still
be nice to see a sample signature included.

=
Thanks for the reminder.=C2=A0 And I'm planning to do a second WGL= C since the first one drew exactly one review.=C2=A0 Hopefully we get a lit= tle more the second time around.

-MSK
--94eb2c1a06c239cbe505636a8e83-- From nobody Tue Jan 23 09:28:34 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830D612762F for ; Tue, 23 Jan 2018 09:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=bN74UXkE; dkim=pass (1536-bit key) header.d=taugh.com header.b=fGhZUhf+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ3-FGVK1SlB for ; Tue, 23 Jan 2018 09:28:28 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD991275AB for ; Tue, 23 Jan 2018 09:28:26 -0800 (PST) Received: (qmail 74270 invoked from network); 23 Jan 2018 17:28:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1221b.5a6770b9.k1801; bh=Mg2U9C8dEw+tFkgN86QWtAGlWTVWjTRKybbJ3lCzIcA=; b=bN74UXkEgw35bOc9LhJjZ6lvCcthdbbULwiJwz7ckjWTOOvqdU4XvU1KW+BXfkNla3y2ixrHat2ozcsoSY0vL0W5qtaIwE8g7zRhxtz65oVDGLGtSvWqpUSYMmVKLcENJzDxUrkOun+KJ9vMX91ij1W/rQLADE2rdUOCpc4n38NPEoXSf2iMPx4e2NTHATOdw4tqwqbk2ZHRIb64PtMR4dtoWw24aC0CTlsnDBSh128V4KID+3dcUye4CeUbUKgb DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1221b.5a6770b9.k1801; bh=Mg2U9C8dEw+tFkgN86QWtAGlWTVWjTRKybbJ3lCzIcA=; b=fGhZUhf+4G+RzcA/z2r4xCundGeO4Ty2VEXm5oU1tk2BR2+DzFWZNJv2l6H749XMTffBSOCxssi3Kpz8Kb/C/VJt69BPj330ycGxI30cccSvjYcs05nDN7D4DPxSa+r85hQGWX6Nn45muu5gCcIQM8xUuBSeJApPZFrZZ7w9a10IsFFDfaZT/brbry7pBnKw5Rg973DwQqwQh8f2SPT3DnVlW1KzcFCFa/GMZgzEZaWMbtTafLUGmRk3aEniqLhw Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 23 Jan 2018 17:28:24 -0000 Received: by ary.qy (Postfix, from userid 501) id 9AC9419B094B; Tue, 23 Jan 2018 12:28:24 -0500 (EST) Date: 23 Jan 2018 12:28:24 -0500 Message-Id: <20180123172824.9AC9419B094B@ary.qy> From: "John Levine" To: dcrup@ietf.org Cc: sklist@kitterman.com In-Reply-To: <2046656.8I2TqWBbc6@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 17:28:31 -0000 In article <2046656.8I2TqWBbc6@kitterma-e6430> you write: >> 4. Examples >> >> It would be nice to have at least one signing example for implementers to >> use to verify correctness. I currently have either a signing bug or a >> verification bug in my work and I'm not sure which. If I had a known >> correct example to bounce my signing results against, that would help a >> lot. Unfortunately, as far as I know you're still the only person to implement it. I'll try and hack it into Mail::DKIM but I don't know when I'll have the time. The other edits are in -9, except that the spec for sha256 is now FIPS 180-4-2015. R's, John From nobody Wed Jan 24 01:35:12 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B43012DA0A for ; Wed, 24 Jan 2018 01:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqDoiv6mK6nv for ; Wed, 24 Jan 2018 01:35:08 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1779512D96D for ; Wed, 24 Jan 2018 01:35:08 -0800 (PST) Received: from [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90.102) id 1eeHST-0004bu-5w for dcrup@ietf.org (return-path ); Wed, 24 Jan 2018 09:35:05 +0000 To: dcrup@ietf.org References: <20180123172824.9AC9419B094B@ary.qy> From: Jeremy Harris Message-ID: Date: Wed, 24 Jan 2018 09:35:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180123172824.9AC9419B094B@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 09:35:10 -0000 On 23/01/18 17:28, John Levine wrote: > In article <2046656.8I2TqWBbc6@kitterma-e6430> you write: >>> It would be nice to have at least one signing example for implementers to >>> use to verify correctness. I currently have either a signing bug or a >>> verification bug in my work and I'm not sure which. If I had a known >>> correct example to bounce my signing results against, that would help a >>> lot. > > Unfortunately, as far as I know you're still the only person to implement it. I'll try and > hack it into Mail::DKIM but I don't know when I'll have the time. I've had a working implementation in exim/gnutls for so long that it's getting bit-rot. I don't recall what state it's in wrt. the double-hash issue. It was internally consistent, sign vs. verify, but has had no independent testing. I think it was only buildable on fedora rawhide due to the GnuTLS version required. It has not gone into the mainline exim sourcebase only because there is no exim/openssl support yet, the library being lacking in the required interfaces. Mail::DKIM support would give me enough testing to release the gnutls- only version. -- Cheers, Jeremy From nobody Wed Jan 24 14:28:25 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B331270FC for ; Wed, 24 Jan 2018 14:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=TYX0dfCf; dkim=pass (1536-bit key) header.d=taugh.com header.b=vSU69kBd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y49BTbR-YrH7 for ; Wed, 24 Jan 2018 14:28:22 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D5F12AF6E for ; Wed, 24 Jan 2018 14:28:21 -0800 (PST) Received: (qmail 59444 invoked from network); 24 Jan 2018 22:28:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=e832.5a690884.k1801; bh=owgtI+i6jZfcTJfx49O7HNM9/DGtBeD89jdV79nmKGQ=; b=TYX0dfCfEFFeuRUCCB6KivoDl39GhnigpLXypowwCTk3pi7HXjXZFgUuRCPtM5Kpv0L4HREwQ1fPyl/q/WF+GadZNUh3hH6bK9mfe4Ay4bYtOe88drGpebTOKjqF7+Uf1OrrqgPd4X3HUp/jl+CPh/7uDZ0Q0m/ncwrkoP0XZXo7GYUAyRsJw6p+wEuacWdW8inmNAmJ7jwQqByEsvN+w2JmJ8T4KhGkByOSG25NJCo0HcP9sAAw5zSuFtFhxyRn DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=e832.5a690884.k1801; bh=owgtI+i6jZfcTJfx49O7HNM9/DGtBeD89jdV79nmKGQ=; b=vSU69kBdKNPg5Ddh9eiDa6R9XY0CLDVMYf03dta/KeXHkmlQ8o5d+oIn9G1IOksPr3AvzDwE4laDVnZDxr87VWCJNtRHRsRE3GxVHiZ5n6GRn7aPHZEAmxfcOpc6MJhJL3o8qCDYHOcqNv65aOP18lQmEB0klpJfN9g+7qikPpQ40u1Ie+/M33j3VC3/MTjkcx7Q+f/F6u7kQiea+JvVDjpmeGDYKv7aLrPHE5OGmWWKG5Mxdgx3ibMxoreB745Q Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 24 Jan 2018 22:28:20 -0000 Received: by ary.qy (Postfix, from userid 501) id 1C53B19C235A; Wed, 24 Jan 2018 17:28:19 -0500 (EST) Date: 24 Jan 2018 17:28:19 -0500 Message-Id: <20180124222820.1C53B19C235A@ary.qy> From: "John Levine" To: dcrup@ietf.org Cc: jgh@wizmail.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 22:28:23 -0000 In article you write: >> Unfortunately, as far as I know you're still the only person to implement it. I'll try and >> hack it into Mail::DKIM but I don't know when I'll have the time. > >I've had a working implementation in exim/gnutls for so long that it's >getting bit-rot. I don't recall what state it's in wrt. the double-hash >issue. It was internally consistent, sign vs. verify, but has had no >independent testing. I think it was only buildable on fedora rawhide >due to the GnuTLS version required. It has not gone into the mainline >exim sourcebase only because there is no exim/openssl support yet, the >library being lacking in the required interfaces. Perhaps you and Scott can compare signature samples. R's, John > >Mail::DKIM support would give me enough testing to release the gnutls- >only version. >-- >Cheers, > Jeremy > From nobody Wed Jan 24 15:05:29 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6543512D779 for ; Wed, 24 Jan 2018 15:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PdJ-jHRJTGi for ; Wed, 24 Jan 2018 15:05:25 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442EC12D7ED for ; Wed, 24 Jan 2018 15:05:25 -0800 (PST) Received: from [10.42.134.91] (mobile-166-170-33-211.mycingular.net [166.170.33.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2A7E1C40218; Wed, 24 Jan 2018 17:05:21 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1516835121; bh=E6iHAXXLk6GwDowFnhWysJpCPoPgx5qx0phJgk5Pmwc=; h=Date:In-Reply-To:References:Subject:To:From:From; b=hkNHtzpGyLPaHEa33f1iASZAhcKQMUd2qX1EDxUR991hN5Smtxc7Cw8dSHOlGCwwa FuQnTxpbVIbvj31+uou5OAggle2bYQmg7Yqhh4xrYuW7DX7GbImIC40eaqS09jWO9V C2PJ2rggrlhDVMxbkSocRmYX0FJXxYhgTEjLCOGI= Date: Wed, 24 Jan 2018 23:05:14 +0000 In-Reply-To: <20180124222820.1C53B19C235A@ary.qy> References: <20180124222820.1C53B19C235A@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <798083A2-1B8A-4659-B51B-34B9CBA127F9@kitterman.com> Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 23:05:27 -0000 On January 24, 2018 10:28:19 PM UTC, John Levine wrote= : >In article you >write: >>> Unfortunately, as far as I know you're still the only person to >implement it=2E I'll try and=20 >>> hack it into Mail::DKIM but I don't know when I'll have the time=2E >> >>I've had a working implementation in exim/gnutls for so long that it's >>getting bit-rot=2E I don't recall what state it's in wrt=2E the >double-hash >>issue=2E It was internally consistent, sign vs=2E verify, but has had n= o >>independent testing=2E I think it was only buildable on fedora rawhide >>due to the GnuTLS version required=2E It has not gone into the mainline >>exim sourcebase only because there is no exim/openssl support yet, the >>library being lacking in the required interfaces=2E > >Perhaps you and Scott can compare signature samples=2E It would be great if I could get the public key/signatures/messages you ha= ve produced=2E My implementation "works", but the signatures don't self-ve= rify=2E If I could get your data to test against, I could narrow down if I= have a signing problem or a verification problem=2E Scott K From nobody Mon Jan 29 15:22:28 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4C012ECA3 for ; Mon, 29 Jan 2018 15:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqcTXOpzlIOD for ; Mon, 29 Jan 2018 15:22:24 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD58131479 for ; Mon, 29 Jan 2018 15:22:23 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id d80so7840177qkg.2 for ; Mon, 29 Jan 2018 15:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ugf3yowkMSoDOi+20eh161mtSF/iMCYPxeEjJKH4yBI=; b=jO7qgIU2y1ZuwoqgQYBImUo8VsjoguH39NV353KRZ+3b0y2kGlF7h+bHjhsXViRdeL ljhUXpE3DEM8kD9Svo2w4tgG++VHMotq9W+v7pHWdXL1nIEcexorvlf0D/KshkgyVo7+ +ry+MSR/w9rNkAis5tMWcOrhZ4T84rV4A+mjG25UE6K0LZjeP4lKkB0/w9chlgY6VOu5 WZe+piq7JCbUn4KJEtASLkZUdnFSis9ML4ho0oNBszuYqe1qz2PHJesVRxAzpVvbH2PI P8jRt6Vp0dzatx7V5FqiSz6PcTQYout1nJmOwRKb2uHccu3C1qbopywkO6lk+yO4zbNP OUwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Ugf3yowkMSoDOi+20eh161mtSF/iMCYPxeEjJKH4yBI=; b=OgtW1TBA5H+FKvhZNUgOUon8LpQVSds9iH0cU1lefgxTX7XYLu7B4/5BtACSs1lSIX KZ1JKr/Eqlw3IuP2Y/Ouylu6tp3TwSxoeZJkzoXNEn40VRGfmE+AXeoKJIMaYTVuCSM5 DobcjNOE/qs6HIFbqGrv+T4mBnzl7cMcOvoXRTRM649i77dxtDwEIbVlvopgQFFHJ3lJ lyNaxj/TMY0rQVDhYsdC0DOnbzBFpD8dVtKMNgNQi++e6RrNG9cYNynSKzuqaXaYx/T/ KcRu3NajfdLyTEMUf3DPvCS6+o21ReIEBiNXxJFzvKy9DUbka5s8yKa0KGMRjkzdOug4 hpow== X-Gm-Message-State: AKwxytdlv4KxLSr5WuBKi8e5jj8MxCeywGJy87LrHM/zBP+Tk3/E0nFr y/MPIqAgEFwrLwnYZLz7844mLG3P0J+Cktb4oZ0= X-Google-Smtp-Source: AH8x226ASfjpamH6w/73tHbPBMLydUnt5304qxgB9I2ssIJNTK+QUfnC96qHr+egqG2E09T8C552jU3qwjLYq0incEQ= X-Received: by 10.55.134.193 with SMTP id i184mr37098139qkd.314.1517268142927; Mon, 29 Jan 2018 15:22:22 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.35.199 with HTTP; Mon, 29 Jan 2018 15:22:22 -0800 (PST) In-Reply-To: References: <2005843.OrHkAfkQ5T@kitterma-e6430> <2046656.8I2TqWBbc6@kitterma-e6430> From: Barry Leiba Date: Mon, 29 Jan 2018 18:22:22 -0500 X-Google-Sender-Auth: DW0l-ooJqtUqhGBvShA5C5lbvfk Message-ID: To: "Murray S. Kucherawy" Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 23:22:26 -0000 > Thanks for the reminder. And I'm planning to do a second WGLC since the > first one drew exactly one review. Hopefully we get a little more the > second time around. Document shepherd speaking: If we're going to do a second WGLC, can we get that started forthwith? On the other hand, what's your plan for getting more reviews the second time than the first? How do you think we'll get value out of it, rather than sending it up with Publication Requested now? Perhaps the working group simply thinks it's ready for that. Barry From nobody Mon Jan 29 15:29:13 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3A0127023 for ; Mon, 29 Jan 2018 15:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2yVu2LJRvC9 for ; Mon, 29 Jan 2018 15:29:06 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578E4131963 for ; Mon, 29 Jan 2018 15:29:06 -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 1899DC401E9 for ; Mon, 29 Jan 2018 17:29:05 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1517268545; bh=hN7jP9X7k0qtpnH2qu2aOOzeQesWwByr4q8xQylwY0E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EjUsxZVtzf3DaWUNeBhe/NKKPDbPdIxm8Q+9iFiLz5JIsZJEiKVUImiz5w3R+mBHs f9JimfKzBVSpnZh5E5rLf6343JHkBV09jljGwM72LYvyjWF8goiEm32N6oio7dJa1N YfWHGlA7zO8V4qih5SpIJ5dD89SlM8poKY+rinyI= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 29 Jan 2018 18:29:04 -0500 Message-ID: <1991314.EiOPZKHnAd@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-139-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 23:29:10 -0000 On Monday, January 29, 2018 06:22:22 PM Barry Leiba wrote: > > Thanks for the reminder. And I'm planning to do a second WGLC since the > > first one drew exactly one review. Hopefully we get a little more the > > second time around. > > Document shepherd speaking: > If we're going to do a second WGLC, can we get that started forthwith? > > On the other hand, what's your plan for getting more reviews the > second time than the first? How do you think we'll get value out of > it, rather than sending it up with Publication Requested now? Perhaps > the working group simply thinks it's ready for that. I'd like to see my comments from the WGLC more fully addressed first. Scott K From nobody Tue Jan 30 05:20:01 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1243131881 for ; Tue, 30 Jan 2018 05:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=YjopwVv/; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=jNHTE7uP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3_hNnElS289 for ; Tue, 30 Jan 2018 05:19:58 -0800 (PST) Received: from ftp.catinthebox.net (unknown [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 99B83131883 for ; Tue, 30 Jan 2018 05:15:01 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=555; t=1517318096; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=qq3FChIr9njp9GVyafJZXfCR1H4=; b=YjopwVv/o/shqgmY63fd0+tac2sdwh6EMVMzygts3FSqG/gdjfHBZ2vx52cIbW SIbsi+9HChZGQuLwsZRgEmDxU39ai8ZbRRFI5nus7GfzUsNhVwdrd8QPt71zEUGg WUQL5CtXUEWXYO4Gg6gj2ATZdjkUyS45wyebIetOaXubI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Tue, 30 Jan 2018 08:14:56 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2891793219.20357.1800; Tue, 30 Jan 2018 08:14:55 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=555; t=1517317820; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=H6OPyj9 AxFqq0WOuspaniVZu1FLWDLEwlOwvp1CpSbA=; b=jNHTE7uPFIcMfIaMceXuGZG NWUO7gCzsfd/wyz7g5EgROBP2SuxZV0Pi5j2MMLPj7DjIP8xCNrI9vFsCaNO8qnP n92PlBK+Eg2TCzczrwKwsb/y38xVz+2hYLKwmsvrX5zTfRVkV2iEMKHXSX4sQk0h IqcCCaYI8eASo5QGsVfo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Tue, 30 Jan 2018 08:10:20 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2891694298.9.243312; Tue, 30 Jan 2018 08:10:20 -0500 Message-ID: <5A706FCF.4060206@isdg.net> Date: Tue, 30 Jan 2018 08:14:55 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] ed25519 in DNS X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 13:20:00 -0000 On 1/22/2018 11:54 AM, John R Levine wrote: > > This whole exercise started because RSA keys were getting too big to > fit into a 255 character text string. But EC keys are so short that > any encoding, even one with lots of ASN.1 goop, will fit. The size > limit isn't an issue, and I don't know of any other crypto > applications where squeezing a text version of the key into 255 > chaaracters matters. > > ...... We should pick a > hex or base64 version of the key, which is very short either way, and > be done with it. +1. -- HLS From nobody Wed Jan 31 06:53:18 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359A7131BAB for ; Wed, 31 Jan 2018 06:53:16 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf7XqO1ET9cA for ; Wed, 31 Jan 2018 06:53:09 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060AE131BBB for ; Wed, 31 Jan 2018 06:48:59 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0VEgLwN027348 for ; Wed, 31 Jan 2018 14:48:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=JyrL9LiWWAWAc2MiPxneytT0CuzI2v4Uxshcqsqnlck=; b=c8P3w4m8JJQzE5hmwDFLB0E3B0xvV/MPO8v2UGywbYm0hEDKRyNXZfSVoYUvARZDNBKn K93siaro4c2I7VYl1aXbg1S+cC8vcc7ardmW3p2Zk0L93/UWGK8et+r85CbTDHf5FT4E gsoGgeKlmrhm7atmBEufk7KKJGfQEVh+esL3S8LbRpJGWeKO8GoaquPvx1Ktb87zweNq XRHBsZZ5oyooQJF5Mu/JPfPRsWyeM83YGwRvQHxehNF2dnFjvs3cYJA+SmiwEcPqrjaV Q+f52A73q/Q7VX2FwXhVDrgE+FAi/GreYt494HoO5erJQwtWVMEU4+ViK1pDuv5Ik8oc mw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2frf5wh09g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 31 Jan 2018 14:48:59 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0VEjptb030026 for ; Wed, 31 Jan 2018 09:48:58 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2frnmy694d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 31 Jan 2018 09:48:58 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 31 Jan 2018 09:48:57 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 31 Jan 2018 09:48:57 -0500 From: "Salz, Rich" To: "dcrup@ietf.org" Thread-Topic: WGLC final issues draft-ietf-dcrup-dkim-crypto Thread-Index: AQHTmqKfjG6+cXRWMEypzMoeK481UA== Date: Wed, 31 Jan 2018 14:48:57 +0000 Message-ID: <3569AEBA-5089-4827-8C18-EC13246BC201@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.52] Content-Type: text/plain; charset="utf-8" Content-ID: <2AAF72DC610C784E9F29E8F0775F5F83@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-31_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=733 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801310193 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-31_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=683 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801310193 Archived-At: Subject: [Dcrup] WGLC final issues draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 14:53:16 -0000 U2NvdHQgaGFzIGFza2VkIHRoYXQgaGlzIFdHTEMgY2FsbCBpc3N1ZXMgZnJvbSBEZWNlbWJlciBi ZSBhZGRyZXNzZWQuICBJIGJlbGlldmUgdGhpcyBpcyB0aGUgbWVzc2FnZSBoZSBtZWFucyBpcyB0 aGlzOg0KICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kY3J1cC9jdXJy ZW50L21zZzAwNjE5Lmh0bWwNCmFuZCB0aGF0IG9ubHkgdGhlIGZpcnN0IHR3byBwb2ludHMgcmVt YWluLiBUaGV5IHNlZW0gbGlrZSBlZGl0b3JpYWwgY2xhcmlmaWNhdGlvbnMgdG8gbWU7IEpvaG4g Y2FuIHlvdSBtYWtlIHRob3NlIGNoYW5nZXMgb3Igc29tZXRoaW5nIHNpbWlsYXI/DQoNClRoZXJl IGhhcyBhbHNvIGJlZW4gZGlzY3Vzc2lvbiBhYm91dCBpbmNsdWRpbmcgc2FtcGxlcyBpbiB0aGUg ZG9jdW1lbnQuICBXaGVyZSBhcmUgd2Ugd2l0aCB0aGF0Pw0KDQoNCg== From nobody Wed Jan 31 07:03:57 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B5D12EB51 for ; Wed, 31 Jan 2018 07:03:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXfbnQph42AR for ; Wed, 31 Jan 2018 07:03:43 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5D712EB78 for ; Wed, 31 Jan 2018 07:02:01 -0800 (PST) Received: from [10.81.197.188] (mobile-166-170-31-0.mycingular.net [166.170.31.0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 216CFC401CA; Wed, 31 Jan 2018 09:02:00 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1517410920; bh=j0ZgfvZrEJ4v5+dpeuYQTKVX2BeRzwLzdj6T4/51Bmo=; h=Date:In-Reply-To:References:Subject:To:From:From; b=uzufp8Nt9Tvy0IIsups+380MxXPSbvyCg7/U1eIHl99BDuMPWRVmreSpJj/AoVlJw TKo5Ir+dTYqQDVm/+I3PbWSDpqBiv5T8tSGqkWiQzW1FHaOEZAMXaxZp5c51BfYstN hPhwymWtz7zc1tIcQ0vYfKhZETYpieX2ipCbkYFQ= Date: Wed, 31 Jan 2018 15:01:55 +0000 In-Reply-To: <3569AEBA-5089-4827-8C18-EC13246BC201@akamai.com> References: <3569AEBA-5089-4827-8C18-EC13246BC201@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <2142766D-1404-409E-9419-C883737AE23E@kitterman.com> Archived-At: Subject: Re: [Dcrup] WGLC final issues draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 15:03:50 -0000 On January 31, 2018 2:48:57 PM UTC, "Salz, Rich" wrot= e: >Scott has asked that his WGLC call issues from December be addressed=2E= =20 >I believe this is the message he means is this: > https://www=2Eietf=2Eorg/mail-archive/web/dcrup/current/msg00619=2Ehtm= l >and that only the first two points remain=2E They seem like editorial >clarifications to me; John can you make those changes or something >similar? I don't think missing to specify hash-alg is editorial=2E I agree the sec= ond is editorial=2E Scott K From nobody Wed Jan 31 09:09:00 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B10B1318C0 for ; Wed, 31 Jan 2018 09:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=AFr15+2y; dkim=pass (1536-bit key) header.d=taugh.com header.b=yYCRL3uE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA5GtQ2dUUkw for ; Wed, 31 Jan 2018 09:08:52 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E661131892 for ; Wed, 31 Jan 2018 09:07:57 -0800 (PST) Received: (qmail 69553 invoked from network); 31 Jan 2018 17:07:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=10faf.5a71f7ec.k1801; bh=X75ltLa5RmEhMzwSr3lmolCjbCAeIo9DJNzgvAvEqy4=; b=AFr15+2ydGPnVjibt/2C+q6pe/nhX1hi1oyhyMpJouybtDjDufHg4TTfi31ha8oApGYbHvCviFDjCKK55P4GoOhfDxvtipVjfSqXUo88rYBKOoq502Oxb0NIHxslwNFBLYkF9WUQSkiDLt3ZMj8aG+L3wpktS4S0g9KG/cS4xLF7iFhxKeVL7ZWkhuxrGEiI+7ijiXxXYlSwtezch4C/mjdO6KvwYgFXlZEMiNwq9MDDHEUUQ6iihpoILH1sSaUi DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=10faf.5a71f7ec.k1801; bh=X75ltLa5RmEhMzwSr3lmolCjbCAeIo9DJNzgvAvEqy4=; b=yYCRL3uEHZucgyklGKGUdEfxaxgP1sZX8evhrLiIvoqe645e6V47j+r8bM39exgOWSlPUfVfu7vw49M+xq4/P976bEquq3q5CI50giaKtYy7Ku5W+ZQjXgJ9xIeO2b4ZjyZVE5J3PkNqER8eBhbq6PsykGWglUpOj35U4CYmyCqRF0NoQ/x/pD1AE/B5zhmLXT6lsG8jtGcuH2JhYP9oBEdxjfs1BBiZkUQLXM68TmFeNFERmfyjB0bHFjcwFhBC Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 31 Jan 2018 17:07:55 -0000 Received: by ary.qy (Postfix, from userid 501) id 8151D1A21F93; Wed, 31 Jan 2018 12:07:55 -0500 (EST) Date: 31 Jan 2018 12:07:55 -0500 Message-Id: <20180131170755.8151D1A21F93@ary.qy> From: "John Levine" To: dcrup@ietf.org Cc: sklist@kitterman.com In-Reply-To: <1991314.EiOPZKHnAd@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 17:08:58 -0000 In article <1991314.EiOPZKHnAd@kitterma-e6430> you write: >> On the other hand, what's your plan for getting more reviews the >> second time than the first? How do you think we'll get value out of >> it, rather than sending it up with Publication Requested now? Perhaps >> the working group simply thinks it's ready for that. > >I'd like to see my comments from the WGLC more fully addressed first. I think I'd like to have enough running code that we can get a signed example into the draft that everyone agrees is correct. That also would make it more likely that my language about key format was right.