From nobody Sun Apr 1 18:08:33 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 DA584126C89 for ; Sun, 1 Apr 2018 18:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=LybiPPgr; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=cOpOIJLR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G7ksHhfWdjx for ; Sun, 1 Apr 2018 18:08:29 -0700 (PDT) Received: from groups.winserver.com (listserv.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 27BFF1243F3 for ; Sun, 1 Apr 2018 18:08:27 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1446; t=1522631296; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Idof4mBvLClA2+Yequn6MQGL6WY=; b=LybiPPgrpEgZAzJDxhggd1DI0dnIMraRR0oZ0XdxMhnNkiuFNhptOhD9kFrReD RD2COJNdJ1zoiapJmW+hf4OScViYqX2NYWJ8RLvie+ZJcJW0WgqwWq0yp09GOO9R vrO0NZ2EZXZNYmp05Hscvq1aAhLs1lMMM0CfsRQOKUbv0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Sun, 01 Apr 2018 21:08:16 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3909964868.1.2940; Sun, 01 Apr 2018 21:08:15 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1446; t=1522630901; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0PbGh2o jwZewYxxfh/RN63fVx+wb8PdqBG0/sykKQ18=; b=cOpOIJLRdSjePLsLiopsGfl EpmEfYDfcoxLLFCFWrqYMu0eVZewlHMI8nwQopSGiBwQdSPWahRZLi0hBDNrJmk2 mBJ7RPKCrvu73zt5aX4PQm6/SWRIhkzrhbn0BWQD5l9BvxDMzFhWQxA+YF+lEFgK gn+twPccLc5LJ5e7EgZY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Sun, 01 Apr 2018 21:01:41 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3909807393.9.229836; Sun, 01 Apr 2018 21:01:40 -0400 Message-ID: <5AC1827B.8080903@isdg.net> Date: Sun, 01 Apr 2018 21:08:11 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "Salz, Rich" , denis bider CC: "dcrup@ietf.org" , Phillip Hallam-Baker , "Murray S. Kucherawy" , "A. Schulze" References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.com> <20180328094636.Horde.Np3GCcO8iEPwmQzOaaUjbrh@andreasschulze.de> <2897E6E0-4535-4EC1-9686-E080CCA82D21@akamai.com> In-Reply-To: <2897E6E0-4535-4EC1-9686-E080CCA82D21@akamai.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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, 02 Apr 2018 01:08:31 -0000 On 3/30/2018 8:05 AM, Salz, Rich wrote: > * The toolkit in question is OpenSSL, and this push is an example of > the open source community assuming it is the end-all and be-all of > all things. > > I wasn’t trying to push anything, sorry if it came across that way. > > We will have to have a consensus decision on this. Let’s let the > discussion run for a few more days. If you have anything new to > mention, please speak up. Otherwise it seems to me that the choice > will be > > ASN1/DER wrap the Ed25519 key > > Just the key without wrapping. > My input, overall, DKIM did not have ASN1/DER API implementation requirements. So for a new hash, it could add a higher barrier for (immediate) support, even put it on the back burner since in reality SHA246 is "good enough." It wouldn't be "plug and play" anymore, per se. On the other hand, today higher overhead is lesser concern with a multi-discipline developer. Using ASN1/DER could probably be useful for documentation, support, perhaps DNS folks. Coders probably would not care. It would be more work. For me, if using a non-ASN1/DER DNS storage is good enough for DKIM, then I think it should be kept that way since it would be a simpler API plugin with lesser QA concerns. But if you are forcing more coding requirements for ASN1/DER support, it would take more time to consider ed25519 support. That may or may not be a problem. -- HLS From nobody Mon Apr 2 14:33:17 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 92C6A12D95E for ; Mon, 2 Apr 2018 14:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrFbqWDfeLQ6 for ; Mon, 2 Apr 2018 14:33:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C2F12D95C for ; Mon, 2 Apr 2018 14:33:13 -0700 (PDT) Received: from [10.200.17.69] (unknown [38.27.161.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 523187A3309; Mon, 2 Apr 2018 21:33:12 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: dcrup@ietf.org Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 2 Apr 2018 17:33:11 -0400 To: dcrup@ietf.org Message-Id: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> X-Mailer: Apple Mail (2.3445.5.20) 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, 02 Apr 2018 21:33:15 -0000 If ed25519/ed448 were the *only* key types supported by DKIM in the = past, present and future, I'd gladly support a raw key format. That, however, is not the case. However simple it might be to explicitly use ed25519 keys in various APIs, the fact is that typically one just wants to = import *whatever* key type is published in a *generic* way, that just yields an opaque public key object that the application library can use for = verification. One should not have to write new code to make use of these keys, and = indeed none would be needed if the were in SPKI, which simply involves = prepending ~12 fixed bytes to the front of the raw key, but substantially = simplifies the use of the key in a generic way. Code that generates keys for various algorithms already supports = producing SPKI output, tools exist that can use the key in a generic way to check signatures, ... The desire to "simplify" by getting rid of ASN.1 is IMHO misplaced in the context of an application that supports keys for a range of algorithms, and where new algorithms might be added in the future. The use of DER here requires no complex ASN.1 parsers, parsing DER is simple, and generating DER for publishing in DNS is something administrators already know how to do with RSA, they have command-line tools for this already. So, for me the obvious, simple and interoperable choice is SPKI. --=20 Viktor. From nobody Mon Apr 2 15:56:56 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 4C41812DA15 for ; Mon, 2 Apr 2018 15:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=IT07jHEa; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=oKl62lU5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2Cu1Ls0h2mN for ; Mon, 2 Apr 2018 15:56:53 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B77112DA16 for ; Mon, 2 Apr 2018 15:56:48 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1522709806; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=szcUPGwMYM1Z5F8N08VWPJL0+flag5YLAN722WH3oRA=; b=IT07jHEaRUEnoPLfq1ypEZ+6rwtXbu82I+3D/3kuzkil9G5wBZYBgFmx h+EslfMypvx4iz8z8Rk9nnwxT7+XBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1522709806; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=szcUPGwMYM1Z5F8N08VWPJL0+flag5YLAN722WH3oRA=; b=oKl62lU5lWC+0pRfyC2Xp0apDmas1z+61V3dXWAC7yZ2MxGhl/sIr3e6 6lngegruw/vDmnHZhMZ5zjnr8TCul1L1dlg3pMQSRrXIkt0xlamhQgOQ2a /RwmrvyBylsiEr0gpmUthcIeTdYUXOaaa+oDBaIMSYb/YEALKKUDaw/3gO n21RlUUOQIOwWrXnu00jvU3XTnrK9uxCRmHAyV+52CGC+ZPSfrL5bBptr0 PAFwLbRDplWj273sldxpzpbfu4jZRdG7oEvOGGNkFbndmOkYOvJWowjZJd qsnXQcBzYHPimWV5gM8lRpjjowCL5VdAfdV8apqOehxvsDDZyZWkFg== 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 70A91C401CA for ; Mon, 2 Apr 2018 17:56:46 -0500 (CDT) From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 02 Apr 2018 18:56:44 -0400 Message-ID: <1603345.WrcMxlQQTC@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-139-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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, 02 Apr 2018 22:56:55 -0000 On Monday, April 02, 2018 05:33:11 PM Viktor Dukhovni wrote: > If ed25519/ed448 were the *only* key types supported by DKIM in the past, > present and future, I'd gladly support a raw key format. That, however, > is not the case. However simple it might be to explicitly use ed25519 > keys in various APIs, the fact is that typically one just wants to import > *whatever* key type is published in a *generic* way, that just yields an > opaque public key object that the application library can use for > verification. > > One should not have to write new code to make use of these keys, and indeed > none would be needed if the were in SPKI, which simply involves prepending > ~12 fixed bytes to the front of the raw key, but substantially simplifies > the use of the key in a generic way. > > Code that generates keys for various algorithms already supports producing > SPKI output, tools exist that can use the key in a generic way to check > signatures, ... > > The desire to "simplify" by getting rid of ASN.1 is IMHO misplaced in > the context of an application that supports keys for a range of > algorithms, and where new algorithms might be added in the future. > > The use of DER here requires no complex ASN.1 parsers, parsing DER > is simple, and generating DER for publishing in DNS is something > administrators already know how to do with RSA, they have command-line > tools for this already. > > So, for me the obvious, simple and interoperable choice is SPKI. I struggled with this for some time and I think I finally understand it. It assumes all key types will be supported by a single crypto library, which isn't a good assumption for all implementers and all algorithms. One person's simplifying assumption is another person's added layer of complexity. Having implemented this, the difference is (using the public key retrieval side of the equation as an example): RSA: Base64 decode -> ASN.1 decode (RSA) -> RSA public key object ed25519: Base64 decode -> ed25519 public key object Even if we make this change and change it to: ed25519: Base64 decode -> ASN.1 decode (ed25519) -> ed25519 public key object there is still a need to know how to handle the ed25519 key. That's approximately 100% of the code difference and because of the k=ed25519 tag in the key record, you know before you start it's not an RSA key. I understand that for the design approach you're considering, that's all exported to an external library, so not a concern, but that isn't always going to be the case. Conveniently, in DKIM we will already know because of the k= tag in the DNS record, so we don't have to go down that path. If you make the assumption that everything after Base64 decoding is someone else's problem (i.e. a single crypto library), then I see your point. That assumption wasn't true when I implemented it in Python. I don't think implementation specific assumptions, which is how I interpret your proposal, are the best basis for IETF protocol design. If this made general sense, I think it would have been in RFC 8032 and not in an X.509 specific document like draft-ietf-curdle-pkix. If you consider that an implementation may need to use different libraries for different crypto, does that change your view any? Scott K From nobody Mon Apr 2 16:19:35 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 8CC3C12DA22 for ; Mon, 2 Apr 2018 16:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oTlb5bM2fNs for ; Mon, 2 Apr 2018 16:19:32 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D217412DA1D for ; Mon, 2 Apr 2018 16:19:31 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id u9so3358108qkk.11 for ; Mon, 02 Apr 2018 16:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=rDu10ihMdKZMAeRx/M5iJurbkNoWrFM1QvI8JXNU41g=; b=mfc9bojrKb1Re5oN4G3SxdKYS6DCV0xdCz19cTlE3hUEGBa9yWgYla075TjO1X1Es2 p/x2AE4SUsq78rCn3OTDx0zUNlNuu/ejDGwWubS9/RUc3PPWq+1yYUmt2LuQGtbKyPqx bdZWb3vS23KmwY2zlNjlkojiG9C19n3bKG96FvR3/JGe8Rg7uVGoe2P1ZfiA5yPJ3oKB WU2JUMT9ptJgrYdCaq9JoI07oltZbkrLg7VoTxiZ0PC5twINfSPnHTaeyJWjC0zGzZTA Zk6Lpu8FTQKr5Nuzn/Vvt8PL2n1nulZZccqujMI0X5AgRna2ocC1hzyZC7Fd3M2RnckV 46Bw== 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=rDu10ihMdKZMAeRx/M5iJurbkNoWrFM1QvI8JXNU41g=; b=Pp/jV+C5jwS6P8Zfo5kvRafvq2mh5d6ZvwTx7ajmtUOHSi+cB+fSizVkIy60BrS1Ov 7cCIBWI3/GwnbYS62VOgUT4t0el6LFK8Vo9T3JPrCbjTi5tTB2ClcrkPDcGa6eyj5rX9 RRnY3nL+4BKCyPGKDt5LOhlV4UT/J4Xg0ZTRJLKmykqLDBW42gg6z/AFtjSf8ARHbql2 JMaw+n6fzZl7OxSxQ6QStQXnVOKujQFudKwRmBHxbn1so7A8CE0FRG5jAFvP2COT2sir TZvF4MCt89pWGVTXSxZegbueUtxu880b6okdL/oIgpQGL2J4uqVvu4oKiGuD5DnVKc/+ pFUg== X-Gm-Message-State: ALQs6tAobv3I+sd7A5YQnHf7Vx/JlrhwPuHjp2FMZuHXTzmBJh6JBo/J BBIXuJaip2iXEBSFQFuvOg5omFLXT4as73sMVI6n5w== X-Google-Smtp-Source: AIpwx48U9/7WzwEhsZIzuPkQGSGc/sCm+bTh6+2Gf1SL87wIlFp2of7QRuxiwDzotUz3Kham93HnKo8T2MqxiXmX/3Q= X-Received: by 10.55.107.70 with SMTP id g67mr15561548qkc.105.1522711170527; Mon, 02 Apr 2018 16:19:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Mon, 2 Apr 2018 16:19:30 -0700 (PDT) In-Reply-To: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> From: denis bider Date: Mon, 2 Apr 2018 18:19:30 -0500 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114873f26a38730568e5d2d7" 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, 02 Apr 2018 23:19:34 -0000 --001a114873f26a38730568e5d2d7 Content-Type: text/plain; charset="UTF-8" > One should not have to write new code to make use of these keys, I don't know how you use the particular crypto library that you use. However, in the libraries I've used, you definitely need to tell the library what type of key it is. Which means you need to have special case handling for each type of key (there are so many types here, RSA and Ed25519) and call the appropriate library functions to import that key. If you are instead using a library which can decide for you what kind of key it is, and you literally want to write ZERO new code to support a new key, then it seems to me you would be failing to check for a situation where the DKIM algorithm says the key is of one type (e.g. RSA), but the actual key is another (e.g. Ed25519). If you do this check, WHICH YOU SHOULD, then you will have an "if" statement. In pseudo code, this "if" statement might look something like this: algorithm = determine_algorithm_from_dkim_parameters(dkim_input) if (algorithm == rsa_algorithm) key = crypto_library_load_key(dkim_key_value) if (key.algorithm != rsa_algorithm) error "unexpected key type"; else if (algorithm == ed25519_algorithm) key = crypto_library_load_key(dkim_key_value) if (key.algorithm != ed25519_algorithm) error "unexpected key type"; Now, if your library desperately, unconditionally needs the key to be ASN.1 decorated, then the above pseudo code becomes HORRIBLY MORE COMPLEX as follows: algorithm = determine_algorithm_from_dkim_parameters(dkim_input) if (algorithm == rsa_algorithm) key = crypto_library_load_key(dkim_key_value) if (key.algorithm != rsa_algorithm) error "unexpected key type"; else if (algorithm == ed25519_algorithm) asn1_key = fixed_asn1_prefix + dkim_key_value // Very tricky part here! Complex string concatenation! key = crypto_library_load_key(asn1_key) if (key.algorithm != ed25519_algorithm) error "unexpected key type"; This whole thread is basically about people not wanting to do string concatenation inside an "if" clause, and wanting other people to pad their keys with the string you would otherwise want to prefix. And also for people to write ASN.1 parsers because you are using one. Because, you know, string concatenation is hard. On Mon, Apr 2, 2018 at 4:33 PM, Viktor Dukhovni wrote: > > If ed25519/ed448 were the *only* key types supported by DKIM in the past, > present and future, I'd gladly support a raw key format. That, however, > is not the case. However simple it might be to explicitly use ed25519 > keys in various APIs, the fact is that typically one just wants to import > *whatever* key type is published in a *generic* way, that just yields an > opaque public key object that the application library can use for > verification. > > One should not have to write new code to make use of these keys, and indeed > none would be needed if the were in SPKI, which simply involves prepending > ~12 fixed bytes to the front of the raw key, but substantially simplifies > the use of the key in a generic way. > > Code that generates keys for various algorithms already supports producing > SPKI output, tools exist that can use the key in a generic way to check > signatures, ... > > The desire to "simplify" by getting rid of ASN.1 is IMHO misplaced in > the context of an application that supports keys for a range of > algorithms, and where new algorithms might be added in the future. > > The use of DER here requires no complex ASN.1 parsers, parsing DER > is simple, and generating DER for publishing in DNS is something > administrators already know how to do with RSA, they have command-line > tools for this already. > > So, for me the obvious, simple and interoperable choice is SPKI. > > -- > Viktor. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a114873f26a38730568e5d2d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0One should not have t= o write new code to make use of these keys,

I don't know how you use the particular crypto library that you u= se. However, in the libraries I've used, you definitely need to tell th= e library what type of key it is. Which means you need to have special case= handling for each type of key (there are so many types here, RSA and Ed255= 19) and call the appropriate library functions to import that key.

If you are instead using a library which can decide for you what = kind of key it is, and you literally want to write ZERO new code to support= a new key, then it seems to me you would be failing to check for a situati= on where the DKIM algorithm says the key is of one type (e.g. RSA), but the= actual key is another (e.g. Ed25519).

If you do this che= ck, WHICH YOU SHOULD, then you will have an "if" statement. In ps= eudo code, this "if" statement might look something like this:


=C2= =A0 =C2=A0 algorithm =3D determine_algorithm_from_dkim_parameters(dkim_inpu= t)

= =C2=A0 =C2=A0 if (algorithm =3D=3D rsa_alg= orithm)
<= span style=3D"font-size:12.8px">=C2=A0 =C2=A0 =C2=A0 =C2=A0 key =3D crypto_= library_load_key(dkim_key_value)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (key.a= lgorithm !=3D rsa_algorithm)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 error "unexpected key ty= pe";

=C2=A0 =C2=A0 else if (algorithm = =3D=3D ed25519_algorithm)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 key =3D crypto_library_load_key(dkim_key_value)=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (key.algorithm !=3D ed25519_algor= ithm)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 error "unexp= ected key type";


Now, if your library desperately, uncon= ditionally needs the key to be ASN.1 decorated, then the above pseudo code = becomes HORRIBLY MORE COMPLEX as follows:


=
<= span style=3D"font-size:12.8px">=C2=A0 =C2=A0 algorithm =3D determine_algor= ithm_from_dkim_parameters(dkim_input)

=C2=A0 =C2=A0 if (a= lgorithm =3D=3D rsa_algorithm)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 key =3D crypto_library_load_key(dkim_key_value)=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if= (key.algorithm !=3D rsa_algorithm)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 error "unexpected key t= ype";

=C2=A0 =C2=A0 else if (algorithm =3D=3D ed2551= 9_algorithm)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 asn1_key =3D fixed_asn1_prefix + dkim_key= _value=C2=A0 =C2=A0 // Very tricky part here! Complex string concatenation!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 key =3D cr= ypto_library_load_key(asn1_key)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (k= ey.algorithm !=3D ed25519_algorithm)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 error "unexpected key type";

This whole thread is basically about people not wanting to do string concat= enation inside an "if" clause, and wanting other people to pad th= eir keys with the string you would otherwise want to prefix. And also for p= eople to write ASN.1 parsers because you are using one.

Because, you know, string concaten= ation is hard.


On Mon, Ap= r 2, 2018 at 4:33 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>= wrote:

If ed25519/ed448 were the *only* key types supported by DKIM in the past, present and future, I'd gladly support a raw key format.=C2=A0 That, ho= wever,
is not the case.=C2=A0 However simple it might be to explicitly use ed25519=
keys in various APIs, the fact is that typically one just wants to import *whatever* key type is published in a *generic* way, that just yields an opaque public key object that the application library can use for verificat= ion.

One should not have to write new code to make use of these keys, and indeed=
none would be needed if the were in SPKI, which simply involves prepending<= br> ~12 fixed bytes to the front of the raw key, but substantially simplifies the use of the key in a generic way.

Code that generates keys for various algorithms already supports producing<= br> SPKI output, tools exist that can use the key in a generic way to check
signatures, ...

The desire to "simplify" by getting rid of ASN.1 is IMHO misplace= d in
the context of an application that supports keys for a range of
algorithms, and where new algorithms might be added in the future.

The use of DER here requires no complex ASN.1 parsers, parsing DER
is simple, and generating DER for publishing in DNS is something
administrators already know how to do with RSA, they have command-line
tools for this already.

So, for me the obvious, simple and interoperable choice is SPKI.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--001a114873f26a38730568e5d2d7-- From nobody Mon Apr 2 16:34:03 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 9BE121252BA for ; Mon, 2 Apr 2018 16:34:02 -0700 (PDT) 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 3RI9Nmk4M0Ir for ; Mon, 2 Apr 2018 16:34:01 -0700 (PDT) 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 BE9A2126B6E for ; Mon, 2 Apr 2018 16:34:00 -0700 (PDT) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; b=NnERtYpXTwict0MHrQds+G7e7R1l7521wkiPWh91GsvwbGfawAmQeuMm/miRFbgm1a9UpRPyNo 8y7K96qe4lBSyAWqNidXBha5cF9eP6Y4YJAReP0214CctTbiJZpUxlk9RsXaBPVGHB4pCFkhYS AI1IXw7Ck22smn8kHTAyIlU=; ARC-Authentication-Results: i=1; wizmail.org; iprev=pass (vgate18.wizint.net); auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; bh=vc1UFmfovcUiPofrMUCgyIPHpGzcnXzK7uRjudb5HSc=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject; b=PHe4GIulYI167qMiJyYajPTK/QHiDsIzrLik4J/l8ggXfLqJbHF3oLxAKHpicJYHjP1Qm/J8yH BOmYOwXGFfjyL+7pk6Y8OpgKYV30DMyZij8389Nuwy/BRaBkK1srOH8tjGbYy/OkOfFUwipL5v DoAMlWHMUkOhntjFGjR+jgM=; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net); auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90.117) id 1f38xa-0007X8-HV for dcrup@ietf.org (return-path ); Mon, 02 Apr 2018 23:33:58 +0000 To: dcrup@ietf.org References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <1603345.WrcMxlQQTC@kitterma-e6430> From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; keydata= xsBNBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAHNJkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+wsB7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGzsBNBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAHCwF8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: <6dce6d23-9ad9-00eb-e08c-5530ff4966e1@wizmail.org> Date: Tue, 3 Apr 2018 00:33:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1603345.WrcMxlQQTC@kitterma-e6430> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa 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, 02 Apr 2018 23:34:02 -0000 On 02/04/18 23:56, Scott Kitterman wrote: > Even if we make this change and change it to: > > ed25519: > > Base64 decode -> ASN.1 decode (ed25519) -> ed25519 public key object > > there is still a need to know how to handle the ed25519 key. That's > approximately 100% of the code difference and because of the k=ed25519 tag in > the key record, you know before you start it's not an RSA key. I understand > that for the design approach you're considering, that's all exported to an > external library, so not a concern, but that isn't always going to be the > case. > > Conveniently, in DKIM we will already know because of the k= tag in the DNS > record, so we don't have to go down that path. > > If you make the assumption that everything after Base64 decoding is someone > else's problem (i.e. a single crypto library), then I see your point. That > assumption wasn't true when I implemented it in Python. I think it isn't true, most likely, for any DKIM implementation. Because of the difference is hashing requirements of RSA and ED25519 in DKIM - specifically, with RSA and the convenience of incremental hashing followed by pure RSA signing/verification, the coding sequence could be very different from that imposed by the Ed25519 separate hash plus HashSign/HashVerify. Now it turns out that the implementation I ended up with needs pretty localised change to handle the proposal to relitigate the design aspect of the pubkey representation. I would still have to rip into bits of the documentation where I've tried to clarify the differences. I'm fairly much on the fence as to which way is better; mostly I don't care. But I do have a release coming up and unless the issue is resolved pronto I get to either release as-is (bare key, base64'd) or rip the whole lot out. I do confess to being quite surprised that the two libraries I deal with (OpenSSL, GnuTLS) do not see fit to provide utility-level access to the bare key value. Having to skip a magic number of bytes into a binary object feels _fragile_. But that is mostly tangential to the issue. -- Jeremy From nobody Mon Apr 2 16:52: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 DA70712DA1A for ; Mon, 2 Apr 2018 16:52:32 -0700 (PDT) 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 KLfH8jviytUS for ; Mon, 2 Apr 2018 16:52:31 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [192.40.56.151]) (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 6375B120721 for ; Mon, 2 Apr 2018 16:52:30 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 8D15D1DF2D; Mon, 2 Apr 2018 23:52:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1522713149; bh=q6/CIBJ+SP4twdmTgBw0HVhyth7soezpy95kbc8+pwo=; h=From:To:Subject:In-Reply-To:References:Date:From; b=kXBOwWcBCgMwTovms7LpF3CFoTvRWJeqZbn3sgy2TJEWmen84l4GbTKJEhTpWKv2C QANGU/VO/myny/TGXkckb3xDNoLLIh1R/FEmpQI/e4o0g61Gez6giY5BN5R70ZUcEz aPYjITuOdmx71iVwylfqS3yl/jq1+Aoing9DCgKmZgGYv2YQk1Ta+hrohOpFlDh2vs RFOylsGNQiJFpXz6c9UApon/vpKI7VVt3xl2Hfsuioj4KAZNIuxIcjYcm/UI80XGz/ NmHG7pBMYAa7I5lYwFCgmGgJyI0sjmd57R8IXffvFMlEPm5kjRWITB0U9X/JpF2Idk 3FNGl4VwVKVuQ== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 1033410A6FF32; Mon, 2 Apr 2018 23:52:23 +0000 (UTC) From: James Cloos To: dcrup@ietf.org In-Reply-To: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> (Viktor Dukhovni's message of "Mon, 2 Apr 2018 17:33:11 -0400") References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2018 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, 02 Apr 2018 19:52:23 -0400 Message-ID: Lines: 14 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, 02 Apr 2018 23:52:33 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> If ed25519/ed448 were the *only* key types supported by DKIM in the past, VD> present and future, I'd gladly support a raw key format. That, however, VD> is not the case. That is irrelevant. Ed25519 should always and only be exchanged as 256 bit strings. Whether in binary or some text encoding. But always just the key. That is the whole point. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Apr 2 17:01:09 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 B9D121242EA for ; Mon, 2 Apr 2018 17:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q48hubVp98N9 for ; Mon, 2 Apr 2018 17:00:50 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB50127076 for ; Mon, 2 Apr 2018 17:00:50 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id s9so16842002qke.12 for ; Mon, 02 Apr 2018 17:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=86VJxmEsW1piVh8tl0ND8ZwHGLK5taaAhpJWek3xJp4=; b=QsHIuZZTQwCPqTlt76A7m+Z666/Am50GqGIjd7g5IpCtXOEPWUtmHcZ3v6GfwTws+d +8uXUPPa6SIO3LBaz9r51zIG95vDKzXccYwrskp3jnFAvLdXyvoidC8rNkGagkGt1M9g 7EBKUmXIol8d8fRyxnSuGej8OWP0z53dGZqwhZkc+sem70BjIdxLHyu/Mw0BqYUtP8FZ wNaZdbST3QbZ+LxchYpFtFlVEodnQVRQhq/i69TpFH8ZfOEDt6OJLq7O2ON6Pdlbxq83 8GeFzmaOm8E4kOiY7Lnx+MD6/7wbzfeYCJj2kzvDg+Tl37vBRhJAcote9KLVeXL7e8le Thzw== 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=86VJxmEsW1piVh8tl0ND8ZwHGLK5taaAhpJWek3xJp4=; b=I2sT5xBO4buoA1LGXar++Zu9CDgIfmRuvsG6byojAt+6tqBFT+nszmPtnALr6oMWsJ x1ux2prUBbmqDassalZ45GcON2Ew8wIa1hhy9e8IpCuYuQ8ulbAwMpX3RrJvK19v7QfF U2j+my/6iTkOgd6ainn9ROAPZRJoeL07l0tK69bp1CBqdYLOOnXpDTy13lg0IdVtn3Oh PH3gqLRCmIVGiiOHD6gKuLVzV/rbGbrr0qPcHx32CdL3ueCqeBmWCnB+8VXkE7l1v3Sj u71VVD9dk9i7CI+Mf6b2LHuOpYC7KdpY0Tvki7hVen0raHIBncqRslzIH8RlaWdXNMpU tYEA== X-Gm-Message-State: ALQs6tAzO9FvtcOQiwMwMT2xGWFBNK86SKxeLp8r0O2c1gGyAjNX+EuQ 34rufcl64PrdAh+IMMWV2okyWgYjDxFZ5yFH49gDfA== X-Google-Smtp-Source: AIpwx4/1fzlZMNr9QWrrlkf5SL+NT8NQfB0z76K05PBFjeAIrffW+r7qlFYSan8IYCs/OjFpIWiVE2FswI5PNCwk2hU= X-Received: by 10.55.200.151 with SMTP id t23mr16352228qkl.146.1522713649169; Mon, 02 Apr 2018 17:00:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Mon, 2 Apr 2018 17:00:48 -0700 (PDT) In-Reply-To: <6dce6d23-9ad9-00eb-e08c-5530ff4966e1@wizmail.org> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <1603345.WrcMxlQQTC@kitterma-e6430> <6dce6d23-9ad9-00eb-e08c-5530ff4966e1@wizmail.org> From: denis bider Date: Mon, 2 Apr 2018 19:00:48 -0500 Message-ID: To: Jeremy Harris Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1142d2da274bf80568e666fe" 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, 03 Apr 2018 00:00:54 -0000 --001a1142d2da274bf80568e666fe Content-Type: text/plain; charset="UTF-8" > I do confess to being quite surprised that the two libraries > I deal with (OpenSSL, GnuTLS) do not see fit to provide > utility-level access to the bare key value. Having to skip > a magic number of bytes into a binary object feels _fragile_. > But that is mostly tangential to the issue. It seems to me that is, actually, pretty much *the* issue. Current interfaces of these libraries make it awkward to deal with bare keys, so folks would like to design the internet around the current interfaces of these libraries. But the interfaces of these libraries can change tomorrow if users argue with maintainers that easier access to the bare keys is needed. Meanwhile, if we design the internet around the current interfaces, we will have to live with that for 15 years. And even with current interfaces, workarounds exist. On encoding, drop the first N bytes. On decoding, prepend fixed prefix. The encoding rules are DER, so although it looks hacky, it's not fragile. The prefix will not change. On Mon, Apr 2, 2018 at 6:33 PM, Jeremy Harris wrote: > On 02/04/18 23:56, Scott Kitterman wrote: > > Even if we make this change and change it to: > > > > ed25519: > > > > Base64 decode -> ASN.1 decode (ed25519) -> ed25519 public key object > > > > there is still a need to know how to handle the ed25519 key. That's > > approximately 100% of the code difference and because of the k=ed25519 > tag in > > the key record, you know before you start it's not an RSA key. I > understand > > that for the design approach you're considering, that's all exported to > an > > external library, so not a concern, but that isn't always going to be the > > case. > > > > Conveniently, in DKIM we will already know because of the k= tag in the > DNS > > record, so we don't have to go down that path. > > > > If you make the assumption that everything after Base64 decoding is > someone > > else's problem (i.e. a single crypto library), then I see your point. > That > > assumption wasn't true when I implemented it in Python. > > I think it isn't true, most likely, for any DKIM implementation. > > Because of the difference is hashing requirements of RSA and ED25519 > in DKIM - specifically, with RSA and the convenience of incremental > hashing followed by pure RSA signing/verification, the coding sequence > could be very different from that imposed by the Ed25519 separate > hash plus HashSign/HashVerify. > > Now it turns out that the implementation I ended up with needs pretty > localised change to handle the proposal to relitigate the design aspect > of the pubkey representation. I would still have to rip into bits of > the documentation where I've tried to clarify the differences. > I'm fairly much on the fence as to which way is better; mostly I > don't care. But I do have a release coming up and unless the issue > is resolved pronto I get to either release as-is (bare key, base64'd) > or rip the whole lot out. > > I do confess to being quite surprised that the two libraries I > deal with (OpenSSL, GnuTLS) do not see fit to provide utility-level > access to the bare key value. Having to skip a magic number of bytes > into a binary object feels _fragile_. But that is mostly tangential to > the issue. > -- > Jeremy > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a1142d2da274bf80568e666fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0I do confess to being= quite surprised that the two libraries
> I=C2=A0deal with (OpenSSL, GnuTLS= ) do not see fit to provide
>= ; utility-level=C2=A0access to the bare k= ey value.=C2=A0 Having to skip
= > a magic number of bytes=C2=A0into a = binary object feels _fragile_.
= > But that is mostly tangential to=C2=A0
It seems to me that is, actually, pretty much <= i>the issue.

Curren= t interfaces of these libraries make it awkward to deal with bare keys, so = folks would like to design the internet around the current interfaces of th= ese libraries.

But the interfaces of these librarie= s can change tomorrow if users argue with maintainers that easier access to= the bare keys is needed.

Meanwhile, if we de= sign the internet around the current interfaces, we will have to live with = that for 15 years.

And even with current inte= rfaces, workarounds exist. On encoding, drop the first N bytes. On decoding= , prepend fixed prefix. The encoding rules are DER, so although it looks ha= cky, it's not fragile. The prefix will not change.

<= br>
On Mon, Apr 2, 2018 at 6:33 PM, Jeremy Harris= <jgh@wizmail.org> wrote:
On 02/04/18 23:56, Scott Kitterman wrote:
> Even if we make this change and change it to:
>
> ed25519:
>
> Base64 decode -> ASN.1 decode (ed25519) -> ed25519 public key ob= ject
>
> there is still a need to know how to handle the ed25519 key.=C2=A0 Tha= t's
> approximately 100% of the code difference and because of the k=3Ded255= 19 tag in
> the key record, you know before you start it's not an RSA key.=C2= =A0 I understand
> that for the design approach you're considering, that's all ex= ported to an
> external library, so not a concern, but that isn't always going to= be the
> case.
>
> Conveniently, in DKIM we will already know because of the k=3D tag in = the DNS
> record, so we don't have to go down that path.
>
> If you make the assumption that everything after Base64 decoding is so= meone
> else's problem (i.e. a single crypto library), then I see your poi= nt.=C2=A0 That
> assumption wasn't true when I implemented it in Python.

I think it isn't true, most likely, for any DKIM implementation.=

Because of the difference is hashing requirements of RSA and ED25519
in DKIM - specifically, with RSA and the convenience of incremental
hashing followed by pure RSA signing/verification, the coding sequence
could be very different from that imposed by the Ed25519 separate
hash plus HashSign/HashVerify.

Now it turns out that the implementation I ended up with needs pretty
localised change to handle the proposal to relitigate the design aspect
of the pubkey representation.=C2=A0 I would still have to rip into bits of<= br> the documentation where I've tried to clarify the differences.
I'm fairly much on the fence as to which way is better; mostly I
don't care.=C2=A0 But I do have a release coming up and unless the issu= e
is resolved pronto I get to either release as-is (bare key, base64'd) or rip the whole lot out.

I do confess to being quite surprised that the two libraries I
deal with (OpenSSL, GnuTLS) do not see fit to provide utility-level
access to the bare key value.=C2=A0 Having to skip a magic number of bytes<= br> into a binary object feels _fragile_.=C2=A0 But that is mostly tangential t= o
the issue.
--
Jeremy

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

--001a1142d2da274bf80568e666fe-- From nobody Mon Apr 2 18:43: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 9841112DA13 for ; Mon, 2 Apr 2018 18:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 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.249, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=DbkVSL3y; dkim=pass (1536-bit key) header.d=taugh.com header.b=wA4I7JFb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26TT1AaZLeLd for ; Mon, 2 Apr 2018 18:43:33 -0700 (PDT) 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 21178126CBF for ; Mon, 2 Apr 2018 18:43:32 -0700 (PDT) Received: (qmail 73828 invoked from network); 3 Apr 2018 01:43:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12060.5ac2dc43.k1804; bh=3f+Bqix89aSH7zfOm/4shPJHqqhAbMdAGjYidz21KTY=; b=DbkVSL3yZzKpiZIY6+pQswIkRuTN80MlaWQrARmRbbpTe4zhAOZBK8anMI23njKa8pZpfs89TnFnMcZUCnd0apw9j2m9II+YGq/Yj3ZRUQMBrE6qy8fGcsvSKDwJeo4ar05HkfoSn0CbYcXgfIm4SNP2CbZq3xd1ouPOwy6HwosXL6CRLxw4u1nmLtrZ+HVWLquOK9J9Is10CbaqqhrKv8W15uec+o7lEdEdDHgAnosXvGFUZs15xy6qU5YFJXXS DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12060.5ac2dc43.k1804; bh=3f+Bqix89aSH7zfOm/4shPJHqqhAbMdAGjYidz21KTY=; b=wA4I7JFbeWrzl4f+aZQvEOyXo/CtFy0Zev1cxLqI8VC4hAWkOLVXBk2E/0frO16ttX2fi8KPNfqogiwX8cjfzLgHPUC/3s3ZB9y0hPWtpELQkzOrPXZESo9eajdd4YKZ7YeXkINj3SVix1nIGYrw+xwxxLHDMM9H7P4TFgwrXu19UikEBvsiDIt60l+WNNLK3nl0wSv8mjyOrW2whiWqu6sgzBKJvyCXfnrYj7QL/L+t9DDgjMP5/v4QvDBTuHeE 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; 03 Apr 2018 01:43:31 -0000 Received: by ary.qy (Postfix, from userid 501) id 69782240236E; Mon, 2 Apr 2018 21:43:31 -0400 (EDT) Date: 2 Apr 2018 21:43:31 -0400 Message-Id: <20180403014331.69782240236E@ary.qy> From: "John Levine" To: dcrup@ietf.org In-Reply-To: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> 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] 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, 03 Apr 2018 01:43:35 -0000 In article <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> you write: > >If ed25519/ed448 were the *only* key types supported by DKIM in the past, >present and future, I'd gladly support a raw key format. That, however, >is not the case. However simple it might be to explicitly use ed25519 >keys in various APIs, the fact is that typically one just wants to import >*whatever* key type is published in a *generic* way, that just yields an >opaque public key object that the application library can use for verification. I'm with Scott. Whatever you're describing is not the library I'm using. Since the signatures and keys both identify the algorithm, the code already knows what algorithm it's using, and there's no reason to assume the RSA and ed25519 routines are in the same library or have the same interface. R's, John From nobody Mon Apr 2 19:26:53 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 0AD3212DA45 for ; Mon, 2 Apr 2018 19:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWV9sp4eAwSn for ; Mon, 2 Apr 2018 19:26:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B24C12DA44 for ; Mon, 2 Apr 2018 19:26:50 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id D5DB07A3309 for ; Tue, 3 Apr 2018 02:26:48 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 2 Apr 2018 22:26:35 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: dcrup@ietf.org Message-Id: <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> To: dcrup@ietf.org X-Mailer: Apple Mail (2.3445.5.20) 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, 03 Apr 2018 02:26:52 -0000 > On Apr 2, 2018, at 7:52 PM, James Cloos wrote: >=20 > That is irrelevant. Ed25519 should always and only be exchanged as = 256 bit > strings. Whether in binary or some text encoding. But always just = the key. >=20 > That is the whole point. Naturally, for ed25519/ed448 the two approaches are isomorphic under = adding or removing a fixed prefix, that (at least for these algorithms) is a = function of the algorithm name. The same isomorphism is not possible with RSA, = because RSA keys come in different sizes and an additionally encoded exponent. So for some key types (e.g. RSA) a flexible encoding is required. A = DKIM verifier should not IMHO use algorithm-spefic crypto libraries, it = should use a library that supports multiple key types, and provide a uniform signature verification interface. That way, when a new key type is introduced, you just pass the key data to the library and if the library supports the new key type, the DKIM verifier requires no code changes. Sure, if the idea is to explicitly play "ed25519" then sure, one can = publish ed25519-specific key formats, but that seems like poor long-term design = to me. The application code is more maintainable if all the verification = and key import functions are farmed out to a crypto library that adds new = key types as time goes by, without the DKIM layer needing to co-evolve and = call new APIs. Since the algorithms in question will also be used in certificates and = with CMS, they will already have SPKI forms. Inventing yet another form is = not doing anyone a favour: https://xkcd.com/927/ --=20 Viktor. From nobody Mon Apr 2 19:32:32 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 DCE1712DA46 for ; Mon, 2 Apr 2018 19:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEVcAOtCnwC4 for ; Mon, 2 Apr 2018 19:32:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8226812DA44 for ; Mon, 2 Apr 2018 19:32:29 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id C12407A3309 for ; Tue, 3 Apr 2018 02:32:28 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <20180403014331.69782240236E@ary.qy> Date: Mon, 2 Apr 2018 22:32:15 -0400 Content-Transfer-Encoding: 7bit Reply-To: dcrup@ietf.org Message-Id: <6366C1A8-5AEE-4CA5-8AF9-D8CE4292F8FB@dukhovni.org> References: <20180403014331.69782240236E@ary.qy> To: dcrup@ietf.org X-Mailer: Apple Mail (2.3445.5.20) 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, 03 Apr 2018 02:32:31 -0000 > On Apr 2, 2018, at 9:43 PM, John Levine wrote: > > Since the signatures and keys both identify the algorithm, the code > already knows what algorithm it's using, and there's no reason to > assume the RSA and ed25519 routines are in the same library or have > the same interface. Except that of course any crypto library that has not been abandoned will support an algorithm independent API for handling SPKI keys and verification, as well as PKCS8 keys and signing. Having to bring in algorithm-specific APIs looks wasteful from my POV. I guess if I ever have to write a DKIM verifier, I'll have to remember to add a non-empty prefix for ed25519 and not do it for RSA, and then call the generic routines, and of course we're bikeshedding to some extent, all these approaches work, but it sure seems odd to go out of one's way to break the abstraction. -- -- Viktor. From nobody Mon Apr 2 20:33:17 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 3048B1243F3 for ; Mon, 2 Apr 2018 20:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXC6Av01VG8k for ; Mon, 2 Apr 2018 20:33:14 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B80124234 for ; Mon, 2 Apr 2018 20:33:13 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id w6so17239736qkb.4 for ; Mon, 02 Apr 2018 20:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=NV3CohKXTed1yqyucYWb1HVb6WdKybZHM5NlQlwfR5E=; b=kx9Ia8NcVYQrV74viYuLPfz0Tin5UUMKnu60rANwY70gVCPtCG7bTBkMH4F2qoxaE6 GOdK13IjTe8f+Eyr/JxUqTBoSEd7cdgiqtO0c8U9rHI8MmRuDqKgqFLLOOM8B1ppQd5k kpuJ9xOWhNA4+Jp0xHYkfpqogd1PJuY2nKUC04wgPdELPHaGiUUfq1vpmaXfuci0J9ag QiAeamYiRA/QyyoxT1XbhJ6HSpqbuUxAA6AELKaoeTWrHUKFDRRoNBPd+/Fc+mD4NAZP EaL8gj944MBL/rpgKVsZZabiWAxPyFLxa2fWwWgkH0EkbcvWHfkR052KOo504ThBRN8G uG9A== 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=NV3CohKXTed1yqyucYWb1HVb6WdKybZHM5NlQlwfR5E=; b=UVQkMtttV2m+tKEtuTs8rYgJNzGOiCUf6g2TSiz4hOnM7APRmCOhmhSor4ECDh7k7+ eKkW7QSrB9+8h4qWCeCbviE9x/cVJ7ychDvQxHhgK66FJ+Ml16X2plLjGWxdI64BnEaL AyH4Zvikg8MgKaAwRXJK6Em0S+/FLGy8u7vUWPPKZzhGXz0q0MZlIVTsaZrZXKG9WQPB dvWamhfvBwHNU38KIqiBt8K8VlYRcLgEaCaLJVeIv6QGCVFJA4L7FghYmtGGA1dmVl7W UongU5E6JSmWgtjU0NwUiOKfFciwbVZP4mmHQee1SpS38rYsuogAxtNKG3FNM0IimCOK lZbQ== X-Gm-Message-State: ALQs6tA6qpX7P0T4wa3chG66vJqERMK2pcFh20pwmQBAcSuLOEjW+Io9 dvIa9euhBZUnMv18k5kxVCuHxGRCmOkePh8xFsQ= X-Google-Smtp-Source: AIpwx48Mod31vHmr+xBSd8gbTgKL/WCpuBzMOQ5YGpShSee6H25QGU/NPfNHgtLe/lVZLfV5BPJyN3yw8OTxTck1gAI= X-Received: by 10.55.72.79 with SMTP id v76mr16245161qka.193.1522726392648; Mon, 02 Apr 2018 20:33:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Mon, 2 Apr 2018 20:33:12 -0700 (PDT) In-Reply-To: <6366C1A8-5AEE-4CA5-8AF9-D8CE4292F8FB@dukhovni.org> References: <20180403014331.69782240236E@ary.qy> <6366C1A8-5AEE-4CA5-8AF9-D8CE4292F8FB@dukhovni.org> From: denis bider Date: Mon, 2 Apr 2018 22:33:12 -0500 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11488b12b959d00568e95d6b" 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, 03 Apr 2018 03:33:16 -0000 --001a11488b12b959d00568e95d6b Content-Type: text/plain; charset="UTF-8" Crypto++ is not abandoned and does not support such an algorithm-independent API. Windows cryptography is not abandoned and does not support such an algorithm-independent API. You are literally generalizing from one or two libraries that you are used to which I have not ever used (from code) in 20 years. On Mon, Apr 2, 2018 at 9:32 PM, Viktor Dukhovni wrote: > > > > On Apr 2, 2018, at 9:43 PM, John Levine wrote: > > > > Since the signatures and keys both identify the algorithm, the code > > already knows what algorithm it's using, and there's no reason to > > assume the RSA and ed25519 routines are in the same library or have > > the same interface. > > Except that of course any crypto library that has not been abandoned > will support an algorithm independent API for handling SPKI keys and > verification, as well as PKCS8 keys and signing. Having to bring in > algorithm-specific APIs looks wasteful from my POV. > > I guess if I ever have to write a DKIM verifier, I'll have to remember > to add a non-empty prefix for ed25519 and not do it for RSA, and then > call the generic routines, and of course we're bikeshedding to some > extent, all these approaches work, but it sure seems odd to go out > of one's way to break the abstraction. > > -- > -- > Viktor. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a11488b12b959d00568e95d6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Crypto++ is not abandoned and does not support such an alg= orithm-independent API.

Windows cryptography is not aban= doned and does not support such an algorithm-independent API.
You are literally generalizing from one or two libraries that y= ou are used to which I have not ever used (from code) in 20 years.

On Mon, Apr 2,= 2018 at 9:32 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:


> On Apr 2, 2018, at 9:43 PM, John Levine <johnl@taugh.com> wrote:
>
> Since the signatures and keys both identify the algorithm, the code > already knows what algorithm it's using, and there's no reason= to
> assume the RSA and ed25519 routines are in the same library or have > the same interface.

Except that of course any crypto library that has not been abandoned=
will support an algorithm independent API for handling SPKI keys and
verification, as well as PKCS8 keys and signing.=C2=A0 Having to bring in algorithm-specific APIs looks wasteful from my POV.

I guess if I ever have to write a DKIM verifier, I'll have to remember<= br> to add a non-empty prefix for ed25519 and not do it for RSA, and then
call the generic routines, and of course we're bikeshedding to some
extent, all these approaches work, but it sure seems odd to go out
of one's way to break the abstraction.

--
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--001a11488b12b959d00568e95d6b-- From nobody Mon Apr 2 20:41:40 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 EE1E7126D73 for ; Mon, 2 Apr 2018 20:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuTx29LnjnLr for ; Mon, 2 Apr 2018 20:41:36 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ACEE126D0C for ; Mon, 2 Apr 2018 20:41:36 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id j26so17780353qtl.11 for ; Mon, 02 Apr 2018 20:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Q17u//1t927hPeZaVLa4cAFH9UMbmRipoZYH4hYnDAA=; b=XGaYbQyxH8P8kzZgAVtMdEMib7cAP2EP5+zJiGkvT0eusj3SxHmbonHNsw6ZlqcmIj jucUfWvFTm5m5hAwZ1nb+hI+dH0bjmJCMYd0A/q8May4/0rF5Cs5jc1k3WtMRkby63PT 1o6UE/YGH7Z3WSFBIFAKpxaRd9G1YQ1YKnHbhWd3r2dw253tUhu1CT8w4UYDalBYan9y qTJ9Ljh8X78YxSzeW4/9bgAX+Fh9ECkWTCDbbicBlpkMN+9ZRymqsaNQHOShr6wT2DRw FWuC+gTDvFeEIg2i30oBGGAvBmTEvsI4o6bPEmW4KRMQPNdhCy2PrAOYSAv5Yfg6mF+N iMuw== 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=Q17u//1t927hPeZaVLa4cAFH9UMbmRipoZYH4hYnDAA=; b=QUoxu+PeKGm7XnYFOPA8+YhscH2jAMW8fd77fMxUIx7WclHF9qjytwVCl7ubElvymO P7L615MOoRpSs9VbUDx+x6//jio0dU6e8gtv7qCuG47YpaI6qQHHywL64Ih0dnFyQPHd uZJytijcu3nEcimoxABj86E5cf5Sab4DQC5z2+YHDM9CEm0YdgC3CQod+OypetK4bwXD x8f+KneZRNLjE2ws5RU+UUDQGwBct1iYjmjwyIYo9CGTa41Gdz6KgZwx0B4UIK332fHu BUQgvW7CCc1vy/1iVKFNkeiUxuDtxLvm7jSsbGEhYU+30ZIsZECGgdy/ZuQaN6pfjbuN 0YpQ== X-Gm-Message-State: ALQs6tCnt3F+aYExjlwCICdp8EMvGB1iA5LtSqoAi8s1rr2PVJLS+AEt nl+oVpoXI202bA3qmMFEAMD1yeth6kjhqSGrDLzEMw== X-Google-Smtp-Source: AIpwx4+AvyLBFd+d/GpricdmDPJsTx454zFvwkDkxKzGkC8VhcMAgTne0fKReWBr3gSUmT3REF+hRKXtnrDx8yWUF6U= X-Received: by 10.200.40.219 with SMTP id j27mr17726217qtj.331.1522726895098; Mon, 02 Apr 2018 20:41:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Mon, 2 Apr 2018 20:41:34 -0700 (PDT) In-Reply-To: <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> From: denis bider Date: Mon, 2 Apr 2018 22:41:34 -0500 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1141af38ac20070568e97bd4" 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, 03 Apr 2018 03:41:39 -0000 --001a1141af38ac20070568e97bd4 Content-Type: text/plain; charset="UTF-8" > the two approaches are isomorphic under > adding or removing a fixed prefix It's not isomorphic, though, because the idea is that you DER-encode, but BER-decode. There is only one DER-encoded ASN.1 prefix for the fixed-size 32-byte Ed25519 key. However, there are an infinite number of BER-encoded prefixes. The encoder that needs to deal with the ASN.1 library can just drop the first N bytes if it knows those bytes are DER-encoded. This is a known implementation detail. But a decoder that is receiving keys from across the internet cannot know if they are DER-encoded or BER-encoded. Therefore at least a partial ASN.1 parser needs to be implemented for the types used in the prefix encoding. On Mon, Apr 2, 2018 at 9:26 PM, Viktor Dukhovni wrote: > > > > On Apr 2, 2018, at 7:52 PM, James Cloos wrote: > > > > That is irrelevant. Ed25519 should always and only be exchanged as 256 > bit > > strings. Whether in binary or some text encoding. But always just the > key. > > > > That is the whole point. > > Naturally, for ed25519/ed448 the two approaches are isomorphic under adding > or removing a fixed prefix, that (at least for these algorithms) is a > function > of the algorithm name. The same isomorphism is not possible with RSA, > because > RSA keys come in different sizes and an additionally encoded exponent. > > So for some key types (e.g. RSA) a flexible encoding is required. A DKIM > verifier should not IMHO use algorithm-spefic crypto libraries, it should > use a library that supports multiple key types, and provide a uniform > signature verification interface. That way, when a new key type is > introduced, you just pass the key data to the library and if the library > supports the new key type, the DKIM verifier requires no code changes. > > Sure, if the idea is to explicitly play "ed25519" then sure, one can > publish > ed25519-specific key formats, but that seems like poor long-term design to > me. The application code is more maintainable if all the verification and > key import functions are farmed out to a crypto library that adds new key > types as time goes by, without the DKIM layer needing to co-evolve and call > new APIs. > > Since the algorithms in question will also be used in certificates and with > CMS, they will already have SPKI forms. Inventing yet another form is not > doing anyone a favour: https://xkcd.com/927/ > > -- > Viktor. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a1141af38ac20070568e97bd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0the two approach= es are isomorphic under
> ad= ding=C2=A0or removing a fixed prefix

It's not isomorphic, though, because the idea is t= hat you DER-encode, but BER-decode.

There is only one DE= R-encoded ASN.1 prefix for the fixed-size 32-byte Ed25519 key. However, the= re are an infinite number of BER-encoded prefixes.

The encoder that needs to deal with the ASN.1 library can just drop the fi= rst N bytes if it knows those bytes are DER-encoded. This is a known implem= entation detail.

But a decoder that is receiving k= eys from across the internet cannot know if they are DER-encoded or BER-enc= oded. Therefore at least a partial ASN.1 parser needs to be implemented for= the types used in the prefix encoding.


On Mon, Apr 2, 2018 at 9:2= 6 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:


> On Apr 2, 2018, at 7:52 PM, James Cloos <cloos@jhcloos.com> wrote:
>
> That is irrelevant.=C2=A0 Ed25519 should always and only be exchanged = as 256 bit
> strings.=C2=A0 Whether in binary or some text encoding.=C2=A0 But alwa= ys just the key.
>
> That is the whole point.

Naturally, for ed25519/ed448 the two approaches are isomorphic under= adding
or removing a fixed prefix, that (at least for these algorithms) is a funct= ion
of the algorithm name.=C2=A0 The same isomorphism is not possible with RSA,= because
RSA keys come in different sizes and an additionally encoded exponent.

So for some key types (e.g. RSA) a flexible encoding is required.=C2=A0 A D= KIM
verifier should not IMHO use algorithm-spefic crypto libraries, it should use a library that supports multiple key types, and provide a uniform
signature verification interface.=C2=A0 That way, when a new key type is introduced, you just pass the key data to the library and if the library supports the new key type, the DKIM verifier requires no code changes.

Sure, if the idea is to explicitly play "ed25519" then sure, one = can publish
ed25519-specific key formats, but that seems like poor long-term design to<= br> me.=C2=A0 The application code is more maintainable if all the verification= and
key import functions are farmed out to a crypto library that adds new key types as time goes by, without the DKIM layer needing to co-evolve and call=
new APIs.

Since the algorithms in question will also be used in certificates and with=
CMS, they will already have SPKI forms.=C2=A0 Inventing yet another form is= not
doing anyone a favour: https://xkcd.com/927/

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--001a1141af38ac20070568e97bd4-- From nobody Mon Apr 2 20:59:50 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 9592D127078 for ; Mon, 2 Apr 2018 20:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZcxzKEzKiCa for ; Mon, 2 Apr 2018 20:59:45 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC04126DD9 for ; Mon, 2 Apr 2018 20:59:45 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id s78so17256116qkl.8 for ; Mon, 02 Apr 2018 20:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=AbnSW2KYzuOncevnq5pg9O/yiDdwV97ykY4GH1ivKrc=; b=ayVST9z2XoMz4FCQC4QSKk+gPRO++T8J5snPVn14+2j793NWijcIXBHCXmMtXenJRd xA0xTUf4XScP1OPYZp50sLvf9nIvokOIt6jbED2hVa2xDPOwzhH1Ou09Wq+w/d67IPMp cVLehD5socu0DdJh7Suhm4hTzdc35xet7n0DKButpEgyakpUBEpk0ToW8oATIUD3NUSP 1oRF/MDcwcw0MC1f+hrPMR4rOaYUOloawMFSWHd4wN0rm53BVIFUd1Q2yVZOPc8CaACM rIWgCHxOplm0mXUxhJ24ADH6R5/Op3COdVwYRFCuuVhGBAifqFuDGVF+5FonRipBFe1K U1+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=AbnSW2KYzuOncevnq5pg9O/yiDdwV97ykY4GH1ivKrc=; b=lG9B0k73t3s62fg8XJ3ki4YCi8Bihlq5VGCVa8MD97MnlrTqIA/LMP6OIPnu7pBr8Z kf45/5E3Zfup2VJwe/AIJqtgRH/jWBauCC7l39cm8Gi4JXibE08ptrWl4mhotezs85yg 0sxO5gkjgWHLMYBIoeRvANhSU0yGEo75VFUw5j2Oeu2RYqGaYr/NjUZ0Fs44/QEJjqtE /9JdkXeXv/QwHkW7vm6ouqWECKbeldT17RjdYZbOSjR5ZL2frZMmcKPKBPP/cILopoCK shUucmBp7kd/ah/AAE+ZXME7h5S+id+tQC6+yLyDSHGou3VcqkqEuFu+2Ism0XJBnRTz Bf6A== X-Gm-Message-State: ALQs6tA18+6d08avBnVEwjtsW3+nJirzyV/L3VR+jZCLLdGyA64UQmm0 xVkZT9Nb7y8f3L/shbb4+2/I8/DdSAdNwZpR0oMJjg== X-Google-Smtp-Source: AIpwx4+KU536D3uE8S0bOgOD6j4V7vPic3KP4u7gZGOugwgEhoGsbkVdO+q94D72vq13HKBzdWHiA6JSmBJBDn5ZgZs= X-Received: by 10.55.66.65 with SMTP id p62mr16518581qka.74.1522727984166; Mon, 02 Apr 2018 20:59:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Mon, 2 Apr 2018 20:59:43 -0700 (PDT) In-Reply-To: References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> From: denis bider Date: Mon, 2 Apr 2018 22:59:43 -0500 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114ab6f695fdb30568e9bc4b" 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, 03 Apr 2018 03:59:49 -0000 --001a114ab6f695fdb30568e9bc4b Content-Type: text/plain; charset="UTF-8" I propose a good solution is to modify the draft as follows: 1. Keep the 32-byte Ed25519 key encoding. 2. Add a section like the following: "*Use with ASN.1 libraries* At the time of this writing, there exist popular cryptographic libraries which do not provide an easy way to import or export a 32-byte Ed25519 key. However, these libraries provide ways to import and export keys with ASN.1 wrapping. To import a 32-byte Ed25519 key into such a library, it is sufficient to prefix the key as follows: ASN.1 wrapped key = DER prefix | Ed25519 key DER prefix = "\x30\x..." To convert an exported ASN.1 wrapped key into a 32-byte Ed25519 key, it is sufficient to remove everything before the last 32 bytes of the key." On Mon, Apr 2, 2018 at 10:41 PM, denis bider wrote: > > the two approaches are isomorphic under > > adding or removing a fixed prefix > > It's not isomorphic, though, because the idea is that you DER-encode, but > BER-decode. > > There is only one DER-encoded ASN.1 prefix for the fixed-size 32-byte > Ed25519 key. However, there are an infinite number of BER-encoded prefixes. > > The encoder that needs to deal with the ASN.1 library can just drop the > first N bytes if it knows those bytes are DER-encoded. This is a known > implementation detail. > > But a decoder that is receiving keys from across the internet cannot know > if they are DER-encoded or BER-encoded. Therefore at least a partial ASN.1 > parser needs to be implemented for the types used in the prefix encoding. > > > On Mon, Apr 2, 2018 at 9:26 PM, Viktor Dukhovni > wrote: > >> >> >> > On Apr 2, 2018, at 7:52 PM, James Cloos wrote: >> > >> > That is irrelevant. Ed25519 should always and only be exchanged as 256 >> bit >> > strings. Whether in binary or some text encoding. But always just the >> key. >> > >> > That is the whole point. >> >> Naturally, for ed25519/ed448 the two approaches are isomorphic under >> adding >> or removing a fixed prefix, that (at least for these algorithms) is a >> function >> of the algorithm name. The same isomorphism is not possible with RSA, >> because >> RSA keys come in different sizes and an additionally encoded exponent. >> >> So for some key types (e.g. RSA) a flexible encoding is required. A DKIM >> verifier should not IMHO use algorithm-spefic crypto libraries, it should >> use a library that supports multiple key types, and provide a uniform >> signature verification interface. That way, when a new key type is >> introduced, you just pass the key data to the library and if the library >> supports the new key type, the DKIM verifier requires no code changes. >> >> Sure, if the idea is to explicitly play "ed25519" then sure, one can >> publish >> ed25519-specific key formats, but that seems like poor long-term design to >> me. The application code is more maintainable if all the verification and >> key import functions are farmed out to a crypto library that adds new key >> types as time goes by, without the DKIM layer needing to co-evolve and >> call >> new APIs. >> >> Since the algorithms in question will also be used in certificates and >> with >> CMS, they will already have SPKI forms. Inventing yet another form is not >> doing anyone a favour: https://xkcd.com/927/ >> >> -- >> Viktor. >> >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrup >> > > --001a114ab6f695fdb30568e9bc4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I propose a good solution is to modify the draft as follow= s:


1. Keep the 32-byte Ed25519 key encodi= ng.


2. Add a section like the follo= wing:


"Use with ASN.1 libra= ries

At the time of this writing, there exist = popular cryptographic libraries which do not provide an easy way to import = or export a 32-byte Ed25519 key. However, these libraries provide ways to i= mport and export keys with ASN.1 wrapping.

To impo= rt a 32-byte Ed25519 key into such a library, it is sufficient to prefix th= e key as follows:

=C2=A0 =C2=A0 ASN.1 wrapped key = =3D DER prefix | Ed25519 key
=C2=A0 =C2=A0 DER prefix =3D=C2=A0 "\x30\x..."

To convert an exported ASN.1 wrapped key into a 3= 2-byte Ed25519 key, it is sufficient to remove everything before the last 3= 2 bytes of the key."





On Mon, Apr 2, 2018 at 10:41 PM, denis bider <denisbider.ietf= @gmail.com> wrote:
>=C2=A0the two= approaches are isomorphic under
or removing a fixed pr= efix

It's not isomorphic, though, because the id= ea is that you DER-encode, but BER-decode.

There is only= one DER-encoded ASN.1 prefix for the fixed-size 32-byte Ed25519 key. Howev= er, there are an infinite number of BER-encoded prefixes.

The encoder that needs to deal with the ASN.1 library can just drop= the first N bytes if it knows those bytes are DER-encoded. This is a known= implementation detail.

But a decoder that is rece= iving keys from across the internet cannot know if they are DER-encoded or = BER-encoded. Therefore at least a partial ASN.1 parser needs to be implemen= ted for the types used in the prefix encoding.


On Mon, Apr 2, 2018 at 9:26 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:


> On Apr 2, 2018, at 7:52 PM, James Cloos <cloos@jhcloos.com> wrote:
>
> That is irrelevant.=C2=A0 Ed25519 should always and only be exchanged = as 256 bit
> strings.=C2=A0 Whether in binary or some text encoding.=C2=A0 But alwa= ys just the key.
>
> That is the whole point.

Naturally, for ed25519/ed448 the two approaches are isomorphic under= adding
or removing a fixed prefix, that (at least for these algorithms) is a funct= ion
of the algorithm name.=C2=A0 The same isomorphism is not possible with RSA,= because
RSA keys come in different sizes and an additionally encoded exponent.

So for some key types (e.g. RSA) a flexible encoding is required.=C2=A0 A D= KIM
verifier should not IMHO use algorithm-spefic crypto libraries, it should use a library that supports multiple key types, and provide a uniform
signature verification interface.=C2=A0 That way, when a new key type is introduced, you just pass the key data to the library and if the library supports the new key type, the DKIM verifier requires no code changes.

Sure, if the idea is to explicitly play "ed25519" then sure, one = can publish
ed25519-specific key formats, but that seems like poor long-term design to<= br> me.=C2=A0 The application code is more maintainable if all the verification= and
key import functions are farmed out to a crypto library that adds new key types as time goes by, without the DKIM layer needing to co-evolve and call=
new APIs.

Since the algorithms in question will also be used in certificates and with=
CMS, they will already have SPKI forms.=C2=A0 Inventing yet another form is= not
doing anyone a favour: https://xkcd.com/927/

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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


--001a114ab6f695fdb30568e9bc4b-- From nobody Mon Apr 2 21:35:35 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 C5B9A12DA4C for ; Mon, 2 Apr 2018 21:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fa-Qsxv8tLy for ; Mon, 2 Apr 2018 21:35:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3593D12D890 for ; Mon, 2 Apr 2018 21:35:33 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 6BBE67A3309 for ; Tue, 3 Apr 2018 04:35:31 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 3 Apr 2018 00:35:30 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: dcrup@ietf.org Message-Id: <4064B063-1313-42A9-A211-D13955A4C882@dukhovni.org> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> To: dcrup@ietf.org X-Mailer: Apple Mail (2.3445.5.20) 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, 03 Apr 2018 04:35:35 -0000 > On Apr 2, 2018, at 11:41 PM, denis bider = wrote: >=20 > It's not isomorphic, though, because the idea is that you DER-encode, = but BER-decode. >=20 > There is only one DER-encoded ASN.1 prefix for the fixed-size 32-byte = Ed25519 key. However, there are an infinite number of BER-encoded = prefixes. >=20 > The encoder that needs to deal with the ASN.1 library can just drop = the first N bytes if it knows those bytes are DER-encoded. This is a = known implementation detail. >=20 > But a decoder that is receiving keys from across the internet cannot = know if they are DER-encoded or BER-encoded. Therefore at least a = partial ASN.1 parser needs to be implemented for the types used in the = prefix encoding. IIRC SPKI is DER encoded by definition, but if I misremembered, then = this specification can require DER encoding. I've never seen BER encoded SPKI, and indeed, = for example, DANE requires DER-encoded SPKI values as input for TLSA records. --=20 Viktor. From nobody Mon Apr 2 21:36:03 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 AAAD912DA4D for ; Mon, 2 Apr 2018 21:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 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.249, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=RsEv1kHJ; dkim=pass (1536-bit key) header.d=taugh.com header.b=VRbsFU+X Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSLH_VyrX33y for ; Mon, 2 Apr 2018 21:36:00 -0700 (PDT) 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 1982512D890 for ; Mon, 2 Apr 2018 21:35:59 -0700 (PDT) Received: (qmail 6394 invoked from network); 3 Apr 2018 04:35:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=18f8.5ac304af.k1804; bh=lGSzhdVQvOKB0GMbxnmZku2979/n54IlWUu+i0FHECc=; b=RsEv1kHJPZnpEPLs276hZdWbaamUNexXafz9ePBA34cAU/tg+aMMo348sKuLeMj79tNtWSP8cIZmFJVY54Ygps494a5UyMZAWYnTcccy0LccS5dvQ2N+2W/Ycx4UbFHs2D0/9SaPlOXQAsz3L0g7nzyQUr5zFgAyj8j6C0IWPbw7VhOx4nCdlKqzo2cGQidRSAy3mH3oToA6ayyl4IsNzkr9lAk7ZXCTvZ6G2//ZMuLl7SIo+HiTRIWAOhOna3mY DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=18f8.5ac304af.k1804; bh=lGSzhdVQvOKB0GMbxnmZku2979/n54IlWUu+i0FHECc=; b=VRbsFU+XTD7AYTUiL8tXWAbM+VA09RU9YcZtSHzrbFzYi118Nb/c9sCNagvjfBS9WoLXfokZHycknTcCe77IxQmMxYgRzU5iJvZqQcDDTdrUePzUuYQgwcTOZCZ5h2TJ7YWL06EYquBwBNhOkiKsq+4OP+C8UXE8ztdiykn2Wy9F/mAwNl++8k77QRKt/p4HYhZFbfxhxYxTzcXsODSnH8tK83KVf5ao2R7adIvZQyAyCtfrTXepayFFB9KS5/Ee 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; 03 Apr 2018 04:35:58 -0000 Received: by ary.qy (Postfix, from userid 501) id 8A9702405227; Tue, 3 Apr 2018 00:35:57 -0400 (EDT) Date: 3 Apr 2018 00:35:57 -0400 Message-Id: <20180403043558.8A9702405227@ary.qy> From: "John Levine" To: dcrup@ietf.org In-Reply-To: <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> 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] 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, 03 Apr 2018 04:36:02 -0000 In article <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> you write: >So for some key types (e.g. RSA) a flexible encoding is required. A DKIM >verifier should not IMHO use algorithm-spefic crypto libraries, it should >use a library that supports multiple key types, and provide a uniform >signature verification interface. Well, that's one theory. > That way, when a new key type is >introduced, you just pass the key data to the library and if the library >supports the new key type, the DKIM verifier requires no code changes. Given that it took us a decade to introduce a new key type, and we have no plans ever to do it again since the required double signing transition is such a pain, this looks to me like a severely premature optimization, even ignoring the fact that it'd need code changes anyway to handle the new tag values in signatures and key records. This isn't TLS/SSL with pages of algorithms and interactive negotiation about which one to use. R's, John From nobody Mon Apr 2 22:09: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 7E034127871 for ; Mon, 2 Apr 2018 22:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJCuUzLvlAFg for ; Mon, 2 Apr 2018 22:09:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D59412751F for ; Mon, 2 Apr 2018 22:09:11 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 950B67A3309 for ; Tue, 3 Apr 2018 05:09:10 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <20180403043558.8A9702405227@ary.qy> Date: Tue, 3 Apr 2018 01:09:09 -0400 Content-Transfer-Encoding: 7bit Reply-To: dcrup@ietf.org Message-Id: References: <20180403043558.8A9702405227@ary.qy> To: dcrup@ietf.org X-Mailer: Apple Mail (2.3445.5.20) 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, 03 Apr 2018 05:09:13 -0000 > On Apr 3, 2018, at 12:35 AM, John Levine wrote: > > Given that it took us a decade to introduce a new key type, and we > have no plans ever to do it again since the required double signing > transition is such a pain, this looks to me like a severely premature > optimization, even ignoring the fact that it'd need code changes > anyway to handle the new tag values in signatures and key records. > This isn't TLS/SSL with pages of algorithms and interactive > negotiation about which one to use. Ever again is a long time. Though not universally anticipated, scalable universal quantum computers might require yet another new set of signature algorithms. The cost of the extra twelve bytes up front is rather modest, and this retains compatibility with a widely used general-purpose public-key format. So it seems prudent, but of course not critical. If the WG strongly feels that Ed25519 needs to be "special", so be it, but it seems needlessly different to me... -- Viktor. From nobody Tue Apr 3 02:56: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 080E212E87B for ; Tue, 3 Apr 2018 02:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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 (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfogm2S7FGC5 for ; Tue, 3 Apr 2018 02:56:03 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0C3120726 for ; Tue, 3 Apr 2018 02:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1522749361; bh=t6o8v04uaWm7p58O75mky1RtCDbn6W8g3zy4fAyPQ9s=; l=1893; h=To:References:From:Date:In-Reply-To; b=CYqL6RxIpzGvqcluHzRTBkApAfMeZtkypj6xJ+kcAkCOEsor8eAX7BGG7BD32uMQd yDT9b70opkBbFBaJIBHjRsWQ2HKwTujOdkENyXUtU5fwDBtWXsp2LOQnYnauY1EK9H FoJFC73fCiLye3JP1Q07RgV+8dAhH5hFp34Pu5Jq9ZEu3D3B5uZSg3+phGNbp Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 03 Apr 2018 11:56:00 +0200 id 00000000005DC02A.000000005AC34FB0.000009B4 To: dcrup@ietf.org, Viktor Dukhovni References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Tue, 3 Apr 2018 11:56:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> Content-Type: text/plain; charset=utf-8 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: Tue, 03 Apr 2018 09:56:05 -0000 On Tue 03/Apr/2018 04:26:35 +0200 Viktor Dukhovni wrote:  > > So for some key types (e.g. RSA) a flexible encoding is required. A DKIM > verifier should not IMHO use algorithm-spefic crypto libraries, it should > use a library that supports multiple key types, and provide a uniform > signature verification interface. That way, when a new key type is > introduced, you just pass the key data to the library and if the library > supports the new key type, the DKIM verifier requires no code changes. If that were true, the k= tag would be totally useless. The generic library used by the DKIM verifier can readily recognize what kind of key and signature are being used. Indeed, k= is OPTIONAL. Its raison d'être is to provide for future extensions without making assumptions on the syntax and semantics of p=. Because of that design, I don't believe a DKIM implementation will ever exist which can handle a new signature type with no code changes, whatever the enhancements of its underlying library functions. > Since the algorithms in question will also be used in certificates and with > CMS, they will already have SPKI forms. Inventing yet another form is not > doing anyone a favour: https://xkcd.com/927/ DKIM already did so, by getting rid of a number of pleonastic PKI features on key management. IMHO, those simplifications are part of the reasons why we currently find and verify more DKIM than S/MIME or PGP signatures. I don't understand what you mean by "SPKI". I only found a past century WG: https://datatracker.ietf.org/wg/spki/about/ And then, the only mention of ASN.1 in the two experimental RFCs associated to that WG is the following snippet: No library code should be required for the packing or parsing of SPKI certificates. In particular, ASN.1 is not to be used. https://tools.ietf.org/html/rfc2692#page-5 Ale -- From nobody Tue Apr 3 08:56: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 ACD2D129C6C for ; Tue, 3 Apr 2018 08:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSu-Mu-g49C0 for ; Tue, 3 Apr 2018 08:56:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA26812895E for ; Tue, 3 Apr 2018 08:56:29 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 110A87A3309 for ; Tue, 3 Apr 2018 15:56:28 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 3 Apr 2018 11:56:14 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: dcrup@ietf.org Message-Id: References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> To: dcrup@ietf.org X-Mailer: Apple Mail (2.3445.5.20) 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, 03 Apr 2018 15:56:34 -0000 > On Apr 3, 2018, at 5:56 AM, Alessandro Vesely wrote: >=20 >> Since the algorithms in question will also be used in certificates = and with >> CMS, they will already have SPKI forms. Inventing yet another form = is not >> doing anyone a favour: https://xkcd.com/927/ >=20 > DKIM already did so, by getting rid of a number of pleonastic PKI = features on > key management. IMHO, those simplifications are part of the reasons = why we > currently find and verify more DKIM than S/MIME or PGP signatures. Ascribing the wide use of DKIM signing to a simplified key format in DNS = is rather a reach. Indeed the present RSA key in DKIM *is* in SPKI format, and there's = little reason to *change* the format when introducing ed25519 keys. DKIM signing has caught on because it does not affect the usability of = email, requires no user interaction, and is believed to improve = deliverability and reduce phishing. The public key format has nothing = to do with that. The key difference is complete transparency to the = user, and acceptance of an insecure key delivery channel (the attacker = being thwarted sends forged emails, but does not cache poison the DNS of = the target domains). SPKI =3D=3D Subject-Public-Key-Info and is the public key element of an = X.509 certificate. This includes an algorithm OID allowing for a generic decoder that = understands all the requisite algorithm OIDs. For a signature scheme one needs a hash = algorithm id in addition to the key (SPKI). None of this is terribly important of course, I am just perplexed by the = desire to to be different here. MTAs already use libraries for TLS and perhaps = S/MIME, that support the usual key formats used with X.509 certs and DANE TLSA = records, .... Why should DKIM be different? Does that really make things better? --=20 Viktor. From nobody Tue Apr 3 14:35: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 00AC512D87A for ; Tue, 3 Apr 2018 14:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYch4zKub9Zf for ; Tue, 3 Apr 2018 14:35:43 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02F3126C2F for ; Tue, 3 Apr 2018 14:35:42 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id s9so20308919qke.12 for ; Tue, 03 Apr 2018 14:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ob55ay9+lopHsN0GiZcHaQZETRb5PZ5f1P6V8P2ur9o=; b=Ra2aGRfmZFR0rMNvZkO/pLXIzAfBDcAHAsG7hRonEvhpKaDmitR0v7XGFlEEP11/ye adJWoTQdBm6EJlSkqOaK3wC5YfSxc8SPaBXASHu1sZ7nPhAMnValRc5HncuRgK8+iGIS fAOoRvOFhQ3OFrpzD9qo9I8Wj2pfEsXcna/U4uDiiQZNWT6nkim3c5uXmi3b0KxVh59b z1/NYeDx2Yu/ZPGU3cRdwVp0R08YwBFOxTeNC/ZZ87sleAsrw5eFyL9L4TqNwT3zzjGh T7N1CPaz0/OeShJlDNyT5HfkQCTl2h1aF9VJc4dE/7bX0/BvLhl4JfT8MbLfdQwyJ6TI Mrmg== 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=ob55ay9+lopHsN0GiZcHaQZETRb5PZ5f1P6V8P2ur9o=; b=t24aofQrZcTGFj+fDGciRHusTfGK4bM25W+FFMfldrjX5lmw3kR0hD7uf/zAJc1hj5 FEf+RfkvO0a7hu/JKt8IqVe9m6qF2kojzz03JqSYYpFTZ2AJm/Ou6gU5t21t+PG9J+7B L/EjSi4NpXfBW5XrATeZ9WNfwaYN0sEp+RiGl4qt7bryAzs4sB9prvso3W1wyuFbt/q1 qmODShIkPehbhdHcidducKxM9XNx3PtuUK0Z1cIRqakuKCaiFQE62dR0YYAIT66eWU+e Iy2UvSW8+sFQjWrP/SN1IS11bJAVlM75UWuVmhTxlEMuPypUUoIp+8T3cj4LYpLfv2MF 2Dfw== X-Gm-Message-State: ALQs6tAW3DPD8QL5XatFa59cP0M4TQqE6TjFUDIuBivdBr4m63nyUyT+ 6Q4lJzkUeH5LuCtrHkDO0WX1fwyGDGq4Guxv8SCdsw== X-Google-Smtp-Source: AIpwx4/gtrDh4XwIXX3gZAe2SWvtHRHZqEjPuA8+q8QnFXQx1EvN3EpcA310gQDpM8mDhjcYEZKMC5Jj+J6dkvguxp4= X-Received: by 10.55.79.81 with SMTP id d78mr19852421qkb.20.1522791341606; Tue, 03 Apr 2018 14:35:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Tue, 3 Apr 2018 14:35:41 -0700 (PDT) In-Reply-To: References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> From: denis bider Date: Tue, 3 Apr 2018 16:35:41 -0500 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114a758efbcd1a0568f87cf9" 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, 03 Apr 2018 21:35:46 -0000 --001a114a758efbcd1a0568f87cf9 Content-Type: text/plain; charset="UTF-8" > MTAs already use libraries for TLS and perhaps S/MIME, > that support the usual key formats used with X.509 certs > and DANE TLSA records, .... To offer some insight - in my implementation, which is native Win32 (not .NET), I use Windows Schannel for TLS, which provides very limited control over the properties of the TLS connection and approximately zero access to the underlying primitives. I can configure system-wide TLS algorithm preferences via registry entries and make some broad choices using the APIs. That's about it. For DKIM, I have the following options that are easily available to me: - For RSA, I can use Windows cryptography or Crypto++. If I use Windows cryptography, I have to implement my own ASN.1 decoding because Win32 does not expose this. If I use Crypto++, it can load the ASN.1 RSA key. - For Ed25519, this is not yet offered either in Windows or Crypto++, so I pick up DJB's public domain implementation. I have to implement my own ASN.1 decoding if the key is wrapped. The bottom line is that what is true in your development environment is not true in others. The cost of implementing ASN.1 decoration in other development environments is greater than the cost to you of dropping it. On Tue, Apr 3, 2018 at 10:56 AM, Viktor Dukhovni wrote: > > > > On Apr 3, 2018, at 5:56 AM, Alessandro Vesely wrote: > > > >> Since the algorithms in question will also be used in certificates and > with > >> CMS, they will already have SPKI forms. Inventing yet another form is > not > >> doing anyone a favour: https://xkcd.com/927/ > > > > DKIM already did so, by getting rid of a number of pleonastic PKI > features on > > key management. IMHO, those simplifications are part of the reasons why > we > > currently find and verify more DKIM than S/MIME or PGP signatures. > > Ascribing the wide use of DKIM signing to a simplified key format in DNS > is rather a reach. > Indeed the present RSA key in DKIM *is* in SPKI format, and there's little > reason to *change* > the format when introducing ed25519 keys. > > DKIM signing has caught on because it does not affect the usability of > email, requires no user interaction, and is believed to improve > deliverability and reduce phishing. The public key format has nothing to > do with that. The key difference is complete transparency to the user, and > acceptance of an insecure key delivery channel (the attacker being thwarted > sends forged emails, but does not cache poison the DNS of the target > domains). > > SPKI == Subject-Public-Key-Info and is the public key element of an X.509 > certificate. > This includes an algorithm OID allowing for a generic decoder that > understands all > the requisite algorithm OIDs. For a signature scheme one needs a hash > algorithm id > in addition to the key (SPKI). > > None of this is terribly important of course, I am just perplexed by the > desire to > to be different here. MTAs already use libraries for TLS and perhaps > S/MIME, that > support the usual key formats used with X.509 certs and DANE TLSA > records, .... > Why should DKIM be different? Does that really make things better? > > -- > Viktor. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a114a758efbcd1a0568f87cf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0MTAs already use libr= aries for TLS and perhaps S/MIME,
>= ; that=C2=A0support the usual key formats= used with X.509 certs
> and= DANE TLSA records, ....

<= div>To offer some insight - in my implementation= , which is native Win32 (not .NET), I use Windows Schannel for TLS, which p= rovides very limited control over the properties of the TLS connection and = approximately zero access to the underlying primitives. I can configure sys= tem-wide TLS algorithm preferences via registry entries and make some broad= choices using the APIs. That's about it.

For DKIM, = I have the following options that are easily available to me:
<= div>
- For RSA, I can use Windows cryptography or Crypto++. If I use Window= s cryptography, I have to implement my own ASN.1 decoding because Win32 doe= s not expose this. If I use Crypto++, it can load the ASN.1 RSA key.=

- For Ed25519, this is not yet offered either in Windows or Cry= pto++, so I pick up DJB's public domain implementation. I have to imple= ment my own ASN.1 decoding if the key is wrapped.

The bot= tom line is that what is true in your development environment is not true i= n others. The cost of implementing ASN.1 decoration in other development en= vironments is greater than the cost to you of dropping it.


= On Tue, Apr 3, 2018 at 10:56 AM, Viktor Dukhovni <ietf-dane@dukhovni.= org> wrote:


> On Apr 3, 2018, at 5:56 AM, Alessandro Vesely <vesely@tana.it> wrote:
>
>> Since the algorithms in question will also be used in certificates= and with
>> CMS, they will already have SPKI forms.=C2=A0 Inventing yet anothe= r form is not
>> doing anyone a favour: https://xkcd.com/927/
>
> DKIM already did so, by getting rid of a number of pleonastic PKI feat= ures on
> key management.=C2=A0 IMHO, those simplifications are part of the reas= ons why we
> currently find and verify more DKIM than S/MIME or PGP signatures.

Ascribing the wide use of DKIM signing to a simplified key format in= DNS is rather a reach.
Indeed the present RSA key in DKIM *is* in SPKI format, and there's lit= tle reason to *change*
the format when introducing ed25519 keys.

DKIM signing has caught on because it does not affect the usability of emai= l, requires no user interaction, and is believed to improve deliverability = and reduce phishing.=C2=A0 The public key format has nothing to do with tha= t.=C2=A0 The key difference is complete transparency to the user, and accep= tance of an insecure key delivery channel (the attacker being thwarted send= s forged emails, but does not cache poison the DNS of the target domains).<= br>
SPKI =3D=3D Subject-Public-Key-Info and is the public key element of an X.5= 09 certificate.
This includes an algorithm OID allowing for a generic decoder that understa= nds all
the requisite algorithm OIDs.=C2=A0 For a signature scheme one needs a hash= algorithm id
in addition to the key (SPKI).

None of this is terribly important of course, I am just perplexed by the de= sire to
to be different here.=C2=A0 MTAs already use libraries for TLS and perhaps = S/MIME, that
support the usual key formats used with X.509 certs=C2=A0 and DANE TLSA rec= ords, ....
Why should DKIM be different?=C2=A0 Does that really make things better?
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--001a114a758efbcd1a0568f87cf9-- From nobody Tue Apr 3 14:56: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 02CF712D9FE for ; Tue, 3 Apr 2018 14:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQtYGlwYYb9A for ; Tue, 3 Apr 2018 14:56:03 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9230812D87F for ; Tue, 3 Apr 2018 14:55:17 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id D760B7A3309 for ; Tue, 3 Apr 2018 21:55:16 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 3 Apr 2018 17:55:16 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: dcrup@ietf.org Message-Id: <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> To: dcrup@ietf.org X-Mailer: Apple Mail (2.3445.5.20) 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, 03 Apr 2018 21:56:07 -0000 > On Apr 3, 2018, at 5:35 PM, denis bider = wrote: >=20 > - For RSA, I can use Windows cryptography or Crypto++. If I use = Windows cryptography, I have to implement my own ASN.1 decoding because = Win32 does not expose this. If I use Crypto++, it can load the ASN.1 RSA = key. >=20 > - For Ed25519, this is not yet offered either in Windows or Crypto++, = so I pick up DJB's public domain implementation. I have to implement my = own ASN.1 decoding if the key is wrapped. You do not need to implement ASN.1 decoding. To decode an ed25519 = DER-encoded key, just skip the first 12 bytes, these contain SEQ - 0x30 (SPKI: (alg oid [params]), key) len - 0x2a (42) SEQ - 0x30 (alg oid) -- no parameters len - 0x05 OBJ - 0x06 len - 0x03 OID - 0x2b, 0x65, 0x70 (1.3.101.112 - id-Curve25519ph) BSTR - 0x03 (bit string) len - 0x21 (33 bytes with leading 00 padding bit count) PAD - 0x00 After these 12 *fixed* bytes follows the proposed raw Ed25519 key. You don't need an ASN.1 decoder to skip these 12 bytes, though you could check that the skipped bytes are indeed: 30 2a 30 05 06 03 2b 65 70 03 21 00 as required. =09 > The bottom line is that what is true in your development environment = is not true in others. The cost of implementing ASN.1 decoration in = other development environments is greater than the cost to you of = dropping it. No ASN.1 parser is required. Prefixing the ASN.1 bits makes the key = format consistent with prior practice, and compatible with algorithm neutral = key processing. I'm just suggesting a measly 12-byte *fixed* prefix to = avoid special casing Ed25519 in a way that's unique to DKIM and deviates from practice with other contexts in which Ed25519 keys might be used (e.g. TLS, DANE, ...). The ASN.1 obstacle is a mirage. --=20 Viktor. From nobody Tue Apr 3 16:25:32 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 E893B1241FC for ; Tue, 3 Apr 2018 16:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lfD7CNjqEOU for ; Tue, 3 Apr 2018 16:25:28 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D26C1201F2 for ; Tue, 3 Apr 2018 16:25:28 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id s2so21245494qti.2 for ; Tue, 03 Apr 2018 16:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wt+WtO45ZS/0ILjXzeS1A390CXo8/fZZ7vzNoCPxMyQ=; b=tJR/4h8/om81fdh///OQ6fuZq2vj9V2TGCUnzu7096VdD/KldDqZHwoCxW0jk0fswE UQelS/aA2KBTQFxYREGisfY3jKDBrBaLqm6NkeczF9ZxnUbLcstEA8XKoevUW0SFpKaM +vO9+5girOuENmBUoI0GDZy+n0kEQl30RrMTDywD1sMANZrlQvXRR/late3xJg5GXKk/ +AtgaHdkq02cX9PPaMkT8lNzQcnVRPAZ1p4RO/L9ozkB/c+p7zluSKpbNAsOa4wMg9gd hf2idlWvDIi7cDQv1VoLrpNduUPLjsDmfZo+j/fUmwb2qYx7GUW+2WMuJlyADYDQS2Na eCjQ== 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=wt+WtO45ZS/0ILjXzeS1A390CXo8/fZZ7vzNoCPxMyQ=; b=UJt5ul+n9aEQtaacW/XWiFmGsWN3K+1xb+tYfi002mnFKhlTTQQ4RFQn3SVYrqzqPz 9dnEfTn5vb7qdELL5hVudOg1Yiq6azB4NmvSa8gO2PQVNDcrLvMu4cMECVNbGsaXE9lZ eyDlFuvupJ3mSiC0HCjdikTPvBfbgox8oDmCuDYABwXuMfM5h+lJyTLJ+/IDwM+UXbYx z8WMVTnWXM//n5GT9aovJ+Enho2Iz6ldihgwaLRIegSigox7VsbmWc1FCFc1q1zXtuqC i28rMWcALMGf55muwTWRje6cTZk2PbQ6vb5bAlXfbomvuuUJK52U+IxJvxubaVl29WXb aIXw== X-Gm-Message-State: ALQs6tD9lxZSMwUKz3+kjj24kVPCx3ESuVbnmBAAXznx9ANGP9ZfObPV kCaeYo1qRMLazcyyfELizh+46FYlt9XLyJCcMnfH6A== X-Google-Smtp-Source: AIpwx4+h2TghQPoXZ94dSyMXdhkt9zHKQ+qlClb/k1KCuvMd+loMPIjJhd3wP2Hm9alj8AW29YxGIP1EXOpMGuVm2L8= X-Received: by 10.200.38.123 with SMTP id v56mr23270483qtv.106.1522797927625; Tue, 03 Apr 2018 16:25:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Tue, 3 Apr 2018 16:25:27 -0700 (PDT) In-Reply-To: <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> From: denis bider Date: Tue, 3 Apr 2018 18:25:27 -0500 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11407ed68a76fd0568fa0557" 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, 03 Apr 2018 23:25:31 -0000 --001a11407ed68a76fd0568fa0557 Content-Type: text/plain; charset="UTF-8" > To decode an ed25519 DER-encoded key, just skip the first 12 bytes Actually, it seems the more reliable solution would be to skip everything except the last 32 bytes. That would cover situations where BER encoding was used. Someone who has to do this would then naturally ask themselves why on Earth these useless leading bytes are being sent in the first place, if they communicate no useful information. Inserting them always for the convenience of some users seems like the more questionable design choice, given that the bytes are always the same and the affected users can insert them using DKIM algorithm information. This information MUST be verified anyway to ensure the key is of same type as specified in the "k=" parameter. > Prefixing the ASN.1 bits makes the key format consistent with prior practice, Omitting the ASN.1 bits is more compatible with prior practice, if you interpret correctly that prior practice was "encode the key in the natural algorithm-specific format". ASN.1 is the natural algorithm-specific format for RSA, 32 bytes is the natural algorithm-specific format for Ed25519. DJB didn't wrap the Ed25519 key into ASN.1, and this was a conscious design choice done for a reason. You want to retroactively undo that design choice by shoehorning the design preferences of a specific library. > and compatible with algorithm neutral key processing You cannot have algorithm-neutral key processing because you MUST verify that the key is consistent with the "k=" DKIM parameter. You are trying to have the whole world insert a 12 byte prefix in front of the key because you don't want to perform a string concatenation that is only necessary for your library and only because of its ideology about how keys ought to be represented, which is NOT universal. But the ideology ATTEMPTS to be universal, as all ideologies do. On Tue, Apr 3, 2018 at 4:55 PM, Viktor Dukhovni wrote: > > > > On Apr 3, 2018, at 5:35 PM, denis bider > wrote: > > > > - For RSA, I can use Windows cryptography or Crypto++. If I use Windows > cryptography, I have to implement my own ASN.1 decoding because Win32 does > not expose this. If I use Crypto++, it can load the ASN.1 RSA key. > > > > - For Ed25519, this is not yet offered either in Windows or Crypto++, so > I pick up DJB's public domain implementation. I have to implement my own > ASN.1 decoding if the key is wrapped. > > You do not need to implement ASN.1 decoding. To decode an ed25519 > DER-encoded key, just > skip the first 12 bytes, these contain > > SEQ - 0x30 (SPKI: (alg oid [params]), key) > len - 0x2a (42) > SEQ - 0x30 (alg oid) -- no parameters > len - 0x05 > OBJ - 0x06 > len - 0x03 > OID - 0x2b, 0x65, 0x70 (1.3.101.112 - id-Curve25519ph) > BSTR - 0x03 (bit string) > len - 0x21 (33 bytes with leading 00 padding bit count) > PAD - 0x00 > > After these 12 *fixed* bytes follows the proposed raw Ed25519 key. > You don't need an ASN.1 decoder to skip these 12 bytes, though you > could check that the skipped bytes are indeed: > > 30 2a 30 05 06 03 2b 65 70 03 21 00 > > as required. > > > The bottom line is that what is true in your development environment is > not true in others. The cost of implementing ASN.1 decoration in other > development environments is greater than the cost to you of dropping it. > > No ASN.1 parser is required. Prefixing the ASN.1 bits makes the key format > consistent with prior practice, and compatible with algorithm neutral key > processing. I'm just suggesting a measly 12-byte *fixed* prefix to avoid > special casing Ed25519 in a way that's unique to DKIM and deviates from > practice with other contexts in which Ed25519 keys might be used (e.g. > TLS, DANE, ...). The ASN.1 obstacle is a mirage. > > -- > Viktor. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a11407ed68a76fd0568fa0557 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0To decode an ed25519 = DER-encoded key, just=C2=A0skip the first= 12 bytes

Actually, it seems the more reliable solution would be to skip everyt= hing except the last 32 bytes. That would cover situations where BER encodi= ng was used.

<= div>Someone who has to do this would then = naturally ask themselves why on Earth these useless leading bytes are being= sent in the first place, if they communicate no useful information.=

Inserting them always for the convenience of some u= sers seems like the more questionable design choice, given that the bytes a= re always the same and the affected users can insert them using DKIM algori= thm information. This information MUST be verified anyway to ensure the key= is of same type as specified in the "k=3D" parameter.


>=C2=A0Prefixing the ASN.1 bits makes the k= ey format=C2=A0consistent with prior prac= tice,

Omitting the ASN.1 bits is more compatible with prior prac= tice, if you interpret correctly that prior practice was "encode the k= ey in the natural algorithm-specific format". ASN.1 is the natural alg= orithm-specific format for RSA, 32 bytes is the natural algorithm-specific = format for Ed25519.

DJB didn't wrap the Ed25519 = key into ASN.1, and this was a conscious design choice done for a reason. Y= ou want to retroactively undo that design choice by shoehorning the design = preferences of a specific library.


>= ;=C2=A0and compatible with algorithm neutral key= =C2=A0processing

You cannot have algorithm-neutral key processing because you MUST= verify that the key is consistent with the "k=3D" DKIM parameter= .

You are trying to have the whole world insert a 12 byte p= refix in front of the key because you don't want to perform a string co= ncatenation that is only necessary for your library and only because of its= ideology about how keys ought to be represented, which is NOT universal. B= ut the ideology ATTEMPTS to be universal, as all ideologies do.

On Tue, Apr 3, 2018 at 4:55 PM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:


> On Apr 3, 2018, at 5:35 PM, denis bider <denisbider.ietf@gmail.com> wrote:
>
> - For RSA, I can use Windows cryptography or Crypto++. If I use Window= s cryptography, I have to implement my own ASN.1 decoding because Win32 doe= s not expose this. If I use Crypto++, it can load the ASN.1 RSA key.
>
> - For Ed25519, this is not yet offered either in Windows or Crypto++, = so I pick up DJB's public domain implementation. I have to implement my= own ASN.1 decoding if the key is wrapped.

You do not need to implement ASN.1 decoding.=C2=A0 To decode an ed25= 519 DER-encoded key, just
skip the first 12 bytes, these contain

=C2=A0 =C2=A0 =C2=A0 =C2=A0 SEQ=C2=A0 - 0x30=C2=A0 (SPKI: (alg oid [params]= ), key)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 len=C2=A0 - 0x2a=C2=A0 (42)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SEQ=C2=A0 - 0x30=C2=A0 (alg oid) -- no paramete= rs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 len=C2=A0 - 0x05
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OBJ=C2=A0 - 0x06
=C2=A0 =C2=A0 =C2=A0 =C2=A0 len=C2=A0 - 0x03
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OID=C2=A0 - 0x2b, 0x65, 0x70=C2=A0 (1.3.101.112= - id-Curve25519ph)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 BSTR - 0x03=C2=A0 (bit string)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 len=C2=A0 - 0x21=C2=A0 (33 bytes with leading 0= 0 padding bit count)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 PAD=C2=A0 - 0x00

After these 12 *fixed* bytes follows the proposed raw Ed25519 key.
You don't need an ASN.1 decoder to skip these 12 bytes, though you
could check that the skipped bytes are indeed:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 30 2a 30 05 06 03 2b 65 70 03 21 00

as required.

> The bottom line is that what is true in your development environment i= s not true in others. The cost of implementing ASN.1 decoration in other de= velopment environments is greater than the cost to you of dropping it.

No ASN.1 parser is required.=C2=A0 Prefixing the ASN.1 bits makes th= e key format
consistent with prior practice, and compatible with algorithm neutral key processing.=C2=A0 I'm just suggesting a measly 12-byte *fixed* prefix t= o avoid
special casing Ed25519 in a way that's unique to DKIM and deviates from=
practice with other contexts in which Ed25519 keys might be used (e.g.
TLS, DANE, ...).=C2=A0 The ASN.1 obstacle is a mirage.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--001a11407ed68a76fd0568fa0557-- From nobody Tue Apr 3 17:02:38 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 4019C127369 for ; Tue, 3 Apr 2018 17:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBIHTrF6LoAF for ; Tue, 3 Apr 2018 17:02:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8CFC1205F0 for ; Tue, 3 Apr 2018 17:02:35 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 70C287A3309 for ; Wed, 4 Apr 2018 00:02:34 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 3 Apr 2018 20:02:33 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: dcrup@ietf.org Message-Id: References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> To: dcrup@ietf.org X-Mailer: Apple Mail (2.3445.5.20) 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: Wed, 04 Apr 2018 00:02:37 -0000 > On Apr 3, 2018, at 7:25 PM, denis bider = wrote: >=20 > You cannot have algorithm-neutral key processing because you MUST = verify that the key is consistent with the "k=3D" DKIM parameter.. I don't find any such "MUST" language in the DKIM RFC. All that it = requires is that the "k" value in the signature header be compatible = with the public key, else the signature verification fails. There is no = explicit requirement that the public key payload match "k=3D" in the DNS = TXT record. With SPKI, one could read the key type from either the "k" = value or the "p" value, whichever is more convenient. That way, when a library is upgraded to support new key types, one can = take the "k" value as as "news" (so that's what that key type is called!) and process the = public key generically, and likewise signatures from DKIM-Signature headers that have "k" tags = that match the TXT record. At no point does the verifier need to understand the new key = type, it is just an opaque string that allows one to short-circuit signature checks early = when there's a mismatch. There's value in abstraction, you don't need to recompile the verifier = when new algorithms show up, just pass suitable self-describing data to the library and off = you go. And there's value in re-using formats widely used in other context in the same = application space. > You are trying to have the whole world insert a 12 byte prefix in = front of the key because > you don't want to perform a string concatenation No, because having uniform key formats (across algorithms) make things = more predictable for users, who can use a broader range of tools that all use the same data = representation. > that is only necessary for your library and only because of its = ideology about how keys > ought to be represented, which is NOT universal. I frankly object to the ad-hominem imputing of motives. This is = unprofessional. SPKI is used and supported by many libraries. These include: * Heimhdal's libhx509 * GnuTLS * OpenSSL's libcrypto Yes, of course I'll have no trouble prepending the bytes after writing = some code to a table of algorithm-specific prefixes, and populating it with = ed25519. But that code needlessly breaks extensibility. And yes this is not such a = big deal, I'll get over it if it has to be done, but I still think it would be a = mistake, and there's no ideology involved, just judgement based on long = experience. Novelty in formats rarely benefits the user. --=20 Viktor. From nobody Tue Apr 3 17:12:09 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 123281241F3 for ; Tue, 3 Apr 2018 17:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=O1dlDgTV; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=c5fXcusp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nES2UjJLZ-Vd for ; Tue, 3 Apr 2018 17:12:06 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98DA31205F0 for ; Tue, 3 Apr 2018 17:12:06 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1522800724; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=E1IT2RInqnLKHB8U7u/UoGsPfJETjscsNf8ir2otveY=; b=O1dlDgTV4Ve9o5/xCgxSIFvkwm1tegsJIT9Pi7Q7fyA6oZJUUZXlGENo cXdL100pdIMQt6MJaV9J3A5crPFOAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1522800724; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=E1IT2RInqnLKHB8U7u/UoGsPfJETjscsNf8ir2otveY=; b=c5fXcuspmDksT0rtnKq5YAnQNVK415niy2aX1Pg6yjEEOKxNuFAKDANk stYEpR3PM/7Z63po3WA13Fy9rfTtQB1QNb2uSb/yiCXTVTe3yOdwB7NTQa pr2F/LTcDmRdxRbQIl1Muy1xg35dbxIulch9rQ4W6Mo5YS/Slc+3fdXUEg YvJQA29mfcBy0p9em7Ik26L3Cm3MReDjGKcURtzH7Etzi6tQS90d1lyfr1 jAqbVPdyrREX01cIimm3NfORnOzsyX6r7u2286jNQsXjIZGT1C7irvoWMb 878UtfMMruujsEyYBwtRU1f5KVnYMT6opFTt2C1GOEGATim0bcJ6qw== Received: from [10.129.22.55] (mobile-166-170-35-90.mycingular.net [166.170.35.90]) (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 C8F61C401C9; Tue, 3 Apr 2018 19:12:03 -0500 (CDT) Date: Wed, 04 Apr 2018 00:11:57 +0000 In-Reply-To: References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <51EE47F2-396D-4F98-971B-C4DE6AC60B31@kitterman.com> 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: Wed, 04 Apr 2018 00:12:08 -0000 On April 4, 2018 12:02:33 AM UTC, Viktor Dukhovni wrote: > > >> On Apr 3, 2018, at 7:25 PM, denis bider >wrote: >>=20 >> You cannot have algorithm-neutral key processing because you MUST >verify that the key is consistent with the "k=3D" DKIM parameter=2E=2E > >I don't find any such "MUST" language in the DKIM RFC=2E All that it >requires is that the "k" value in the signature header be compatible >with the public key, else the signature verification fails=2E There is >no explicit requirement that the public key payload match "k=3D" in the >DNS TXT record=2E With SPKI, one could read the key type from either the >"k" value or the "p" value, whichever is more convenient=2E =2E=2E=2E To focus on this one point: If I read you correctly, your claim is that a record with RSA as the "k" v= alue and an ed25519 key isn't an error if we ASN=2E1 the ed25519 key so we = can extract the key type from the ASN=2E1 structure? Is that correct? Scott K From nobody Tue Apr 3 17:48: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 344C112D942 for ; Tue, 3 Apr 2018 17:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpMuCn_MTyZV for ; Tue, 3 Apr 2018 17:48:21 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C66112D93E for ; Tue, 3 Apr 2018 17:48:21 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 0355D7A3309 for ; Wed, 4 Apr 2018 00:48:19 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <51EE47F2-396D-4F98-971B-C4DE6AC60B31@kitterman.com> Date: Tue, 3 Apr 2018 20:48:18 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: dcrup@ietf.org Message-Id: <5992E018-74AB-42F2-94CD-F13F67AC4042@dukhovni.org> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> <51EE47F2-396D-4F98-971B-C4DE6AC60B31@kitterman.com> To: dcrup@ietf.org X-Mailer: Apple Mail (2.3445.5.20) 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: Wed, 04 Apr 2018 00:48:23 -0000 > On Apr 3, 2018, at 8:11 PM, Scott Kitterman = wrote: >=20 > If I read you correctly, your claim is that a record with RSA as the = "k" value and an ed25519 key isn't an error if we ASN.1 the ed25519 key = so we can extract the key type from the ASN.1 structure? >=20 > Is that correct? It is not explicitly proscribed by the specification. Of course an = implementation may reasonably object. What the freedom to not object gives you is the = ability to support novel "k=3D" values without modifying the code. Recall also = that "k=3Drsa" is implicit, so some users may be leaving it out, and might = forget "k=3Ded25519" (though unlikely perhaps). The key data is less likely to = lie. There is no harm if the application does not object. If the = DKIM-signature calls ed25519 "fred25519" and the TXT record does likewise, and the signature = checks out, there's no harm (just loss of interoperability with more strict = implementations). One can take the "k=3D" value as informational and the actual SPKI data = as authoritative (if SPKI form is retained going forward). This is not set in stone yet. And the issues are not so critical in the = end, but perhaps worth spending a few extra cycles to get from adequate to = good. --=20 Viktor. From nobody Tue Apr 3 17:52:17 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 3B7BD12D944 for ; Tue, 3 Apr 2018 17:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkNPW-yqhs1Q for ; Tue, 3 Apr 2018 17:52:14 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C421D12D93E for ; Tue, 3 Apr 2018 17:52:13 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id o205so20800767qke.3 for ; Tue, 03 Apr 2018 17:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=20IxgZLWkKJ+tWHurfYydFueuSMDQU/xbEpjWc9vgyQ=; b=eKrSqDfOZ4EBcCc1H5f4YN8fOlKNL/fYHRxnhV7AymH8y6WhL3pkaOMEtsYuyUpa+Z GqQJPbw9FKjaAS0Pec8cd+k7ffocAEuFfNhc+Vtxxg1p0yuZeAukt35RI+ZDZuPjx00l IB8c8Lyl/fU79+1I70rUaQvvs9k0MxsWtSRMe8SmQscByJMusFA29T8x1661lqdfG0Gx iJp38pZ6rM0eBiKMGLK/mV57XOHRLDI41y7AxKxQbIFTqqC2FGB7mLsHFKMJ+/5lunP1 fEltuO268nsFm/IYWUc9ilDHmyvVbVOS6bgSZPPg40AnKoP8JdK1HvfZWzl+jcReZJAu ruFQ== 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=20IxgZLWkKJ+tWHurfYydFueuSMDQU/xbEpjWc9vgyQ=; b=FeFCgSbolHc8KpqNRZ3e2UCEatM3pjQtzbmvqqg06BvNuPcuhAu+Midw/6eMwxW3Up H26DdN+Tu5B+PKEV3xUxLPA/F4ALHcw3yIQVvE04vNazBZOvlVLIiO5cVAKtDUSYKihq hv1itU7AC+s1spe0I6nhsZOP27mcicPs5i5/o3EaNJ9bfotojk2FsF1cEZj7aoGZCWyK XCczw37G1DZ95SC5JmnUzaiEGZcSwgIdBXCTDK9ZFs44QfFTjtD4f+20pj+cpGU7RMsa b8GfYFCmDaGwmPrPLhckHlOgnLTvFULK6mi73CC9E6pJoHX/i9KSYg96lyaIRlVLp3ya jD6Q== X-Gm-Message-State: ALQs6tCvYAtQBryeJJZJ5TX8R+ET4zmogzrvcXEnXjNj7Tsm4wKgV1u2 lBHZ4Vs7EwuHb8cncfsVs4jD1CQsdW3u3TeWikk= X-Google-Smtp-Source: AIpwx4+f7Ss6YP1AEPj1zSNYTeYG0ezMF9owH+LcTaOFT8N3dOZOpXBNj8sH5XMRfxwH9PsGLsd8UhBqaD2eTEB3nvE= X-Received: by 10.55.43.234 with SMTP id r103mr21332086qkr.37.1522803132494; Tue, 03 Apr 2018 17:52:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Tue, 3 Apr 2018 17:52:11 -0700 (PDT) In-Reply-To: References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> From: denis bider Date: Tue, 3 Apr 2018 19:52:11 -0500 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11496e50c678be0568fb3b4f" 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: Wed, 04 Apr 2018 00:52:16 -0000 --001a11496e50c678be0568fb3b4f Content-Type: text/plain; charset="UTF-8" I would think the suggestion to send the key with ASN.1 padding would make much more sense if it was accompanied with a suggestion to remove the "k=" parameter, which the ASN.1 wrapping makes unnecessary. What seems strange to me is asking for two ways for the key type to be expressed: one human readable ("k=") and then another more obscured (ASN.1) that can contain an altogether different and conflicting type of key. Your further suggestions appear to be to ignore "k=" and treat it as advisory. I find this deeply problematic. If implementations are going to do this then either "k=" needs to be removed or ASN.1 wrapping needs to be prohibited. Double signaling of algorithm type that is not actually checked for consistency is potentially exploitable if one of the algorithms becomes vulnerable, and the other doesn't. On Tue, Apr 3, 2018 at 7:02 PM, Viktor Dukhovni wrote: > > > > On Apr 3, 2018, at 7:25 PM, denis bider > wrote: > > > > You cannot have algorithm-neutral key processing because you MUST verify > that the key is consistent with the "k=" DKIM parameter.. > > I don't find any such "MUST" language in the DKIM RFC. All that it > requires is that the "k" value in the signature header be compatible with > the public key, else the signature verification fails. There is no > explicit requirement that the public key payload match "k=" in the DNS TXT > record. With SPKI, one could read the key type from either the "k" value > or the "p" value, whichever is more convenient. > > That way, when a library is upgraded to support new key types, one can > take the "k" value as > as "news" (so that's what that key type is called!) and process the public > key generically, > and likewise signatures from DKIM-Signature headers that have "k" tags > that match the TXT > record. At no point does the verifier need to understand the new key > type, it is just an > opaque string that allows one to short-circuit signature checks early when > there's a mismatch. > > There's value in abstraction, you don't need to recompile the verifier > when new algorithms > show up, just pass suitable self-describing data to the library and off > you go. And there's > value in re-using formats widely used in other context in the same > application space. > > > You are trying to have the whole world insert a 12 byte prefix in front > of the key because > > you don't want to perform a string concatenation > > No, because having uniform key formats (across algorithms) make things > more predictable for > users, who can use a broader range of tools that all use the same data > representation. > > > that is only necessary for your library and only because of its ideology > about how keys > > ought to be represented, which is NOT universal. > > I frankly object to the ad-hominem imputing of motives. This is > unprofessional. > SPKI is used and supported by many libraries. These include: > > * Heimhdal's libhx509 > * GnuTLS > * OpenSSL's libcrypto > > Yes, of course I'll have no trouble prepending the bytes after writing > some code > to a table of algorithm-specific prefixes, and populating it with > ed25519. But > that code needlessly breaks extensibility. And yes this is not such a big > deal, > I'll get over it if it has to be done, but I still think it would be a > mistake, > and there's no ideology involved, just judgement based on long experience. > Novelty in formats rarely benefits the user. > > -- > Viktor. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a11496e50c678be0568fb3b4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would think the suggestion to send the key with ASN.1 pa= dding would make much more sense if it was accompanied with a suggestion to= remove the "k=3D" parameter, which the ASN.1 wrapping makes unne= cessary.

What seems strange to me is asking for two ways= for the key type to be expressed: one human readable ("k=3D") an= d then another more obscured (ASN.1) that can contain an altogether differe= nt and conflicting type of key.

Your further sugge= stions appear to be to ignore "k=3D" and treat it as advisory. I = find this deeply problematic. If implementations are going to do this then = either "k=3D" needs to be removed or ASN.1 wrapping needs to be p= rohibited. Double signaling of algorithm type that is not actually checked = for consistency is potentially exploitable if one of the algorithms becomes= vulnerable, and the other doesn't.

On Tue, Apr 3, 2018 at 7:02 PM, Viktor Du= khovni <ietf-dane@dukhovni.org> wrote:


> On Apr 3, 2018, at 7:25 PM, denis bider <denisbider.ietf@gmail.com> wrote:
>
> You cannot have algorithm-neutral key processing because you MUST veri= fy that the key is consistent with the "k=3D" DKIM parameter..
I don't find any such "MUST" language in the DKIM RFC.=C2=A0 = All that it requires is that the "k" value in the signature heade= r be compatible with the public key, else the signature verification fails.= =C2=A0 There is no explicit requirement that the public key payload match &= quot;k=3D" in the DNS TXT record.=C2=A0 With SPKI, one could read the = key type from either the "k" value or the "p" value, wh= ichever is more convenient.

That way, when a library is upgraded to support new key types, one can take= the "k" value as
as "news" (so that's what that key type is called!) and proce= ss the public key generically,
and likewise signatures from DKIM-Signature headers that have "k"= tags that match the TXT
record.=C2=A0 At no point does the verifier need to understand the new key = type, it is just an
opaque string that allows one to short-circuit signature checks early when = there's a mismatch.

There's value in abstraction, you don't need to recompile the verif= ier when new algorithms
show up, just pass suitable self-describing data to the library and off you= go.=C2=A0 And there's
value in re-using formats widely used in other context in the same applicat= ion space.

> You are trying to have the whole world insert a 12 byte prefix in fron= t of the key because
> you don't want to perform a string concatenation

No, because having uniform key formats (across algorithms) make thin= gs more predictable for
users, who can use a broader range of tools that all use the same data repr= esentation.

> that is only necessary for your library and only because of its ideolo= gy about how keys
> ought to be represented, which is NOT universal.

I frankly object to the ad-hominem imputing of motives.=C2=A0 This i= s unprofessional.
SPKI is used and supported by many libraries.=C2=A0 These include:

=C2=A0 =C2=A0* Heimhdal's libhx509
=C2=A0 =C2=A0* GnuTLS
=C2=A0 =C2=A0* OpenSSL's libcrypto

Yes, of course I'll have no trouble prepending the bytes after writing = some code
to a table of algorithm-specific prefixes, and populating it with ed25519.= =C2=A0 But
that code needlessly breaks extensibility.=C2=A0 And yes this is not such a= big deal,
I'll get over it if it has to be done, but I still think it would be a = mistake,
and there's no ideology involved, just judgement based on long experien= ce.
Novelty in formats rarely benefits the user.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--001a11496e50c678be0568fb3b4f-- From nobody Tue Apr 3 17:56: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 9B0C5127775 for ; Tue, 3 Apr 2018 17:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ_Pb2pj7Axj for ; Tue, 3 Apr 2018 17:56:07 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAFE012D93E for ; Tue, 3 Apr 2018 17:56:06 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id c188so20809700qkg.2 for ; Tue, 03 Apr 2018 17:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=BLTVxsI+BE4WlGru4LLYV9ljDIn9rihjKP8ilZTYKHc=; b=Af6GFbutUmiQz3h7L4Y8U8F+d51pF7rRXKcXYz313vgjPNtN66e9DDnxubIkUMDqV+ h6I7031eFdKBetEIMrJOQK4/pl8Dleffh22/A+rNnjJl2E3ra/aam/XzjL1RXpMsMXAh eTul9R1ZNza1apnUPDg3hYkuwR4QhNX8OsGs2VX/G70QQ/xLszLVRs+G3rt9Swc41e1y Lxk1EFgPCJPqdH4po78gW2MqyurEeu3E3CcTLVAYFBHsyv84A3aCG59xrKqVWPJhnNqv YYxJJBBYkqVH3rWVtad326tgem90LYqEBuRdWxPy4bz8BSoQ/E0CRXeH7l54zZ1om4OQ vn0g== 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=BLTVxsI+BE4WlGru4LLYV9ljDIn9rihjKP8ilZTYKHc=; b=oB18DSfLzJNMnw3zK5MNk1MApbJobC4FxE/Q2WtuNJpjh5lLaF1nOgrb4EusXZX7d1 zw/9kSz7VGnMswSaq5IHh66tkQs0PGe0tnNwF8nsMw/1B3wRuXj4Tg5TO6hvB7nRO9vn spUXMiAhRAE0P3M3uVk9Doi5CioGJkysPkXusGIAOa4o8MgWf/6oYBLdAWOnT2ALoQ7/ KJ/ot0BSHp0wQWPctOtXbPupJHeZy3BiKFAM+CdY/nKgWsE6XtnxpEHZtaOnuZhCJb3B JhraueokMWgTlFzmZp3PjjQ5Dm29uKfINpHS8aNy0sZwSqwqlzwn2Nqjjre9auwoXipA a8fg== X-Gm-Message-State: ALQs6tCV55uiys6j81QoTn48+Xde+AtPQg9V0QJRmWmGuV5QyZyRf6LJ xivjYN4v3uPTZaseYXjrOTfyaQ7PkRjIlWsmOl4= X-Google-Smtp-Source: AIpwx48AcwFXqCADMjwZVUMibqdCG121mjASNKIGxhBW2J3r6dn7hmZhzopM/mlC05z0yB3C8mjP3PkNXBgYSsQa1hI= X-Received: by 10.55.200.151 with SMTP id t23mr22428440qkl.146.1522803365712; Tue, 03 Apr 2018 17:56:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Tue, 3 Apr 2018 17:56:05 -0700 (PDT) In-Reply-To: References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> From: denis bider Date: Tue, 3 Apr 2018 19:56:05 -0500 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1142d2daad178c0568fb49a1" 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: Wed, 04 Apr 2018 00:56:09 -0000 --001a1142d2daad178c0568fb49a1 Content-Type: text/plain; charset="UTF-8" To be clear, I favor human readable signaling of algorithm type ("k=" parameter) to ASN.1 signaling (obscured), but either is preferable to double-signaling. I find the idea that you'll just let your crypto library handle whatever non-standard algorithms also concerning. If you're doing this, it means you already have a wide open attack surface so that if an error is identified in how your crypto library handles a completely unrelated algorithm, one not used in DKIM, then DKIM becomes an exploitation vector with which your implementation can be attacked, even though the obscure algorithm is not supported or standardized in DKIM. So, yeah... I understand these principles you espouse come from experience, and I find them contrary to good security practice and deeply concerning. On Tue, Apr 3, 2018 at 7:52 PM, denis bider wrote: > I would think the suggestion to send the key with ASN.1 padding would make > much more sense if it was accompanied with a suggestion to remove the "k=" > parameter, which the ASN.1 wrapping makes unnecessary. > > What seems strange to me is asking for two ways for the key type to be > expressed: one human readable ("k=") and then another more obscured (ASN.1) > that can contain an altogether different and conflicting type of key. > > Your further suggestions appear to be to ignore "k=" and treat it as > advisory. I find this deeply problematic. If implementations are going to > do this then either "k=" needs to be removed or ASN.1 wrapping needs to be > prohibited. Double signaling of algorithm type that is not actually checked > for consistency is potentially exploitable if one of the algorithms becomes > vulnerable, and the other doesn't. > > On Tue, Apr 3, 2018 at 7:02 PM, Viktor Dukhovni > wrote: > >> >> >> > On Apr 3, 2018, at 7:25 PM, denis bider >> wrote: >> > >> > You cannot have algorithm-neutral key processing because you MUST >> verify that the key is consistent with the "k=" DKIM parameter.. >> >> I don't find any such "MUST" language in the DKIM RFC. All that it >> requires is that the "k" value in the signature header be compatible with >> the public key, else the signature verification fails. There is no >> explicit requirement that the public key payload match "k=" in the DNS TXT >> record. With SPKI, one could read the key type from either the "k" value >> or the "p" value, whichever is more convenient. >> >> That way, when a library is upgraded to support new key types, one can >> take the "k" value as >> as "news" (so that's what that key type is called!) and process the >> public key generically, >> and likewise signatures from DKIM-Signature headers that have "k" tags >> that match the TXT >> record. At no point does the verifier need to understand the new key >> type, it is just an >> opaque string that allows one to short-circuit signature checks early >> when there's a mismatch. >> >> There's value in abstraction, you don't need to recompile the verifier >> when new algorithms >> show up, just pass suitable self-describing data to the library and off >> you go. And there's >> value in re-using formats widely used in other context in the same >> application space. >> >> > You are trying to have the whole world insert a 12 byte prefix in front >> of the key because >> > you don't want to perform a string concatenation >> >> No, because having uniform key formats (across algorithms) make things >> more predictable for >> users, who can use a broader range of tools that all use the same data >> representation. >> >> > that is only necessary for your library and only because of its >> ideology about how keys >> > ought to be represented, which is NOT universal. >> >> I frankly object to the ad-hominem imputing of motives. This is >> unprofessional. >> SPKI is used and supported by many libraries. These include: >> >> * Heimhdal's libhx509 >> * GnuTLS >> * OpenSSL's libcrypto >> >> Yes, of course I'll have no trouble prepending the bytes after writing >> some code >> to a table of algorithm-specific prefixes, and populating it with >> ed25519. But >> that code needlessly breaks extensibility. And yes this is not such a >> big deal, >> I'll get over it if it has to be done, but I still think it would be a >> mistake, >> and there's no ideology involved, just judgement based on long experience. >> Novelty in formats rarely benefits the user. >> >> -- >> Viktor. >> >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrup >> > > --001a1142d2daad178c0568fb49a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To be clear, I favor human readable signaling of algorithm= type ("k=3D" parameter) to ASN.1 signaling (obscured), but eithe= r is preferable to double-signaling.

I find the idea tha= t you'll just let your crypto library handle whatever non-standard algo= rithms also concerning. If you're doing this, it means you already have= a wide open attack surface so that if an error is identified in how your c= rypto library handles a completely unrelated algorithm, one not used in DKI= M, then DKIM becomes an exploitation vector with which your implementation = can be attacked, even though the obscure algorithm is not supported or stan= dardized in DKIM.

So, yeah... I understand these p= rinciples you espouse come from experience, and I find them contrary to goo= d security practice and deeply concerning.

On Tue, Apr 3, 2018 at 7:52 PM, denis = bider <denisbider.ietf@gmail.com> wrote:
I would think the suggestion to sen= d the key with ASN.1 padding would make much more sense if it was accompani= ed with a suggestion to remove the "k=3D" parameter, which the AS= N.1 wrapping makes unnecessary.

What seems strange to me= is asking for two ways for the key type to be expressed: one human readabl= e ("k=3D") and then another more obscured (ASN.1) that can contai= n an altogether different and conflicting type of key.

=
Your further suggestions appear to be to ignore "k=3D" and t= reat it as advisory. I find this deeply problematic. If implementations are= going to do this then either "k=3D" needs to be removed or ASN.1= wrapping needs to be prohibited. Double signaling of algorithm type that i= s not actually checked for consistency is potentially exploitable if one of= the algorithms becomes vulnerable, and the other doesn't.
<= div class=3D"HOEnZb">

On Tue, Apr 3, 2018 at 7:02 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:


> On Apr 3, 2018, at 7:25 PM, denis bider <denisbider.ietf@gmail.com> wrot= e:
>
> You cannot have algorithm-neutral key processing because you MUST veri= fy that the key is consistent with the "k=3D" DKIM parameter..
I don't find any such "MUST" language in the DKIM RFC.=C2=A0 = All that it requires is that the "k" value in the signature heade= r be compatible with the public key, else the signature verification fails.= =C2=A0 There is no explicit requirement that the public key payload match &= quot;k=3D" in the DNS TXT record.=C2=A0 With SPKI, one could read the = key type from either the "k" value or the "p" value, wh= ichever is more convenient.

That way, when a library is upgraded to support new key types, one can take= the "k" value as
as "news" (so that's what that key type is called!) and proce= ss the public key generically,
and likewise signatures from DKIM-Signature headers that have "k"= tags that match the TXT
record.=C2=A0 At no point does the verifier need to understand the new key = type, it is just an
opaque string that allows one to short-circuit signature checks early when = there's a mismatch.

There's value in abstraction, you don't need to recompile the verif= ier when new algorithms
show up, just pass suitable self-describing data to the library and off you= go.=C2=A0 And there's
value in re-using formats widely used in other context in the same applicat= ion space.

> You are trying to have the whole world insert a 12 byte prefix in fron= t of the key because
> you don't want to perform a string concatenation

No, because having uniform key formats (across algorithms) make thin= gs more predictable for
users, who can use a broader range of tools that all use the same data repr= esentation.

> that is only necessary for your library and only because of its ideolo= gy about how keys
> ought to be represented, which is NOT universal.

I frankly object to the ad-hominem imputing of motives.=C2=A0 This i= s unprofessional.
SPKI is used and supported by many libraries.=C2=A0 These include:

=C2=A0 =C2=A0* Heimhdal's libhx509
=C2=A0 =C2=A0* GnuTLS
=C2=A0 =C2=A0* OpenSSL's libcrypto

Yes, of course I'll have no trouble prepending the bytes after writing = some code
to a table of algorithm-specific prefixes, and populating it with ed25519.= =C2=A0 But
that code needlessly breaks extensibility.=C2=A0 And yes this is not such a= big deal,
I'll get over it if it has to be done, but I still think it would be a = mistake,
and there's no ideology involved, just judgement based on long experien= ce.
Novelty in formats rarely benefits the user.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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


--001a1142d2daad178c0568fb49a1-- From nobody Tue Apr 3 18:01: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 C1C1512D93F for ; Tue, 3 Apr 2018 18:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 FZzWzOLWt0jV for ; Tue, 3 Apr 2018 18:01:01 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC5C127775 for ; Tue, 3 Apr 2018 18:01:00 -0700 (PDT) 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 w340vEf9027715; Wed, 4 Apr 2018 02:00:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=OOJg4/A/zHQ79X05h0OZFoasFgGurBwoJ+vrS1h8cds=; b=CgVGSrl0kl0IzAyNl1iWTex3cZ26hEi0rx9UgUp0yoGkXIPZHdWA17EKZhJ4U4AgL9Br 1fLLS+EWwBizVzM017mHv4FMJq71EOTOn2HmD7AnP08hNRUeQuA/tl1wKD03uOb/X7AY 6RGOezGxMZR0be6yVqaNh/E6OG+2Qc0NrMZ+HVPINP0+jtXLZMfs5tuDAuwHMsiXB55y 3rWRZ+BTylvWcpcHBWzpGw3cQCD9xSqdG/65M0Cvxt3lieh2rlot1bGO5pb42UJyyy58 8lnPT7uE4iWMXXAGwznZLje2pMxt90SGre6/w6TBzKGk/PN+VpVZY+aGKIQZx3+c54d6 ow== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2h42u42870-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Apr 2018 02:00:58 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3410BrI000606; Tue, 3 Apr 2018 21:00:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2h25nv4pk6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 03 Apr 2018 21:00:44 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 3 Apr 2018 21:00:44 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Tue, 3 Apr 2018 21:00:43 -0400 From: "Salz, Rich" To: denis bider , "dcrup@ietf.org" Thread-Topic: [Dcrup] ed25519 in DNS Thread-Index: AQHTysoyBQuIVyAaXkGxq4oyoJ8nq6PuJchlgABuEYCAAH2QAIAAZKYAgABe2ICAAAV4AIAAGTOAgAAKXYCAAA3egIAAAReA//++AwA= Date: Wed, 4 Apr 2018 01:00:43 +0000 Message-ID: <3F3F2215-EDBE-47DF-B8C6-8D7C37DBFC87@akamai.com> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.129] Content-Type: multipart/alternative; boundary="_000_3F3F2215EDBE47DFB8C68D7C37DBFC87akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-03_11:, , 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=612 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804040007 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-03_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=548 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804040008 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: Wed, 04 Apr 2018 01:01:03 -0000 --_000_3F3F2215EDBE47DFB8C68D7C37DBFC87akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3BlYWtpbmcgYXMgYW4gaW5kdmlkaXVhbCwgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBoYXZlIG9u bHkgb25lIHdheSBvZiBzYXlpbmcgdGhpbmdzLiAgU2luY2Ug4oCcaz3igJ0gaXMgYWxyZWFkeSB0 aGVyZSwga2V5LXdyYXBwaW5nIHNlZW1zIGVycm9yLXByb25lIHdpdGggbGl0dGxlIGdhaW4uICDi gJxXaGVuIGNvZGUgYW5kIGNvbW1lbnQgZGlzYWdyZWUsIGJvdGggYXJlIHdyb25nLuKAnQ0KDQo= --_000_3F3F2215EDBE47DFB8C68D7C37DBFC87akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlNwZWFraW5nIGFzIGFuIGluZHZpZGl1YWwsIEkgYWdyZWUgdGhhdCB3ZSBzaG91 bGQgaGF2ZSBvbmx5IG9uZSB3YXkgb2Ygc2F5aW5nIHRoaW5ncy4mbmJzcDsgU2luY2Ug4oCcaz3i gJ0gaXMgYWxyZWFkeSB0aGVyZSwga2V5LXdyYXBwaW5nIHNlZW1zIGVycm9yLXByb25lIHdpdGgg bGl0dGxlIGdhaW4uJm5ic3A7IOKAnFdoZW4gY29kZSBhbmQgY29tbWVudCBkaXNhZ3JlZSwgYm90 aCBhcmUgd3Jvbmcu4oCdPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9hPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3F3F2215EDBE47DFB8C68D7C37DBFC87akamaicom_-- From nobody Tue Apr 3 18:27:03 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 7065F12D943 for ; Tue, 3 Apr 2018 18:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3np0sMeIbIX for ; Tue, 3 Apr 2018 18:26:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B49129C6C for ; Tue, 3 Apr 2018 18:26:59 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 8BF217A3309 for ; Wed, 4 Apr 2018 01:26:58 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 3 Apr 2018 21:26:57 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: dcrup@ietf.org Message-Id: <3E33F994-28D6-48AC-A2C5-9D4EF9E4CABA@dukhovni.org> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> To: dcrup@ietf.org X-Mailer: Apple Mail (2.3445.5.20) 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: Wed, 04 Apr 2018 01:27:01 -0000 > On Apr 3, 2018, at 8:56 PM, denis bider = wrote: >=20 > I find the idea that you'll just let your crypto library handle = whatever non-standard algorithms also concerning. If you're doing this, = it means you already have a wide open attack surface so that if an error = is identified in how your crypto library handles a completely unrelated = algorithm, one not used in DKIM, then DKIM becomes an exploitation = vector with which your implementation can be attacked, even though the = obscure algorithm is not supported or standardized in DKIM. OK, it probably makes sense for some layer in the software stack to = check that the algorithm is valid for DKIM. Thus, while for TLS applications, it is OK = to delegate such details to the TLS library, since it knows what's valid for TLS, = for DKIM there is no middle-layer above the crypto library, the DKIM library needs to = know which algorithms are kosher. With that some knowledge of each supported = algorithm is unavoidable. And we lose zero code algorithm support, because the = crypto library is not a DKIM library. If so, do all DKIM implementations check when the DER bits of an RSA key = are loaded that what they got was an RSA key? Fine, drop the prefix. The user can prepend the right one for this new = key type, and ensure that the library will then load that type of key. For RSA, = it would have to check after the fact. --=20 --=20 Viktor. From nobody Tue Apr 3 18:56: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 2630E124BFA for ; Tue, 3 Apr 2018 18:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 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.249, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=bm3HCinv; dkim=pass (1536-bit key) header.d=taugh.com header.b=M+0vgSqU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTIy2Z07HSVb for ; Tue, 3 Apr 2018 18:56:09 -0700 (PDT) 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 9585B1243FE for ; Tue, 3 Apr 2018 18:56:09 -0700 (PDT) Received: (qmail 98106 invoked from network); 4 Apr 2018 01:56:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=17f38.5ac430b8.k1804; bh=VRNiz2wjZDQBnNiFyQ9MPViM1cfNFfXzzzQutZMkqtk=; b=bm3HCinv3L+yMDRpOwbP85NZYLmlwCs/H0cxI0tsczszm9wMGvPLt+m4sn2rGzP5Kr2JxRKBLhjygMUthj5aAzXmXozXoxWKv0nIjwmeLST2YfWGheTOWmZ+KSqoHGCaAzsaNFxHwtQA6KNmYlcVvpjhGYHJp+EcLucnzXeDh0OUupP6kZqK1bwdsF3kLFmTM4q7hiZWglTsLOoJYhP4ESRM0fsG5SHI3YKFMulG8ZVs58pK6RkE6yHOPD29gTNX DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=17f38.5ac430b8.k1804; bh=VRNiz2wjZDQBnNiFyQ9MPViM1cfNFfXzzzQutZMkqtk=; b=M+0vgSqU/zXZUlHb+jaJHuphuhF1p8P9R8BNO3weBFB3poZxCnsXQTFIGW+XZbZqIH9RHSYePM3XB4kvPu+N9SRVVKNOixahDhjpe7MujGTV92/nhRzO1+oA5dyZwvOlCBGpRhLuYOMriDoq5pfabnVosm7t641mC1uUxQq21bQw3qgp1gkZni2Zh9oyZnMuZMG4Xtjx8WZfKmKWptFEKIMgYita/omAB0m+qI1GO+PzRxontRwyuugOEvbJJi2v 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; 04 Apr 2018 01:56:07 -0000 Received: by ary.qy (Postfix, from userid 501) id B0795240C700; Tue, 3 Apr 2018 21:56:06 -0400 (EDT) Date: 3 Apr 2018 21:56:06 -0400 Message-Id: <20180404015607.B0795240C700@ary.qy> From: "John Levine" To: dcrup@ietf.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] 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: Wed, 04 Apr 2018 01:56:11 -0000 In article you write: >Ever again is a long time. Though not universally anticipated, scalable >universal quantum computers might require yet another new set of signature >algorithms. The cost of the extra twelve bytes up front is rather modest, ... For the umpteenth time, there is more to adding a new algorithm to DKIM than handing the key to OpenSSL, so whatever simplification you imagine this provides does not actually exist. This is not a helpful line of argument. Please stop. R's, John From nobody Tue Apr 3 19:27:33 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 ECB72126CBF for ; Tue, 3 Apr 2018 19:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Fo0oKiGZOuE for ; Tue, 3 Apr 2018 19:27:29 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615DC1243FE for ; Tue, 3 Apr 2018 19:27:29 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id g7so8777002qkm.1 for ; Tue, 03 Apr 2018 19:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=j9oqUfxXwiLFuGy2/LIpV+LVQAjkRlLIzXeMH9PXVwo=; b=EJIzJtd3ep+3puUprg2tjPgaVaUkRYvDktRtVxA7zY5hIa2c13m/cDricFpuKf/Ooy fk4ieBoKK+Ox7JdrR6EwgYCeybHcg+EgOzzyptrsnhxb/vF3YtdhmuwzyYrGsiqoSF96 mWC49b6hwl1qL0f8EDaw/UP9oZjZWXvJHccm534IHKF2Gm69w2EK2vDhHlhNmCRCI/a1 hhlht8PCZ+3zgrbuFWpQ7DjXF3tpyFMBXyrfPjAQ09FJqsfFX/Oizbwy1eiiHcU/HRfW shwMJA4T7Tb2+f2Ax0FwMZCHYKQFQYVDkbNuZL/5goZPCehGhzd7j09ln168xMWhg/Hh M1fw== 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=j9oqUfxXwiLFuGy2/LIpV+LVQAjkRlLIzXeMH9PXVwo=; b=Wy/+lszNJtpn7fQNKLmgsScxJ4u3NdE1WKVPap7ly1bwGCIIxnJTYpUXuMdBXMQpAN KMqlis9iy0+k+j/dLMHYrzqxja96CwMRbXozr9Xdt1xQm8XPqdFpKYlWuAawRBjtf/xO Dkcd07nGTnhnqODoARMbCPF1tbPTgYpoFkrdeYUxq4FQOVvvi8Xkjg7ppP3gAB0b0/JD JsmFftS/j34r5WdwwTrQ8aJKX0m2BZ3+i2aSzj6QP1NR1byAs0qTod4DpbUwfDpf/Qso NL7MAqtxxCPWzdInsR4om1I+QhhLo6awhUEdipXUgggeQRddLCf4jYplOBo4e73D/reM iMkw== X-Gm-Message-State: ALQs6tBf72iL1QgBZNNIZPeVHTroAp5fY5EIdi3RvMi7z1gTypeQrxqo X+64hvWcTb6vCsyGsxA5way4vrPBItN4bQvbuVP5CQ== X-Google-Smtp-Source: AIpwx48KQNsQM4jiaLoOSaiJ/PPeHRwIklInkhTJK1p+sbwDXj3l3Wqp1H8P4l1vwiCdPO1NC/INj6VWVtYn7AHoqG4= X-Received: by 10.55.79.81 with SMTP id d78mr20899201qkb.20.1522808847979; Tue, 03 Apr 2018 19:27:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Tue, 3 Apr 2018 19:27:27 -0700 (PDT) In-Reply-To: <3E33F994-28D6-48AC-A2C5-9D4EF9E4CABA@dukhovni.org> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> <3E33F994-28D6-48AC-A2C5-9D4EF9E4CABA@dukhovni.org> From: denis bider Date: Tue, 3 Apr 2018 21:27:27 -0500 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114a758e71d9c90568fc9088" 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: Wed, 04 Apr 2018 02:27:32 -0000 --001a114a758e71d9c90568fc9088 Content-Type: text/plain; charset="UTF-8" > If so, do all DKIM implementations check when the DER bits of an RSA > key are loaded that what they got was an RSA key? The ideal behavior would be that non-RSA code paths are prevented from being invoked. Allowing non-RSA code paths to be invoked, even while loading the key, is a security liability. However, now that this conversation has explained to me the interface exposed by OpenSSL; and the ways in which implementers might be using it; I am concerned that indeed many implementations may exist which do not make this check, and would easily swallow some completely unrelated key type that's not defined in DKIM. And perhaps not only load that key, but perhaps even validate a signature with it. Now this means that if any of those key encodings are complex, and if any bug is found in a popular crypto library related to decoding an unusual key type, this would mean a surprising number of DKIM implementations might be vulnerable. This sounds like an interesting avenue for security researchers to investigate. > Fine, drop the prefix. Thank you. :-) > For RSA, it would have to check after the fact. I would strongly suggest BEFORE the fact. Lock away access to alternate code paths that would attempt to load unsupported key types. This is a bit like wanting to support ZIP, but accidentally also supporting RAR, 7z, lzma, tar.gz and so on... Especially if some of those key types are rarely used, that increases the likelihood that the implementations have bugs. On Tue, Apr 3, 2018 at 8:26 PM, Viktor Dukhovni wrote: > > > > On Apr 3, 2018, at 8:56 PM, denis bider > wrote: > > > > I find the idea that you'll just let your crypto library handle whatever > non-standard algorithms also concerning. If you're doing this, it means you > already have a wide open attack surface so that if an error is identified > in how your crypto library handles a completely unrelated algorithm, one > not used in DKIM, then DKIM becomes an exploitation vector with which your > implementation can be attacked, even though the obscure algorithm is not > supported or standardized in DKIM. > > OK, it probably makes sense for some layer in the software stack to check > that the > algorithm is valid for DKIM. Thus, while for TLS applications, it is OK > to delegate > such details to the TLS library, since it knows what's valid for TLS, for > DKIM there > is no middle-layer above the crypto library, the DKIM library needs to > know which > algorithms are kosher. With that some knowledge of each supported > algorithm is > unavoidable. And we lose zero code algorithm support, because the crypto > library > is not a DKIM library. > > If so, do all DKIM implementations check when the DER bits of an RSA key > are loaded that > what they got was an RSA key? > > Fine, drop the prefix. The user can prepend the right one for this new > key type, > and ensure that the library will then load that type of key. For RSA, it > would > have to check after the fact. > > -- > -- > Viktor. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a114a758e71d9c90568fc9088 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0If so, do all DKIM im= plementations check when the DER bits of an RSA
> key are loaded that=C2=A0= what they got was an RSA key?

The ideal behavi= or would be that non-RSA code paths are prevented from being invoked. Allow= ing non-RSA code paths to be invoked, even while loading the key, is a secu= rity liability.

However, now that this conver= sation has explained to me the interface exposed by OpenSSL; and the ways i= n which implementers might be using it; I am concerned that indeed many imp= lementations may exist which do not make this check, and would easily swall= ow some completely unrelated key type that's not defined in DKIM. And p= erhaps not only load that key, but perhaps even validate a signature with i= t. Now this means that if any of those key encodings are complex, and if an= y bug is found in a popular crypto library related to decoding an unusual k= ey type, this would mean a surprising number of DKIM implementations might = be vulnerable. This sounds like an interesting avenue for security research= ers to investigate.

<= /span>

>=C2=A0 Fine, drop the prefix.
<= span style=3D"font-size:12.8px">
Th= ank you. :-)


>=C2=A0 For RSA, it would=C2=A0have to check after the fact.

I would strongly suggest BEFORE the fact. Lock away access to alter= nate code paths that would attempt to load unsupported key types. This is a= bit like wanting to support ZIP, but accidentally also supporting RAR, 7z,= lzma, tar.gz and so on... Especially if some of those key types are rarely= used, that increases the likelihood that the implementations have bugs.


=


On Tue, Apr 3, 2018 at 8:= 26 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:<= br>


> On Apr 3, 2018, at 8:56 PM, denis bider <denisbider.ietf@gmail.com> wrote:
>
> I find the idea that you'll just let your crypto library handle wh= atever non-standard algorithms also concerning. If you're doing this, i= t means you already have a wide open attack surface so that if an error is = identified in how your crypto library handles a completely unrelated algori= thm, one not used in DKIM, then DKIM becomes an exploitation vector with wh= ich your implementation can be attacked, even though the obscure algorithm = is not supported or standardized in DKIM.

OK, it probably makes sense for some layer in the software stack to = check that the
algorithm is valid for DKIM.=C2=A0 Thus, while for TLS applications, it is = OK to delegate
such details to the TLS library, since it knows what's valid for TLS, f= or DKIM there
is no middle-layer above the crypto library, the DKIM library needs to know= which
algorithms are kosher.=C2=A0 With that some knowledge of each supported alg= orithm is
unavoidable.=C2=A0 And we lose zero code algorithm support, because the cry= pto library
is not a DKIM library.

If so, do all DKIM implementations check when the DER bits of an RSA key ar= e loaded that
what they got was an RSA key?

Fine, drop the prefix.=C2=A0 The user can prepend the right one for this ne= w key type,
and ensure that the library will then load that type of key.=C2=A0 For RSA,= it would
have to check after the fact.

--
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--001a114a758e71d9c90568fc9088-- From nobody Wed Apr 4 01:05:58 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 6C8E7126BF3 for ; Wed, 4 Apr 2018 01:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZhPE79FvRZ6 for ; Wed, 4 Apr 2018 01:05:54 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE513120047 for ; Wed, 4 Apr 2018 01:05:53 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id F00D97A3309 for ; Wed, 4 Apr 2018 08:05:52 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 4 Apr 2018 04:05:51 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: dcrup@ietf.org Message-Id: References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> <3E33F994-28D6-48AC-A2C5-9D4EF9E4CABA@dukhovni.org> To: dcrup@ietf.org X-Mailer: Apple Mail (2.3445.5.20) 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: Wed, 04 Apr 2018 08:05:56 -0000 > On Apr 3, 2018, at 10:27 PM, denis bider = wrote: >=20 > However, now that this conversation has explained to me the interface = exposed by OpenSSL; and the ways in which implementers might be using = it; I am concerned that indeed many implementations may exist which do = not make this check, and would easily swallow some completely unrelated = key type that's not defined in DKIM. The generic SPKI decoding function in OpenSSL is d2i_PUBKEY(). There's = also d2i_RSA_PUBKEY(), which decodes an SPKI object and ensures that the = result is an RSA key. And d2i_RSAPubkey(), which decodes just the RSA key (a = sequence of the key and exponent) without the algorithm oid and (NULL) = parameters. So one can certainly use algorithm-specific functions if one so chooses. Likely DKIM implementations based on OpenSSL use d2i_RSA_PUBKEY or = equivalent, that's essentially the case with OpenDKIM which implements the = equivalent of d2i_RSA_PUBKEY() on top of d2i_PUBKEY_bio(). The same public key algorithms that could exercised via DKIM can be = found in peer certificates, so they all need to be handled correctly. = Unconstrained, the key type might be any of: DH DSA RSA RSA_PSS ECDSA Ed25519 - (signature) Ed448 - (signature) X25519 - (key exchange) X448 - (key exchange) (or GOST if that engine is loaded) These are all required to be able to handle untrusted data (a peer's = public key). --=20 Viktor. From nobody Wed Apr 4 01:39: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 636DA1270A0 for ; Wed, 4 Apr 2018 01:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B65dq5us3Wqo for ; Wed, 4 Apr 2018 01:38:58 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6999A12708C for ; Wed, 4 Apr 2018 01:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1522831136; bh=kqYK8IT8iQvmArx02IMYIesOdL0EQDfpmjmO6NlR8jk=; l=1983; h=To:References:From:Date:In-Reply-To; b=B4Bwx/w3QUKeWus/PxAuHbaWRERLymCOZXr6IBE0mM8zuwtINaHhCNh359d5n+1H2 whhZ+sY2E9Z+klArgLSVmHPi+8gGPn1e39tGBK/+KRi1Z/hkUmhmFSVFhej4Vr+vCx W5KBHYjoWSHZJmTI1kUVEvwkzUfico691iWDKPUSNDvb7L8iICubthioVwysO Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 04 Apr 2018 10:38:56 +0200 id 00000000005DC067.000000005AC48F20.00001ECD To: dcrup@ietf.org References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> <51EE47F2-396D-4F98-971B-C4DE6AC60B31@kitterman.com> <5992E018-74AB-42F2-94CD-F13F67AC4042@dukhovni.org> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <605ba2e4-35f3-0fe6-c512-ddbd19bff2ed@tana.it> Date: Wed, 4 Apr 2018 10:38:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5992E018-74AB-42F2-94CD-F13F67AC4042@dukhovni.org> Content-Type: text/plain; charset=utf-8 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: Wed, 04 Apr 2018 08:39:00 -0000 On Wed 04/Apr/2018 02:48:18 +0200 Viktor Dukhovni wrote:  >> On Apr 3, 2018, at 8:11 PM, Scott Kitterman wrote: >> >> If I read you correctly, your claim is that a record with RSA as the "k" >> value and an ed25519 key isn't an error if we ASN.1 the ed25519 key so we >> can extract the key type from the ASN.1 structure?>> >> Is that correct? > > It is not explicitly proscribed by the specification. Of course an > implementation may reasonably object. What the freedom to not object gives > you is the ability to support novel "k=" values without modifying the code. > Recall also that "k=rsa" is implicit, so some users may be leaving it out, > and might forget "k=ed25519" (though unlikely perhaps). The key data is > less likely to lie.> > There is no harm if the application does not object. If the DKIM-signature > calls ed25519 "fred25519" and the TXT record does likewise, and the > signature checks out, there's no harm (just loss of interoperability with > more strict implementations). One can take the "k=" value as informational > and the actual SPKI data as authoritative (if SPKI form is retained going > forward).> > This is not set in stone yet. And the issues are not so critical in the > end, but perhaps worth spending a few extra cycles to get from adequate to > good. Assuming that coding a key-type-agnostic DKIM verifier is feasible, the benefit of adding those 12 byte SPKI prefix is lost if a future key type will introduce a different semantic rather than follow the preceding types. Now, to silently follow unwritten conventions is not a good practice for an SDO, so I think we can all agree on one point: Mandating SPKI format for ed 25519 makes no sense unless the ID also updates the descriptions of tags k= and p= so as to explicitly state SPKI usage and role. For example, the ID could say that the content of p= establishes the actual key type, and that k= is obsolete. Ale -- From nobody Thu Apr 5 13:13:10 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 6564C12E8B1 for ; Thu, 5 Apr 2018 13:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YBTO-nHBkQA for ; Thu, 5 Apr 2018 13:13:04 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BA812EAD6 for ; Thu, 5 Apr 2018 13:12:50 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id x4so10494713wmh.5 for ; Thu, 05 Apr 2018 13:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YqsykhbCd1ic6M5iOJb+XySvK6AXdAxE8ccAFYKs8ds=; b=uPaj4bjPUxFdJyfFMeD2JvdP9KVsxMHGKiZ4Om+8AqCsF7GoFfG1Pv0E1ojTsM7eWR ymXHIRJ6d2rkCwL8VWbZx/tN8TufIG68mXzU6jnbhy2NqPuaBjELFbp0wtGFmObMjse7 s+ATBjdzO0gLwWM5NCRg3CKTlblatdMklTIb3VASCJ59Zk0FZZlsaeI7DKPF+jTVFhBi evLOSue0xqJNn+8TMtj8T7KmPfvQk28LS5iLdApEPydlr3vxjspWZsq+0ajNhOvB+Mqx /8gT+JMpoQoYxKcpH7rEC5aYs9mlXsS5Y+KpxYIkyY1cUqi9cBYYOC0PuRGWFPI7ROhB A5Lw== 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=YqsykhbCd1ic6M5iOJb+XySvK6AXdAxE8ccAFYKs8ds=; b=hpqlMVqweF9UBAA2buUowajT0p+25KCNq4ErEkD+V2qICbxbY5uwhCH76YohIK04Op K+Y5GoCoVwN1X7fwmCBSK/XNTNytfvbG0Jd7l4/AWy7p91z4kUtcGMqyx9aCuINNWn1i hKDHZuUJobQnkj2n/xoXGYDbxmqBHVs9zJlUu2QZbkuv5kLk8uz5CXP2EQRd4DxWEagc g18Xd//BJ7uQgz2yZ6+5kYDIo+s0/LFC+tLSG1tc3BXYCJDatlPdd+UYBTe/ekyESB12 PCT78JH1petPBwRcnPFJfzycQUxaWtpSFutler8rzZe6nhguMiP9bg9T3C3/p5w8Z9WH /t8g== X-Gm-Message-State: ALQs6tAvknvGx7ZF+k6ftDAAFKDaikA6bb66Hmpdyp/PzOEdkQ/7FjZD U2lQG28hxKzM2R0cWQ2TORyfu84zfY1PSfWPGo4R9g== X-Google-Smtp-Source: AIpwx48v2qTTRICo5AHAe7v9cBS5ixkk+VfnC4NAQYAYp0z2p0TEZBXuPTzSsSYPEFxgZ2zrj0/Z1M2ql+3eeulaH3Y= X-Received: by 10.46.99.93 with SMTP id x90mr15104717ljb.2.1522959168561; Thu, 05 Apr 2018 13:12:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.115.7 with HTTP; Thu, 5 Apr 2018 13:12:47 -0700 (PDT) In-Reply-To: <20180404015607.B0795240C700@ary.qy> References: <20180404015607.B0795240C700@ary.qy> From: "Murray S. Kucherawy" Date: Thu, 5 Apr 2018 13:12:47 -0700 Message-ID: To: John Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114a55f43fe75f05691f9011" 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: Thu, 05 Apr 2018 20:13:09 -0000 --001a114a55f43fe75f05691f9011 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 3, 2018 at 6:56 PM, John Levine wrote: > In article you write: > >Ever again is a long time. Though not universally anticipated, scalable > >universal quantum computers might require yet another new set of signature > >algorithms. The cost of the extra twelve bytes up front is rather > modest, ... > > For the umpteenth time, there is more to adding a new algorithm to > DKIM than handing the key to OpenSSL, so whatever simplification you > imagine this provides does not actually exist. This is not a helpful > line of argument. Please stop. > I disagree. We can guess all we like about how soon it will be before another change like this will be needed, but we are notoriously bad at making such predictions and would rather not dismiss the notion out of hand. -MSK --001a114a55f43fe75f05691f9011 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 3, 2018 at 6:56 PM, John Levine <johnl@taugh.co= m> wrote:
In article <E4163395-92D= 0-4EDB-8693-6D9D5A224A79@dukhovni.org> you write:
>Ever again is a long time.=C2=A0 Though not universally anticipated, sc= alable
>universal quantum computers might require yet another new set of signat= ure
>algorithms.=C2=A0 The cost of the extra twelve bytes up front is= rather modest, ...

For the umpteenth time, there is more to adding a new algorithm to
DKIM than handing the key to OpenSSL, so whatever simplification you
imagine this provides does not actually exist.=C2=A0 This is not a helpful<= br> line of argument.=C2=A0 Please stop.

I disagree.=C2=A0 = We can guess all we like about how soon it will be before another change li= ke this will be needed, but we are notoriously bad at making such predictio= ns and would rather not dismiss the notion out of hand.

-MSK
--001a114a55f43fe75f05691f9011-- From nobody Thu Apr 5 13:20:09 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 DA92F12D778 for ; Thu, 5 Apr 2018 13:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLdR7CQPOGeu for ; Thu, 5 Apr 2018 13:20:06 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09F51200B9 for ; Thu, 5 Apr 2018 13:20:05 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id u189so8811442wmd.1 for ; Thu, 05 Apr 2018 13:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=9onuhekjaMdkHRT25CPIOMFnIQlI/tgGNRao/VnC7Ok=; b=HWBHeXkNP1338AyJ2MTijedxCbumgT8wq5Lko+m0mm0I5/Kwqu0ql8i9ThEWKwo9W5 IcgTUNgtWNeqoDpqHgUP2zoQkikrXBocBDVDlOIbKpmIXsVMCWxb4KsalRE9Nux2bW0G dn1CBpfXJUl5isy1hwkKCfOMePIp4/EtUSaM1T0fE2sZwZNGcyv+K8iMv9j8YfZawUy5 0lpzICYHKZYi73kdt3K2jSD7Zm6wBHErhBnlinCVdaUR0BMblaScTeiovhxmmj/qMEfp vt31OoY8bvO7G7IrYdaR4Tg0de1VcU3+8ty6SXyqdtbdZesHWCbUGGDP8UhPfOF68tIu +mGw== 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=9onuhekjaMdkHRT25CPIOMFnIQlI/tgGNRao/VnC7Ok=; b=S9rTwg5b/b6Bw8na7y6xLUuhoDBUs9OsRjimwFYuwWbESiUVQmXzp8NmzF1kWbKVQM 5wdLac5Vn3ZzmiI97tS81DsTd6Ewan5JxyLH5UmrLJC9Pj19/u3rmqLHX9NHepzDo0u9 +Xfg1SkKO9bwJ4/BarXuO3Izut0hqIJYDzaAeUu5TrV4v/QVpiQzdUdq3tUu7xBx209e QqGIp3jNg44yW3YdXMulwVLZo35lPoWFutHR/dG1hyOVDTpNEytxq7ptYrOxNdCFRVAq 8da+GBWQyhnhGJkP6zTtCZLB3IKhlig6Rp1NBmTrJeoqc3nRvMygnHCn17mfeMtwa63X +6zg== X-Gm-Message-State: ALQs6tDKteptVoLtFZb2FT7fHentl8a2uL0mdatfJfQBBqX8t0nk0kF3 Z0/wupFXqX6i5KWo8TuztSd3Dzx66a2v5XXrGJsZlxVz X-Google-Smtp-Source: AIpwx4+KqbepTNbKP0fvs1WOFYp2iz0KAZcYF/hzhP0A2taauts9ZG/ZPKneSZ4R4/GYRhiq9EXkCExjYI0ePxzalsk= X-Received: by 10.46.23.70 with SMTP id l67mr14533607lje.132.1522959603773; Thu, 05 Apr 2018 13:20:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.115.7 with HTTP; Thu, 5 Apr 2018 13:20:02 -0700 (PDT) In-Reply-To: <3E33F994-28D6-48AC-A2C5-9D4EF9E4CABA@dukhovni.org> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> <3E33F994-28D6-48AC-A2C5-9D4EF9E4CABA@dukhovni.org> From: "Murray S. Kucherawy" Date: Thu, 5 Apr 2018 13:20:02 -0700 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114af28a30bac805691faafe" 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: Thu, 05 Apr 2018 20:20:08 -0000 --001a114af28a30bac805691faafe Content-Type: text/plain; charset="UTF-8" On Tue, Apr 3, 2018 at 6:26 PM, Viktor Dukhovni wrote: > > On Apr 3, 2018, at 8:56 PM, denis bider > wrote: > > I find the idea that you'll just let your crypto library handle whatever > non-standard algorithms also concerning. If you're doing this, it means you > already have a wide open attack surface so that if an error is identified > in how your crypto library handles a completely unrelated algorithm, one > not used in DKIM, then DKIM becomes an exploitation vector with which your > implementation can be attacked, even though the obscure algorithm is not > supported or standardized in DKIM. > I agree that implementations should be confirming what they read in, e.g., the key type, if the key import function is generic in nature. My implementation allows selection between OpenSSL and GNUTLS. For OpenSSL, yes, I'm going to have to make different calls for different kinds of keys here, which I think is an unfortunate choice but it does seem that the consensus is to do just that. I haven't tried this yet for GNUTLS so I don't know if it's the same story over there. I suppose you could make the argument that this is pressure we should be applying on those library providers to provide generic access to keys via a single function and have the import logic split live in there. > OK, it probably makes sense for some layer in the software stack to check > that the > algorithm is valid for DKIM. Thus, while for TLS applications, it is OK > to delegate > such details to the TLS library, since it knows what's valid for TLS, for > DKIM there > is no middle-layer above the crypto library, the DKIM library needs to > know which > algorithms are kosher. With that some knowledge of each supported > algorithm is > unavoidable. And we lose zero code algorithm support, because the crypto > library > is not a DKIM library. > > If so, do all DKIM implementations check when the DER bits of an RSA key > are loaded that > what they got was an RSA key? > Presumably RSA_verify() will fail somehow if what you give it as the public key isn't actually an RSA key, assuming that's the interface you use and you got that far in the first place. An earlier call to EVP_PKEY_get1_RSA() would probably also fail. -MSK --001a114af28a30bac805691faafe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 3, 2018 at 6:26 PM, Viktor Dukhovni <ie= tf-dane@dukhovni.org> wrote:
= > On Apr 3, 2018, at 8:56 PM, denis bider <denisbider.ietf@gmail.com>= wrote:
> I find the idea that you'll just let your crypto library handle wh= atever non-standard algorithms also concerning. If you're doing this, i= t means you already have a wide open attack surface so that if an error is = identified in how your crypto library handles a completely unrelated algori= thm, one not used in DKIM, then DKIM becomes an exploitation vector with wh= ich your implementation can be attacked, even though the obscure algorithm = is not supported or standardized in DKIM.

<= /div>
I agree that implementations should be confirming what they read = in, e.g., the key type, if the key import function is generic in nature.
My implementation allows selection between OpenSSL and GNUT= LS.=C2=A0 For OpenSSL, yes, I'm going to have to make different calls f= or different kinds of keys here, which I think is an unfortunate choice but= it does seem that the consensus is to do just that.=C2=A0 I haven't tr= ied this yet for GNUTLS so I don't know if it's the same story over= there.

I suppose you could make the argument that this i= s pressure we should be applying on those library providers to provide gene= ric access to keys via a single function and have the import logic split li= ve in there.
=C2=A0
OK, it probably makes sense for some layer in the software stack to = check that the
algorithm is valid for DKIM.=C2=A0 Thus, while for TLS applications, it is = OK to delegate
such details to the TLS library, since it knows what's valid for TLS, f= or DKIM there
is no middle-layer above the crypto library, the DKIM library needs to know= which
algorithms are kosher.=C2=A0 With that some knowledge of each supported alg= orithm is
unavoidable.=C2=A0 And we lose zero code algorithm support, because the cry= pto library
is not a DKIM library.

If so, do all DKIM implementations check when the DER bits of an RSA key ar= e loaded that
what they got was an RSA key?

Presumabl= y RSA_verify() will fail somehow if what you give it as the public key isn&= #39;t actually an RSA key, assuming that's the interface you use and yo= u got that far in the first place.=C2=A0 An earlier call to EVP_PKEY_get1_R= SA() would probably also fail.

-MSK
--001a114af28a30bac805691faafe-- From nobody Thu Apr 5 13:25: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 E366812D779 for ; Thu, 5 Apr 2018 13:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeyTVLnDgQCU for ; Thu, 5 Apr 2018 13:24:57 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF131200B9 for ; Thu, 5 Apr 2018 13:24:56 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id x82so10672900wmg.1 for ; Thu, 05 Apr 2018 13:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cjyn1creQj78CsPQgMFoOsFlSz9AKWpSJ6O7QnEG9oc=; b=Uz8qaO/dHwP86NNM+GCEcN5Dwq+Hd5NZRZHVaLen6r0KimYFaobZiW4zztEVzPpI9y L9LjbHSg2sTHkyo4fStJn2XKxIq2sodA6ARIdI8v1rRZa5dAt4lrMzauOwkoEMBOVLIn etICk79yNf82sfQ8TmVYZqtI7uq9jxQPf6B/SiwI4XeW1kmkILlFxog3i2lT03s6ESLw BDIg/rx72ngTFhiI8GgFfINOF+kRhGFHMmo+lrLnGpJbb12cDq8uraY0cgM0YnCIyqX8 12l7LIhpCP/cg7OaVN9co/OgC6ZXkUcGBSH4djCu9yMQS3pJbGqXxDjsmZMJC7Ei2T7U nRSw== 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=cjyn1creQj78CsPQgMFoOsFlSz9AKWpSJ6O7QnEG9oc=; b=m1K5DGe1wk0sGFKB0wt1HfAr12dxQMNgcEedxEbnb58+hH476bFUpHaHT3mlWp78Qf D4rmhmZ+VvOq2GhWwGnditvwgOms0iiPy8vXyIp4Hk+pWADk2/Roef7X2TNcnOrbJQee YbGj5LU/FeAQi0hhVlZWZE6UFy5LUET2UXU9dmXZWz7ksiAvVGLtxTJuAk8GkpxUJTq7 z7FkyfvFNIROcwBikv+8ElSrigG/ljhKMqOCWBhudxmDjcDn8T40CKnbk72/aAfO7Ht/ 94jYzLEtbE+p8o+enHjqHEEilPp+iFCrkUfOJvRr+cxEgDcQ8LIqTeJT6U+/D8CvBkHw KdlQ== X-Gm-Message-State: ALQs6tBQ5C5giaHBShYO+LavX67X+EguW5d6uLUww5AGIwjJHbrV2kjj tcThWCpy3hoqp2tJfmzQ0hEyN8VRX9wMnC7Fh9Y/0Q== X-Google-Smtp-Source: AIpwx4/CW6FdgY029DeS5v4vViLi8I5tQzTK6D1WXvPCk6Ma+kXJUq2DdGEKUsw+oZOnhVMkYiSs2TN6z2v38llTLAM= X-Received: by 10.46.41.156 with SMTP id p28mr14870838ljp.32.1522959895310; Thu, 05 Apr 2018 13:24:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.115.7 with HTTP; Thu, 5 Apr 2018 13:24:54 -0700 (PDT) In-Reply-To: References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> From: "Murray S. Kucherawy" Date: Thu, 5 Apr 2018 13:24:54 -0700 Message-ID: To: denis bider Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114b5bb891342805691fbbb3" 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: Thu, 05 Apr 2018 20:24:59 -0000 --001a114b5bb891342805691fbbb3 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 3, 2018 at 4:25 PM, denis bider wrote: > > To decode an ed25519 DER-encoded key, just skip the first 12 bytes > > Actually, it seems the more reliable solution would be to skip everything > except the last 32 bytes. That would cover situations where BER encoding > was used. > That means now I have to understand DER encoding, rather than invoking a generic function that does all that for me. That's what I was hoping to avoid. I would be very happy to hand a base64 blob to one function and it hands me back a key object that I can then inspect (to get type, size, whatever) or use as needed. The proposal here prevents that sort of convenience from existing, unless the library intends to provide that switching somehow. But unless the logic in that library specifically says "any 32-byte blob is assumed to be an ED25519 key", I don't see how that's possible. It needs a hint at least. -MSK --001a114b5bb891342805691fbbb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 3, 2018 at 4:25 PM, denis bider <deni= sbider.ietf@gmail.com> wrote:
<= div class=3D"gmail_quote">
<= span class=3D"">>=C2=A0To decode an ed25519 D= ER-encoded key, just=C2=A0skip the first = 12 bytes

Actually, it seems the more reliable solution would be to skip= everything except the last 32 bytes. That would cover situations where BER= encoding was used.

That= means now I have to understand DER encoding, rather than invoking a generi= c function that does all that for me.=C2=A0 That's what I was hoping to= avoid.

I would be very happy to hand a base64 blob to on= e function and it hands me back a key object that I can then inspect (to ge= t type, size, whatever) or use as needed.=C2=A0 The proposal here prevents = that sort of convenience from existing, unless the library intends to provi= de that switching somehow.=C2=A0 But unless the logic in that library speci= fically says "any 32-byte blob is assumed to be an ED25519 key", = I don't see how that's possible.=C2=A0 It needs a hint at least.

-MSK
--001a114b5bb891342805691fbbb3-- From nobody Thu Apr 5 13:28:41 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 7ED7D1200B9 for ; Thu, 5 Apr 2018 13:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cucw3-yhNnb2 for ; Thu, 5 Apr 2018 13:28:37 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FE812D77B for ; Thu, 5 Apr 2018 13:28:31 -0700 (PDT) Received: from [10.200.17.69] (unknown [38.27.161.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 551507A330D for ; Thu, 5 Apr 2018 20:28:30 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 5 Apr 2018 16:28:29 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: dcrup@ietf.org Message-Id: References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> To: dcrup@ietf.org X-Mailer: Apple Mail (2.3445.5.20) 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: Thu, 05 Apr 2018 20:28:39 -0000 > On Apr 5, 2018, at 4:24 PM, Murray S. Kucherawy = wrote: >=20 > I would be very happy to hand a base64 blob to one function and it = hands me back a key object that I can then inspect (to get type, size, = whatever) or use as needed. The proposal here prevents that sort of = convenience from existing, unless the library intends to provide that = switching somehow. But unless the logic in that library specifically = says "any 32-byte blob is assumed to be an ED25519 key", I don't see how = that's possible. It needs a hint at least. I've admitted my error, and now support the short raw key. You can = decode via the generic d2i_PUBKEY and be sure you'll get the right key type, by prefixing the correct 12 byte = DER header to the raw key. When you prepend DER that carries the Ed25519 OID, the parsed key is sure to = be an Ed25519 key. --=20 Viktor. From nobody Thu Apr 5 13:29: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 D57A81200B9 for ; Thu, 5 Apr 2018 13:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSmamiraigNm for ; Thu, 5 Apr 2018 13:29:26 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B10F12D77D for ; Thu, 5 Apr 2018 13:29:24 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id u46so30504358wrc.11 for ; Thu, 05 Apr 2018 13:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/W2M4xDp+8BrmmMCqtPIGoflGcZOmBpC3szb2F4XDuQ=; b=DzfMUAdAu5+nXvi9HHzcOuBKVSdqnxGRZ5dcHHciCC7Xsw5AJi/B1M2cdeXPXDhfYq sGGlMhc/uO3D/Vp9L+3rr2TNHR5NhGdbqRh8oVOJfN7AsA/m9LetoRTVBVBstkMPyDDF dwHkMJKw5ScEV6/wX+HiUgHCSP3wKJ2TM7RFgYcqInFNkFTtsKkaWSl0OHQVreSlmbom njxgoG1etA9q3v2t45S2cS7ssZ/H5syCgF9997VIDQXmYqJyZaVTTG2KbyJQXyGtmfSc clfWkLvyCCLIWu1ecH6r1CoQ2TFyqfjPsW9qJ4ohanPPJ/kerfiP+B0ZDBQ4FGpvFXxS LKfA== 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=/W2M4xDp+8BrmmMCqtPIGoflGcZOmBpC3szb2F4XDuQ=; b=ddQbe1off9QK0m4M3ELP+HJEemHJYXUDe3bYi0XlTXnXji1N0RJqLXyMfpU5BQAtB7 po97Jy3rqwPefWRzLmvXyClTszHVQ8MzZNH5W+wtzPpYSakEDFF2oiSoowRRWw/DKP7+ jCW5uGhIlK3nG7W/K+Ktqh09lL1pq1/3AqEYeiNxj8MObAl3HjDQtjI6ohu+BSgYUbUN 8sJ7EfhbnZwzHW3oYuhGfnBjZXR9lgXMDWJhrFosaAgNef1GkmxpuQ9QuW6y6CbaNv/9 e+VRe7RdxXWAieilofJFshfRU/PZ/SMlRc6SQY5lupvyy3VJy9n/qxzu3GfBNUv1sdOj D9eQ== X-Gm-Message-State: ALQs6tDoSxM+gfl4icTLuP7JkTYrJniNcdFHI4+x535fyWi1Woo3oGTd zyTUPUM65EvQIa78KnKH7KfI8x2q9EhQ/Rz+Ze7sWQ== X-Google-Smtp-Source: AIpwx4+wp3mqj2zDa4ZycfN3uZydGGgXgEc39ipAzbp94316UZ2rUYNEGlxMFpmiCJ8BCXtgZmUYNOOKBPmJrpM8zFk= X-Received: by 2002:a19:5317:: with SMTP id h23-v6mr13587045lfb.6.1522960162851; Thu, 05 Apr 2018 13:29:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.115.7 with HTTP; Thu, 5 Apr 2018 13:29:22 -0700 (PDT) In-Reply-To: <51EE47F2-396D-4F98-971B-C4DE6AC60B31@kitterman.com> References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> <51EE47F2-396D-4F98-971B-C4DE6AC60B31@kitterman.com> From: "Murray S. Kucherawy" Date: Thu, 5 Apr 2018 13:29:22 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="00000000000083901905691fcb6f" 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: Thu, 05 Apr 2018 20:29:28 -0000 --00000000000083901905691fcb6f Content-Type: text/plain; charset="UTF-8" On Tue, Apr 3, 2018 at 5:11 PM, Scott Kitterman wrote: > To focus on this one point: > > If I read you correctly, your claim is that a record with RSA as the "k" > value and an ed25519 key isn't an error if we ASN.1 the ed25519 key so we > can extract the key type from the ASN.1 structure? > > Is that correct? > It's more like: - the signature says "a=ed25519-sha256" - they public key retrieved from the DNS is - is decoded and handed to a key import function provided by a crypto library - key import function gives me a key object - we can then confirm what type of key that was and match it against what's in the "a" value In my ideal world, the key import function in the third step can import either kind of key and then tell me what type it is. In the world you prefer, the switching logic lives in the DKIM implementation, and so the last step isn't necessary because the DKIM implementation already knows the answer. In my ideal world, the bottom four steps work as-is even if new key types are added later. -MSK --00000000000083901905691fcb6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 3, 2018 at 5:11 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
To focus on this one po= int:

If I read you correctly, your claim is that a record with RSA as the "= k" value and an ed25519 key isn't an error if we ASN.1 the ed25519= key so we can extract the key type from the ASN.1 structure?

Is that correct?

It's more like:
- the signature says "a=3Ded25519-sha256"
- they public key retrieved from the DNS is <b64blob>
- <b64blob> is decoded and handed to a key import function prov= ided by a crypto library
- key import function gives me a key= object
- we can then confirm what type of key that was and m= atch it against what's in the "a" value

In = my ideal world, the key import function in the third step can import either= kind of key and then tell me what type it is.=C2=A0 In the world you prefe= r, the switching logic lives in the DKIM implementation, and so the last st= ep isn't necessary because the DKIM implementation already knows the an= swer.

In my ideal world, the bottom four steps work as-is= even if new key types are added later.

-MSK
--00000000000083901905691fcb6f-- From nobody Thu Apr 5 14:54:41 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 D41A312D948 for ; Thu, 5 Apr 2018 14:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=INr2EzUJ; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=gHBfxLDW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUYcz9WdR6Cb for ; Thu, 5 Apr 2018 14:54:37 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D71312D864 for ; Thu, 5 Apr 2018 14:54:36 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1522965272; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=qCVjSwjvZS3zrPx0lNmsAJ5rHOVdjIyi3TPPecT6YHU=; b=INr2EzUJQDbMIbtgs4AGS8vAdkAf/cDIYIwYH9C8XfC7uzD/4BTGAAkQ OA/30IgCO+VT0g57iHfJnS31B3VZBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1522965272; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=qCVjSwjvZS3zrPx0lNmsAJ5rHOVdjIyi3TPPecT6YHU=; b=gHBfxLDWV10l9m5BJPISV/XuUp0szEtsZx77SzLUW01IafPQgZXRqynP VzIsU/S0Gj5ksmetdrUOo5ZF8MyXjUnbXJY1L9kCbytX+XyJPNUoZ6sC2T rfMqinpDYoN1svdfu9Aa/33HUjUplwBvMSOIeoyKu5g3MhRJ/+sS2vinrJ V9SXofl1TvA6gG3CbhNQilBG6PJOCzJVnGF141pl6Yog4norMqLtQs0PzP m5l8Bn2IO6nBieM55F5CM8A+Wj5pARbq1n3jjoH1WLePcZJHupUhGB9xRM fqb8FHt/6nRkpeY0G+90V671wjP/SsAoInlPYxNIWlnb310t19cXBw== Received: from [10.129.249.30] (mobile-166-170-35-153.mycingular.net [166.170.35.153]) (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 0A704C40149; Thu, 5 Apr 2018 16:54:32 -0500 (CDT) Date: Thu, 05 Apr 2018 21:54:28 +0000 In-Reply-To: References: <06C62CDD-9E73-440D-9677-D34A07B01A2A@dukhovni.org> <631D5636-33D1-443B-9BB9-50F7D706F43E@dukhovni.org> <219E7B82-98E7-4FB8-863A-9573309ECA1B@dukhovni.org> <51EE47F2-396D-4F98-971B-C4DE6AC60B31@kitterman.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: <47B3BCB7-91F3-4805-A69A-95C32C9F2694@kitterman.com> 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: Thu, 05 Apr 2018 21:54:39 -0000 On April 5, 2018 8:29:22 PM UTC, "Murray S=2E Kucherawy" wrote: >On Tue, Apr 3, 2018 at 5:11 PM, Scott Kitterman >wrote: > >> To focus on this one point: >> >> If I read you correctly, your claim is that a record with RSA as the >"k" >> value and an ed25519 key isn't an error if we ASN=2E1 the ed25519 key >so we >> can extract the key type from the ASN=2E1 structure? >> >> Is that correct? >> > >It's more like: > >- the signature says "a=3Ded25519-sha256" >- they public key retrieved from the DNS is >- is decoded and handed to a key import function provided by >a >crypto library >- key import function gives me a key object >- we can then confirm what type of key that was and match it against >what's >in the "a" value > >In my ideal world, the key import function in the third step can import >either kind of key and then tell me what type it is=2E In the world you >prefer, the switching logic lives in the DKIM implementation, and so >the >last step isn't necessary because the DKIM implementation already knows >the >answer=2E > >In my ideal world, the bottom four steps work as-is even if new key >types >are added later=2E I think you miss verifying the k=3D tag in the DNS record=2E You don't se= e it much today since no k=3D is implicitly RSA=2E That won't be the case = in the future since a DNS record with no k=3D tag and an ed25519 key is bro= ken and wrong=2E I understand the desire, but it looks to me like you want to add a new pro= tocol requirement that all future algorithms have an ASN=2E1 key type embed= ded in them that doesn't currently exist=2E Given the existence of k=3D, I= think the existing protocol works fine and doesn't need changing=2E Keep in mind your reply earlier today about the poor job we do at predicti= ng future crypto=2E I agree with you=2E That's one of the reasons I think= baking a particular key representation into the protocol is a risky move= =2E Scott K From nobody Thu Apr 5 15:00:41 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 8BBA612D870 for ; Thu, 5 Apr 2018 15:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Wu1XMpLo; dkim=pass (1536-bit key) header.d=taugh.com header.b=jOYU8G88 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApEdH4qKSAzL for ; Thu, 5 Apr 2018 15:00:37 -0700 (PDT) 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 961D112D86F for ; Thu, 5 Apr 2018 15:00:37 -0700 (PDT) Received: (qmail 81111 invoked from network); 5 Apr 2018 22:00: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=13cd2.5ac69c83.k1804; bh=Ba5io2HG0IQKunqEwt6aici7LZy5jsvHti+RSLLO9rA=; b=Wu1XMpLoKbOeZNgnNruanc8ySWzmgmizvXtNrbhst0tkdoFwxzkF/GBnJOAiCNdG2Qv7cvlIb/9mQu7HAUSD5Aro8Nx0XP5KNoZGhuLZZT2ezSb28A0xgfjoCjeHYcPa7DJfsMOzcpf6zE4v5gUlGlWRwr2JHDvqcnq5SLJ5W/2sc1O+iEYOQpNNGpcX31cyfVRjnEEUop4cKtmBa+HYgAKa2gyt0/IK92PwxUquG4hG3Gk3jGbDKavRfZwnUR56 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=13cd2.5ac69c83.k1804; bh=Ba5io2HG0IQKunqEwt6aici7LZy5jsvHti+RSLLO9rA=; b=jOYU8G88P7o0spEXzpXnfnKAslPdBAYN9BDv+qk/6CWejbR+Y/ySSvAhCtQ1TdvXw/yLi5IwyjLKiItF4O9e7wT7DnNIPgQusBvBNdQdLegkjseETGfjcr+19QeZVtIkbfRn60oNusn7eFyHCwDVWRPRlj6SzB2nBIHZtNywZXjlvxLj4/+fTF+qRKSu8oIr/e4zg4HwxIZRfB2lojnFyaVWqcL8GMMzdjKg2eWZPFMD9EhAAWf0zmOu5KET9vwZ 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; 05 Apr 2018 22:00:34 -0000 Date: 5 Apr 2018 18:00:34 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: dcrup@ietf.org In-Reply-To: References: <20180404015607.B0795240C700@ary.qy> 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 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 22:00:39 -0000 >> For the umpteenth time, there is more to adding a new algorithm to >> DKIM than handing the key to OpenSSL, so whatever simplification you >> imagine this provides does not actually exist. This is not a helpful >> line of argument. Please stop. > > I disagree. We can guess all we like about how soon it will be before > another change like this will be needed, but we are notoriously bad at > making such predictions and would rather not dismiss the notion out of hand. I don't think we're disagreeing. Victor has apperently been saying that if you wrap the key in ASN.1, crypto libraries will automatically select the right code to handle it so you could add new algorithms by relinking with the new crypto library without changing the DKIM code. Even if that were true, which I doubt, you still need to change the DKIM library that handles the k= tag in the key record and the a= tag in the signatures and lets the caller or a configuration file set the algorithm. By the time you've done all that, the extra code to switch off to the appropriate crypto routine which uses whatever key format it uses is easy. This would be the same if we added another algo tomorrow or another ten years from now. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 6 04:34:40 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 99D22124E15 for ; Fri, 6 Apr 2018 04:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 rC2YXHCq0c-8 for ; Fri, 6 Apr 2018 04:34:36 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB081201FA for ; Fri, 6 Apr 2018 04:34:35 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id f47-v6so831591oth.2 for ; Fri, 06 Apr 2018 04:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=08bQoX24is4BqDGuuC+BdF70OabH/+AxiCyGZCBXhHA=; b=ct3Dm7timbKjPwEaFFAPXBFMpvfMRTM54PhQDRG7bfgJdXpOqc+eYJdfDh1f+t8vAy K7slH621bPmuQb884gGslTDMTFBPPq78YZ5ErWH14sq6CsST2m69d1YhxnbsyIT1+SEx pJHggFk836Ct1MPH762Ca6u8eXVUvn4GTpkNdZopA9BUd7TMyB/hMUFkAaeu9HjX5Myt f/40vD2v/ws0k27mMJ9Amol6qFdShaYr4twEYIvyAk5kwCDwNK3+Xjw0d31UCS/04IeO p/6RHwxgwbvHc1jNS2RkdtEPeS0FcAFOp3p+QNBphQ6S4tINxNrTvxFIn6b/rIVmQY1Z 23Ww== 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=08bQoX24is4BqDGuuC+BdF70OabH/+AxiCyGZCBXhHA=; b=ncArqfjqDmOoaA2j5azI7qaxOc6Tb/xZPZ0MkJfJM3kwtPDezSEjsauxUri5Bdb8Wb TJV40hGgjgvLfIW01ogaiJK980OFiLxDpSNVY8iaA+n2v5d5Q19ziObLZnwFIBBkT0VC e3FKM+/W17WyHQN0Kx7zWgBxassrY+XJdB1XBMihtFjtl1G63FrFCdaODrg2KsR3ifP8 PGvx1wNhHlkqE+2ZU94Iq7hRg0Vc+4GVS1omnOcAcarDi5T+GfmFrTRQ8EqyfhZMrjj2 hkVzeIb9MOAmcMC16sQbVOw1SuurbfGqOlXcV5Ao082GIRFXpYm46tUiEWqwtX2dKTC/ uC0A== X-Gm-Message-State: AElRT7Eoy5tEvfAZvxBApG1I/tr9ufGW5HvjbdCINvYBIMajRqjn9wbZ gVyY00EnlfpmjbUvXbp4LYvo/FrUlOp2Q0gFq54= X-Google-Smtp-Source: AIpwx49nlHD+ZpIQga4qKCuOv/pFuujR9FNeJhjdGXdiJkTXax/qR5KHhx9uTXtidBvas1aNhqUQT7aQ677dG7+/+Sw= X-Received: by 2002:a9d:4a52:: with SMTP id d18-v6mr16915083otj.380.1523014475268; Fri, 06 Apr 2018 04:34:35 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Fri, 6 Apr 2018 04:34:34 -0700 (PDT) In-Reply-To: References: <20180404015607.B0795240C700@ary.qy> From: Phillip Hallam-Baker Date: Fri, 6 Apr 2018 07:34:34 -0400 X-Google-Sender-Auth: 2do0pnTDloHJkA1xMq4CNXMYf6o Message-ID: To: John R Levine Cc: "Murray S. Kucherawy" , dcrup@ietf.org Content-Type: multipart/alternative; boundary="000000000000c9471e05692c70e7" 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: Fri, 06 Apr 2018 11:34:39 -0000 --000000000000c9471e05692c70e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 5, 2018 at 6:00 PM, John R Levine wrote: > For the umpteenth time, there is more to adding a new algorithm to >>> DKIM than handing the key to OpenSSL, so whatever simplification you >>> imagine this provides does not actually exist. This is not a helpful >>> line of argument. Please stop. >>> >> >> I disagree. We can guess all we like about how soon it will be before >> another change like this will be needed, but we are notoriously bad at >> making such predictions and would rather not dismiss the notion out of >> hand. >> > > I don't think we're disagreeing. Victor has apperently been saying that > if you wrap the key in ASN.1, crypto libraries will automatically select > the right code to handle it so you could add new algorithms by relinking > with the new crypto library without changing the DKIM code. > > Even if that were true, which I doubt, you still need to change the DKIM > library that handles the k=3D tag in the key record and the a=3D tag in t= he > signatures and lets the caller or a configuration file set the algorithm. > By the time you've done all that, the extra code to switch off to the > appropriate crypto routine which uses whatever key format it uses is easy= . > > This would be the same if we added another algo tomorrow or another ten > years from now. > =E2=80=8BThis would have been true if: 1) DKIM had originally specified use of a SubjectPublicKeyInfo blob for the key.=E2=80=8B =E2=80=8B2) Applications used the OID in the field and not the tag for algo= rithm selection. We did not. The issue is not whether to use ASN.1 encoding it is WHAT WE USE ASN.1 to encode. PKIX and CMS do not encode public key parameters in ASN.1. That is simply a fact. They never have and never will. SubjectPublicKeyInfo contains two slots. A slot for an OID and a slot for a bag of bits. The DKIM specification uses its own tag and the same data that goes in that bag of bits. For RSA, that bag of bits just happened to be encoded in ASN.1. For ECC, it is not ASN.1. In the hope of getting to closure on this, I suggest people stop talking about ASN.1 encoding and instead talk about the ASN.1 structure they propose to use. =E2=80=8BThere is no reason that Ed25519 keys should need to use the RSAPub= lic structure. So this is an unproductive argument. This is not a matter of opinion, it is a matter of understanding the specification, sorry. The pattern of this argument is that the issue is continually re-opened by people coming in to the argument who imagine that this is an issue of ASN.1 hate and it is not. It is a matter of the proposal being mistaken. We do not use the =E2=80=8BSubjectPublicKeyInfo blob in DKIM. To propose to= use it is a major change to the spec. --000000000000c9471e05692c70e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Ap= r 5, 2018 at 6:00 PM, John R Levine <johnl@taugh.com> wrote:
For the umpteenth time, there is more to adding a new algorithm to
DKIM than handing the key to OpenSSL, so whatever simplification you
imagine this provides does not actually exist.=C2=A0 This is not a helpful<= br> line of argument.=C2=A0 Please stop.

I disagree.=C2=A0 We can guess all we like about how soon it will be before=
another change like this will be needed, but we are notoriously bad at
making such predictions and would rather not dismiss the notion out of hand= .

 I don't think we're disagreeing.=C2=A0 Victor has apperently been s= aying that if you wrap the key in ASN.1, crypto libraries will automaticall= y select the right code to handle it so you could add new algorithms by rel= inking with the new crypto library without changing the DKIM code.

Even if that were true, which I doubt, you still need to change the DKIM li= brary that handles the k=3D tag in the key record and the a=3D tag in the s= ignatures and lets the caller or a configuration file set the algorithm. By= the time you've done all that, the extra code to switch off to the app= ropriate crypto routine which uses whatever key format it uses is easy.

This would be the same if we added another algo tomorrow or another ten yea= rs from now.

=E2=80=8BThis would have been true if:

1) DKIM had originally specifi= ed use of a SubjectPublicKeyInfo blob for the key.=E2=80=8B
=E2=80=8B2) Applications used = the OID in the field and not the tag for algorithm selection.

We did not.


The issue is not whether to use ASN.1 encoding it is WHAT WE = USE ASN.1 to encode. PKIX and CMS do not encode public key parameters in AS= N.1. That is simply a fact. They never have and never will.

SubjectPublicK= eyInfo contains two slots. A slot for an OID and a slot for a bag of bits.<= /span>

The DKIM specification uses its own tag and the same d= ata that goes in that bag of bits.

For RSA, that bag of bits just happened to be encoded in ASN.1. = For ECC, it is not ASN.1.


In the ho= pe of getting to closure on this, I suggest people stop talking about ASN.1= encoding and instead talk about the ASN.1 structure they propose to use.
= =E2=80=8BThere is no reason that Ed25519 keys should need to use the RSAPub= lic structure. So this is an unproductive argument.


This is not a matter of opinion, it is a matter of underst= anding the specification, sorry. The pattern of this argument is that the i= ssue is continually re-opened by people coming in to the argument who imagi= ne that this is an issue of ASN.1 hate and it is not. It is a matter of the= proposal being mistaken.

We do not use the =E2=80=8BSubjectPublicKeyInfo = blob in DKIM. To propose to use it is a major change to the spec.
--000000000000c9471e05692c70e7-- From nobody Sun Apr 8 10:59: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 5F5C6129C6E for ; Sun, 8 Apr 2018 10:59:06 -0700 (PDT) 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 3VoSvxOhd4dS for ; Sun, 8 Apr 2018 10:59:04 -0700 (PDT) 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 F363B129C59 for ; Sun, 8 Apr 2018 10:59:03 -0700 (PDT) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1523210344; b=D1gekx9wrpKW+ZRv1OA+aLfSi/i8VYgXbRDz7QADuGf7lNmUzsRe3r9a2L2a73VjQ9vFxDLlnx 1AOD8mTpvIC5bND1fgZY1xRYtQEdEh23akb29K/w6YIrpcdR7tBglq4U6EXd7I0Saj70j5eXdA Z++MS4ttEYMuCA1wjA0/z2s=; ARC-Authentication-Results: i=1; wizmail.org; iprev=pass (vgate18.wizint.net); auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1523210344; x=1525802344; bh=KWLnGsVvAMVIKe14/1SylcbskhFNw0rPF+XZ12mdeB8=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject; b=cX+zjqZQVbL9ox+UHn1GPZHhcSmwUwjIwzSuSRE5scnE3kATiLuNC6FylH50yuss1WOoDI2R1V ReHunFT5AY5bEEwPq7nO/mKgdSw23hsa6nCnfkf2Ic/VPjVnvx6F6h6fXZ0+4Zkc/jfYGvgVJ0 3Y+L85I9LmAzS+sRSEsq4SE=; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net); auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90.118) id 1f5Eaj-0006Hw-1c for dcrup@ietf.org (return-path ); Sun, 08 Apr 2018 17:59:01 +0000 To: dcrup@ietf.org References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= xsBNBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAHNJkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+wsB7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGzsBNBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAHCwF8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: <39125178-cf16-a0d4-7747-5cc84c421414@wizmail.org> Date: Sun, 8 Apr 2018 18:59:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa 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: Sun, 08 Apr 2018 17:59:06 -0000 Could we move towards a decision on this point? My current reading of the preferences expressed is (apologies if I've misread anyone; please correct me): Bare key: phill@hallambaker.com johnl@taugh.com sklist@kitterman.com Viktor Dukhovni denisbider.ietf@gmail.com (?) rsalz@akamai.com cloos@jhcloos.com mdb@juniper.net sca@andreasschulze.de SubjectPublicKeyInfo wrapped key: Murray S. Kucherawy Neutral: jgh@wizmail.org Unclear: vesely@tana.it hsantos@isdg.net r.e.sonneveld@sonnection.nl -- Thanks, Jeremy From nobody Tue Apr 10 09:24:17 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 6FD3F12DA13 for ; Tue, 10 Apr 2018 09:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=MpG+arzr; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=smbn+H2m Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8AxfQCyoofO for ; Tue, 10 Apr 2018 09:24:14 -0700 (PDT) Received: from pop3.winserver.com (ftp.catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id ACED112DA16 for ; Tue, 10 Apr 2018 09:24:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1728; t=1523377447; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=icWhx4azkXBmwyA0cxzydQdDpKs=; b=MpG+arzrxFFiws4u4SVz168TRLR5sCp237vtU5DwMlWrgcMIT+w0Xb8lg+p3bM wyDLjMowueUDpsVpMDJUgBouYX3IVmhTEpcMxj0o3xw2Yh451sPiD3N7I/KX3+3+ ajxKmPmzUU+GcsWg+rHKtOwmnm6L5RFcyD3QTxPk1SZhQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Tue, 10 Apr 2018 12:24:07 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 361139996.1.9396; Tue, 10 Apr 2018 12:24:06 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1728; t=1523377035; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=7eExSPB Y6sBoAJddEBVQqZtPp8OuQhcamfePEKoOUwo=; b=smbn+H2mVYL36q0yNLDUyKH O+FYxXkZRKu3BSCSUvfaueRzG8A7hPk4stOvNv32o6LZ3tFjP4bToEE2OMZOORtn rk+q4S4PKNRjQuhXgOJWrHbgWDEgLcRsfjUz7/b08GKLL7uEmV474uu1oANLE0ry mOYWHZEMUeQISNnKYO6A= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Tue, 10 Apr 2018 12:17:15 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 360974628.9.91144; Tue, 10 Apr 2018 12:17:15 -0400 Message-ID: <5ACCE527.9040100@isdg.net> Date: Tue, 10 Apr 2018 12:24:07 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Jeremy Harris , dcrup@ietf.org References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <39125178-cf16-a0d4-7747-5cc84c421414@wizmail.org> In-Reply-To: <39125178-cf16-a0d4-7747-5cc84c421414@wizmail.org> 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, 10 Apr 2018 16:24:17 -0000 Hi Jeremy, I must admit this is a IETF first for me, to see a WG issue position outline per individual. I suppose it helps. In any case, I am for the "least DKIM change" position -- a plug and play new hash option, with minimum code change. If that is what "bare key" means, then I support it. My expectation is that when the time comes, I will just take what is already being done in our package for DKIM SHA1/SHA256 signing, verification and setup, copy and paste the logic code and make the OpenSSL crypto functional changes for Ed25519 support. At the frontend, this is where it gets more difficult because the sysops options will need to be added, i.e. double signing support (Ed25519 and SHA256). side note: if there are customers who believe a previous version of OpenSSL is better than the latest (that we will compile and distribute), we will need to add support for a disabled ED25519 OpenSSL DLL/API, i.e, possible dynamic Linking support required here or some stub/wrapper wcEd25519() function. Thanks -- HLS On 4/8/2018 1:59 PM, Jeremy Harris wrote: > Could we move towards a decision on this point? > > My current reading of the preferences expressed is > (apologies if I've misread anyone; please correct me): > > > Bare key: > > phill@hallambaker.com > johnl@taugh.com > sklist@kitterman.com > Viktor Dukhovni > denisbider.ietf@gmail.com (?) > rsalz@akamai.com > cloos@jhcloos.com > mdb@juniper.net > sca@andreasschulze.de > > SubjectPublicKeyInfo wrapped key: > > Murray S. Kucherawy > > Neutral: > jgh@wizmail.org > > Unclear: > > vesely@tana.it > hsantos@isdg.net > r.e.sonneveld@sonnection.nl > From nobody Mon Apr 16 10:38: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 53DF9127909 for ; Mon, 16 Apr 2018 10:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3DjLN3oKFVs for ; Mon, 16 Apr 2018 10:38:04 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E630126C19 for ; Mon, 16 Apr 2018 10:38:04 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w3GHSHpg002713; Mon, 16 Apr 2018 18:37:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=OXJBG+hQug3Q5xTPJ7c+lZK2km4HoU+7cxD0S3ytFtI=; b=V/R8TmgpLykOgYBorHs06PaVaceluW+vOW7ZQGPsbR8WAdMIJZt1mlbH40rVLKNeUO7G PV6s+7Dz66+z9CxncSStE4x5f5k+i+kyxuV3LWIr3Jmvv9Fth+fvUAn3sJTFtu9Ec7N9 QYvfKUUjgbQVltXiLt9NS6YKFuO4RuGz64EnbKsIgtBy9T+sey7D89rUIpYfHrh8DVnB l7arui3KTILN1nwnLwwMA8mqboFIPfUKGeKsuty4GouGRwVJ07IWTyEkcDRY26YPQoDv /Qi6heINbuOG0dxzyGY6hh4Yrufuc1Ix69zztKT01D8FyoauI99mYTA6SGWA2ob6MUXJ ow== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2hba265uv4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Apr 2018 18:37:45 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3GHQ9iQ000388; Mon, 16 Apr 2018 13:37:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint4.akamai.com with ESMTP id 2hbd0cywfw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 16 Apr 2018 13:37:45 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 16 Apr 2018 13:37:43 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Mon, 16 Apr 2018 13:37:43 -0400 From: "Salz, Rich" To: denis bider CC: "dcrup@ietf.org" , Phillip Hallam-Baker , "Murray S. Kucherawy" , "A. Schulze" Thread-Topic: [Dcrup] ed25519 in DNS Thread-Index: AQHTwELMBQuIVyAaXkGxq4oyoJ8nq6PZYOKAgAt2FYCAAC7BgIAAQpyAgAAPcgCAABGngIAADquAgAAcPACAAYtmgIAAFqwAgADCToCAAAMNAIAABiyA//+9z4CAAP2LgIAAAPwAgBsUdoA= Date: Mon, 16 Apr 2018 17:37:43 +0000 Message-ID: <765B1211-E03B-459A-9F20-B1ABCD5F61AF@akamai.com> References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.com> <20180328094636.Horde.Np3GCcO8iEPwmQzOaaUjbrh@andreasschulze.de> <2897E6E0-4535-4EC1-9686-E080CCA82D21@akamai.com> In-Reply-To: <2897E6E0-4535-4EC1-9686-E080CCA82D21@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180410 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.75] Content-Type: multipart/alternative; boundary="_000_765B1211E03B459A9F20B1ABCD5F61AFakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-16_09:, , 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=551 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804160155 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-16_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=482 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804160155 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, 16 Apr 2018 17:38:06 -0000 --_000_765B1211E03B459A9F20B1ABCD5F61AFakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgV2Ugd2lsbCBoYXZlIHRvIGhhdmUgYSBjb25zZW5zdXMgZGVjaXNpb24gb24gdGhpcy4g IExldOKAmXMgbGV0IHRoZSBkaXNjdXNzaW9uIHJ1biBmb3IgYSBmZXcgbW9yZSBkYXlzLiAgSWYg eW91IGhhdmUgYW55dGhpbmcgbmV3IHRvIG1lbnRpb24sIHBsZWFzZSBzcGVhayB1cC4gIE90aGVy d2lzZSBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBjaG9pY2Ugd2lsbCBiZQ0KICAgICAgICAgICAg ICAgIEFTTjEvREVSIHdyYXAgdGhlIEVkMjU1MTkga2V5DQogICAgICAgICAgICAgICAgSnVzdCB0 aGUga2V5IHdpdGhvdXQgd3JhcHBpbmcuDQoNCkRpc2N1c3Npb24gc2VlbXMgdG8gaGF2ZSBkaWVk IGRvd24sIGFuZCBpdCBzZWVtcyB0aGUg4oCccmF3IGtleeKAnSB3aXRob3V0IGFueSB3cmFwcGlu ZyAoc3VjaCBhcyBPSUQvb2N0ZXQtc3RyaW5nKSBpcyB0aGUgY29uc2Vuc3VzLiAgRG9lcyBhbnlv bmUgKkRJU0FHUkVFKiB3aXRoIHRoYXQ/DQo= --_000_765B1211E03B459A9F20B1ABCD5F61AFakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <7F1311FD7B4CB44690CA84E49E46F1E7@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjM4MTc1OTQ2OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTIxMDQ1NTk2NTY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMzA0Mzg3MzUy Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozOTYwMTg5 NzQgMjQ0NzczNTY2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2 ZWwtc3RhcnQtYXQ6MTc0NzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28tYW5zaS1mb250LXdlaWdodDpib2xkO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE2ODcwOTYyMDA7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTUwMDU1ODkyIC0x NTIzOTE5NjcyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwt c3RhcnQtYXQ6NTkwNzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjx1bCBzdHlsZT0ibWFyZ2lu LXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij48YSBuYW1lPSJfTWFp bE9yaWdpbmFsQm9keSI+V2Ugd2lsbCBoYXZlIHRvIGhhdmUgYSBjb25zZW5zdXMgZGVjaXNpb24g b24gdGhpcy4mbmJzcDsgTGV04oCZcyBsZXQgdGhlIGRpc2N1c3Npb24gcnVuIGZvciBhIGZldyBt b3JlIGRheXMuJm5ic3A7IElmIHlvdSBoYXZlIGFueXRoaW5nIG5ldyB0byBtZW50aW9uLCBwbGVh c2Ugc3BlYWsNCiB1cC4mbmJzcDsgT3RoZXJ3aXNlIGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGNo b2ljZSB3aWxsIGJlPG86cD48L286cD48L2E+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFTTjEvREVSIHdyYXAgdGhlIEVkMjU1MTkga2V5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEp1c3QgdGhlIGtleSB3aXRob3V0IHdyYXBwaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkRpc2N1 c3Npb24gc2VlbXMgdG8gaGF2ZSBkaWVkIGRvd24sIGFuZCBpdCBzZWVtcyB0aGUg4oCccmF3IGtl eeKAnSB3aXRob3V0IGFueSB3cmFwcGluZyAoc3VjaCBhcyBPSUQvb2N0ZXQtc3RyaW5nKSBpcyB0 aGUgY29uc2Vuc3VzLiZuYnNwOyBEb2VzIGFueW9uZSAqPGI+RElTQUdSRUU8L2I+KiB3aXRoIHRo YXQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_765B1211E03B459A9F20B1ABCD5F61AFakamaicom_-- From nobody Mon Apr 16 11:08: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 66AC1127909 for ; Mon, 16 Apr 2018 11:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=UArNUooE; dkim=pass (2048-bit key) header.d=kitterman.com header.b=rCvhq/lx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLcOAv41RMBF for ; Mon, 16 Apr 2018 11:08:51 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BE512D878 for ; Mon, 16 Apr 2018 11:08:50 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1523902129; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=8SwgzwJ9xJgDcPXTxvIXeUNut8t3o31sLhhxNZV7wNQ=; b=UArNUooEBC8uNoYioT8m43V+iTYMOO5Jc6cmSPDp6YobdI+GPoQD+RI+ QDmHVvkXbBcEKKsWR3NbI+9LF3kiAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1523902129; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=8SwgzwJ9xJgDcPXTxvIXeUNut8t3o31sLhhxNZV7wNQ=; b=rCvhq/lxTWxbvQcqRtWih5fLJbvsPbtRdYjbtDdMP6Ep2Eids17MS+0/ xtvIp1bnyuhk1MOmL5QHfZne2oEMNCfVxtiI+dJHGB2wl8dl+Zt/2YNC2m sEf8Za0s1pesggr5e8wVDoyP3IX30Uq+Y5kErKpAM16MjUhkyQeIF1FT9X YkmvrvYpyHWH9Aq7ePDt498Uk1viJoiTt1wkQykkDlmGj7GV0eEFIF6n6o b+PbThZ418cSQesGPYn1UKvj/v9lz52zQVOTOGbzqwvXyosfvgK6zVVG9I ruayAl5bsze+ZmA7FLiqKKBFH3gKp+pQEYw96rvrNJ8n0Xy/8kMkcg== 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 5C936C401D7 for ; Mon, 16 Apr 2018 13:08:49 -0500 (CDT) From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 16 Apr 2018 14:08:43 -0400 Message-ID: <1750368.vZOJbTfRev@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-144-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [Dcrup] Authentication Results and Ed25519 Signatures X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 16 Apr 2018 18:08:54 -0000 Since I've been sending dual rsa-sha256/ed25519-sha256 signed emails for awhile now, I decided to look for cases where I could see how the results were being recorded (in some cases I'll get the mails back). Unfortunately, most of them don't add an A-R header field, but I was often able to see that the messages were correctly scored as DKIM signed with a valid signature. I have not found any cases that were problematic. The two data points I found A-R for were Google and IETF lists (non-DCRUP relevant bits elided): Authentication-Results: mx.google.com; dkim=neutral (no key) header.i=@kitterman.com header.s=201803e header.b=hxFQlnEt; Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=INr2EzUJ; Ideally, I think a bit of what's in both should be included. I think the IETF (amavisd-new) error message is very good. I think it's completely clear what's going on. I also like that Google included the selector. I know 201803e is a selector for an ed25519 key, so I understand "no key" means "no RSA key". Does anyone else have other examples? If anyone has another implementation they'd like to test, feel free to mail me off list and I'll be glad to help. Scott K From nobody Mon Apr 16 12:26:48 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 9A05B126D05 for ; Mon, 16 Apr 2018 12:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=yUAzWyjD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jztF294O Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKmmgukriP3u for ; Mon, 16 Apr 2018 12:26:44 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4E6120725 for ; Mon, 16 Apr 2018 12:26:44 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 33A3021B27; Mon, 16 Apr 2018 15:26:44 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 16 Apr 2018 15:26:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=XoPn8viyWjZeuO45s m/V7vryh6aTNeOui/jI9ZY1mPI=; b=yUAzWyjD+FmH1tLMCarj4Jsl5Fiz5KwdR JHyxE7agzvZfH+r2VMJjVRFpuE5XoNvqHhCEntIlAJ7abjhkCnlVJqPjkPKiTfph P2IDM2yuGfdAmi6LsOm40BzDvnrVmraeiOA9LgQXEoKZtA7AA6BIsljawlcDjpyE nTJIT4bMoz3fJahGWq1OVsbTsd46kWg58rirI9vegBF3BoNB0Gs+swS0QOOc+WJ+ FxWi1fYiX93rmWYtT6xZPM4s+TH3ijFnIM1BKdyO+gBJjImSix1QGagI2kdCb3BQ g1M3clJYkVDGRMuXCe6q4mkbGGJ9eEqilORA3EZb9Mc1pvraaYj9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=XoPn8v iyWjZeuO45sm/V7vryh6aTNeOui/jI9ZY1mPI=; b=jztF294O2K7gemiTGafo8t 5zHvCJHaiKq0RezYJ13rq7FJeIxRAPVELSvVVVJVoCiBLossNisTNll8QK7iGy/A 0nnhcwPKKsKRWyazTwSNFSjMmpeayKJMTEhq4+GUU7E1ICeHUHP1Kw5G15rAeZSq jNNfMJ53E1GRoSle1u/f391HidLv05AxHM0Yv28ynUYMOIsEU+5dxb234kNGRf92 1qRi5SICOaShESpIgffF5mrmTGdjGhmlQCpdRBR9FbrkyWTzIzxmNbxRrSItJVpl m0MbnR4Q419fJm1ncshzr1c6QbiFrjqkIUcWtm66Ui/q65Q9m7N6h5QSia5UsWYQ == X-ME-Sender: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.com> <20180328094636.Horde.Np3GCcO8iEPwmQzOaaUjbrh@andreasschulze.de> <2897E6E0-4535-4EC1-9686-E080CCA82D21@akamai.com> <765B1211-E03B-459A-9F20-B1ABCD5F61AF@akamai.com> MIME-Version: 1.0 In-Reply-To: <765B1211-E03B-459A-9F20-B1ABCD5F61AF@akamai.com> Content-Type: multipart/alternative; boundary=Apple-Mail-63A7F539-2690-4339-BBA7-7F57A46E7650 Content-Transfer-Encoding: 7bit Message-Id: <38A90ECD-6AF4-4A85-A4DB-F0748DF3F368@glyphein.mailforce.net> Cc: denis bider , "dcrup@ietf.org" , Phillip Hallam-Baker , "Murray S. Kucherawy" , "A. Schulze" From: Stan Kalisch Date: Mon, 16 Apr 2018 15:26:40 -0400 To: "Salz, Rich" 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, 16 Apr 2018 19:26:47 -0000 --Apple-Mail-63A7F539-2690-4339-BBA7-7F57A46E7650 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Apr 16, 2018, at 1:37 PM, Salz, Rich wrote: >=20 > We will have to have a consensus decision on this. Let=E2=80=99s let the d= iscussion run for a few more days. If you have anything new to mention, ple= ase speak up. Otherwise it seems to me that the choice will be > ASN1/DER wrap the Ed25519 key > Just the key without wrapping. FWIW, I was relatively neutral at the beginning of this, but I've found the a= rguments in favor of raw to be more compelling, and more detailed in general= , than those in favor of ASN1, etc. Thanks, Stan > Discussion seems to have died down, and it seems the =E2=80=9Craw key=E2=80= =9D without any wrapping (such as OID/octet-string) is the consensus. Does a= nyone *DISAGREE* with that? > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup --Apple-Mail-63A7F539-2690-4339-BBA7-7F57A46E7650 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Apr 16, 2018, at 1:3= 7 PM, Salz, Rich <rsalz@akamai.com> wrote:

 =             &nbs= p;  ASN1/DER wrap the Ed25519 key

 =             &nbs= p;  Just the key without wrapping.

<= div>
FWIW, I was relatively neutral at the beginning of this, but I= 've found the arguments in favor of raw to be more compelling, and more deta= iled in general, than those in favor of ASN1, etc.


Thanks,
Stan

Discus= sion seems to have died down, and it seems the =E2=80=9Craw key=E2=80=9D wit= hout any wrapping (such as OID/octet-string) is the consensus.  Does an= yone *DISAGREE* with that?

__________________________= _____________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/li= stinfo/dcrup
= --Apple-Mail-63A7F539-2690-4339-BBA7-7F57A46E7650-- From nobody Mon Apr 16 12:57: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 4F35D12EB38 for ; Mon, 16 Apr 2018 12:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=andreasschulze.de header.b=f8y7+VcO; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=IJ01nkE0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfl__VpYBJ2S for ; Mon, 16 Apr 2018 12:57:19 -0700 (PDT) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:470:77b3:100::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACC712EAEE for ; Mon, 16 Apr 2018 12:57:19 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=andreasschulze.de; i=@andreasschulze.de; q=dns/txt; s=ed25519; t=1523908636; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : subject : from : date; bh=3owwUBcaEVzbxJzlFOr5I/w02U6dc+UtZofWXTW8QzQ=; b=f8y7+VcOzVsyH5OAi4xAJsuB1JKgHX1uc5tDazpuX7jiZGPMtCAtdU9L ii5NT1+iRJXmtD3EBw/E+BU7HHLIBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=ybz; t=1523908635; x=1528908635; bh=3owwUBcaEVzbxJzlFOr5I/w02U6dc+UtZofWXTW8QzQ=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To: Content-Type:from:reply-to:subject:date:to:cc:content-type: message-id; b=IJ01nkE0ni/LjHNrUaRid9CzeQBMgQDOVnP6pb6WepwwsKb7jOvT96IpssmIuArQx 3xIyMFLThp+8JI94jKxodTFSXwL47BVJrXjKIs+4jDWHudjL2OXRva6cK8zUxRcbR8 8Pc9bnTzjwvD1CiKKQUk238BUfDyeHz2L0YuHW5KiNW/O1Ua2EupiVknMyIQy8ERkL GWphOoX5d27U64tmnZEW0MKKuW+PNk5K2DL2OqwqBQpONsxahlC8j2JUrhJPOVj0WI 4wWG0PG12Ufblxz4VOTEYj/O4i2roGCoFSfGKtsIE9v3ui1qLpa73NRSVwt35ABgA2 CmWcq8vk+lpgQ== To: dcrup@ietf.org References: <1750368.vZOJbTfRev@kitterma-e6430> From: "A. Schulze" Message-ID: Date: Mon, 16 Apr 2018 21:57:13 +0200 MIME-Version: 1.0 In-Reply-To: <1750368.vZOJbTfRev@kitterma-e6430> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Authentication Results and Ed25519 Signatures X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 16 Apr 2018 19:57:36 -0000 Am 16.04.2018 um 20:08 schrieb Scott Kitterman: > Does anyone else have other examples? I also run Scott's software for some weeks. The A-R header I saw confirm Scott's findings. I did not notice any negative impact. Andreas From nobody Mon Apr 16 13:11:38 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 368C612D810 for ; Mon, 16 Apr 2018 13:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=spodhuis.org header.b=WB6+SQLF; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=spodhuis.org header.b=d1UA+97k Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZl3yUFjH9OD for ; Mon, 16 Apr 2018 13:11:35 -0700 (PDT) Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (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 82385127078 for ; Mon, 16 Apr 2018 13:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201804; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6rilxzhAvZNm6AhNyj/KxWDeGF1JOfKl031IhyYVjyc=; b=WB6+SQLF0GzGvOntB6QxJQeC05 F0jHnoXysgWPFS2aHKRGgrxyIbZ9/H9y+xCCfOoOme5Aaqcp9Zd7YQZHcIG9y6e0YGqWkQjpJsti5 NmY8ES5cO5iKcDKFDYjYv7lLnFNyGckqwJ0sEXN5sO5aOrSSyxmHlYd94zYlPFhYC3mnaKyQw+LHp 7g2NCagyRetqpNXFPGYBiXILHMjJJk7X9uH+8j9Xi7foYtsy4BHgn4LAQgC7u4k+t2fEBHZ4rEDHG XyFYg+zPoPEZQ4fmnfGgjfHwQEmKajhVb+D1AQNEXQxfgfNwxU+IdC5heJ8RWeWQb+ik5cUZEjuus 4rO//IaA==; DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201804e2; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6rilxzhAvZNm6AhNyj/KxWDeGF1JOfKl031IhyYVjyc=; b=d1UA+97kKj+rWl0wUStLCzjOb HFySR9Hs576GPOFZNxJooXLlEPsoI7xQ5AmfvBMtbdIziv8c/hY1U0cUG4YCw==; Received: from authenticated user by smtp.spodhuis.org with esmtpa id 1f8ATL-000Chs-VB; Mon, 16 Apr 2018 20:11:32 +0000 Date: Mon, 16 Apr 2018 16:11:31 -0400 From: Phil Pennock To: Scott Kitterman Cc: dcrup@ietf.org Message-ID: <20180416201131.GA17390@tower.spodhuis.org> Mail-Followup-To: Scott Kitterman , dcrup@ietf.org References: <1750368.vZOJbTfRev@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1750368.vZOJbTfRev@kitterma-e6430> OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc Archived-At: Subject: Re: [Dcrup] Authentication Results and Ed25519 Signatures X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 16 Apr 2018 20:11:37 -0000 On 2018-04-16 at 14:08 -0400, Scott Kitterman wrote: > Does anyone else have other examples? Exim 4.91 has just been released (yesterday), with support for Ed25519 (with usual library caveats). ARC-Authentication-Results: i=1; exim.org; iprev=pass (smtp.spodhuis.org); spf=pass smtp.mailfrom=spodhuis.org; dkim=pass header.d=spodhuis.org header.s=d201804 header.a=rsa-sha256; dkim=pass header.d=spodhuis.org header.s=d201804e2 header.a=ed25519-sha256; dmarc=pass header.from=spodhuis.org; arc=none (Note that the main exim.org MTA does not link against a pre-release OpenSSL, so does not handle Ed25519; our standing "next-exim" MTA instance, on port 26, currently does. My own domain, spodhuis.org, is running on pre-release OpenSSL for all SMTP ports.) -Phil From nobody Mon Apr 16 13:17: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 C85E212EAA4 for ; Mon, 16 Apr 2018 13:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJmgtiBDPCsL for ; Mon, 16 Apr 2018 13:17:01 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56962127078 for ; Mon, 16 Apr 2018 13:17:01 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id l11so7560992qtj.10 for ; Mon, 16 Apr 2018 13:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PdJ2oCHPKdb1lK9IHJK44+xoZ7hm6D0tOJ78aZ8XIe8=; b=SqucDKQQpBRaMVH+mEZbHK9efY0hGFURsUVOcFPMlXTRvI5OVIbMndT2ql2i0peZoy e55SuYxM5voiAwwls1HJwVIHphm6YD/2gL1mrmGzb/flRFYYvmSFc6vGmSQkIxS+Kl6p SrYeVQu5Mp/aq6kGofDLQzl1Mhno4BHYsnd1Eb13cCK6iZkp2x1sYyczfwCh+KjGAwCO 1qVm4WPoi6VzrvkBxCfLcAPVLzG+VDI1I97z1az6mo1PDUZtU6p7kW5NpZ4Z5qAZJ3yG EN8FA29CMmFUcc3YCySYFIqHfxzg0Uae5fMOFC5aHJnykwuOpiSWP/nepVOTvz4tD55l t38A== 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=PdJ2oCHPKdb1lK9IHJK44+xoZ7hm6D0tOJ78aZ8XIe8=; b=pMAXmmvRhmqvGgtJ+xKp3fdZrGjYN0cjTogfRDZPqDfurplhDwo0+VZlVskRIMX6vk OQg4U5qQfGOG6n4QsOrcwvsN78FAf2OWCsHC27HffhDU1BgeFJLlkqSPINzkna/TsVSv bSRn306xJ3yeBIfgIbsz+XW1oOEVZMmo3xmCiBrvid+l3SjecuVjMpEvyp0rCSzZ+mHC 6RBxtRNzHUnmEtqQDrQhEkS4F7ITLaha3ecooa3h7vyv7QXwVgzqRcCISZrukwPnj48Y Qktvz+z7a3ziiDHGQuoVP9JqtLtcZ2rFnqMOgffwUfd9m4ohkQ2ASPwm0/eeZtQJpb0B 2LOg== X-Gm-Message-State: ALQs6tC/o4HB7WEX3aDGjkxszDfyMuzPSP8KAxqg+Fl2/Oy+BsmyOwof ZORpykWRzBjXD2f2Md0ugAAKgYDfa7HeFWqPL2MwSnZq X-Google-Smtp-Source: AIpwx4/mU6QHcpLX3CGw1rvsuQN9wb+F2jbb58FQKKUZ9h7EKJdTrcb4uPJuOp29A6pcFxyL4UXM0gormtNXXVxJSKg= X-Received: by 10.237.59.9 with SMTP id p9mr17540043qte.240.1523909820182; Mon, 16 Apr 2018 13:17:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.49.26 with HTTP; Mon, 16 Apr 2018 13:16:39 -0700 (PDT) In-Reply-To: <20180416201131.GA17390@tower.spodhuis.org> References: <1750368.vZOJbTfRev@kitterma-e6430> <20180416201131.GA17390@tower.spodhuis.org> From: Seth Blank Date: Mon, 16 Apr 2018 13:16:39 -0700 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c190338808d440569fce7c1" Archived-At: Subject: Re: [Dcrup] Authentication Results and Ed25519 Signatures X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 16 Apr 2018 20:17:04 -0000 --94eb2c190338808d440569fce7c1 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 16, 2018 at 1:11 PM, Phil Pennock < dcrup-phil+ww0hib7g@spodhuis.org> wrote: > ARC-Authentication-Results: i=1; exim.org; > iprev=pass (smtp.spodhuis.org); > spf=pass smtp.mailfrom=spodhuis.org; > dkim=pass header.d=spodhuis.org header.s=d201804 > header.a=rsa-sha256; > dkim=pass header.d=spodhuis.org header.s=d201804e2 > header.a=ed25519-sha256; > dmarc=pass header.from=spodhuis.org; > arc=none > I think stamping header.a in the dkim A-R is the exact right way to handle this, and I believe 7601bis provides us this ability. -- Seth Blank | Director of Industry Initiatives E: seth@valimail.com | P: 415.894.2724 --94eb2c190338808d440569fce7c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Apr 16, 2018 at 1:11 PM, Phil Pennock <dcrup-phil+ww0hi= b7g@spodhuis.org> wrote:
AR= C-Authentication-Results: i=3D1; exim.org;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 iprev=3Dpass (smtp.spodhuis.org);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 spf=3Dpass smtp.mailfrom=3Dspodhuis.org;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dkim=3Dpass header.d=3Dspodhuis.org header.s=3Dd2= 01804 header.a=3Drsa-sha256;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dkim=3Dpass header.d=3Dspodhuis.org header.s=3Dd2= 01804e2 header.a=3Ded25519-sha256;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dmarc=3Dpass header.from=3Dspodhuis.org;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 arc=3Dnone

I think stamping header.a in the dkim A-R is the exact right way t= o handle this, and I believe 7601bis provides us this ability.
--

Seth Blank | Director of Industry Initiat= ives

E: seth@valimail.com | P: 415.894.2724

--94eb2c190338808d440569fce7c1-- From nobody Mon Apr 16 13:38:56 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 31EB6126D0C for ; Mon, 16 Apr 2018 13:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=QRIgXbrk; dkim=pass (2048-bit key) header.d=kitterman.com header.b=FCIfXYXV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU8EGv5hWc6D for ; Mon, 16 Apr 2018 13:38:53 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D0C126CE8 for ; Mon, 16 Apr 2018 13:38:53 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1523911132; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=TRZOPlhzKsi15CY5JaHu/1db5k4kwfP5lN1+7uad7Ew=; b=QRIgXbrkbCc5rVJW0ZHpks7BdBJRoALIO2sezEEYgTGpjDDEboPLXxvj Ldt3OAW2/Khft8WsvbJGkA5RsEOCBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1523911132; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=TRZOPlhzKsi15CY5JaHu/1db5k4kwfP5lN1+7uad7Ew=; b=FCIfXYXV7tkVnURhLLsCGaY1vZo48yhkZY+5LQ1fUNECuPYGI0DjyKiE hFoVFVGrb0sT3HD/PF9oFLWkkYF05q1K5QxHaE+encJxEi1rv/YzCl4E4+ MOGnYuiOzjAElBx4EeHCU+1BQZF8f1BJ+S9B/GoHE+/UDlcdj+ZKuEfjhS CecqB0f1PzVt9Z+/zSQ6hvB+HiChgVJEFWRs8o/x9fyBmSyKrxbYilTt+e XI/06i9Odnk8YjKH0vJx2rOe9MValh+jvELMvQwNedYTXXaonO1QuqhEWC z7RJOjMMuR32365W+vTYWYXn9LHqSGcozoffeKgByqrKhxNFirOmQA== 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 01EA2C400C9 for ; Mon, 16 Apr 2018 15:38:52 -0500 (CDT) From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 16 Apr 2018 16:38:51 -0400 Message-ID: <7817702.oNLnsdcsyL@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-144-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <1750368.vZOJbTfRev@kitterma-e6430> <20180416201131.GA17390@tower.spodhuis.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Authentication Results and Ed25519 Signatures X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 16 Apr 2018 20:38:55 -0000 On Monday, April 16, 2018 01:16:39 PM Seth Blank wrote: > On Mon, Apr 16, 2018 at 1:11 PM, Phil Pennock < > > dcrup-phil+ww0hib7g@spodhuis.org> wrote: > > ARC-Authentication-Results: i=1; exim.org; > > > > iprev=pass (smtp.spodhuis.org); > > spf=pass smtp.mailfrom=spodhuis.org; > > dkim=pass header.d=spodhuis.org header.s=d201804 > > > > header.a=rsa-sha256; > > > > dkim=pass header.d=spodhuis.org header.s=d201804e2 > > > > header.a=ed25519-sha256; > > > > dmarc=pass header.from=spodhuis.org; > > arc=none > > I think stamping header.a in the dkim A-R is the exact right way to handle > this, and I believe 7601bis provides us this ability. Yeah. Jeremy Harris (Exim developer) and I collaborated on this. Here's what my milter provides: Authentication-Results: relay02; dkim=pass (Good ed25519-sha256 signature) header.d=kitterman.com header.i=@kitterman.com header.a=ed25519-sha256; dkim=pass (Good 2048 bit rsa-sha256 signature) header.d=kitterman.com header.i=@kitterman.com header.a=rsa-sha256 I'm currently holding off on a 1.0 release of dkimpy-milter until we have the key format issue sorted. It's be nice to see 7601bis move forward, too, but I guess that's a different list. Scott K From nobody Tue Apr 17 10:44: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 84D5012783A for ; Tue, 17 Apr 2018 10:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=spodhuis.org header.b=M1vj5qGn; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=spodhuis.org header.b=lzBlGLbu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD1ST8DYADao for ; Tue, 17 Apr 2018 10:43:58 -0700 (PDT) Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (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 E829212D95B for ; Tue, 17 Apr 2018 10:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201804; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=/bR8HSu4uz43wqIZeQKN1bDMQOjpqE+f/hwIuVbWdW8=; b=M1vj5qGnyz49Aw+xFX9bb7GDuB Qxkxr0xXOU4OekHYj58KCNSwpuyhYUpTxmWj06KQSUZuPuO2pOJRjlhSKbNqZysR0KJdb3OJOFvQb 5PlJ3YlJCYtVC1hmH6OSh6RebbhU2GdcPK5IY4MkcULUExqw4SqKQCkjDarENjFT03lp5Srvgaa/p aQ0kkBd15v6nJq29F0aSgsiaU7nXSK0Sgnq0Ux2oai+pM52z0pXf8TEDW8n9Mb5mCmRSmidmgwRJj fsuznOizGTrBpiSznPaMaUqSbcbyGKUJu2z0gvvIr5rqa8cZzV89hnhj4eL6a4ep3QV/+iEWXcRM3 JFU9m+0g==; DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201804e2; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/bR8HSu4uz43wqIZeQKN1bDMQOjpqE+f/hwIuVbWdW8=; b=lzBlGLbudeSUxlWXVT3NtHUvp 0Ld4oAPyaZUNPwcxqKrjB43YYmno25XPP2ND+D3U4V5YYJcjDOlNjxiOWb7Cg==; Received: from authenticated user by smtp.spodhuis.org with esmtpa id 1f8Ue1-000At1-Rr; Tue, 17 Apr 2018 17:43:53 +0000 Date: Tue, 17 Apr 2018 13:43:53 -0400 From: Phil Pennock To: Scott Kitterman Cc: dcrup@ietf.org Message-ID: <20180417174353.GA41769@tower.spodhuis.org> Mail-Followup-To: Scott Kitterman , dcrup@ietf.org References: <1750368.vZOJbTfRev@kitterma-e6430> <20180416201131.GA17390@tower.spodhuis.org> <7817702.oNLnsdcsyL@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7817702.oNLnsdcsyL@kitterma-e6430> OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc Archived-At: Subject: Re: [Dcrup] Authentication Results and Ed25519 Signatures X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 17 Apr 2018 17:43:59 -0000 On 2018-04-16 at 16:38 -0400, Scott Kitterman wrote: > I'm currently holding off on a 1.0 release of dkimpy-milter until we have the > key format issue sorted. It's be nice to see 7601bis move forward, too, but I > guess that's a different list. We didn't want to wait longer for Exim 4.91, so I made the call (ie, blame me for this decision, not Jeremy who did the work): Exim currently supports both key formats in DNS, but will drop whatever doesn't end up officially specified by the RFC. It's a simple length-based check on the p= section of the string; not the cleanest but MTAs have far dirtier logic to deal with the junk people put in DNS so justifiable for support for draft-stage features. -Phil, Exim hat on From nobody Thu Apr 19 16:27:10 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 9B9AB1200A0 for ; Thu, 19 Apr 2018 16:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XS9mWkoZfYE for ; Thu, 19 Apr 2018 16:27:07 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CDB9124D37 for ; Thu, 19 Apr 2018 16:27:06 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id j68-v6so2515987lfg.13 for ; Thu, 19 Apr 2018 16:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TddrRhkq/u1+qbWdM1QambYX3qlQQJGvFzQKVkWp5Z0=; b=PXIzs/VK5xWTvv2nPYrbZQkAKk5V9LJB2krcc7q4uelp4jiRKIroOInLMZ80bHphwa qKfdqYdBmty1tW+RUFbakTY6dRVD+ExIEUJrwdp7afD2RRm5x6wvpgZfW96lwHOPaLUD Q/sEHWu0bJelfeiBf+bqN4SlJtoyPft9qazLjBzVRgSZg0ooeScOVegqQDzYvSJLVlTE Ri4dtmib+cemoKJTKI1fRh+9017G82Vg58SHbGXvEBqQ4NYNR4j7JGZe6qHhInhEH8Z+ FyHctCE8mblXu86GrkbDcuLNGzobZgeEGvQ1qn1yq6Dzywe0Sn/128CRTnllo3knUiRW YmMA== 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=TddrRhkq/u1+qbWdM1QambYX3qlQQJGvFzQKVkWp5Z0=; b=YNSe1Wdw9u3scwxBOP054xcjdaCzxD2piC+Lq8j/S87xBYDplCEVOIcABN6M0tSwZF P4RPNAK271oi4VnM1alKTTRrEluFo2Dtj7mxtjkdzrL344YQ7bjV1bSVTLalCkSmARzd pk8+wJ4/6Vxr7P70E10EEc0JHus3ws50LqohAzZ6fQhLJpM7dkrUZW6NdfhPEQQ6wlg+ +ayevfhZ+CL6AAcU3fuQsWrGd1CiWvmIItCN72tpkFDyOZaLY5J6vmQrtS/zEbKskUYu fwe1khDv0xCHmrHq2BY0ZwPTVyLsVof0IWu1KW9snqZkLDCl7/axxy7pTXlitHwnXMX8 LkMw== X-Gm-Message-State: ALQs6tD+unWyfmU7YxyZGJ1jZflPJXRXsrza4bYRxGCA4tvabur+FKU4 csXGhrLQ542lT3JZx/Q1YWjX5juuyoiF/pelk9M= X-Google-Smtp-Source: AIpwx48te3SM9rXD1ApAJQza3C1NAQMJw+gUITy13ZZzBPY7oSyT3UIQUmVCZ/avcSsdb0BqjOLbH4GP4tWreS9WSPM= X-Received: by 10.46.157.136 with SMTP id c8mr5722006ljj.85.1524180424705; Thu, 19 Apr 2018 16:27:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.131.71 with HTTP; Thu, 19 Apr 2018 16:27:03 -0700 (PDT) In-Reply-To: <39125178-cf16-a0d4-7747-5cc84c421414@wizmail.org> References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <39125178-cf16-a0d4-7747-5cc84c421414@wizmail.org> From: "Murray S. Kucherawy" Date: Thu, 19 Apr 2018 16:27:03 -0700 Message-ID: To: Jeremy Harris Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="883d24f220a0c9cb3b056a3be874" 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: Thu, 19 Apr 2018 23:27:09 -0000 --883d24f220a0c9cb3b056a3be874 Content-Type: text/plain; charset="UTF-8" On Sun, Apr 8, 2018 at 10:59 AM, Jeremy Harris wrote: > Could we move towards a decision on this point? > > My current reading of the preferences expressed is > (apologies if I've misread anyone; please correct me): > [...] > This isn't really how we figure out whether all raised issues have been addressed. -MSK --883d24f220a0c9cb3b056a3be874 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Apr 8, 2018 at 10:59 AM, Jeremy Harris <jgh@wizma= il.org> wrote:
Could we move towards a decision = on this point?

My current reading of the preferences expressed is
(apologies if I've misread anyone; please correct me):
[...]

This isn't really how we figu= re out whether all raised issues have been addressed.

-MS= K
--883d24f220a0c9cb3b056a3be874-- From nobody Thu Apr 19 16:48: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 00C8D126CB6 for ; Thu, 19 Apr 2018 16:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=LUNAXRXK; dkim=pass (1536-bit key) header.d=taugh.com header.b=k2Ng46QF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Arn5mODJyJf3 for ; Thu, 19 Apr 2018 16:48:12 -0700 (PDT) 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 88055124B0A for ; Thu, 19 Apr 2018 16:48:12 -0700 (PDT) Received: (qmail 83047 invoked from network); 19 Apr 2018 23:48:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14465.5ad92abb.k1804; bh=XPNeMW1C4G8KlvYSaozD1/N13sGt01IuKhIPE4D+JWY=; b=LUNAXRXKShpznWWTTeYRES7naWsz5g9Ugk//99/vgccsDcS5SPsBI1RBYgnye/0P4w9buq7CnkBkRvUnKgUrNejeNe6H+FPoEnzjxDAWZWm2WuoTM/Xngz0m8LyocCKrf2f3IzXoj25J52bdv3807jGz9xKUWxod6P7pdG92eCUJ4N04GfELBfXnXfqicgtbb9S4ioTzUQ+WeMddBu/nsOAUY6DNCMDiBpNA1GMNj0jXTHgxBgeLRTCcj7cqfUSP 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=14465.5ad92abb.k1804; bh=XPNeMW1C4G8KlvYSaozD1/N13sGt01IuKhIPE4D+JWY=; b=k2Ng46QFWMccT/I5PLKx3rLukMpTfm2OR/f6U48YugI5qQMgFcaHk89vndLuKAUaN8L5f8fdS5i5+MnAPwoL9Bm3DGRaaqL5OptZ4QXmt48yj/El7NZjgd26a26n3kM1PeN9XnvWXSj7PAvogwEAuLC6eP0COpdV/cM/cqUvAWC5vZdLE7S4yTJiszm3NGLJFzmA25i04n1+zFHKKhZVDhWjS9OeRBPFIpo0/HIwvtccD6iQ6VHNIz9Kfe2HKH27 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; 19 Apr 2018 23:48:10 -0000 Received: by ary.qy (Postfix, from userid 501) id BA7FC25424D9; Thu, 19 Apr 2018 19:48:10 -0400 (EDT) Date: 19 Apr 2018 19:48:10 -0400 Message-Id: <20180419234810.BA7FC25424D9@ary.qy> From: "John Levine" To: dcrup@ietf.org Cc: stan@glyphein.mailforce.net In-Reply-To: <38A90ECD-6AF4-4A85-A4DB-F0748DF3F368@glyphein.mailforce.net> 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] sample signatures, was 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: Thu, 19 Apr 2018 23:48:14 -0000 In article <38A90ECD-6AF4-4A85-A4DB-F0748DF3F368@glyphein.mailforce.net> you write: >> Just the key without wrapping. As soon as someone can send me a sample signed message to splice into the draft, I think it'll really be done. R's, John From nobody Thu Apr 19 18:07:41 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 BC5B212E8A4 for ; Thu, 19 Apr 2018 18:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1rlUfHnbXwe for ; Thu, 19 Apr 2018 18:07:38 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52A11270AB for ; Thu, 19 Apr 2018 18:07:37 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id o123-v6so193780lfe.8 for ; Thu, 19 Apr 2018 18:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pF0MFIprbxQQ6QR0p5760Q0UJUh54AxWgoTZ4SJ2MUw=; b=ZMgTJIGkYNFidkp+R9H1pDjcJxlVysc8TduD7MJt7/uew6trp8G3FOZ3XIUmJxNwc+ rz8kl2JmJj7mtJh6F+54quaebfeOL5fkTYCLiidHoTkbOQw5wK8qCfYhsvDLtRJosLkZ VlEnIULxZgYkNV9pTDlolglrCoH15bkl5b3GAAle4XgfQB1KFR9zVZHsMHTYTsi12V9j dqfI2r7lRA3esojyVfUiZ79HHmX+6T76qfgNq/QuHt7PLlgdqJhvtZkdSfEJ18GxHWsf vlAW/+OKB14E8dstNVasykY6HX3nFbcuhH0iNtQVCCQDcUn7mjv4jRAnp/nPEN4Dr3ZS Kvzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pF0MFIprbxQQ6QR0p5760Q0UJUh54AxWgoTZ4SJ2MUw=; b=Qf77N6FFiF1xOqe0w/T4icnX5MWfpQIcpqcWqmsLRdv/Q7UYHZrzaP9FDydcS5CA0j iWx0t/xTWLMHD1wJtCO8+n1JLm7dzVOO38ODy+fRWGCADUa4xY3XJBu1oJxjRJ3yHlxy VTqYc2hXd28UNh/3+R1n4dvcLCDQL9qhPpTlra2Kj2JtQUvy7FuyIwjv0IaNuW+kQCTP mX4unjR5Bcn0oHTcUYA0mC9mXw+pHLJ1/bb7dqck9hqaBl8Es2d1QSPeVcAICyVrhZ52 no4yPGPFQ4ESSIWn9MI0xANMVEJ3kTZ79Z2iMcy3cvWHuFeN8wm+sdU+YAdsKH7c3yeV 70/g== X-Gm-Message-State: ALQs6tBMMPTyBsfFXqgjJsNLG7cFODA290olU46za9CB89xlfvOy8nGx 4KlrMv6POrXrnMGryRX3wiedGrfymbzwpTuNmBM= X-Google-Smtp-Source: AIpwx49O5phEX20sBP4d83Z3VnNC/C3Ava+QNf/M9ffLXWjgFN07wLFmfJoBCPMj8HPbxV/KHwVN5/HehjGs1UmOxnQ= X-Received: by 10.46.20.10 with SMTP id u10mr5850363ljd.61.1524186456027; Thu, 19 Apr 2018 18:07:36 -0700 (PDT) MIME-Version: 1.0 References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.com> <20180328094636.Horde.Np3GCcO8iEPwmQzOaaUjbrh@andreasschulze.de> <2897E6E0-4535-4EC1-9686-E080CCA82D21@akamai.com> <765B1211-E03B-459A-9F20-B1ABCD5F61AF@akamai.com> In-Reply-To: <765B1211-E03B-459A-9F20-B1ABCD5F61AF@akamai.com> From: "Murray S. Kucherawy" Date: Fri, 20 Apr 2018 01:07:24 +0000 Message-ID: To: "Salz, Rich" Cc: "A. Schulze" , Phillip Hallam-Baker , "dcrup@ietf.org" , denis bider Content-Type: multipart/alternative; boundary="f403045fbf644877e3056a3d5090" 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: Fri, 20 Apr 2018 01:07:40 -0000 --f403045fbf644877e3056a3d5090 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2018 at 10:37 AM, Salz, Rich wrote: > > - We will have to have a consensus decision on this. Let=E2=80=99s le= t the > discussion run for a few more days. If you have anything new to menti= on, > please speak up. Otherwise it seems to me that the choice will be > > ASN1/DER wrap the Ed25519 key > > Just the key without wrapping. > > > > Discussion seems to have died down, and it seems the =E2=80=9Craw key=E2= =80=9D without any > wrapping (such as OID/octet-string) is the consensus. Does anyone * > *DISAGREE** with that? > I don't have any objection to declaring the consensus that way at this point. Thanks to everyone who participated in the discussion -- which I'm glad we have on the record in case the IESG or a Last Call reviewer asks about this point -- and, for the most part, keeping it civil. Barry (who has volunteered to shepherd), please begin your write-up work at your convenience. -MSK --f403045fbf644877e3056a3d5090 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --f403045fbf644877e3056a3d5090-- From nobody Thu Apr 19 18:19: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 5EF91127076 for ; Thu, 19 Apr 2018 18:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=5vUBvMCZ; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Q6MyUXf9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkyhMCO1VCGw for ; Thu, 19 Apr 2018 18:19:12 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9C3126C83 for ; Thu, 19 Apr 2018 18:19:12 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1524187151; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=M9bchkfwpi0fHV9Y22RR5XmYdGRVI9XsdXT06+aJ4z0=; b=5vUBvMCZ5Q/06oXkkRs/+2jLzUkQNebFG9JjgBHuZ9L6wi4cqiXEHt1M MKaJi43eq4YdnckmICB59Z5ZS39SAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1524187151; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=M9bchkfwpi0fHV9Y22RR5XmYdGRVI9XsdXT06+aJ4z0=; b=Q6MyUXf9fjj6GpNQv9fdHt30vR1yyi3ToUJ4FAnuqTwLGAX7um6sCken Va0CvbawL7AqdYD8xOQ08A3OKEVPjPfd4i3nteObzMGhR7foYdnggdeQDF 4pa4m/lzw1DePUadcw6vup2fjzwVNgFbpmR3fiMATW7YW/HbQhTMnL+QNK DDpLS0W2Xd98pCK+RiJ6Ws35qpu6BW2bSZJEPZSWsGcqxG8OaTr7DnBE9l nkWhF86uRf4G6R7DLWQsAHCjdlNyi5c9ExWEdOy+bUky4heaDkLh7XRXUa 4GO5moNSeLEutXo+fjIHfzhnw+OOfl1Kg6NTH/ynOtyz/IRo1P2HSQ== Received: from [192.168.1.146] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (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 2AC19C40282; Thu, 19 Apr 2018 20:19:11 -0500 (CDT) Date: Fri, 20 Apr 2018 01:19:06 +0000 In-Reply-To: <20180419234810.BA7FC25424D9@ary.qy> References: <20180419234810.BA7FC25424D9@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: <7340B387-8FB4-4A09-8886-128DAEFEC6B7@kitterman.com> Archived-At: Subject: Re: [Dcrup] sample signatures, was 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: Fri, 20 Apr 2018 01:19:14 -0000 On April 19, 2018 11:48:10 PM UTC, John Levine wrote: >In article ><38A90ECD-6AF4-4A85-A4DB-F0748DF3F368@glyphein=2Emailforce=2Enet> you >write: >>> Just the key without wrapping=2E > >As soon as someone can send me a sample signed message to splice into >the draft, I think it'll really be done=2E > IIRC, at [1], rfc6376=2Esigned=2Emsg and rfc8032_7_1=2Ekey have what you= need=2E Scott K [1] https://git=2Elaunchpad=2Enet/dkimpy/tree/dkim/tests/data From nobody Thu Apr 19 18:24: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 2B59A127076 for ; Thu, 19 Apr 2018 18:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=nkZdFlqW; dkim=pass (2048-bit key) header.d=kitterman.com header.b=GozejpMw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRIP7b9ZPrLy for ; Thu, 19 Apr 2018 18:24:21 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ADD7126C83 for ; Thu, 19 Apr 2018 18:24:21 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1524187459; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=RtOQcjScG5LKUD8qnPjALat8PAV0Qk3h9YDWj+q7jLc=; b=nkZdFlqWbBwYsDmUcSjj2Iulndsi4I2YliE45Sz9+wKJtVJHZKG3GYKc agAaXpjUdVSolL4HdHCLs/C69020Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1524187459; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=RtOQcjScG5LKUD8qnPjALat8PAV0Qk3h9YDWj+q7jLc=; b=GozejpMwoqt2PvGTjD1mEb9IgZkvEzWYGEADG2oVvC9pk+KGk6t9xvW2 JV1UwEebSa7jb11EyMQ6nka0Oc9kFsOswl6j+4jfpk5xj3Zmdbivl05G26 EtDvjTnyLHIGwCdmsyxOniTSAdDZvf6KGW2K9AVOV+oj4DTlQPy32Fq1Cd VPJyhyAic/Bao2fFOacNSG3iPh6NnIpbAQxfjwo/zhrZzcNyv6ifdE2xmg 9FyZMZSLiP4C0TJKy8zpC0KoxskVtA/fSVp/KOIxMKrps4Hq5h94sLTF1O EjFzV5EAykX3FgJtHJevvDf0Y0opcZJ2653QkMd++g6awjc0gqr12w== Received: from [192.168.1.146] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (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 C4FF3C40282; Thu, 19 Apr 2018 20:24:19 -0500 (CDT) Date: Fri, 20 Apr 2018 01:24:17 +0000 In-Reply-To: <7340B387-8FB4-4A09-8886-128DAEFEC6B7@kitterman.com> References: <20180419234810.BA7FC25424D9@ary.qy> <7340B387-8FB4-4A09-8886-128DAEFEC6B7@kitterman.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: Archived-At: Subject: Re: [Dcrup] sample signatures, was 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: Fri, 20 Apr 2018 01:24:23 -0000 On April 20, 2018 1:19:06 AM UTC, Scott Kitterman = wrote: > > >On April 19, 2018 11:48:10 PM UTC, John Levine wrote: >>In article >><38A90ECD-6AF4-4A85-A4DB-F0748DF3F368@glyphein=2Emailforce=2Enet> you >>write: >>>> Just the key without wrapping=2E >> >>As soon as someone can send me a sample signed message to splice into >>the draft, I think it'll really be done=2E >> > >IIRC, at [1], rfc6376=2Esigned=2Emsg and rfc8032_7_1=2Ekey have what yo= u >need=2E I forgot to mention that the private key is base64 encoded binary key from= RFC 8032 7=2E1, the first example=2E >Scott K > >[1] https://git=2Elaunchpad=2Enet/dkimpy/tree/dkim/tests/data