From nobody Tue Mar 6 06:24:20 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 34E00127076 for ; Tue, 6 Mar 2018 06:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-mMooKH51Lt for ; Tue, 6 Mar 2018 06:24:17 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A156E1270AE for ; Tue, 6 Mar 2018 06:24:17 -0800 (PST) Authentication-Results: w1.wizint.net; 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.109) id 1etDVn-0001QY-PA for dcrup@ietf.org (return-path ); Tue, 06 Mar 2018 14:24:15 +0000 To: dcrup@ietf.org References: <20180207171204.F0F0C1A5E207@ary.qy> <4405549.Ah4LRhlE6C@kitterma-e6430> From: Jeremy Harris Message-ID: <35d77dd5-8ded-7c82-1cd6-accdefa3156e@wizmail.org> Date: Tue, 6 Mar 2018 14:24:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Dcrup] WGLC final issues draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 14:24:19 -0000 On 25/02/18 09:43, Murray S. Kucherawy wrote: > Scott or Jeremy, > > Do you happen to have the sample key and message you used to generate these > in a file I can easily grab for testing an OpenDKIM revision that supports > the new key type? I tried to reply offlist, but possibly "Murray S. Kucherawy" does not actually get to you... I've not seen that Scott has re-generated the info yet. I do have a public-facing MTA (not the one sending this message) which handles it, should you want to test interop. -- Cheers, Jeremy From nobody Tue Mar 6 07:25: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 E3C06124D68 for ; Tue, 6 Mar 2018 07:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLd6Dbekf42E for ; Tue, 6 Mar 2018 07:25:04 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FEC3120454 for ; Tue, 6 Mar 2018 07:25:04 -0800 (PST) Received: from [10.121.179.7] (mobile-166-170-34-140.mycingular.net [166.170.34.140]) (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 02E19C40109; Tue, 6 Mar 2018 09:25:02 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1520349903; bh=WQAhh2NLrKQS9iYrW75/y9dvIBecKZ423NcZLRVrUwI=; h=Date:In-Reply-To:References:Subject:To:From:From; b=TDGZ9CeF9vn/JZKlhEGNcNdGJTAVvMd+0SbAdGzv21/9SN5ZfNZFfwboQJG66tGuF qJ0b3a3QWYXBifaisA1clZpm0Dg1GqW/E4OQy0liqQzkZPkC1Cxg0yR+PdsSw2o5HW fV2xNhyzuOwHVA3FqJP3uc+slWlTlq+Iizd5RxKU= Date: Tue, 06 Mar 2018 15:24:59 +0000 In-Reply-To: <35d77dd5-8ded-7c82-1cd6-accdefa3156e@wizmail.org> References: <20180207171204.F0F0C1A5E207@ary.qy> <4405549.Ah4LRhlE6C@kitterma-e6430> <35d77dd5-8ded-7c82-1cd6-accdefa3156e@wizmail.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: <7F7A9AE2-ADA4-445E-9C7E-E4FA9D9C35F3@kitterman.com> Archived-At: Subject: Re: [Dcrup] WGLC final issues draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 15:25:11 -0000 On March 6, 2018 2:24:14 PM UTC, Jeremy Harris wrote: >On 25/02/18 09:43, Murray S=2E Kucherawy wrote: >> Scott or Jeremy, >>=20 >> Do you happen to have the sample key and message you used to generate >these >> in a file I can easily grab for testing an OpenDKIM revision that >supports >> the new key type? > >I tried to reply offlist, but possibly > "Murray S=2E Kucherawy" >does not actually get to you=2E=2E=2E > >I've not seen that Scott has re-generated the info yet=2E I do have >a public-facing MTA (not the one sending this message) which handles >it, should you want to test interop=2E https://bazaar=2Elaunchpad=2Enet/~dkimpy-hackers/dkimpy/trunk/view/head:/d= kim/tests/data/rfc6376=2Esigned=2Emsg If anyone wants to test interop, contact me offlist and I'll give you an a= ddress you can mail=2E Scott K From nobody Tue Mar 13 16:41: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 062ED12422F for ; Tue, 13 Mar 2018 16:41:24 -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=KLH2ahuY; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=t8kYWmSn 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 0p9n6aZA_KO0 for ; Tue, 13 Mar 2018 16:41:22 -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 04691126DFB for ; Tue, 13 Mar 2018 16:41: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=1520984478; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=Gr7Hgbv1BMMwUhlJGUB8GDVZtreKanHpCdDJ01ZGgLU=; b=KLH2ahuYYfLjDc8j6Gb0KUbuPwXoABjw6zWWl0ho3TOOEkqUslnTRSOB d17Lv5XtAMRZMYubsk/6r7NHDMYeCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1520984478; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=Gr7Hgbv1BMMwUhlJGUB8GDVZtreKanHpCdDJ01ZGgLU=; b=t8kYWmSnd/lTwN05D/V0FpPSEcAeW2MyuZ1pbxVfeL1e3notYSXqYHqu 4V9BgKKbzAIiBwEx3XGMdVWnqeVpy728Q2QcsDQ5zAR1CSm21aDW1bi4L1 l28qtGJRcTt2UmZGJtk1Nlo34dSd/k/AFmCEo0C3n1yhaJuUTXyaelJgTp QGCIQxfA7pI8jhzXhfK4ZoORL89hiVHlLstLqjpZXVP53EfsIQpNPRi4FA xO3vlraUNgry6Ogs6GKtFX0/nrUNzLRWEOo+wZDKI5h2LD+Ocs70QqXF2s szZtFczCUE102gSlmq+kP7c42WQz0ThVcbn3vGFIppWI9GhNOwAxNg== Received: from kitterma-e6430.localnet (unknown [50.94.114.71]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D2727C40109 for ; Tue, 13 Mar 2018 18:41:18 -0500 (CDT) From: Scott Kitterman To: dcrup@ietf.org Date: Tue, 13 Mar 2018 19:41:17 -0400 Message-ID: <10210075.4ZMJhRTKdM@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-139-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1594199.fQmGbeNpCI@kitterma-e6430> References: <1594199.fQmGbeNpCI@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [Dcrup] Sendmail/Postfix Milter With Ed25519 Support 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, 13 Mar 2018 23:41:24 -0000 As a mentioned several weeks ago, I've been working on a Python based DKIM milter with Ed25519. That's to help from Andreas Schulze and Jim Fenton it's mature enough (I hope) to let more people know about it and take it for a spin. If you are interested, you can get it either through pypi.python.org [1] or from the project home page on Launchpad [2]. You can either install from source (follow the directions in the provided README) or using pip. In order to make it easy for people to experiment with this, I mostly reused OpenDKIM option names, so (at least for the options supported, this does way less than OpenDKIM), configuration files should be compatible. This is a one time announcement. For support you can either email me or use the Launchpad Questions [3], or Launchpad Bugs [4]. [1] https://pypi.python.org/pypi/dkimpy-milter/ [2] https://launchpad.net/dkimpy-milter [3] https://answers.launchpad.net/dkimpy-milter [4] https://bugs.launchpad.net/dkimpy-milter I know it's annoying to sign up for another service, but I'd really prefer one of the last two methods to discuss the project, so then it doesn't get lost in my email. So far, all the testing has been done on Debian Stable using the default init system (systemd). There is a sysv init provided, but no one has been able to completely test it. It would be good to get inputs from people on other distributions/operating systems. I'll be glad to document more if I have inputs. If anyone is willing to test this in a high volume application, even for a short period, please contact me and we can work out how best to do it safely. I believe it's reasonably scalable (it's a thin layer of python on top of C bindings to libsodium for crypto and libmilter for MTA integration), but I don't have access to a high volume mail stream to inflict it on. It is a beta, so all the usual caveats apply, but I'm confident enough that I'm running it in production. Hopefully this helps move things along. On Saturday, February 17, 2018 11:46:45 PM Scott Kitterman wrote: > I think we'll have an example header here shortly. In the meantime, I've > got a DKIM milter running (experimentally) that signs/verifies Ed25519 (see > the signatures that hopefully won't get stripped off this message). > > I am in need of a Sendmail user to help me out with this effort. What I > have works in Postfix, but I've no way (or interest) in figuring out > Sendmail. If you're interested in having a milter to support Ed25519 and > aren't allergic to Python, please contact me off list. > > Scott K > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup From nobody Wed Mar 14 04:08:23 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 23C9D129C51 for ; Wed, 14 Mar 2018 04:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=GzkDRJSS; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=kePzgRrR 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 uxXQ303D1aLS for ; Wed, 14 Mar 2018 04:08: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 3755B1241F3 for ; Wed, 14 Mar 2018 04:08: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=1521025695; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : subject : from : date; bh=9SjaBmUZhR6WF9jOdpUPWityrwbiUhjByUF4eacVD2Q=; b=GzkDRJSSSYb0g1LxWmt3Hi+rJn34rJZ3OF5c5xxB3Ul3j+DELSzaPSlI gkzgsn1G8zotFP4gGBkBL6CAnWIWAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=ybz; t=1521025694; x=1526025694; bh=9SjaBmUZhR6WF9jOdpUPWityrwbiUhjByUF4eacVD2Q=; 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=kePzgRrRQbkxkXRX2ivOUtf7sp4/EWSgxN9as4Feoup8cMigHB3ytZpIyD6rvMLEq CeNVimYjrrtJkiPW1gPBBoRMc4MIOrl0jDXSNZ1+rCzzmkhtiJWK0Njo7ZmAvXHkMQ 2xlmW90I0S0a8K4MV0sS6tdtz0FjmTdJO3WsAAeeSJ1ycG2drSYjjOBU9ks/c0vjrl fj2M8TYslp4U+Kzo5FP7LfMNfbKI6JcT0brPe6kkcvS2Yzm+ee/arNGJh2p5ClLHvA RoXOrLH3BFpYDnXnodUHSdPTg898xrq+gRKIaMWE2dm2YdzVRkDO2qmkQMfDm1ypPV 6NYdh48MMsPyg== To: dcrup@ietf.org References: <1594199.fQmGbeNpCI@kitterma-e6430> <10210075.4ZMJhRTKdM@kitterma-e6430> From: "A. Schulze" Message-ID: Date: Wed, 14 Mar 2018 12:08:13 +0100 MIME-Version: 1.0 In-Reply-To: <10210075.4ZMJhRTKdM@kitterma-e6430> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Sendmail/Postfix Milter With Ed25519 Support 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, 14 Mar 2018 11:08:22 -0000 Am 14.03.2018 um 00:41 schrieb Scott Kitterman: > As a mentioned several weeks ago, I've been working on a Python based DKIM > milter with Ed25519. That's to help from Andreas Schulze and Jim Fenton it's > mature enough (I hope) to let more people know about it and take it for a > spin. > > If you are interested, you can get it either through pypi.python.org [1] or > from the project home page on Launchpad [2]. You can either install from > source (follow the directions in the provided README) or using pip. Hello, Thanks to Scott for the implementation! I like to mention that I have also a template to build a docker container: https://github.com/andreasschulze/docker-dkimpy-milter It's intended for personal use and require customization: * Dockerfile: change "FROM" * docker-compose.yml: change image name Andreas From nobody Wed Mar 14 06:28: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 5B63212711B for ; Wed, 14 Mar 2018 06:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.973 X-Spam-Level: X-Spam-Status: No, score=0.973 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_GREY=1.084] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNtQn-wIlWIh for ; Wed, 14 Mar 2018 06:28:31 -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 F1CC9127333 for ; Wed, 14 Mar 2018 06:28:30 -0700 (PDT) Received: (qmail 14219 invoked from network); 14 Mar 2018 13:28:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=3789.5aa9237d.k1803; bh=1AcErAYdHh5Z1UH6tA2CgS4Z4/jl1xRCH/j77JbkhGA=; b=raw+JDWV6sLQXGN+mDiuYaQDSQsvDyskozR+U3OcGFXGybbYoHSqQi/D97p/kXK5F99HI8vgWfjGUk9zlasVfaRqWpY/wx7JqtFmtAdusiifavJB5/LJ/zlvR8TGLDfWUtvJa1v2ReMMtH9VCL9bzJBteCa0GeDWMX5t9xr2zmKR7wX6HNM2/+wp3EGMpmrp6wdFA93XgcwRxtAkg7vR8KAlwEbw1T7ZFW5dOU4RbzZP0+tmRR0LksQJw7gzg4ph 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; 14 Mar 2018 13:28:29 -0000 Date: 14 Mar 2018 09:28:28 -0400 Message-ID: From: "John R. Levine" To: dcrup@ietf.org 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: [Dcrup] sha1 wall of shame 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, 14 Mar 2018 13:28:33 -0000 I went through my mail logs to see who's still signing with rsa-sha1. I wouldn't claim that my system is typical but some of these really should know better. R's. John 24 inbound.readersupportednews.org 21 email.nextdoor.com 19 marketwatchmail.com 16 geldenhuyslaw.com 15 reply.newsmax.com 15 nytimes.com 14 dfh-logistics.com 13 mail.salsalabs.net 12 sendgrid.info 12 castingfrontier.com 11 info.pentondes.com 10 public.govdelivery.com 10 mail.ecnmag.com 10 e.designworldonline.com 9 sg.actionnetwork.org 8 infusionmail.com 8 email.pvhba.com 8 email.keysight.com 7 townhallmail.com 7 mail.advantagebusinessmedia.com 6 newsletter.newyorker.com 6 mta-bbcspool.convio.net 6 memberservices.latimes.com 6 mail.wirelessdesignmag.com 6 inside.com 6 giftpacs.com 5 mail.rdmag.com 5 email.engineering360.com 4 walmart.com 4 thedailybeast.com 4 quora.com 4 ontramail.com 4 gotowebinar.com 4 enews.machinedesign.com 4 care.com 3 u.harvard.edu 3 subscriptions.uspto.gov 3 scr.org 3 navigatingcancer.com 3 morning7.theskimm.com 3 mail.pddnet.com 3 mail.dmnews.com 3 email.ucas.com 3 email.scmagazineus.com 3 email.microsoftemail.com 3 ed-email.techtarget.com 3 e.officedepot.com 3 credomobile.com 3 bounce.myngp.com 3 afsc.org 2 thomasnet.com 2 tastingtable.com 2 sierratradingpost.com 2 sendgrid.me 2 reply.ien.com 2 radiantretailapps.com 2 purewow.com 2 peoplesaction.org 2 newsweek-mail.com 2 media.ieee.org 2 mail.inddist.com 2 flagnotify.com 2 enews.newequipment.com 2 emails.underarmour.com 2 emails.sierraclub.org 2 email1.easternbank.com 2 email.zappos.com 2 email.tablethotels.com 2 email.fastcompany.com 2 em.target.com 2 ebay.com 2 ealerts.bankofamerica.com 2 e.outsideonline.com 2 e.nymag.com 2 e.medicaldesignandoutsourcing.com 2 e.massdevice.com 2 e.fluidpowerworld.com 2 e.etsy.com 2 dripemail2.com 2 cp20.com 2 broadwaybox.com 2 bnp-promotions.com 2 bnp-interactive.com 2 biologicaldiversity.org 2 aclusocal.org 1 yogaaccessories.com 1 wsj.com 1 worbix.com 1 wateremail.com 1 vresp.com 1 vox.com 1 vetdepot.com 1 ucsusa.org 1 ucc.org 1 thedreamcorps.org 1 swiftpage3.com 1 standwithsandra.org 1 socalgas.com 1 skyscanner.com 1 signupgenius.com 1 shermanstravel.com 1 salsalabs.org 1 rjbs.manxome.org 1 rickhanson.net 1 retevia.net 1 rapidmanufacturing.com 1 quantagreengels.com 1 pm.mtasv.net 1 pdamerica.org 1 pasadenaplayhouse.org 1 outboundsend.com 1 o.delta.com 1 nwlc.org 1 news.ecmconnection.com 1 ncjw.org 1 nationsend4.com 1 muckfestms.com 1 mfp.underarmour.com 1 messages.fwwatch.org 1 members.wayfair.com 1 medium.com 1 mass-creative.org 1 mailings.ticketmaster.co.uk 1 mail.zocdoc.com 1 mail.vividseats.com 1 mail.scmagazineus.com 1 mail.change.org 1 mail.aramarkparks.com 1 mail.alnmag.com 1 lyftmail.com 1 lists.toxicstargeting.com 1 lagunaplayhouse.com 1 ivy.com 1 itrustwomen.org 1 interactive.wsj.com 1 info.mouser.com 1 icontact.vn 1 iccsafe.org 1 hubspot.com 1 hotgadgetdeals.com 1 hms.harvard.edu 1 harborfreightemail.com 1 getpocket.com 1 fivethirtyeight.com 1 ewasteshop.com 1 et.npr.org 1 equisolve.com 1 enews.pentonmanufacturing.com 1 enews.hydraulicspneumatics.com 1 enews.electronicdesign.com 1 emails.evernote.com 1 email.thetileapp.com 1 email.microsoftrewards.com 1 email.listen360.com 1 email.homedepot.com 1 email-weightwatchers.com 1 email-aaa.com 1 em.ftd.com 1 e1.emeraldexpoinfo.com 1 e.mozilla.org 1 e.fitbit.com 1 douthitforcolorado.com 1 dlink.com 1 demandforced3.com 1 dccc.org 1 cryptonector.com 1 connect.scpr.org 1 cmail19.com 1 cm.zazzle.com 1 cleargov.co 1 bullhornmail.com 1 booking.com 1 au.org 1 atdi.com 1 andreasschulze.de 1 act.centerforfoodsafety.org 1 aclum.org 1 aadvantage.email.aa.com From nobody Wed Mar 14 06:39:46 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 2C02B12D0C3 for ; Wed, 14 Mar 2018 06:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=NyUelXa2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PpEgODVe 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 iqXHDFXR372t for ; Wed, 14 Mar 2018 06:39:43 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E803512D778 for ; Wed, 14 Mar 2018 06:39:42 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2FF9220D1E; Wed, 14 Mar 2018 09:39:42 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 14 Mar 2018 09:39:42 -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=fm2; bh=rXNc/JhohU9s95u6X FChfhpLTlx8dPXD3cHD2j4pwJo=; b=NyUelXa2gF+KYCUbrs0cEtqF97fr4xPNz gMaq8FG3h4a70DUyaITan3tilYI+YwmBtW0+ea/mjEW1vLy+IeK3kOcmn80VLLw+ Gc35zs8JKhaE5ZTah6bk8AZzmBLtxW6seIyIetZxGAabnKeUsSL5ZLkFVWo/MKcy lt6O8wrfeqRS9TJ+i5u7wkUmQ4UBhdb5iZZrnpDkM9S+afzp3s6YwdO/KHlsQK7m w6q/Ip7p7x3fg+0pfALEuTlGWk3QTNj3OT+jcQW5DpF9F7U1y4u5QAbTHdn0fVSe 5NsJM8xhMrgoBvHZUrVd+XLDog7dgzKjgnpj0gmpYTip2y3tV3RQw== 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=rXNc/J hohU9s95u6XFChfhpLTlx8dPXD3cHD2j4pwJo=; b=PpEgODVeuqAr2UhyaTQmy9 cGimjypdgJ/5ZE3AIn9JrQLi//XnDulEdHW6RwqyQ5ED91DxMvgKSdez1otiTPaP 8o96wVuEKjSgdUVusi3yhApsWVjqBiltxk3oc72ll/JZLuLeveKyRBuqCgPlDRdM 6AcI8UlqpKnftPZOFsRBExvYzGDXaz+tZkcrBvHFLlnRPXxCTohDi5SuLoKrNuIT DqHO7ecdtt4FjVGNb10vvrmX8brxisCPznvQl609q5+bGz+GT2vUAd69Fu/zyPpQ tuUXTOcI62gCwAuIkIYdwUWWXvLO191dSxAWXNIhhmQjHfCj2gHOj576w8KrpcTA == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id C74547E1D1; Wed, 14 Mar 2018 09:39:41 -0400 (EDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5D9767D9-653B-49C7-9759-7679419BE427@glyphein.mailforce.net> Cc: dcrup@ietf.org X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Wed, 14 Mar 2018 09:39:39 -0400 To: "John R. Levine" Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 14 Mar 2018 13:39:45 -0000 > On Mar 14, 2018, at 9:28 AM, John R. Levine wrote: >=20 > I went through my mail logs to see who's still signing with rsa-sha1. I w= ouldn't claim that my system is typical but some of these really should know= better. I didn't want to single them out, but since you've gone to the trouble to po= st a list, I'll note US-CERT's mailing lists still use rsa-sha1. Stan From nobody Wed Mar 14 07:55: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 0B95712D77A for ; Wed, 14 Mar 2018 07:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=iI8yYW0S; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=0pdynT+A 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 Rnpg5PrXoXCn for ; Wed, 14 Mar 2018 07:55:29 -0700 (PDT) Received: from ntbbs.winserver.com (ftp.catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8916512D7EC for ; Wed, 14 Mar 2018 07:54:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4518; t=1521039294; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=C+7wgWgWSIu79VopULd662zMf4k=; b=iI8yYW0SlTkn8uhWSBd57DRsabGy5QLlSD8b43Mf3sgvK2BO/zexLx6dGKART+ W0G6ObeV3DkQHziMYKLJgpMOLF37PopmU4byNWUqjSyX4m2NOVbD4UK4CW8+rZ1K lXISVua8cHD7SaLhjW2sIxdeqX+LxTXATFjIYVlgmf68g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Wed, 14 Mar 2018 09:54:54 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2317982013.1.1400; Wed, 14 Mar 2018 09:54:54 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4518; t=1521038937; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=8En1yL+ Sf72mbwd5xHY1IIdeYXDy1wvvI0DHL/J1I/8=; b=0pdynT+ANwCDVo85BymrHfL eqm0wqx4eUrUl96mgeF0AT2DhDcQfeqoG5ZcrxeMG784Vb2qn0sR+vm1PuGOHarE aW0xnIp8ikmmYY+gA8rZ3Ibqs7gKZb7isx0/d8INpUkEU8tX0O72kL8U1u6iXhTl DP7Y8j6QGSpaUVje0VRs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Wed, 14 Mar 2018 10:48:57 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2317843237.9.97576; Wed, 14 Mar 2018 10:48:56 -0400 Message-ID: <5AA937BD.60009@isdg.net> Date: Wed, 14 Mar 2018 10:54:53 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 14 Mar 2018 14:55:35 -0000 This is bullshit. You should know better. I ask that the chairs and the IETF cops to keep this crap out of here. On 3/14/2018 9:28 AM, John R. Levine wrote: > I went through my mail logs to see who's still signing with rsa-sha1. > I wouldn't claim that my system is typical but some of these really > should know better. > > R's. > John > > 24 inbound.readersupportednews.org > 21 email.nextdoor.com > 19 marketwatchmail.com > 16 geldenhuyslaw.com > 15 reply.newsmax.com > 15 nytimes.com > 14 dfh-logistics.com > 13 mail.salsalabs.net > 12 sendgrid.info > 12 castingfrontier.com > 11 info.pentondes.com > 10 public.govdelivery.com > 10 mail.ecnmag.com > 10 e.designworldonline.com > 9 sg.actionnetwork.org > 8 infusionmail.com > 8 email.pvhba.com > 8 email.keysight.com > 7 townhallmail.com > 7 mail.advantagebusinessmedia.com > 6 newsletter.newyorker.com > 6 mta-bbcspool.convio.net > 6 memberservices.latimes.com > 6 mail.wirelessdesignmag.com > 6 inside.com > 6 giftpacs.com > 5 mail.rdmag.com > 5 email.engineering360.com > 4 walmart.com > 4 thedailybeast.com > 4 quora.com > 4 ontramail.com > 4 gotowebinar.com > 4 enews.machinedesign.com > 4 care.com > 3 u.harvard.edu > 3 subscriptions.uspto.gov > 3 scr.org > 3 navigatingcancer.com > 3 morning7.theskimm.com > 3 mail.pddnet.com > 3 mail.dmnews.com > 3 email.ucas.com > 3 email.scmagazineus.com > 3 email.microsoftemail.com > 3 ed-email.techtarget.com > 3 e.officedepot.com > 3 credomobile.com > 3 bounce.myngp.com > 3 afsc.org > 2 thomasnet.com > 2 tastingtable.com > 2 sierratradingpost.com > 2 sendgrid.me > 2 reply.ien.com > 2 radiantretailapps.com > 2 purewow.com > 2 peoplesaction.org > 2 newsweek-mail.com > 2 media.ieee.org > 2 mail.inddist.com > 2 flagnotify.com > 2 enews.newequipment.com > 2 emails.underarmour.com > 2 emails.sierraclub.org > 2 email1.easternbank.com > 2 email.zappos.com > 2 email.tablethotels.com > 2 email.fastcompany.com > 2 em.target.com > 2 ebay.com > 2 ealerts.bankofamerica.com > 2 e.outsideonline.com > 2 e.nymag.com > 2 e.medicaldesignandoutsourcing.com > 2 e.massdevice.com > 2 e.fluidpowerworld.com > 2 e.etsy.com > 2 dripemail2.com > 2 cp20.com > 2 broadwaybox.com > 2 bnp-promotions.com > 2 bnp-interactive.com > 2 biologicaldiversity.org > 2 aclusocal.org > 1 yogaaccessories.com > 1 wsj.com > 1 worbix.com > 1 wateremail.com > 1 vresp.com > 1 vox.com > 1 vetdepot.com > 1 ucsusa.org > 1 ucc.org > 1 thedreamcorps.org > 1 swiftpage3.com > 1 standwithsandra.org > 1 socalgas.com > 1 skyscanner.com > 1 signupgenius.com > 1 shermanstravel.com > 1 salsalabs.org > 1 rjbs.manxome.org > 1 rickhanson.net > 1 retevia.net > 1 rapidmanufacturing.com > 1 quantagreengels.com > 1 pm.mtasv.net > 1 pdamerica.org > 1 pasadenaplayhouse.org > 1 outboundsend.com > 1 o.delta.com > 1 nwlc.org > 1 news.ecmconnection.com > 1 ncjw.org > 1 nationsend4.com > 1 muckfestms.com > 1 mfp.underarmour.com > 1 messages.fwwatch.org > 1 members.wayfair.com > 1 medium.com > 1 mass-creative.org > 1 mailings.ticketmaster.co.uk > 1 mail.zocdoc.com > 1 mail.vividseats.com > 1 mail.scmagazineus.com > 1 mail.change.org > 1 mail.aramarkparks.com > 1 mail.alnmag.com > 1 lyftmail.com > 1 lists.toxicstargeting.com > 1 lagunaplayhouse.com > 1 ivy.com > 1 itrustwomen.org > 1 interactive.wsj.com > 1 info.mouser.com > 1 icontact.vn > 1 iccsafe.org > 1 hubspot.com > 1 hotgadgetdeals.com > 1 hms.harvard.edu > 1 harborfreightemail.com > 1 getpocket.com > 1 fivethirtyeight.com > 1 ewasteshop.com > 1 et.npr.org > 1 equisolve.com > 1 enews.pentonmanufacturing.com > 1 enews.hydraulicspneumatics.com > 1 enews.electronicdesign.com > 1 emails.evernote.com > 1 email.thetileapp.com > 1 email.microsoftrewards.com > 1 email.listen360.com > 1 email.homedepot.com > 1 email-weightwatchers.com > 1 email-aaa.com > 1 em.ftd.com > 1 e1.emeraldexpoinfo.com > 1 e.mozilla.org > 1 e.fitbit.com > 1 douthitforcolorado.com > 1 dlink.com > 1 demandforced3.com > 1 dccc.org > 1 cryptonector.com > 1 connect.scpr.org > 1 cmail19.com > 1 cm.zazzle.com > 1 cleargov.co > 1 bullhornmail.com > 1 booking.com > 1 au.org > 1 atdi.com > 1 andreasschulze.de > 1 act.centerforfoodsafety.org > 1 aclum.org > 1 aadvantage.email.aa.com > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > -- HLS From nobody Thu Mar 15 05:02: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 9DCB8126CD8 for ; Thu, 15 Mar 2018 05:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFD8-YJlHpBE for ; Thu, 15 Mar 2018 05:02: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 8BC7B1241F3 for ; Thu, 15 Mar 2018 05:02:01 -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 w2FBq5YH000305; Thu, 15 Mar 2018 12:01:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Zsnu7snIvOM4fGq44nnFjmyVvp5BndSoQziWUkNIj8w=; b=ZMcpVXkUNVxIkqsnUH6c8FD/HkvmbeojooHWetVSBtKMiw2mTfUuV6H6rDf22aTlF4qQ WCzu0LxqnetCQ1I7J6+vJhcR01tyge9CTWD7B3anAFveToT/CMxb1ARkh+9aLj6vYhqo /uK8moJty8cbPjsTNtliXKvPDaa5gCpO8w3mDb/ok5MnX9fksRF9GU+vhXpUwNk2YaQL 3HT4pzRBeDpST2Z8AQdodclaqzIh05gb1sKqDq9tjZJuWW41SoxVjCm8Bch4FVZdfNs+ KkMphdbhdhb8nPUyvYZdX6VqWLVrB0Um+nYRyFXwxoO2mEbBQxaTx0nn9NrsMNY+kxdS tw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2gpjrh4yh5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Mar 2018 12:01:59 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w2FC1Fkg026264; Thu, 15 Mar 2018 08:01:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2gmbk01bk7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 15 Mar 2018 08:01:58 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 15 Mar 2018 08:01:57 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 15 Mar 2018 08:01:58 -0400 From: "Salz, Rich" To: Hector Santos , "dcrup@ietf.org" Thread-Topic: [Dcrup] sha1 wall of shame Thread-Index: AQHTu5hcEol5MR2ikUWgD18Uq8+TbqPQFK6AgAEe4gA= Date: Thu, 15 Mar 2018 12:01:57 +0000 Message-ID: <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> References: <5AA937BD.60009@isdg.net> In-Reply-To: <5AA937BD.60009@isdg.net> 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.32.111] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-15_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=849 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803150135 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-15_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=801 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803150134 Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 15 Mar 2018 12:02:08 -0000 PiAgICBUaGlzIGlzIGJ1bGxzaGl0LiBZb3Ugc2hvdWxkIGtub3cgYmV0dGVyLiAgSSBhc2sgdGhh dCB0aGUgY2hhaXJzIGFuZCANCiAgICB0aGUgSUVURiBjb3BzIHRvIGtlZXAgdGhpcyBjcmFwIG91 dCBvZiBoZXJlLg0KICANCldoYXQgaXMgYnVsbHNoaXQsIGV4YWN0bHk/ICBXZSBzaG91bGRuJ3Qg bGlzdCBzaXRlcyB0aGF0IHVzZSBzaGExPyAgUGxlYXNlIGNsYXJpZnkuDQogDQoNCg== From nobody Thu Mar 15 06:51:30 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 3859612AAB6 for ; Thu, 15 Mar 2018 06:51:30 -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=tx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeogS_WI-v06 for ; Thu, 15 Mar 2018 06:51:29 -0700 (PDT) Received: from emu.tx.net (emu.tx.net [141.198.193.124]) (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 24C0C129C70 for ; Thu, 15 Mar 2018 06:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tx.net; s=default; t=1521121959; bh=xygksBYcvWznH25/tpAYTO47eoWEy28ttZj/1hvR5/A=; h=Subject:From:To:Date:In-Reply-To:References; b=NPcRkWrY12A1eUX/G+nAktu3zU1Q1LSXuC52rOk47HdUZy+Z5DnYBVZ50MJ6dCHni L1qkb1ifwtQwdW4RIjktQFVPV/ZQ6RO6VMGMNfzprDiCn+Wtf44vU1SW13kttJtm9l NRmBnuq5p0MfJletyfH3990H7NdAESspJyg4qowRzI1bxGjP/XZpg6I5FSLYfGmU3e K1P4JYOvysX3YxIz779EFZiGnPOpRs4FK4oD4iHJB3MDNMe9k/wTH9fFHC20pd0OPw px2KSm2+j/NtU6yw+Aaq+wUndcPB0pEH44MTkcy10f0kQd/0afN4CkqnLBUWDw/ZM8 vvhZxLWLdplkw== X-Received-From: bryan@tx.net X-Delivered-To: dcrup@ietf.org X-Originating-IP: [141.198.160.96] X-Site-Policy: NO UBE, NO UCE, NO spam Received: from asimov (mokee.texan.state.tx.us [141.198.160.96]) (authenticated bits=0) by emu.tx.net (8.15.2/8.15.2/20111115.a.EL) with ESMTPA id w2FDqaHZ014743; Thu, 15 Mar 2018 08:52:37 -0500 (CDT) (envelope-from bryan@tx.net) X-EL-Whitelist: sent via whitelisted host Message-ID: <1521121872.3815.118.camel@tx.net> From: Bryan Bradsby To: Hector Santos , "dcrup@ietf.org" Date: Thu, 15 Mar 2018 08:51:12 -0500 In-Reply-To: <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 15 Mar 2018 13:51:30 -0000 >    the IETF cops to keep this crap out of here. Since when is the truth not wanted? -bryan From nobody Thu Mar 15 09:32:24 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 280D81252BA for ; Thu, 15 Mar 2018 09:32:19 -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=QcOI5nG+; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=Cqqrb1IQ 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 qktAl9sIs5Z5 for ; Thu, 15 Mar 2018 09:32:17 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 38E381274D2 for ; Thu, 15 Mar 2018 09:32:17 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1833; t=1521131527; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=GHl+iN/jjVHvELhv3HvL9pA4d6Q=; b=QcOI5nG+F4Xu7oRHU20bI/qihBFBwNZEE3wcrytBsfQAGIEci2qFXiTa6yDMOD jlrpuWl1NTVLioakcQ87sGcVG1LxCaDsVWB2bIEIpCoAcvalEx2kGx2rSdcFPUhZ EFY3IFiayj+W+LtwRT5t6f6lrwvq40v9bmTCzC8eGA1xg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 15 Mar 2018 11:32:07 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2410213439.1.6620; Thu, 15 Mar 2018 11:32:06 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1833; t=1521131169; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=IJfNx0K PolXGk1KufvzOY0FgFkrEhOidcin65b/vKtk=; b=Cqqrb1IQImCyQE/A/de0t1s fH0hFHRz/cwSb+bCKo3PDWFEyu8aErvSQOuE29pEV6xPh7SyZnQsbeICa2mW/Gp9 TKNFQoWwR2xYcoD1uxV85GMJ1iYEf0QFtz881Vb67xfYIAdDksvdIwZX9T7P2VUx blOugWc+kH26w6j2HUQU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 15 Mar 2018 12:26:09 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2410074971.9.266588; Thu, 15 Mar 2018 12:26:08 -0400 Message-ID: <5AAAA008.6090807@isdg.net> Date: Thu, 15 Mar 2018 12:32:08 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> In-Reply-To: <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 15 Mar 2018 16:32:19 -0000 On 3/15/2018 8:01 AM, Salz, Rich wrote: >> This is bullshit. You should know better. I ask that the chairs and > the IETF cops to keep this crap out of here. > > What is bullshit, exactly? We shouldn't list sites that use sha1? Please clarify. If you have to ask why.... First, I don't wish to participate in a game of public "shaming." Pointing out SHA1 usage is one thing, Shaming them is another. You should know better. Second, Its only been a few months and there is bound to be untold number of domains, legacy or otherwise using a perfectly valid SHA1 lower overhead hashing method based on a standard DKIM document and RFCs before it for many years. You CAN NOT expect these domains to be switching anytime soon. Unrealistic. Third, have you bothered to see if they even need DKIM? I bet most of them, if not all of them, then don't have a DKIM POLICY or it is very relaxed, i.e. p=none. What they may have is a strong SPF policy which is generally good enough. You don't need DKIM with a strong SPF, especially if they have a HardFail (-ALL). Forth, there is certainly shaming that can go around against that do. For example, shame on those (like akamai.com) for not having an SPF record. Queries with NXDOMAIN results against your domain are higher overhead. You have a DMARC record, but no SPF record. You have no protection at SMTP, even more receiver overhead to handle and help protect your mail, you are asking receivers to do. All this is far worst than using a DKIM SHA1 because its real today. Fifth, many legitimate domains will continue to use SHA1 in some fashion and and machines for various reasons, including compatibility and product support with other domains and customers. Do I really need to go further? I hope not. Please stop the SHA1 shaming. -- HLS From nobody Thu Mar 15 09:51: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 4C9CC126D73 for ; Thu, 15 Mar 2018 09:51:51 -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=VTgqP+82; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=ovGHe32T 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 hdBJLOcCKgQ7 for ; Thu, 15 Mar 2018 09:51:45 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3943D124B0A for ; Thu, 15 Mar 2018 09:51:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=213; t=1521132697; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=p61ZUX3Qw/KJ2VuL7xbd59K+csE=; b=VTgqP+82aKyHHmM0WPHqRyZNPtBVCyPB6H4LY+7oXT9XMQT8cwNkg1F3Hq89NT OXRyZeSQVkAzxJIDxXC/EJwp0nYjjr4xQq4Ue+EV4fGCCDAMNJp/8pBBoG+2l1Ms q2aDOVDveyRNG7Pwqx57Qy8qFZ9rukNmhJPihh28CE8QM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 15 Mar 2018 11:51:36 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2411383384.1.8688; Thu, 15 Mar 2018 11:51:36 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=213; t=1521132340; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=o0CsxF7 7WGnDNjWqctHs89ojBjmYwAjwwyi7Al6tau0=; b=ovGHe32TOYgyP1N+3KPhq0b JqUijPTeNRXukqAxINGaiCximkJPT96NymoS/VZ3Oa0TuEcvSR9xf8+MClBtHibT Zc28H4nSNgJqookEBdLtDYJmfS8RkkGjasqEc21SSfnn4ASitLyH7Nze+MT09W8T j6rkqMWIS8ajDvyrrx/Y= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 15 Mar 2018 12:45:39 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2411246455.9.266800; Thu, 15 Mar 2018 12:45:39 -0400 Message-ID: <5AAAA49C.7020401@isdg.net> Date: Thu, 15 Mar 2018 12:51:40 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <1521121872.3815.118.camel@tx.net> In-Reply-To: <1521121872.3815.118.camel@tx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 15 Mar 2018 16:51:51 -0000 On 3/15/2018 9:51 AM, Bryan Bradsby wrote: >> the IETF cops to keep this crap out of here. > > Since when is the truth not wanted? Create a "SHAE1 Usage" report. Domain shaming is not necessary. -- HLS From nobody Thu Mar 15 10:03:45 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 740E812D7F0 for ; Thu, 15 Mar 2018 10:03:43 -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, 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=47ZVecfQ; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=ofE+/5Sh 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 AfSbSniOA8WB for ; Thu, 15 Mar 2018 10:03:42 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD278124B0A for ; Thu, 15 Mar 2018 10:03:41 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1521133419; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=8kwieYmGL14e39NQdiQcSkQsdMdZBu5Yjrqqnj//+7E=; b=47ZVecfQ+DhD/wpcH/F44NKkEz8pc30M6GrrI/dK4p+mELxmsTBivWJo p/TJqWeEev1kCFGXzVmTSU74ErNHDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1521133419; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=8kwieYmGL14e39NQdiQcSkQsdMdZBu5Yjrqqnj//+7E=; b=ofE+/5ShchPdJ91MX3qRMUntEnHACQ1sih20wQPChR92A4QuaWgrL4oV YghXyYx9eThyB4tz7SBKdcA6ecI5Y/2oSLTeYRthFnNkxHSV/Md37JuQ14 1wAvQArw8UaCSal581PuEpTTagsKYQ4qYWyMPEuZQ5PnvUBnYwFqbp64/n gjp7ViBOI+xFWVhI8a2yZjMYTPxGE27E/ozUi0PBZoRHKaQRgC74oJZgkI t6CG+o92rGqplspivUBYb+7VNIZx/WaxXDdLGPUoZ3zht9R0x5J7fnwVEh Z+8TKZEieackV7Js+1vsZztZWNEeosSg5i26wAipLfE5xXhxbA7klA== 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 AE4ACC401F6 for ; Thu, 15 Mar 2018 12:03:39 -0500 (CDT) From: Scott Kitterman To: dcrup@ietf.org Date: Thu, 15 Mar 2018 13:03:40 -0400 Message-ID: <2145921.Z693kLspBj@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-139-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <5AAAA008.6090807@isdg.net> References: <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <5AAAA008.6090807@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 15 Mar 2018 17:03:43 -0000 On Thursday, March 15, 2018 12:32:08 PM Hector Santos wrote: > On 3/15/2018 8:01 AM, Salz, Rich wrote: > >> This is bullshit. You should know better. I ask that the chairs and > >> > > the IETF cops to keep this crap out of here. > > > > What is bullshit, exactly? We shouldn't list sites that use sha1? Please > > clarify. > If you have to ask why.... > > First, I don't wish to participate in a game of public "shaming." > Pointing out SHA1 usage is one thing, Shaming them is another. You > should know better. > > Second, Its only been a few months and there is bound to be untold > number of domains, legacy or otherwise using a perfectly valid SHA1 > lower overhead hashing method based on a standard DKIM document and > RFCs before it for many years. You CAN NOT expect these domains to > be switching anytime soon. Unrealistic. > > Third, have you bothered to see if they even need DKIM? I bet most of > them, if not all of them, then don't have a DKIM POLICY or it is very > relaxed, i.e. p=none. What they may have is a strong SPF policy > which is generally good enough. You don't need DKIM with a strong SPF, > especially if they have a HardFail (-ALL). > > Forth, there is certainly shaming that can go around against that do. > For example, shame on those (like akamai.com) for not having an SPF > record. Queries with NXDOMAIN results against your domain are higher > overhead. You have a DMARC record, but no SPF record. You have no > protection at SMTP, even more receiver overhead to handle and help > protect your mail, you are asking receivers to do. All this is far > worst than using a DKIM SHA1 because its real today. > > Fifth, many legitimate domains will continue to use SHA1 in some > fashion and and machines for various reasons, including compatibility > and product support with other domains and customers. > > Do I really need to go further? I hope not. Please stop the SHA1 shaming. It's not a few months. It's since the beginning of DKIM. Here's the RFC 4871 language (May 2007): > 3.3. Signing and Verification Algorithms > > DKIM supports multiple digital signature algorithms. Two algorithms > are defined by this specification at this time: rsa-sha1 and rsa- > sha256. The rsa-sha256 algorithm is the default if no algorithm is > specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. > Signers MUST implement and SHOULD sign using rsa-sha256. > > INFORMATIVE NOTE: Although sha256 is strongly encouraged, some > senders of low-security messages (such as routine newsletters) may > prefer to use sha1 because of reduced CPU requirements to compute > a sha1 hash. In general, sha256 should always be used whenever > possible. If you were signing only rsa-sha1 in 2007, you were probably wrong, even then. DKIM has always required rsa-sha256, so (unless someone didn't fully implement RFC 4871 and then sat on their hands for a decade), there's no backward compatibility issue. Scott K From nobody Thu Mar 15 10:21: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 2785B12D7F0 for ; Thu, 15 Mar 2018 10:21:07 -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=WRy+RBOo; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=slBzs6CL 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 S5Y-DEOh51fT for ; Thu, 15 Mar 2018 10:21:06 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id E76E712D0C3 for ; Thu, 15 Mar 2018 10:21:05 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1834; t=1521134462; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=zF7n7/WtKr9QYpE/RnHVgowkuio=; b=WRy+RBOoLU+n9cCNsZ182U/DNnYD2Qw0bd6v6FUp2fy836tMDUitZNYL7pDKrU qK3NrPVEClRRwm8/HIIkz3Rtk+5QmTQtOGzvyp8w7zNxXcaVmOUSdsh4lNWwLiNY 1CpaqAYHgocSqXAH6jTYWj9Ucp4jvDnPssUY6XopzMbpI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 15 Mar 2018 12:21:02 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2413148566.1.7756; Thu, 15 Mar 2018 12:21:01 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1834; t=1521134105; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=lx/T8cb cFF1ODrOqnDQHKtPaK2Jd1T+7hYn96Wu7d08=; b=slBzs6CLoneVE49OBUk8hKs tMgyPZ6h7pvBpLjPVguehGHyr7kQNSt0MMXpf7pipGJ7PbMlva5t+8d43aEBufHb NPvtwDFSmEQNvv0bISa7J6zRy9/cKrLUWUaJWh4QrZLZuK/Tr3QzpW8ddqSR3orp j3D3ZhEp0Cu1PklxmlNA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 15 Mar 2018 13:15:05 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2413012268.9.271612; Thu, 15 Mar 2018 13:15:05 -0400 Message-ID: <5AAAAB82.9050909@isdg.net> Date: Thu, 15 Mar 2018 13:21:06 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <5AAAA008.6090807@isdg.net> <2145921.Z693kLspBj@kitterma-e6430> In-Reply-To: <2145921.Z693kLspBj@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 15 Mar 2018 17:21:07 -0000 On 3/15/2018 1:03 PM, Scott Kitterman wrote: > On Thursday, March 15, 2018 12:32:08 PM Hector Santos wrote: >> On 3/15/2018 8:01 AM, Salz, Rich wrote: >> >> Do I really need to go further? I hope not. Please stop the SHA1 shaming. > > It's not a few months. It's since the beginning of DKIM. Your RFC update was only endorsed recently. > Here's the RFC 4871 language (May 2007): > >> 3.3. Signing and Verification Algorithms >> >> DKIM supports multiple digital signature algorithms. Two algorithms >> are defined by this specification at this time: rsa-sha1 and rsa- >> sha256. The rsa-sha256 algorithm is the default if no algorithm is >> specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. >> Signers MUST implement and SHOULD sign using rsa-sha256. >> >> INFORMATIVE NOTE: Although sha256 is strongly encouraged, some >> senders of low-security messages (such as routine newsletters) may >> prefer to use sha1 because of reduced CPU requirements to compute >> a sha1 hash. In general, sha256 should always be used whenever >> possible. > > If you were signing only rsa-sha1 in 2007, you were probably wrong, even then. > DKIM has always required rsa-sha256, so (unless someone didn't fully implement > RFC 4871 and then sat on their hands for a decade), there's no backward > compatibility issue. I technically disagree with you. Nonetheless, the fact remains SHA1 was a legitimate STD protocol option for many years despite the hypothetical security concerns and still is usage without concerns, and when you study the domains that you (speaking in general) which to shame, you may find that DKIM may be a low priority. Without a policy-based model, there is was very little, to zero payoff, and I've been saying that since 2007. Using SHA1 was not a concern. -- HLS From nobody Thu Mar 15 10:32:19 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 2414812D7F0 for ; Thu, 15 Mar 2018 10:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDPwWpDsLE0b for ; Thu, 15 Mar 2018 10:32:17 -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 11DC1129C5D for ; Thu, 15 Mar 2018 10:32:16 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2FHQr32007494; Thu, 15 Mar 2018 17:32:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=DBZmAH3NS52MHnefXYRx78izNySOnDWM+LAC/D8LaRY=; b=PKmp/bMG04nvkKD7B92SauWucV+MICo+Vgh59e9yG7SJkkIvPV/2NcHkqYh6I6rGpKIw hy90UU9OsmpWsY7KQDxtTfoClYGQeCNxWv7NEe7WyukVTqXc2vR9o3uMgKdjwlwYzeBV yr+IroCIdq1kZkjLCj1aPquzXuIfs0NUwDEvMGxc+eFandKol78ZXE2syaDfch6G2QYa BaA/7/lZt+cfozwh2X2WCiUQfpn4SjAo+OcDT4qjuRWfAWcyKunQM6t8Fit6Pipx57RI Fc/oJp5+IAxqldJieh1quFHqnW2aPNa9qX3vjmHoLiZS8u9dHwYsMlbxtpVVtb46f020 4Q== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2gq90wtuvc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Mar 2018 17:32:14 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w2FHQYgU029234; Thu, 15 Mar 2018 13:32:14 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2gmbk1eq4y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 15 Mar 2018 13:32:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 15 Mar 2018 13:32:11 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 15 Mar 2018 13:32:11 -0400 From: "Salz, Rich" To: Hector Santos , "dcrup@ietf.org" Thread-Topic: [Dcrup] sha1 wall of shame Thread-Index: AQHTu5hcEol5MR2ikUWgD18Uq8+TbqPQFK6AgAEe4gCAAI6fAP//zbmA Date: Thu, 15 Mar 2018 17:32:11 +0000 Message-ID: <4B0D617D-5EAA-4BF3-89EB-0CDA2B14A21A@akamai.com> References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <5AAAA008.6090807@isdg.net> In-Reply-To: <5AAAA008.6090807@isdg.net> 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.113] Content-Type: text/plain; charset="utf-8" Content-ID: <6C85A009A29B8F43967BECF38C703FD5@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-15_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=828 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803150190 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-15_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=777 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803150191 Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 15 Mar 2018 17:32:18 -0000 PiAgICBQb2ludGluZyBvdXQgU0hBMSB1c2FnZSBpcyBvbmUgdGhpbmcsIFNoYW1pbmcgdGhlbSBp cyBhbm90aGVyLiANCg0KU28gaWYgdGhlIHN1YmplY3QgbGluZSB3ZXJlIGRpZmZlcmVudCB5b3Ug d291bGQgaGF2ZSBubyBjb25jZXJuIGFib3V0IEpvaG4ncyBtZXNzYWdlPw0KIA0KDQo= From nobody Thu Mar 15 10:50:43 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 C449C12D80E for ; Thu, 15 Mar 2018 10:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=dZnf9Hs+; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=nCU4n4fk 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 z1qO0yQCnqoC for ; Thu, 15 Mar 2018 10:50:36 -0700 (PDT) Received: from listserv.winserver.com (unknown [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 574DE12DA00 for ; Thu, 15 Mar 2018 10:50:36 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=467; t=1521136228; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=70yug6rMcHb/YUEPOrBfFFnyM7U=; b=dZnf9Hs+S6bH0Ox96s0gNVUYd6dQ8TS+GzkKG1FLPA2E4pO+wuT6teMnn/bast REtNJHX5+T8BA70GQexCjnJrgolJ50xBOGGvkrSXIpss4zqBJKWhju5jIHkZg6Vq c0EyRgaCrfXD3+7/D/d0qelycWUXaTpymYnLDp+nsWOdo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 15 Mar 2018 12:50:28 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2414913983.1.5028; Thu, 15 Mar 2018 12:50:27 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=467; t=1521135869; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=zQ/FI02 hJ2AMe/UVzYVQ5b5uHc3BJ7kerW9JkE3AUQI=; b=nCU4n4fk6Uta4EK7XR9++dc ASOBmwLhdQW3qahijLDWGkt5jjJBYOBiWfzCENekkSkpsKNGMHd4rbR++7B/BdbK U2LEdJcRnGeZ6FAhMMpHUL3IpBGvOzTCYq3x08yey/0on1ANLYdchrwa69LKrfZq C00NOMZOXfmn6sbbDLM8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 15 Mar 2018 13:44:29 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2414776268.9.271792; Thu, 15 Mar 2018 13:44:29 -0400 Message-ID: <5AAAB266.9090502@isdg.net> Date: Thu, 15 Mar 2018 13:50:30 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "dcrup@ietf.org" References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <5AAAA008.6090807@isdg.net> <4B0D617D-5EAA-4BF3-89EB-0CDA2B14A21A@akamai.com> In-Reply-To: <4B0D617D-5EAA-4BF3-89EB-0CDA2B14A21A@akamai.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 15 Mar 2018 17:50:38 -0000 On 3/15/2018 1:32 PM, Salz, Rich wrote: >> Pointing out SHA1 usage is one thing, Shaming them is another. > > So if the subject line were different you would have no concern about John's message? > That and also I don't think specifically labeling and shaming domains is appropriate, especially without studying the domain facts and technical priorities a domain may or may not have. In principle its wrong, especially in an IETF environment. -- HLS From nobody Thu Mar 15 13:49: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 66347124BE8 for ; Thu, 15 Mar 2018 13:49:47 -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 69DqJ1bgWP1e for ; Thu, 15 Mar 2018 13:49:45 -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 83A1B1200F1 for ; Thu, 15 Mar 2018 13:49:45 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id m69-v6so12190828lfe.8 for ; Thu, 15 Mar 2018 13:49: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 :cc; bh=vpQ3Ol6xYLGT4AZpr1yfQJuKa8loii7/7+KhesOm1/E=; b=IjPrFiiJm7ObAF8W/DADakoA1pPUU7zq123skYL3P6h1yOB5d7l+LTtblCBQGJU+wS /CA25Rgz7A9Hm8LtaeqfxygjTdKlheQzHG+c9E7GQBxu2uBs0UtTrZfdfl+HFd0XQN7D OO/AmAXT7Ta7kmUp8k20JtWyCbbnIGnyDwjP5+efUL7SEJAC+My2CQOkbicDcLPfQGmO VRKg/CGSJTLYf9R0T5jSbzzusgrxJy3vp6eUb2vJx9xbqiHjMEPbeoe2qo0TjNHzmPYE q5xjHpj2gbFjHF734agDtWnaPm3eCeaGSh8KJO1i8InIC4mZHKr0FRSkwy62LV8etQTz 5hwQ== 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=vpQ3Ol6xYLGT4AZpr1yfQJuKa8loii7/7+KhesOm1/E=; b=N0XLxgcGI6iOEla8TgYz/RIjHVo2uMsOyZXrChbDXJC6hPo/yCj2tTFirIl/m7zHig ILtTpjs1rzV4qeRTW7gt3R2gJ6VAXnUmDFSCc6e1kjfkBRWHcR7cpn3z6iImVXqXtAeY 9P9jc3MoqPxfOAKm5fykJIDUOJQL5IDa1iYBeQCBthjFoauYQ0vB639n5iJOvFYh63mJ r7WMDblIBYcn+g44L8uVvFtNFT0Ijt1iJgRnXmuGxTZdITWO+KzoUnVI5TwNoneDdKPj vy5fRE7FtAH0REYC/0T8JcufLozzptbQro4jNK+F3jIAf6ug3PweVzYmYvEYpw0s/Fmv Yoeg== X-Gm-Message-State: AElRT7GwCjg0LnjgKGWytaMH27mqvnS5ldym6E3QqWGZVIB178bDi4cX aCKO8pt9Mml528xaLQyAb9pUY25DZbHrXWBv/EZ4Qw== X-Google-Smtp-Source: AG47ELsRS+vAqHV2px0sK+c86O+5cK88D3NoLjUie2+eqp3jbw2+xO0vogaIS1ZIS7BrPhxBoMe71UnkOXHeQ843uH4= X-Received: by 2002:a19:5317:: with SMTP id h23-v6mr6564972lfb.6.1521146983660; Thu, 15 Mar 2018 13:49:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.66.82 with HTTP; Thu, 15 Mar 2018 13:49:42 -0700 (PDT) In-Reply-To: <5AAAA49C.7020401@isdg.net> References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <1521121872.3815.118.camel@tx.net> <5AAAA49C.7020401@isdg.net> From: "Murray S. Kucherawy" Date: Thu, 15 Mar 2018 13:49:42 -0700 Message-ID: To: Hector Santos Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="0000000000009cf4b9056779a1fd" Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 15 Mar 2018 20:49:47 -0000 --0000000000009cf4b9056779a1fd Content-Type: text/plain; charset="UTF-8" On Thu, Mar 15, 2018 at 9:51 AM, Hector Santos wrote: > On 3/15/2018 9:51 AM, Bryan Bradsby wrote: > >> the IETF cops to keep this crap out of here. >>> >> >> Since when is the truth not wanted? >> > > Create a "SHAE1 Usage" report. Domain shaming is not necessary. I fail to see how (a) a post on a mailing list with only a handful of participants with specific domain knowledge constitutes legitimate "shaming"; or (b) creating a usage report of some kind would be any different. This is interesting data to this group, not a press release. -MSK --0000000000009cf4b9056779a1fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 15, 2018 at 9:51 AM, Hector Santos <hsantos@= isdg.net> wrote:
On 3/15/2018 9= :51 AM, Bryan Bradsby wrote:
=C2=A0 =C2=A0 the IETF cops to keep this crap out of here.

Since when is the truth not wanted?

 Create a "SHAE1 Usage"=C2=A0 report.=C2=A0 Domain shaming is not = necessary.

I= fail to see how (a) a post on a mailing list with only a handful of partic= ipants with specific domain knowledge constitutes legitimate "shaming&= quot;; or (b) creating a usage report of some kind would be any different.<= br>
This is interesting data to this group, not a press relea= se.

-MSK
--0000000000009cf4b9056779a1fd-- From nobody Thu Mar 15 15:10: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 0C74B126CC4 for ; Thu, 15 Mar 2018 15:10:40 -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=Qrh0HLYU; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=dhkpy7Pg 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 Bsw9dOC8nbfY for ; Thu, 15 Mar 2018 15:10:38 -0700 (PDT) Received: from mail.santronics.com (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id D7E0C1241FC for ; Thu, 15 Mar 2018 15:10:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=868; t=1521151833; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=EaTR6CrFKK76pUD+WD2nWXkSB6s=; b=Qrh0HLYUkv3/q3/RmLOUWXz2lJMKr8WbF6AyIDULzA0GitdcrDjloes6XJMZgZ ec0pyr9dm83/fcTHFSmIEIDlUfCmYweuoDLH/pvkExXKkXBFrPLZ2C06yzwonIdD Cj8sXvvWZy47eXGXhu/sYxDTyJzYDQmJeDok9uub7N9/U= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 15 Mar 2018 17:10:33 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2430519340.1.6848; Thu, 15 Mar 2018 17:10:32 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=868; t=1521151476; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hZShR+N DgCajTmcre8Lz0RygdssIV6VF8yK2xUQVmeA=; b=dhkpy7PgB6ZU7VR9YvuiV6a hDUthtGHMEudIAigiHPUkojPi5xBh4acFav8nngGditjtvhmDHfAD7tswMTexJj4 EPZn1hGMFusMgAOmIFuvy8oWRtdE3RDqgZynRbU16RLhQ2AQlkirt/d17RhURJ8L GNe8X26ApGJ/ODxUgmMY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 15 Mar 2018 18:04:36 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2430382565.9.297128; Thu, 15 Mar 2018 18:04:35 -0400 Message-ID: <5AAAEF5D.1010900@isdg.net> Date: Thu, 15 Mar 2018 18:10:37 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <1521121872.3815.118.camel@tx.net> <5AAAA49C.7020401@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 15 Mar 2018 22:10:40 -0000 On 3/15/2018 4:49 PM, Murray S. Kucherawy wrote: > > I fail to see how (a) a post on a mailing list with only a handful of > participants with specific domain knowledge constitutes legitimate > "shaming"; or (b) creating a usage report of some kind would be any > different. > > This is interesting data to this group, not a press release. As a discussion/report of SHA1 usage still in practice, yes, I agree, it would be interesting data. However, listing the domains in order to "shame" them, not to prove the point of usage, in my ethical opinion, is not. The op should of known better. I know it, he knows it, you know it and everyone else knows it. So excuse me if I am bewildered with the backlash on a very inappropriate action that you know typically would be considered a taboo. You know what. Go ahead. Shame away. I'm done. -- HLS From nobody Thu Mar 15 19:18: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 B2470124F57 for ; Thu, 15 Mar 2018 19:18:37 -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 262kHZQ0g4wN for ; Thu, 15 Mar 2018 19:18:35 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4031200B9 for ; Thu, 15 Mar 2018 19:18:35 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id s188so9581256qkb.2 for ; Thu, 15 Mar 2018 19:18:35 -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=b5TrOECbKQLkNUlwPx7AlKJ35QiaLZRSBt3wS5EK4MI=; b=OlXSqCI2ClnkO7tXuH2XaA1RmA243a2AA9Sbw3Ksv7WFgf+COYSgBbsNrN+YohB4+l O1L8XOPIboC/rSrVize1iHgGxmrUYzDwH8h1KXB32W2p3Rsyl8ICOnMyuiRkQ3czdP2L q8gJw/rvRORRvGpDx5k4MGbWmB9btwVzw+vaPeYHTJw5/u4ggPhoIvIshBlYE98/PhRp YuOqwotXCpHgznoG47UXUJNyLa4rL1kiA9v+aU0BOa673DVSU1KOilFjznQ3kDaRyG3w 2UFy8fCU7xzPPO5PBgF8qdVt1YCYwWlpKxk7oWlh55Td6KKWWf3No5uXRdeu7HgJ/SMt ewcQ== 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=b5TrOECbKQLkNUlwPx7AlKJ35QiaLZRSBt3wS5EK4MI=; b=HFCpSQnqh+E8UExmEaZOurCQDDgJotyZTiKuChQd1G2gHQIfGepZxP7FrfJZe4DuFS xDfKy07PK3yFzF825219sSuxIFWKc9XvrIp7V3X8xRO1Y7ma+Hrgmk7cQ9hVYNQfxD9F YMnOfxOU0IaYijKOqvJHA5MWW/NGz3WKW01UdQ5IKa6qtaz5tLnGmdXS30Km7jos58/L q8lR5NWAeI4Zt2WBGbv8ojfWkrtW64Uh7QnS7aXfj/xR4ONaACKvE9CrJUMSIf/vzdw1 HGHnedsW30FMQADAodsp4qUaLuXkgTIpZABZVwfQ8KiuXe340FmbPiH4MIL3wNIgs5jl bHug== X-Gm-Message-State: AElRT7GZIVb0sqJwE7TGOib71T8NI2AsFqOnBZiBMr2sPhiso0P1cJT4 LHbgmhU6Jqv/8TWKkv9Jt7Tm2/APB41GDuAcSmw= X-Google-Smtp-Source: AG47ELsS99XfjR3UWSNV2PGwvgR/INE6lnd7Jl67tHyxzZN4VjK5cuWyAE5jUn46deOEaXRFMSyaOSIE4DqtmeDX244= X-Received: by 10.55.107.70 with SMTP id g67mr142560qkc.105.1521166714747; Thu, 15 Mar 2018 19:18:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.225.71 with HTTP; Thu, 15 Mar 2018 19:18:34 -0700 (PDT) In-Reply-To: <5AAAEF5D.1010900@isdg.net> References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <1521121872.3815.118.camel@tx.net> <5AAAA49C.7020401@isdg.net> <5AAAEF5D.1010900@isdg.net> From: denis bider Date: Thu, 15 Mar 2018 21:18:34 -0500 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114873f2ad3e3f05677e39bc" Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 16 Mar 2018 02:18:38 -0000 --001a114873f2ad3e3f05677e39bc Content-Type: text/plain; charset="UTF-8" I do not share Hector's strong feelings about the issue, but I think the points he made make sense. :-) On Thu, Mar 15, 2018 at 5:10 PM, Hector Santos wrote: > On 3/15/2018 4:49 PM, Murray S. Kucherawy wrote: > >> >> I fail to see how (a) a post on a mailing list with only a handful of >> participants with specific domain knowledge constitutes legitimate >> "shaming"; or (b) creating a usage report of some kind would be any >> different. >> >> This is interesting data to this group, not a press release. >> > > As a discussion/report of SHA1 usage still in practice, yes, I agree, it > would be interesting data. However, listing the domains in order to > "shame" them, not to prove the point of usage, in my ethical opinion, is > not. The op should of known better. I know it, he knows it, you know it > and everyone else knows it. So excuse me if I am bewildered with the > backlash on a very inappropriate action that you know typically would be > considered a taboo. > > You know what. Go ahead. Shame away. I'm done. > > > > -- > HLS > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a114873f2ad3e3f05677e39bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do not share Hector's strong feelings about the issu= e, but I think the points he made make sense. :-)

On Thu, Mar 15, 2018 at 5:10 PM, Hect= or Santos <hsantos@isdg.net> wrote:
On 3/15/2018 4:49 PM, Murray S. Kucherawy wrote:=

I fail to see how (a) a post on a mailing list with only a handful of
participants with specific domain knowledge constitutes legitimate
"shaming"; or (b) creating a usage report of some kind would be a= ny
different.

This is interesting data to this group, not a press release.

 As a discussion/report of SHA1 usage still in practice, yes, I agree, it wo= uld be interesting data.=C2=A0 =C2=A0However, listing the domains in order = to "shame" them, not to prove the point of usage, in my ethical o= pinion, is not.=C2=A0 =C2=A0The op should of known better. I know it, he kn= ows it, you know it and everyone else knows it.=C2=A0 So excuse me if I am = bewildered with the backlash on a very inappropriate action that you know t= ypically would be considered a taboo.

You know what. Go ahead. Shame away. I'm done.



--
HLS


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

--001a114873f2ad3e3f05677e39bc-- From nobody Thu Mar 15 19:44:28 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98418126DFB for ; Thu, 15 Mar 2018 19:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=iN912X6r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OKp0wEju 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 aIJexmkkv5-J for ; Thu, 15 Mar 2018 19:44:25 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A4E126D45 for ; Thu, 15 Mar 2018 19:44:25 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id F147120840; Thu, 15 Mar 2018 22:44:24 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 15 Mar 2018 22:44:24 -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=fm2; bh=ZK5XC6cCRwBCIZUlP VDPzrTYS+BMRzQ2y8TfNSE+5Pg=; b=iN912X6rMIk7aJ0o/bPwLqHy1dMDnv7B/ lobV4ShE3mcH14IF/CGHSGhsRoBW1AHJkskATvVik4pZYbVmD4lf0AQts4ydYmHR 2jAhxYLJhPlwoX1gzuQUQn5uNSROOYwuTDa7HLw61e1jLp0LY0K3285OEjgBsQwG +wS6cf4L/inqAIGPgQpzcZ5gnfGjdjwt+WCTvq1rl3+WRsglZ0soJWiYAK3Aibkd 1ID+qzHxe/et/nTM6KyrRnce3cnwJTM+VmZm68wlqE9Fo22cMz/HkSYOPkYxiECh 4FpkeMt0GIVUCU+VzVn9kTlkNm1bzjpD2XBZ3m4GCg3j53kxE3F6w== 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=ZK5XC6 cCRwBCIZUlPVDPzrTYS+BMRzQ2y8TfNSE+5Pg=; b=OKp0wEjujd5jBXICFNQVQb 5/S6FIUs+fTAvFlxOtsporma7d6Im7U7+Lk5QEfWFjE9zYvOkp1rUd0pUNwj5ag0 5dUxv4DYdUr4btn+/RQh/57wL7Kyddy9yk83Q6GrfeZK2tiqeKSUlPx46d2LuFKU 9PftkFVaWxw07wz1c09SNGLLZnq+EsVFXXEKSjsDBnUz1xD+1dKgnfLdUtj2371z HpyXsKksulLKmzLggv5vey/Aj0E39uJ1pLY5v0/bdiFHXgDH+LphssHvRahD7SwE GHj3qlRgYihV9vQhO78FUMdKiwHPUOwBjnyR1ILUOWFVB7pldCmzuYpjFIMCMhyQ == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id AD99D7E13B; Thu, 15 Mar 2018 22:44:24 -0400 (EDT) References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <1521121872.3815.118.camel@tx.net> <5AAAA49C.7020401@isdg.net> <5AAAEF5D.1010900@isdg.net> In-Reply-To: <5AAAEF5D.1010900@isdg.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <75B6163D-7FB4-4BED-AD2F-2EED0CD0B33C@glyphein.mailforce.net> Cc: dcrup@ietf.org X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Thu, 15 Mar 2018 22:44:22 -0400 To: Hector Santos Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 16 Mar 2018 02:44:28 -0000 > On Mar 15, 2018, at 6:10 PM, Hector Santos wrote: >=20 > However, listing the domains in order to "shame" them, not to prove the po= int of usage, in my ethical opinion, is not. The op should of known better= . I know it, he knows it, you know it and everyone else knows it. No, we don't know it. As you noted one sentence prior, this is your opinion= . I wasn't going to say anything further in this thread, but, speaking as a re= latively new poster, it's gotten to the point that it wouldn't surprise me i= f your attacks on people here turn potential participants off from this WG. = The ease and vigor with which you take offense to things or misconstrue the= m as personal attacks are, in my opinion, disruptive. I suspect I am not the= only person who feels this way. Stan= From nobody Thu Mar 15 20:10:21 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A17C12702E for ; Thu, 15 Mar 2018 20:10:21 -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=LXJstgz1; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=prQ480DZ 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 GdPByMxjMtku for ; Thu, 15 Mar 2018 20:10:19 -0700 (PDT) Received: from dkim.winserver.com (mail.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4A91242F7 for ; Thu, 15 Mar 2018 20:10:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1548; t=1521169813; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Wf5EayBsDQu6Z77G0RiQV5Qp1AY=; b=LXJstgz1WSRhKizuvzMdp8BHwpsMp47rG3ady2+pqrIzrEVF/m65tHR2ZJMio6 K+QFroVlRZ7AlU57jAm5gp+0RDiS31PE5RxiALo5LcDaCsl1YRNsh18jWNb+I7yZ zCEdqrwHHxa4lDhTC6uHL4jLFRNrx8PVZv0uUJVa4m87Y= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 15 Mar 2018 22:10:13 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2448499797.1.1736; Thu, 15 Mar 2018 22:10:13 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1548; t=1521169453; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=NRHTYLP TbxFJ5H8qdCGr0omNEbKh+bcgbHYdJwOKGV8=; b=prQ480DZA7Iz2/RQbkzuccc J5/5tV7pVpdngZTUS6tRxniNNc8rM6sUlKoS/y2Cn8hDWruxMLf2xknKfGYlWB+C Qfjr8jXg8ZbVMfMdYROYPtMUtfO2mOu0OjnztIfIX+KVDUfEOSBVwmGOeklKrgYK i2LK416mJz+5VUhyhq+E= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 15 Mar 2018 23:04:13 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2448360002.9.331160; Thu, 15 Mar 2018 23:04:13 -0400 Message-ID: <5AAB3596.7060503@isdg.net> Date: Thu, 15 Mar 2018 23:10:14 -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: Stan Kalisch CC: dcrup@ietf.org References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <1521121872.3815.118.camel@tx.net> <5AAAA49C.7020401@isdg.net> <5AAAEF5D.1010900@isdg.net> <75B6163D-7FB4-4BED-AD2F-2EED0CD0B33C@glyphein.mailforce.net> In-Reply-To: <75B6163D-7FB4-4BED-AD2F-2EED0CD0B33C@glyphein.mailforce.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 16 Mar 2018 03:10:21 -0000 On 3/15/2018 10:44 PM, Stan Kalisch wrote: > >> On Mar 15, 2018, at 6:10 PM, Hector Santos wrote: >> >> However, listing the domains in order to "shame" them, not to prove the point of usage, in my ethical opinion, is not. The op should of known better. I know it, he knows it, you know it and everyone else knows it. > > No, we don't know it. As you noted one sentence prior, this is your opinion. > > I wasn't going to say anything further in this thread, but, speaking as a relatively new poster, it's gotten to the point that it wouldn't surprise me if your attacks on people here turn potential participants off from this WG. The ease and vigor with which you take offense to things or misconstrue them as personal attacks are, in my opinion, disruptive. I suspect I am not the only person who feels this way. > This is a direct personal attack on a very subjective issue. I take exception to your false insinuation I have attacked anyone. You should apologize. On the other hand, I'm getting hit from the usual except a few who dare to give an inking of support. Greatly appreciated. I make no excuse for my passion in engineering and ethics. I'll get back to the main point, whether you like it or not, Shaming -- it is a very widely acceptable ethical engineering opinion, in my view, that you don't do it. It is very disruptive. I don't agree that you should allow opening the door to technical shaming for no legitimate reasoning. If you want to open that door, go right ahead. -- HLS From nobody Thu Mar 15 20:15:21 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0D812D77A for ; Thu, 15 Mar 2018 20:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAD8_Sb55dd0 for ; Thu, 15 Mar 2018 20:15:17 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [IPv6:2001:470:1:6d::9a]) by ietfa.amsl.com (Postfix) with ESMTP id B8A01129C6B for ; Thu, 15 Mar 2018 20:15:17 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id C1EC523379 for ; Thu, 15 Mar 2018 20:16:09 -0700 (PDT) From: Steve Atkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 15 Mar 2018 20:15:16 -0700 References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <1521121872.3815.118.camel@tx.net> <5AAAA49C.7020401@isdg.net> <5AAAEF5D.1010900@isdg.net> <75B6163D-7FB4-4BED-AD2F-2EED0CD0B33C@glyphein.mailforce.net> <5AAB3596.7060503@isdg.net> To: dcrup@ietf.org In-Reply-To: <5AAB3596.7060503@isdg.net> Message-Id: <772EFC60-73F5-4BAB-B0D7-D884E26E370B@blighty.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 16 Mar 2018 03:15:19 -0000 > On Mar 15, 2018, at 8:10 PM, Hector Santos wrote: >=20 > On 3/15/2018 10:44 PM, Stan Kalisch wrote: >>=20 >>> On Mar 15, 2018, at 6:10 PM, Hector Santos wrote: >>>=20 >>> However, listing the domains in order to "shame" them, not to prove = the point of usage, in my ethical opinion, is not. The op should of = known better. I know it, he knows it, you know it and everyone else = knows it. >>=20 >> No, we don't know it. As you noted one sentence prior, this is your = opinion. >>=20 >> I wasn't going to say anything further in this thread, but, speaking = as a relatively new poster, it's gotten to the point that it wouldn't = surprise me if your attacks on people here turn potential participants = off from this WG. The ease and vigor with which you take offense to = things or misconstrue them as personal attacks are, in my opinion, = disruptive. I suspect I am not the only person who feels this way. >>=20 +1 >=20 > This is a direct personal attack on a very subjective issue. I take = exception to your false insinuation I have attacked anyone. You should = apologize. >=20 > On the other hand, I'm getting hit from the usual except a few who = dare to give an inking of support. Greatly appreciated. I make no excuse = for my passion in engineering and ethics. >=20 > I'll get back to the main point, whether you like it or not, Shaming = -- it is a very widely acceptable ethical engineering opinion, in my = view, that you don't do it. It is very disruptive. I don't agree that = you should allow opening the door to technical shaming for no legitimate = reasoning. >=20 > If you want to open that door, go right ahead. Actual shaming would require a much more public forum, an accusation = more heinous than "uses a somewhat outdated protocol", and some actual = accusation of malfeasance. It's not actually terribly interesting detailed data (as compared to a = count / summary) and John could perhaps have used a different subject = line but other than that, and it triggering a thread full of bile, I see = no issue with it. Can we move on to something productive now? Cheers, Steve From nobody Fri Mar 16 07:27:16 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 6D4B4126C25 for ; Fri, 16 Mar 2018 07:27:15 -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=EMW+4kKG; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=F1mFfWMP 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 K5KFamDSsw1o for ; Fri, 16 Mar 2018 07:27:12 -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 B80EE126B6E for ; Fri, 16 Mar 2018 07:27:12 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=andreasschulze.de; i=@andreasschulze.de; q=dns/txt; s=ed25519; t=1521210428; h=to : from : subject : message-id : date : mime-version : content-type : content-transfer-encoding : from : subject : date; bh=SpMIfQDw6Sz15JuHTCcJaR9pM0Tu7THKTjJHsZsFq5M=; b=EMW+4kKGpmCWTxEJXZHPcrf8H0PkzKQKqeG0dJtmzcL7OLs/zQe7Z96l KO21UAed4iGan9OLrnTsLygy/vlmCQ== To: dcrup@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=ybz; t=1521210428; x=1526210428; bh=SpMIfQDw6Sz15JuHTCcJaR9pM0Tu7THKTjJHsZsFq5M=; h=To:From:Subject:Message-ID:Date:Content-Type:from:reply-to: subject:date:to:cc:content-type:message-id; b=F1mFfWMPn+jcnuEqZGxOBAH/8qLf8VGB0JeyvJW8rBJWe7bMFUSdGofLCY44zjFu3 BbTuhkxVMRocJ9j2RkOlU1nbImaTn0z4pqeVELuMkwoioWOtuzyLMsyVtNMYRALR2S oNWQquHeEeEcTR9LWfaW3kBmCsshuLMDpzzEV77ermvjBa4COUoZSQeC8NoLSCiKYP c/vlKg18BD9sUd+bTeNM6rS8Ia8oVwp7fvguobZveV5Xq1cp+Se4Qo14sKRCRRYB5V mKzXb55O96Gve37x2cpc1lu0X0eiyHgMEHixdXvV7qmKE0V/YG8oyBHrLXvos+XnGJ sirfsz4XFFHtg== From: "A. Schulze" Message-ID: <1981d40e-db70-f43d-f48b-b90dbddde23f@andreasschulze.de> Date: Fri, 16 Mar 2018 15:27:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Dcrup] SHA1 in current software 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, 16 Mar 2018 14:27:15 -0000 Hello, I just stumbled about a message from Ebay I just received. SHA1 signed :-/ Yes, SHA1 is deprecated. But the software I usual use still mark such messages as valid. I think it's time for a software update. But how to handle SHA1 technically? The way of "minimum surprise to the admin" would be to introduce new option "rfc8301-conformance = yes | no" Ideas about the default? Anyway a signature validation result "PERMFAIL" would not immediately reject such messages. But it would be visible via DMARC aggregate reporting to the sender. Please advise if this is not the right place for discussion on specific implementation. Andreas From nobody Fri Mar 16 09:54: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 9D51A12711D for ; Fri, 16 Mar 2018 09:54:54 -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, 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=gwHwiZK+; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=gje7hIDr 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 6GVyETA2u3aQ for ; Fri, 16 Mar 2018 09:54: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 475A71270FC for ; Fri, 16 Mar 2018 09:54: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=1521219291; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ernc0t1H6lbKYeEK0up0aEU0ZVmAOvhtOPZ1KQ+ojU4=; b=gwHwiZK+81st+/2J62VFFy8hETB5Tv9xJDL6G+rhLnU6wZQ+P+xYwNTs sMEXNUWOzDw7iIQDMba8p5y7kYSVAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1521219291; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ernc0t1H6lbKYeEK0up0aEU0ZVmAOvhtOPZ1KQ+ojU4=; b=gje7hIDrIkHOaPH9ckMcEwTwpeLDit7WLor6ABUreEYL3J2B9Lbg/yOF IMHbC+8AbY0/eN/jjKyR2dd+Njt/ERlg6ODalQ+Fy8t85gNYJI6xnq4R63 OVm0Q17DA6fkKw1eVqE9TL2TcwRYKYqd0Ap+8VxDHZMGE0LrijQN73zFic SHFHK124Y4AkjYSAQQAzrLaG8e2yH67DWwTf78clPUb50BTMq6duVTsBw4 pBCUKM3RAmlSqa0rgmnvfsxGqx4cl1iOMytontnkHOCvdYkfs55GO1WjYu HZou2QCoAG6PqOSfUPpcN6rFODPTK1mvdgMz5W+kDdHzCCgPq4Vp/w== 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 1D83AC402C6 for ; Fri, 16 Mar 2018 11:54:51 -0500 (CDT) From: Scott Kitterman To: dcrup@ietf.org Date: Fri, 16 Mar 2018 12:54:51 -0400 Message-ID: <2786130.ar0Udb5fUx@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-139-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1981d40e-db70-f43d-f48b-b90dbddde23f@andreasschulze.de> References: <1981d40e-db70-f43d-f48b-b90dbddde23f@andreasschulze.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] SHA1 in current software 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, 16 Mar 2018 16:54:55 -0000 On Friday, March 16, 2018 03:27:05 PM A. Schulze wrote: > Hello, > > I just stumbled about a message from Ebay I just received. SHA1 signed :-/ > Yes, SHA1 is deprecated. But the software I usual use still mark such > messages as valid. > > I think it's time for a software update. But how to handle SHA1 technically? > The way of "minimum surprise to the admin" would be to introduce new option > "rfc8301-conformance = yes | no" Ideas about the default? > > Anyway a signature validation result "PERMFAIL" would not immediately reject > such messages. But it would be visible via DMARC aggregate reporting to the > sender. > > Please advise if this is not the right place for discussion on > specific implementation. I think exposing this in DMARC reporting is a great idea. I suspect the DMARC list (dmarc@ietf.org) is likely a better place to discuss how to go about it. At this point, making the issue visible to senders is the right place to focus. This also connects to the RFC 7601bis work that is (IIRC) also discussed on that list since I've asked to have the DKIM key type and hash algorithm added to authentication results. Scott K From nobody Fri Mar 16 13:58:51 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D351252BA for ; Fri, 16 Mar 2018 13:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=Z4O1JIJx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iodIFUOB 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 xdHQdZ0GcvHg for ; Fri, 16 Mar 2018 13:58:48 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76420124BE8 for ; Fri, 16 Mar 2018 13:58:48 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E5A9620AE6; Fri, 16 Mar 2018 16:58:47 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Fri, 16 Mar 2018 16:58:47 -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=fm2; bh=BGYaxnlLmLrKQDbwY a1A3I8ubHeDtnpcJCwnnUjWqhI=; b=Z4O1JIJxvfcnC6Ck9ztktPJCTnPA8A4wv q4NRKZkl4CJ8HywAnuHfb+ANnpDAJ9IJ8H0HWLr7Awfl3BgkkEwKze1joUBv/fVe ErMinI1S5hBYoA8HeG1oOt23zJvyoKgKJy9wMETmUbpr8AxJL9un1sUXpOMTmHia gK8m1aZN0NEjPVijQMhKzyR1VTZ8nU8rdlmEAFofELGd7ptdAgCxpNvIek3/wiiY +VT1CzogOYN54iuY3AuxHJA6vH1L2bsTJ4APpq/fseO58VNT7GJrd76p7sb6Gcye 9B2lyvQj//nEwcu/oJYWh7uvNUsYtlYulf4rtfBIro5OPLcgbAt6A== 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=BGYaxn lLmLrKQDbwYa1A3I8ubHeDtnpcJCwnnUjWqhI=; b=iodIFUOBym2UPxKuOmB3xY 5+cVc/XZ4eR9j/q9DVSx6zFaj3u3skM2k5KIepriohiBoGBo0uNWRIStQ+ArBeE+ mZZONEzZnooBrpujK6khiGgav5XOOn8gKxaDcrVtjZYx53fMgGVeYUA2/zgebJEM cwGRQfHRQm4i1HZMqpRdvaayvrt7ZulAlDLPyd55RfnFACnmkGdFPEJxi2BbadAs mEntUbMBhzuW4N6CoJI41R2fD2eqVJSDiKHRW5r3afl0VDcxB3cDrfuL3skp3B9F F1J7kW8jfbpzxICetqu+oa/dOxwEeC8ykAwfyWiNicmBQ2apGv7gDU61KGeMrRkw == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id A23907E07F; Fri, 16 Mar 2018 16:58:47 -0400 (EDT) References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <1521121872.3815.118.camel@tx.net> <5AAAA49C.7020401@isdg.net> <5AAAEF5D.1010900@isdg.net> <75B6163D-7FB4-4BED-AD2F-2EED0CD0B33C@glyphein.mailforce.net> <5AAB3596.7060503@isdg.net> Mime-Version: 1.0 (1.0) In-Reply-To: <5AAB3596.7060503@isdg.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8522600D-9020-4428-AC90-13241496B3A0@glyphein.mailforce.net> Cc: dcrup@ietf.org X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Fri, 16 Mar 2018 16:58:45 -0400 To: Hector Santos Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 16 Mar 2018 20:58:50 -0000 Likewise, I take exception to everything you said; I stand by my characteriz= ation of your behavior. In any event, I will not continue to discuss this o= n the list. Stan > On Mar 15, 2018, at 11:10 PM, Hector Santos wrote: >=20 > This is a direct personal attack on a very subjective issue. I take excep= tion to your false insinuation I have attacked anyone. You should apologize.= From nobody Sun Mar 18 05:29:39 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 23DD9127873 for ; Sun, 18 Mar 2018 05:29:38 -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 JrRkPw2Vw5SF for ; Sun, 18 Mar 2018 05:29:37 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6D512704A for ; Sun, 18 Mar 2018 05:29:36 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id l191-v6so21516909lfe.1 for ; Sun, 18 Mar 2018 05:29: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 :cc; bh=AUwLgh2fMAJcNm2yC+Lr0K/IFUhAkL6E5stNXBx//HU=; b=pW39UUAC633LdT+4Td20YnO/ijRiGieLt+sDFXeHt4MMX67oULiJhvnYKZJeDh0Nu5 tM9BWcdTiR/IixGBYY1VIscPgNVC3qp7IkCzNxF4VkglfUBnXRMDUOCjqwwcvBSZ3EbS CvMzxHOLMd4Jc1CDI8DBhy0f07JcCqIk4fcthpc6Qp6A4F95BQRYouQ+LYDKXTxNDBRt viMbkGcEkds1Q/JXZNOzsk7B6Egld0000QoA0WeScbPDtOi9MHktLDAdsv8bzhf8puEk KvOlmnc/kKsYn7T8ENaiLUGpD28l/7BKy9KRBZc8vRwGDBgBvLtF/j7mFWP7pTJgZff9 zdqg== 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=AUwLgh2fMAJcNm2yC+Lr0K/IFUhAkL6E5stNXBx//HU=; b=HCYMW2BlOuZIlKZXI3j1hV8lKdVx28fqkOoOZEM8jMvpo8n1sQR+H9cnk9hAfpLIsf Rqatb043l1DXt/j/r5q9mSFoQGlBJMhc2rsxR6MPIxVIartAnGfCk3gy/CQh6h9s1Jg4 MEdTDDM8h/5LLXD/3K4BFIN3owfkIw2qQ3q8L5lhvQliIamG2ttlZ4xNvI6tQzRrDO/X foGtNixFNkrlm0zJSMUxLUmiHUR055o0mGmMYhbK01Rm9X3IzMjCewthc2mRMXYSOlWP WDQOuFtF7GR0nQVdexZ8aQvgDB9F1dCSXvs2osaDKIbcC3R/NDFE3PWnNH2sSfN6vE8w bkYA== X-Gm-Message-State: AElRT7EjF43Z3MdjtdoBxe6oztYZjy1RBtcX9/Chapdu2hT2fHX3d1Jl u4BWx/R3Eou5+OIJBQYHR1/IA37yLLa6X5CHHYpsXQ== X-Google-Smtp-Source: AG47ELvcMKFEywdOpLQhtcAhE+dzYGysTy1g6B1jhxGkKGmaNHHzyDWvNMg4ygASaAdfPAJOrQXF7fViPqPGWfkcTsU= X-Received: by 2002:a19:6d03:: with SMTP id i3-v6mr5494704lfc.34.1521376174859; Sun, 18 Mar 2018 05:29:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.66.82 with HTTP; Sun, 18 Mar 2018 05:29:34 -0700 (PDT) In-Reply-To: <8522600D-9020-4428-AC90-13241496B3A0@glyphein.mailforce.net> References: <5AA937BD.60009@isdg.net> <161853F2-317C-405B-B241-4468FFBF4D04@akamai.com> <1521121872.3815.118.camel@tx.net> <5AAAA49C.7020401@isdg.net> <5AAAEF5D.1010900@isdg.net> <75B6163D-7FB4-4BED-AD2F-2EED0CD0B33C@glyphein.mailforce.net> <5AAB3596.7060503@isdg.net> <8522600D-9020-4428-AC90-13241496B3A0@glyphein.mailforce.net> From: "Murray S. Kucherawy" Date: Sun, 18 Mar 2018 12:29:34 +0000 Message-ID: To: Stan Kalisch Cc: Hector Santos , dcrup@ietf.org Content-Type: multipart/alternative; boundary="00000000000078eba30567aefe9e" Archived-At: Subject: Re: [Dcrup] sha1 wall of shame 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, 18 Mar 2018 12:29:38 -0000 --00000000000078eba30567aefe9e Content-Type: text/plain; charset="UTF-8" On Fri, Mar 16, 2018 at 8:58 PM, Stan Kalisch wrote: > Likewise, I take exception to everything you said; I stand by my > characterization of your behavior. In any event, I will not continue to > discuss this on the list. Yes, let's please move on. -MSK, chair hat sitting nearby --00000000000078eba30567aefe9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Mar 16, 2018 at 8:58 PM, Stan Kalisch <= stan@glyphein.mailforce.net> wrote:
Likewise, I = take exception to everything you said; I stand by my characterization of yo= ur behavior.=C2=A0 In any event, I will not continue to discuss this on the= list.

Yes, let's please move on.
-MSK, chair hat sitting nearby
--00000000000078eba30567aefe9e-- From nobody Sun Mar 18 10:10:05 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E823126DFF for ; Sun, 18 Mar 2018 10:10:04 -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 aUojQsyncinv for ; Sun, 18 Mar 2018 10:10:02 -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 74831126BF3 for ; Sun, 18 Mar 2018 10:10:01 -0700 (PDT) Authentication-Results: w1.wizint.net; iprev=fail; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org; arc=none Received: from [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90.112) id 1exbok-0007jg-Tj for dcrup@ietf.org (return-path ); Sun, 18 Mar 2018 17:09:59 +0000 To: dcrup@ietf.org References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> From: Jeremy Harris Message-ID: <9f898f2e-2c25-e47a-eabb-a85a03caee45@wizmail.org> Date: Sun, 18 Mar 2018 17:09:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=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, 18 Mar 2018 17:10:04 -0000 On 22/01/18 17:30, James Cloos wrote: > [Replying to a random mail in the thread.] > > The optimal way to encode an eddsa public key in dns is raw binary with > either hex, base32 or base64 for the presentation format. > > But for dkim, since it is stuck with TXT and already uses base64 for > k=rsa's p=, then base64 of the raw public key is the answer. > > In base64 an ed25519 key will take 44 octets. > > A records like this: > > v=DKIM1;k=ed25519;p=fjkXkmq6aJiRS2tycuHzHdCYRcA2WWgEs0oh+HoXz2g= Unsure if this is the right place to ask, but... while a site has both rsa and ed25519 keys, must a different selector be used? Or do multiple TXT records for one selector suffice, with the verifying MTA required to search for a match between the TXT record k= and the signature a= ? -- Thanks, Jeremy From nobody Sun Mar 18 11:20:59 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 9350A124D6C for ; Sun, 18 Mar 2018 11:20:57 -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, 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=HXPgaUfC; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=Q7aSEAu0 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 jzmOCO4yNk9t for ; Sun, 18 Mar 2018 11:20:56 -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 0DDD512025C for ; Sun, 18 Mar 2018 11:20:56 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1521397254; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=x3HRoVHiUUSAk9fipK6WAI9rqeHf59xW87INMUBjMg4=; b=HXPgaUfCDzJRyuZPYgy/x1Npr2IfNFbf0vJRRPKX34ub2T7Ohz1HPOyl oQUIGWC7lDvVA3ukF4yye7u2n5uyCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1521397254; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=x3HRoVHiUUSAk9fipK6WAI9rqeHf59xW87INMUBjMg4=; b=Q7aSEAu0ZzEYCWp7wmUNIXPCkWsecLsaA1uxOuRyq57Rt5xLiQOpfyd5 DbFNcKcdYCcbmMBXfbEz7bf/iz+orGyeakk6CwrhuFNgbBJsLYKezJykis G5rNjcKtWJ2tXvpO/KFOQpsDj/thr2Uo/fBJBtVMSncs5G8TQe5CAo9oUq 3KDeJcKU44GrRaKFr8Dl9oFBN6lkv3ZCFAsAxsBVF4MN7pG4b5aS2Mt4SM oDm05jO0AY/s0mAgsVBI8jt7g5i9tFF/rjXunmbpdk2E6cXGd61aHe3VX8 70xkR4g4TTRDxknSwWd9OEnCz1bONw3/seEISOISW+kCYloQbPk/Ww== 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 E505DC401F6; Sun, 18 Mar 2018 13:20:53 -0500 (CDT) Date: Sun, 18 Mar 2018 18:20:50 +0000 In-Reply-To: <9f898f2e-2c25-e47a-eabb-a85a03caee45@wizmail.org> References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <9f898f2e-2c25-e47a-eabb-a85a03caee45@wizmail.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: <89C46D5C-9538-4305-A41A-8BDCBAA7F9BE@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: Sun, 18 Mar 2018 18:20:58 -0000 On March 18, 2018 5:09:58 PM UTC, Jeremy Harris wrote: >On 22/01/18 17:30, James Cloos wrote: >> [Replying to a random mail in the thread=2E] >>=20 >> The optimal way to encode an eddsa public key in dns is raw binary >with >> either hex, base32 or base64 for the presentation format=2E >>=20 >> But for dkim, since it is stuck with TXT and already uses base64 for >> k=3Drsa's p=3D, then base64 of the raw public key is the answer=2E >>=20 >> In base64 an ed25519 key will take 44 octets=2E >>=20 >> A records like this: >>=20 >> v=3DDKIM1;k=3Ded25519;p=3DfjkXkmq6aJiRS2tycuHzHdCYRcA2WWgEs0oh+HoXz2g= =3D > >Unsure if this is the right place to ask, but=2E=2E=2E > >while a site has both rsa and ed25519 keys, must a >different selector be used? Or do multiple TXT records >for one selector suffice, with the verifying MTA required >to search for a match between the TXT record k=3D >and the signature a=3D ? RFC 6376 paragraph 3=2E6=2E2=2E2 says, "TXT RRs MUST be unique for a parti= cular selector name; that is, if there are multiple records in an RRset, th= e results are undefined=2E" I think it has to be a different selector=2E Scott K From nobody Tue Mar 20 04:44:21 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F30412EAC6 for ; Tue, 20 Mar 2018 04:44:13 -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 hwg-iRhtHV7P for ; Tue, 20 Mar 2018 04:44:11 -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 4D12812EAAF for ; Tue, 20 Mar 2018 04:43:52 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id e5-v6so2020015lfb.7 for ; Tue, 20 Mar 2018 04:43:52 -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=8DwD0BBSylY2G0bvy6QlX/HAOJBDs9sP+61CzLvWO+A=; b=F9i+WY8daeYDguNncjMLarqe468vzA7VvsVbXHpU5mkxadFvCzH2q/4BN76RXQ0dTV vWP/WeKj2UYttE89oLDOsDxqb7Cdyexdn8DwWo6x61RQRQH8z+YiRPR5k+5u7v/y+c7b pD5Reos66dp9zEsG8RAOSy8+8ru55+TruVcLBhd6gneMKzs0Ga0Omyy0cnzIth+xy3iZ LO3Jw3r/xj0cZZbvCdfpmGUvwtjbwlyE2mt+cq9vDfFqnwPRVEeKNNTe3dvDd8YoN3yY 4TmbBp+gESwn9Ep1efjwIuZvtz9+1eKpHT3eii0R+oz+R+6O5VMhqfPuWpEpbc4I0RTe 9sGA== 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=8DwD0BBSylY2G0bvy6QlX/HAOJBDs9sP+61CzLvWO+A=; b=qMl1999IxIMbKTr3QnT40ibvW5vZGQcRu/YICzV22yixW2On2LoYRHqfXld1DrytkP pyr1KNPFmxvhDtOQTEMknIRZFaikagMEs9xL0ENuaXFoR2UN/H9jroi0xdTjk2fIacdV J46qo4NQ07smIivoAcbAfGOp7bY1I4viEKV3Nv7k1GdVqUwyI5+EkUeH0WIvQrKNJyHW xdGJQxrIF5HAjLXn1ak+A43dAUCE/kPqgxMf5YozX4gvSsYK55TlCU6bTrjHnZAjJQO2 UpbHi11HBiZ0JCJM1LVZlWke9A5mayMISPJPOew0Zwtm8wBhsNkGsoODyv4KLCBAyzRc X3Og== X-Gm-Message-State: AElRT7EMsy2ItN1jO2x8toqEnYJ2EHcJyGMiBrS32EqQ6zATGSiAC1/7 G6iFv9fp6gSpsrN7M7BCz1V2MVK1o65lMb2EPWc= X-Google-Smtp-Source: AG47ELtdX54wM1Lr6pjhYPYyWx/K015PLLJ5uXof/v7ucqRN4O8HvDp6sqcAj0N7sZiKihKKOUOCcabtfuKuRMCowM8= X-Received: by 10.46.75.17 with SMTP id y17mr10179768lja.10.1521546230500; Tue, 20 Mar 2018 04:43:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.66.82 with HTTP; Tue, 20 Mar 2018 04:43:49 -0700 (PDT) In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> From: "Murray S. Kucherawy" Date: Tue, 20 Mar 2018 11:43:49 +0000 Message-ID: To: "John R. Levine" Cc: "Salz, Rich" , "dcrup@ietf.org" , Scott Kitterman Content-Type: multipart/alternative; boundary="f403045ea6bc94104f0567d696a9" Archived-At: Subject: Re: [Dcrup] ed25519 in DNS (was: Re: Review of: draft-ietf-dcrup-...) X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:44:16 -0000 --f403045ea6bc94104f0567d696a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Typo in Section 4.2 ("mignt" should be "might"). Also, I'm ignorant about these things, so bear with me: The format chosen for DNS in the draft is "the ed25519 public key encoded in base64". Is this the same as what we did for RSA keys, where it's just the PEM format of the key with all the guard strings and wrapped lines removed, or is there more to it than that? -MSK On Tue, Jan 23, 2018 at 3:50 AM, John R. Levine wrote: > Will the author of the draft please pick on and update the draft soon. I= f >> anyone on the WG has good rationale for disagreeing with the author=E2= =80=99s >> choice, think twice and post it. >> > > The people have spoken and seem to have said base64. Updated draft > posted, also with style edits per Dave's suggestions. > > > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > --f403045ea6bc94104f0567d696a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Typo in Section 4.2 ("mignt" should be= "might").

Also, I'm ignorant about these things= , so bear with me: The format chosen for DNS in the draft is "the ed25= 519 public key encoded in base64".=C2=A0 Is this the same as what we d= id for RSA keys, where it's just the PEM format of the key with all the= guard strings and wrapped lines removed, or is there more to it than that?=

-MSK


On Tue, Jan 23, 2018 at 3:50 AM, John R. Levine <johnl@iecc= .com> wrote:
Will the author of the draft please pick on and update the draft soon.=C2= =A0 If anyone on the WG has good rationale for disagreeing with the author= =E2=80=99s choice, think twice and post it.

 The people have spoken and seem to have said base64.=C2=A0 Updated draft po= sted, also with style edits per Dave's suggestions.


Regards,
John Levine, johnl@iecc= .com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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


--f403045ea6bc94104f0567d696a9-- From nobody Tue Mar 20 04:58: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 AF990126D85 for ; Tue, 20 Mar 2018 04:58:38 -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 0sBUv_DfZN92 for ; Tue, 20 Mar 2018 04:58:35 -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 C0F31126DC2 for ; Tue, 20 Mar 2018 04:58:35 -0700 (PDT) Authentication-Results: w1.wizint.net; iprev=pass (vgate18.wizint.net); auth=pass (PLAIN) smtp.auth=jgh@wizmail.org; arc=none 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.112) id 1eyFuT-0005L4-LT for dcrup@ietf.org (return-path ); Tue, 20 Mar 2018 11:58:33 +0000 To: dcrup@ietf.org References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> From: Jeremy Harris Message-ID: Date: Tue, 20 Mar 2018 11:58:30 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: 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: Tue, 20 Mar 2018 11:58:39 -0000 On 20/03/18 11:43, Murray S. Kucherawy wrote: > Also, I'm ignorant about these things, so bear with me: The format chosen > for DNS in the draft is "the ed25519 public key encoded in base64". Is > this the same as what we did for RSA keys, where it's just the PEM format > of the key with all the guard strings and wrapped lines removed, or is > there more to it than that? It's very different; there's _less_to it than that. It's the raw key number; b64-encoded. Unlike for RSA keys, there is no ASN.1 wrapping. It's quite difficult to generate the string, or at least was as of a few months ago. I ended up writing a little program, using a GnuTLS version I found only on Fedora Rawhide. None of the utility programs commonly found for GnuTLS, OpenSSL or NSS appeared to support the need. Published ways of doing it would be a good thing. -- Cheers, Jeremy From nobody Tue Mar 20 05:27:52 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 CA3F312DA73 for ; Tue, 20 Mar 2018 05:27:47 -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 (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPg4PzPT6f49 for ; Tue, 20 Mar 2018 05:27:44 -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 098E512E8EA for ; Tue, 20 Mar 2018 05:27:43 -0700 (PDT) Received: (qmail 70176 invoked from network); 20 Mar 2018 12:27:43 -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=1121e.5ab0fe3f.k1803; bh=s4CM7Fja7dOJeO3cyB2o0zGU98rOpNJTNtNmEe4P+lM=; b=MfwgVMaut3OjVlZTS0TrKOv0ONM5NthpweixQ6UEFhsfToEqWB0ljWwsY6cX6NYYrcUAaY4lJWiOEzSI77UgrLiEEZLz4raF8qo6mjG3eHxV4VZclIuR/uNrqhx+hVY660CiPbqRDNmOB4Z+o4ZdU8egOeavg7dbtpXs12Ymbs9k41T4Poj/LLcZGOQLTpDuJcQ57sQzCRNY3XyLiXvDMLFHZgTRqNyOWWG7MJm4je4KB1fu9trl9jbrUoo4edLZ 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; 20 Mar 2018 12:27:42 -0000 Date: 20 Mar 2018 12:27:42 +0000 Message-ID: From: "John R. Levine" To: "Murray S. Kucherawy" Cc: "Salz, Rich" , "dcrup@ietf.org" In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] ed25519 in DNS (was: Re: Review of: draft-ietf-dcrup-...) X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 12:27:50 -0000 > Also, I'm ignorant about these things, so bear with me: The format chosen > for DNS in the draft is "the ed25519 public key encoded in base64". Is > this the same as what we did for RSA keys, where it's just the PEM format > of the key with all the guard strings and wrapped lines removed, or is > there more to it than that? There's much less. The RSA key is a blob of ASN.1 that wraps subparts, while the ed25519 key is just the bare 32 byte public key in base64. Should you have a PEM format ed25519 key it's up to you to pick the actual key out of the ASN.1. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Mar 20 05:47:19 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 43DE612702E for ; Tue, 20 Mar 2018 05:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmkS1OBW9Atz for ; Tue, 20 Mar 2018 05:47:16 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4037126DED for ; Tue, 20 Mar 2018 05:47:16 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2KCgvhT016948; Tue, 20 Mar 2018 12:47:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=aq8G05yJZhvlXhWk4UebjG0ntOFVNGhyWIhqYa+kSzY=; b=G+voAsWtb2+VAOHj9Wer4N5n6RjyiMN6FfwJZg88MH3HbfElVf5KLz9/XoQUyxVRRACv iAh3z6Sqn007NEijzPTe6XtyMmtDcKW44JFx/CVOjO7MI0ghB1AsHvAfuiAwfG6ctL8W JaqVkhAX6nZQK7OXg5mg7F7ngE+cMNmke43Qbgf7smw/6HwL1w9IFiMG6YLMCebkMUVA 1rvMDlCBUU44NDXXUGVkDr6PsUk+sJZcum1yOdvbZ3lU68PreWfmm/7i96Tdvl181Thj l8SpFzFNl0p8asNTpJtekLNUUoFTFryTaQTOQuvtONVVwHiqSclY0X0o5yPYd+xUbpsA vw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2gruxm0cjm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Mar 2018 12:47:15 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w2KCk0qh028556; Tue, 20 Mar 2018 08:47:14 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint1.akamai.com with ESMTP id 2grxbujerm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Mar 2018 08:47:14 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 20 Mar 2018 08:47:13 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Tue, 20 Mar 2018 08:47:13 -0400 From: "Salz, Rich" To: Jeremy Harris , "dcrup@ietf.org" Thread-Topic: [Dcrup] ed25519 in DNS Thread-Index: AQHTwELMBQuIVyAaXkGxq4oyoJ8nq6PZEp2A Date: Tue, 20 Mar 2018 12:47:13 +0000 Message-ID: <302AAC54-A013-4ACD-A9F9-815D1124C146@akamai.com> References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.5] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-20_05:, , 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=765 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200149 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-20_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=703 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200149 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, 20 Mar 2018 12:47:18 -0000 RG9uJ3QgZG8gYW55IGNyeXB0bywganVzdCB0YWtlIHRoZSByYXcga2V5IGRhdGEgYW5kIGJhc2U2 NCBlbmNvZGUgaXQsIHJpZ2h0Pw0KDQoNCu+7v09uIDMvMjAvMTgsIDc6NTggQU0sICJKZXJlbXkg SGFycmlzIiA8amdoQHdpem1haWwub3JnPiB3cm90ZToNCg0KICAgIE9uIDIwLzAzLzE4IDExOjQz LCBNdXJyYXkgUy4gS3VjaGVyYXd5IHdyb3RlOg0KICAgID4gQWxzbywgSSdtIGlnbm9yYW50IGFi b3V0IHRoZXNlIHRoaW5ncywgc28gYmVhciB3aXRoIG1lOiBUaGUgZm9ybWF0IGNob3Nlbg0KICAg ID4gZm9yIEROUyBpbiB0aGUgZHJhZnQgaXMgInRoZSBlZDI1NTE5IHB1YmxpYyBrZXkgZW5jb2Rl ZCBpbiBiYXNlNjQiLiAgSXMNCiAgICA+IHRoaXMgdGhlIHNhbWUgYXMgd2hhdCB3ZSBkaWQgZm9y IFJTQSBrZXlzLCB3aGVyZSBpdCdzIGp1c3QgdGhlIFBFTSBmb3JtYXQNCiAgICA+IG9mIHRoZSBr ZXkgd2l0aCBhbGwgdGhlIGd1YXJkIHN0cmluZ3MgYW5kIHdyYXBwZWQgbGluZXMgcmVtb3ZlZCwg b3IgaXMNCiAgICA+IHRoZXJlIG1vcmUgdG8gaXQgdGhhbiB0aGF0Pw0KICAgIA0KICAgIEl0J3Mg dmVyeSBkaWZmZXJlbnQ7IHRoZXJlJ3MgX2xlc3NfdG8gaXQgdGhhbiB0aGF0Lg0KICAgIEl0J3Mg dGhlIHJhdyBrZXkgbnVtYmVyOyBiNjQtZW5jb2RlZC4gIFVubGlrZSBmb3IgUlNBDQogICAga2V5 cywgdGhlcmUgaXMgbm8gQVNOLjEgd3JhcHBpbmcuDQogICAgDQogICAgDQogICAgSXQncyBxdWl0 ZSBkaWZmaWN1bHQgdG8gZ2VuZXJhdGUgdGhlIHN0cmluZywgb3IgYXQgbGVhc3QNCiAgICB3YXMg YXMgb2YgYSBmZXcgbW9udGhzIGFnby4gIEkgZW5kZWQgdXAgd3JpdGluZyBhIGxpdHRsZQ0KICAg IHByb2dyYW0sIHVzaW5nIGEgR251VExTIHZlcnNpb24gSSBmb3VuZCBvbmx5IG9uIEZlZG9yYQ0K ICAgIFJhd2hpZGUuICBOb25lIG9mIHRoZSB1dGlsaXR5IHByb2dyYW1zIGNvbW1vbmx5IGZvdW5k DQogICAgZm9yIEdudVRMUywgT3BlblNTTCBvciBOU1MgYXBwZWFyZWQgdG8gc3VwcG9ydCB0aGUg bmVlZC4NCiAgICANCiAgICBQdWJsaXNoZWQgd2F5cyBvZiBkb2luZyBpdCB3b3VsZCBiZSBhIGdv b2QgdGhpbmcuDQogICAgLS0gDQogICAgQ2hlZXJzLA0KICAgICAgSmVyZW15DQogICAgDQogICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBEY3J1 cCBtYWlsaW5nIGxpc3QNCiAgICBEY3J1cEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGNydXANCiAgICANCg0K From nobody Tue Mar 20 06:09: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 98ED6126DED for ; Tue, 20 Mar 2018 06:09:52 -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=mgJx49QS; dkim=pass (1536-bit key) header.d=taugh.com header.b=bXpOvhSC 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 h1dpCofn8wE7 for ; Tue, 20 Mar 2018 06:09:51 -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 6ED1F124B17 for ; Tue, 20 Mar 2018 06:09:51 -0700 (PDT) Received: (qmail 77832 invoked from network); 20 Mar 2018 13:09:50 -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=13005.5ab1081e.k1803; bh=Tam/SSpviVzGTnjVwlECNghwhubRXKNIRmMuzSCmSls=; b=mgJx49QSZZiiPriP2ffl9CjInpUELPvLR08V5uVaJD455Ns4zzy+4IjH9q2wc16LgT/VcdnRvVpWLgdldjiGzW5FoM8yyFXCaLyKQWEHsAbXyI5ROgjxMjlEcD0Vvcgq2m2wwiEyJ100WZAXMITOfVQpKmz6ccHkyJxN1MVrpuHgAe5AahyoxP++AWjJISazg8+3axEP0GuonnwVyXGj+R57oHpgRJKxINynsbokv82PHJgfh/AkmV887HWkgIZw 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=13005.5ab1081e.k1803; bh=Tam/SSpviVzGTnjVwlECNghwhubRXKNIRmMuzSCmSls=; b=bXpOvhSCkZhO9mezu1Xd35T+fDIhEZfJTh66nTTw+LhgcK6rwk9NEJ5xSCZzkdcHOZMrPAJZudQmTFExIZKQLXa1bGjYqyfPXs6K4zvPsiNFB43YeH6qBtafa/WrLUBoqYqazJqJJXm9IITKywj1p6AwXgCbe0hZFFc4ZDpnQeUofVFRyJU4nAUBdEHg0d1XOD0P7ItKBC4Sbwf3wpSutnPIKg2L09yAe5XT4Y8FFq7D+RaBYA6xpSqzuge0x6Xm Received: from dhcp-935d.meeting.ietf.org ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 20 Mar 2018 13:09:49 -0000 Received: by dhcp-935d.meeting.ietf.org (Postfix, from userid 501) id 2CFA023641AE; Tue, 20 Mar 2018 13:09:48 +0000 (GMT) Date: 20 Mar 2018 13:09:48 +0000 Message-Id: <20180320130949.2CFA023641AE@dhcp-935d.meeting.ietf.org> From: "John Levine" To: dcrup@ietf.org Cc: sklist@kitterman.com In-Reply-To: <89C46D5C-9538-4305-A41A-8BDCBAA7F9BE@kitterman.com> 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, 20 Mar 2018 13:09:52 -0000 In article <89C46D5C-9538-4305-A41A-8BDCBAA7F9BE@kitterman.com> you write: >>while a site has both rsa and ed25519 keys, must a >>different selector be used? >RFC 6376 paragraph 3.6.2.2 says, "TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in >an RRset, the results are undefined." >I think it has to be a different selector. Agreed. Multiple key records at the same name would open a can of worms. (If you can have two keys of different k=, how about keys with different h= ?) R's, John From nobody Tue Mar 20 06:11: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 A44491270AE for ; Tue, 20 Mar 2018 06:11:45 -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 (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKSJ7DCo9SjP for ; Tue, 20 Mar 2018 06:11:44 -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 19DE4126DED for ; Tue, 20 Mar 2018 06:11:44 -0700 (PDT) Received: (qmail 78224 invoked from network); 20 Mar 2018 13:11:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=1318e.5ab1088f.k1803; bh=ZrB6zg3uQsRIoxZeWpVoFPvHm75Q6LVDXGU/MrU48LA=; b=QCZgLoV6Y7bTCDYEvB87K5gCJQb4v82j9EAA8f6BgB4YxS5G/xUfMmmfO+/Yz+ZbV0AFKZf+d+5jHpoVpIso09+2NA8KKc87Y2TH890S4uSXDiZHoakQ3slXU62avcKOAv2eEKn776G7D6/0yEUcXeDWj0Cwx9zBYAOZjyM94SSaZ9llGKrIoU0E3wbP8ckJVr7xzAfoCIma0wcSEMVltMp0l1ZrpeBUkXw5SN/UbgWgtfsTkTBhsTktCWAIwMg1 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; 20 Mar 2018 13:11:42 -0000 Date: 20 Mar 2018 13:11:40 +0000 Message-ID: From: "John R. Levine" To: dcrup@ietf.org 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 key format in DNS (was: Re: Review of: draft-ietf-dcrup-...) X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 13:11:46 -0000 > Also, I'm ignorant about these things, so bear with me: The format chosen > for DNS in the draft is "the ed25519 public key encoded in base64". Is > this the same as what we did for RSA keys, where it's just the PEM format > of the key with all the guard strings and wrapped lines removed, or is > there more to it than that? There's much less. The RSA key is a blob of ASN.1 that wraps subparts, while the ed25519 key is just the bare 32 byte public key in base64. Should you have a PEM format ed25519 key it's up to you to pick the actual key out of the ASN.1. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Mar 20 06:27:30 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 7B12D126DED for ; Tue, 20 Mar 2018 06:27:28 -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, 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=E0yjyUkf; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=qEdAxchc 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 qQBf2pfLcjix for ; Tue, 20 Mar 2018 06:27:25 -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 C9DD5124B17 for ; Tue, 20 Mar 2018 06:27:25 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1521552444; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=ZLF35NojaEbjOKwTTwn4vy3SC48p32q2fdJUl3v+Rlg=; b=E0yjyUkfMYqNoFFaJ5tMitzFB6ORoX0PMAZ+T8kCg694T5UHekHnl/0P Zkp0fJb6liCygi4U9vC53LXEM8l5AA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1521552444; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=ZLF35NojaEbjOKwTTwn4vy3SC48p32q2fdJUl3v+Rlg=; b=qEdAxchcJ7v4Mf7p1AqvjFLYOhiv5RTX4qYFOLCI3lFk7tzI0lD9fsMn E1ug86l6dtt9HUaF5I6ydxLG35oPyXsFl7Mx9PDreC960Pz58EhayHJMWs bwYZagV9nNw/RQes42vxrbMzc1RRffdC3/cRNKL0Lh7Kfei8+U/6zrn8/Z K+AoOf8xAEMKCYP9YZIZBAuqvrG+hl3zz/I/s9nKnapnHprWIrNOCMkpQe E/7hqKlgeRVrDR0RRXOxsE/PPw90prRRM0ihlyYPfi4nSayx6eSxhLhxM5 6RYv1GFziowHiacuI0wTJ7lOTE/laby+Ib4Di5WnRabqeYJnEX/GRQ== 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 93BBDC401AD; Tue, 20 Mar 2018 08:27:24 -0500 (CDT) Date: Tue, 20 Mar 2018 13:27:21 +0000 In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: 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, 20 Mar 2018 13:27:28 -0000 On March 20, 2018 11:58:30 AM UTC, Jeremy Harris wrote= : >On 20/03/18 11:43, Murray S=2E Kucherawy wrote: >> Also, I'm ignorant about these things, so bear with me: The format >chosen >> for DNS in the draft is "the ed25519 public key encoded in base64"=2E= =20 >Is >> this the same as what we did for RSA keys, where it's just the PEM >format >> of the key with all the guard strings and wrapped lines removed, or >is >> there more to it than that? > >It's very different; there's _less_to it than that=2E >It's the raw key number; b64-encoded=2E Unlike for RSA >keys, there is no ASN=2E1 wrapping=2E > > >It's quite difficult to generate the string, or at least >was as of a few months ago=2E I ended up writing a little >program, using a GnuTLS version I found only on Fedora >Rawhide=2E None of the utility programs commonly found >for GnuTLS, OpenSSL or NSS appeared to support the need=2E > >Published ways of doing it would be a good thing=2E I guess it depends on the tools=2E For me it was completely trivial=2E S= ee GenEd25519Keys at line 50 in https://git=2Elaunchpad=2Enet/dkimpy/tree/d= knewkey=2Epy for private key generation and ExtractEd25519PublicKey at line= 82 for generating the private key and then extracting the public key from = it=2E Of course now that it's written, it's even easier to just run the script= =2E Scott K From nobody Tue Mar 20 06:47: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 B9461126DED for ; Tue, 20 Mar 2018 06:47: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 7WuvATFG2B8r for ; Tue, 20 Mar 2018 06:47:30 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 E5B32124B17 for ; Tue, 20 Mar 2018 06:47:29 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id p142-v6so2639565lfd.6 for ; Tue, 20 Mar 2018 06:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yQdYxB0cSglbI2lEX6yyyl9FEG6d/vOLFfXQpU+gvq0=; b=fkoZ5hZsjQstw1BwylFdqf++cjngLCOG4wVBQz/FFhemItV2XNck8Ov2o6MZZFrZ25 qAXnM0QciF+FNf2BRuigGWQSziKTmwFLt1ztEDgLuVN/yxjjSPwTgUMsUt8ceZzQhzlQ KtEiFunCrhig3+bBj7Oxk8fbGrTRTLEhMDNRhk2XIscjsVoBJqSfCXvkwnYzofB4X5p0 ppoLmw0fjU6lUGcd0coxsl3l2sSUeaFl+6h0NqCAP/gDht4YJVkenc3k9G6EB2FBbBiz zqZz0JMTouJ30r+jZMz41jkAqTuzCHpBD8Kt7naA+FMsrTn0dYUlydmGq7tnLOI9NR1l dGFw== 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=yQdYxB0cSglbI2lEX6yyyl9FEG6d/vOLFfXQpU+gvq0=; b=JWH+b6EUxU9jf+jEQ7KzsTlwwWq2e+1U5u5iL8qjoIoyFMQyEbP0XMiz30fFQG+qZ4 Poy/fuZyxjiXnJAzzyo6Xo280kTbTh2mWvPpNYl/hNZbwwB1X8md5bw12pOs9VhSpl0/ zIHqvtQxfswHFwseUvq4z0lI1vdVTyxUs2MAfJJAgZQ/GqQvvZ0sFDntyX4D1s84YFVX cDv33j0NSi5Lu8XbZgZgR9SqrSaiF17Hof204VCyiRdzuR2UHhpjr6xvJo2zeHHqYQHN Pnnt5gKB8FqcJZmV32YrKEpmhkmbY7Vt1vM2ebG+jVNvuuno+2QL9GZ4Dux/NTaNYFLO RbeA== X-Gm-Message-State: AElRT7EMWH3mCgXh7TMME1FSgVO9ir0goywoWLNtDkYjAa0Cgs5qPaPr mQk3Q97kGNwPSMYvjVEFw7VJHSwLldUDMuy+HMI= X-Google-Smtp-Source: AG47ELvLvzo5hwROBlSa31qVTE4HigzvYElDnZbahtcL8zPdPKQY0x0n+eeCu2gxrQKQlWyDYxquhroUB98+Apuii2E= X-Received: by 2002:a19:5789:: with SMTP id l131-v6mr11384529lfb.135.1521553648117; Tue, 20 Mar 2018 06:47:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.66.82 with HTTP; Tue, 20 Mar 2018 06:47:27 -0700 (PDT) In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> From: "Murray S. Kucherawy" Date: Tue, 20 Mar 2018 13:47:27 +0000 Message-ID: To: Jeremy Harris Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="000000000000b3ee3a0567d8509b" 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, 20 Mar 2018 13:47:32 -0000 --000000000000b3ee3a0567d8509b Content-Type: text/plain; charset="UTF-8" On Tue, Mar 20, 2018 at 11:58 AM, Jeremy Harris wrote: > It's very different; there's _less_to it than that. > It's the raw key number; b64-encoded. Unlike for RSA > keys, there is no ASN.1 wrapping. > > It's quite difficult to generate the string, or at least > was as of a few months ago. I ended up writing a little > program, using a GnuTLS version I found only on Fedora > Rawhide. None of the utility programs commonly found > for GnuTLS, OpenSSL or NSS appeared to support the need. > > Published ways of doing it would be a good thing. That's what I was thinking. Extracting something from a PEM-formatted RSA key and putting it in the DNS requires a tiny amount of programming, because I don't care what's under the base64. As I understand it, the way we're choosing to do this requires a PEM-formatted ed25519 to be base64-decoded and then parsed somehow to extract only a key number, and then re-base64 that and put it in the DNS. -MSK --000000000000b3ee3a0567d8509b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 20, 2018 at 11:58 AM, Jeremy Harris <jgh@wizma= il.org> wrote:
It's very different; there= 9;s _less_to it than that.
It's the raw key number; b64-encoded.=C2=A0 Unlike for RSA
keys, there is no ASN.1 wrapping.

It's quite difficult to generate the string, or at least
was as of a few months ago.=C2=A0 I ended up writing a little
program, using a GnuTLS version I found only on Fedora
Rawhide.=C2=A0 None of the utility programs commonly found
for GnuTLS, OpenSSL or NSS appeared to support the need.

Published ways of doing it would be a good thing.

That's what I was thinking.=C2=A0 = Extracting something from a PEM-formatted RSA key and putting it in the DNS= requires a tiny amount of programming, because I don't care what's= under the base64.=C2=A0 As I understand it, the way we're choosing to = do this requires a PEM-formatted ed25519 to be base64-decoded and then pars= ed somehow to extract only a key number, and then re-base64 that and put it= in the DNS.

-MSK
--000000000000b3ee3a0567d8509b-- From nobody Tue Mar 20 07:07:54 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 209F31270AE for ; Tue, 20 Mar 2018 07:06:38 -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=DVKf6YwX; dkim=pass (1536-bit key) header.d=taugh.com header.b=gi16YAGt 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 UpP5US4nx5Ql for ; Tue, 20 Mar 2018 07:06:32 -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 22A0F12EAF0 for ; Tue, 20 Mar 2018 07:06:31 -0700 (PDT) Received: (qmail 91023 invoked from network); 20 Mar 2018 14:06:30 -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=1638c.5ab11566.k1803; bh=THgnVgej5xnse3IRl9UIng6VbKcAHwduFGrL1q+WpX4=; b=DVKf6YwX0a4Ch9HmrnFxYG7a6nBstYDS7SEL+iwPmkuCyTGFb4OM+rYkUHwxzpyZLuFdsZttUJ76NlLMBFE4w9ZPJ+H6QNDSG1zdA1wOpWalKwURZF8sPE7efVUl1pi+DeuIk/m1ArrmSub5iTndOcnAxeg1H+gISyb1wTBMxPSDbDRaKBCXTf3oksu4fbgXGGlg+gmUV7N6o1+5c4V8PI1XpkRcwdp85R1o3w9KO8d0VI1SjC9nw6u7PIHPdWlI 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=1638c.5ab11566.k1803; bh=THgnVgej5xnse3IRl9UIng6VbKcAHwduFGrL1q+WpX4=; b=gi16YAGtI7U9iPGJICem67ImlGCLnUNNrz71crALaSEQHpY3BU1xvUzp7F2zUl4RWQzie89fAaaNTnxRsB+EGFP1pRbzZLQIN0jcZx7WCwjF7a1G9Mh3Znng8RbCW3yovuuSNGzodojR8HYcVqnV7Lqaz7Goya3e2dnr5oFYO2xopdI+NpsUf4uAXtVrTONITZSQfq6+JW6Q19XAcYM6tzgY1FwoakCncAGfHzVfj6gGrFjJkDyG6DJbIzmp+XMW Received: from dhcp-8344.meeting.ietf.org ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 20 Mar 2018 14:06:29 -0000 Received: by dhcp-8344.meeting.ietf.org (Postfix, from userid 501) id B3E402365ECF; Tue, 20 Mar 2018 14:06:28 +0000 (GMT) Date: 20 Mar 2018 14:06:28 +0000 Message-Id: <20180320140628.B3E402365ECF@dhcp-8344.meeting.ietf.org> From: "John Levine" To: dcrup@ietf.org Cc: rsalz@akamai.com In-Reply-To: <302AAC54-A013-4ACD-A9F9-815D1124C146@akamai.com> 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, 20 Mar 2018 14:06:42 -0000 In article <302AAC54-A013-4ACD-A9F9-815D1124C146@akamai.com> you write: >Don't do any crypto, just take the raw key data and base64 encode it, right? Right. >On 3/20/18, 7:58 AM, "Jeremy Harris" wrote: > > On 20/03/18 11:43, Murray S. Kucherawy wrote: > > Also, I'm ignorant about these things, so bear with me: The format chosen > > for DNS in the draft is "the ed25519 public key encoded in base64". Is > > this the same as what we did for RSA keys, where it's just the PEM format > > of the key with all the guard strings and wrapped lines removed, or is > > there more to it than that? > > It's very different; there's _less_to it than that. > It's the raw key number; b64-encoded. Unlike for RSA > keys, there is no ASN.1 wrapping. > > > It's quite difficult to generate the string, or at least > was as of a few months ago. I ended up writing a little > program, using a GnuTLS version I found only on Fedora > Rawhide. None of the utility programs commonly found > for GnuTLS, OpenSSL or NSS appeared to support the need. > > Published ways of doing it would be a good thing. From nobody Tue Mar 27 13:28: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 1AB1C1273E2 for ; Tue, 27 Mar 2018 13:28:57 -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 qS0zVtnG0KWo for ; Tue, 27 Mar 2018 13:28:55 -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 95FF8127337 for ; Tue, 27 Mar 2018 13:28:54 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id e5-v6so269500lfb.7 for ; Tue, 27 Mar 2018 13:28:54 -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=NBUGoSql2UsPLCSfi1B5L/5dacHv2d9dWkeTLqmxzek=; b=BFk2bd+Z9ateL1fcPB1VzbCDbX7Qe5oVi817eiUQ26A+6riztrAU9WqNFlvrmS/c8i 3lrwLMzJZ4Zy75vQJi2KZjUdFA4Ibxj5ONlpGTZHKAXXC4Ow6hAirZHzNAGZCx9uWY6C /t6hyLlXBXsMtlooEsStuxVz2Ok15yd/QV1QZZda/yTmpDaS2u9lJPQBjDbHSdEUpJ0n IP2YoSjxWsJH/YF1GfsXYlaj5PWf2q9jms/t1Zri2dt6acTLrqXKpoKKhN25U9CJpTP3 /ipjySgjC+MwZQI4mugWah+hbfnHZhdwzgE787G4Pt1OM5+h6W+MwIEgpGb8HQcoDz3d bbkg== 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=NBUGoSql2UsPLCSfi1B5L/5dacHv2d9dWkeTLqmxzek=; b=hmt9Mh2Pk0oej1ugVf5jaY5bUFz0OZ10sumy6WFN0fqmq0Khbxg6KA/4Ei35JOhJXm qG8U1kgJyNOnenK34lP0/NHsMkAnQoBXHz7oCRV8PLR4GnnymP9fH9D7XzKrew2pbeDc EMfofBjgaRy7fxYfpH0GbV3Up9vaTBKMia4ef/OcZ4cdcrpk3AME8ecJwzwyTgdN5gDU jERn9PESVoahhbQwFb03x4HSIObbqosgSgLKyM0dbTROnp8QpWnBuP7+hkniu7sbbLOf Ywc4B5C1d2+Y0lhqkDFwtiqSKHTpO8NrFG1ICeYkZY+AKXFHG1V031w2ziS2Q3gyAX2g lC1A== X-Gm-Message-State: AElRT7GT6fy/p1wOMh87L9l8HhOyYsk+yMWEgq/RrIRpPU0MfhzU+kkc o/CLpCbEUiTqS90VuyJlDOVCOFlim5genHFlX+gATA== X-Google-Smtp-Source: AIpwx4+wziQROMlak8e5CSNoa5lVbSRdA+ZaMs7p8pr+Sa0Pcw9oL2igmy1muIDvHVEq/67yNAt/CQY3Vb3cCVP33e0= X-Received: by 10.46.41.156 with SMTP id p28mr496346ljp.32.1522182532362; Tue, 27 Mar 2018 13:28:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.115.7 with HTTP; Tue, 27 Mar 2018 13:28:51 -0700 (PDT) In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> From: "Murray S. Kucherawy" Date: Tue, 27 Mar 2018 20:28:51 +0000 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114b5bb81ff64b05686abd6b" 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, 27 Mar 2018 20:28:57 -0000 --001a114b5bb81ff64b05686abd6b Content-Type: text/plain; charset="UTF-8" On Tue, Mar 20, 2018 at 1:27 PM, Scott Kitterman wrote: > >It's very different; there's _less_to it than that. > >It's the raw key number; b64-encoded. Unlike for RSA > >keys, there is no ASN.1 wrapping. > > > >It's quite difficult to generate the string, or at least > >was as of a few months ago. I ended up writing a little > >program, using a GnuTLS version I found only on Fedora > >Rawhide. None of the utility programs commonly found > >for GnuTLS, OpenSSL or NSS appeared to support the need. > > > >Published ways of doing it would be a good thing. > > I guess it depends on the tools. For me it was completely trivial. See > GenEd25519Keys at line 50 in https://git.launchpad.net/dkim > py/tree/dknewkey.py for private key generation and > ExtractEd25519PublicKey at line 82 for generating the private key and then > extracting the public key from it. > > Of course now that it's written, it's even easier to just run the script. > A raw 32-byte integer is certainly small, but is it painful to leave it in ASN.1 and store it that way? It certainly fits in a DNS record, has a fixed format, is more idiomatic (i.e., standard) when manipulating crypto objects, and there's no ambiguity around how to interpret it. The process to extract one with OpenSSL is to generate the private key, then get the public key, then extract it in binary form, then chop the leading dozen bytes, then base64 that, or: $ openssl genpkey -algorithm ed25519 -outfile test.pem $ openssl pkey -outform DER -pubout -in test.pem | tail -c +13 | openssl base64 Meanwhile, DKIM users are already used to something more like: $ openssl genpkey -algorithm ed25519 -outfile test.pem $ openssl pkey -outform PEM -pubout -in test.pem ...and then taking that base64 blob and sticking it in the DNS as-is. Since that's guaranteed to fit, why don't we stick with it? Or, if we really think the integer-only approach is the right one, don't we have to specify stuff like byte order? -MSK, participating --001a114b5bb81ff64b05686abd6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 20, 2018 at 1:27 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
>It's very= different; there's _less_to it than that.
>It's the raw key number; b64-encoded.=C2=A0 Unlike for RSA
>keys, there is no ASN.1 wrapping.
>
>It's quite difficult to generate the string, or at least
>was as of a few months ago.=C2=A0 I ended up writing a little
>program, using a GnuTLS version I found only on Fedora
>Rawhide.=C2=A0 None of the utility programs commonly found
>for GnuTLS, OpenSSL or NSS appeared to support the need.
>
>Published ways of doing it would be a good thing.

I guess it depends on the tools.=C2=A0 For me it was completely triv= ial.=C2=A0 See GenEd25519Keys at line 50 in https:/= /git.launchpad.net/dkimpy/tree/dknewkey.py for private key generat= ion and ExtractEd25519PublicKey at line 82 for generating the private key a= nd then extracting the public key from it.

Of course now that it's written, it's even easier to just run the s= cript.

A raw 32-byte integer is certain= ly small, but is it painful to leave it in ASN.1 and store it that way?=C2= =A0 It certainly fits in a DNS record, has a fixed format, is more idiomati= c (i.e., standard) when manipulating crypto objects, and there's no amb= iguity around how to interpret it.

The process to extract= one with OpenSSL is to generate the private key, then get the public key, = then extract it in binary form, then chop the leading dozen bytes, then bas= e64 that, or:

$ openssl genpkey -algorithm ed25519 -outfi= le test.pem
$ openssl pkey -outform DER -pubout -in test.pem = | tail -c +13 | openssl base64

Meanwhile, DKIM users are = already used to something more like:

$ openssl genpkey -algorit= hm ed25519 -outfile test.pem
$ openssl pkey -outform PEM -pub= out -in test.pem

...and then taking that base64 blob and = sticking it in the DNS as-is.=C2=A0 Since that's guaranteed to fit, why= don't we stick with it?

Or, if we really think the i= nteger-only approach is the right one, don't we have to specify stuff l= ike byte order?

-MSK, participating
<= /div>
--001a114b5bb81ff64b05686abd6b-- From nobody Tue Mar 27 16:16:23 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 733A3126CF6 for ; Tue, 27 Mar 2018 16:16:21 -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=sm/srlMW; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=OYQT8WU4 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 nSniCN7Ad622 for ; Tue, 27 Mar 2018 16:16:20 -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 E1805124B18 for ; Tue, 27 Mar 2018 16:16:19 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1522192576; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=9/nk3Pl6bjt21erdoE+nRM3LhxWkV89pfze5b00NHik=; b=sm/srlMWLwLmqP5dOY0BisoBgqQAvRs3ZFwA/xqJ2GUOztM5Yv/0yWbu WfCp4dJsEBC4YFurXo92OkoQLw8uCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1522192576; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=9/nk3Pl6bjt21erdoE+nRM3LhxWkV89pfze5b00NHik=; b=OYQT8WU485roJ8+5kE5vfGKT/zRAaVSOV8Z8LLCefW6qa7/DmBBXi+oW yndRz8RwSbuYOkWPcGLZ349LlVvTOB0h3j0sd+H+tNeJc7xMgUKbDxlDbd y19lqBU0OliywL6qzXI/PimEFNpZjM6kDRcMazsOlmgib9X6jbP19dWIj3 Kz3KEhEIVgtxXnLo03SNA0r+QUri1LS3fi/1qw2hK6x7O6dfYzlGlMVHlP P2OvukynDAvvYrxf+e79QrTXWzwRnHOBjX08wdVuw6mXeKGUJSGqI8ed25 R7vPlmySDvzWycVVIaytzpKbbqGYb3LRTzbOyw3F/PmlZBSP0nOfjQ== Received: from [10.34.42.169] (mobile-166-170-33-51.mycingular.net [166.170.33.51]) (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 3A3F2C4026D; Tue, 27 Mar 2018 18:16:16 -0500 (CDT) Date: Tue, 27 Mar 2018 23:16:11 +0000 In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: 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, 27 Mar 2018 23:16:21 -0000 On March 27, 2018 8:28:51 PM UTC, "Murray S=2E Kucherawy" wrote: >On Tue, Mar 20, 2018 at 1:27 PM, Scott Kitterman >wrote: > >> >It's very different; there's _less_to it than that=2E >> >It's the raw key number; b64-encoded=2E Unlike for RSA >> >keys, there is no ASN=2E1 wrapping=2E >> > >> >It's quite difficult to generate the string, or at least >> >was as of a few months ago=2E I ended up writing a little >> >program, using a GnuTLS version I found only on Fedora >> >Rawhide=2E None of the utility programs commonly found >> >for GnuTLS, OpenSSL or NSS appeared to support the need=2E >> > >> >Published ways of doing it would be a good thing=2E >> >> I guess it depends on the tools=2E For me it was completely trivial=2E= =20 >See >> GenEd25519Keys at line 50 in https://git=2Elaunchpad=2Enet/dkim >> py/tree/dknewkey=2Epy for private key generation and >> ExtractEd25519PublicKey at line 82 for generating the private key and >then >> extracting the public key from it=2E >> >> Of course now that it's written, it's even easier to just run the >script=2E >> > >A raw 32-byte integer is certainly small, but is it painful to leave it >in >ASN=2E1 and store it that way? It certainly fits in a DNS record, has a >fixed format, is more idiomatic (i=2Ee=2E, standard) when manipulating >crypto >objects, and there's no ambiguity around how to interpret it=2E > >The process to extract one with OpenSSL is to generate the private key, >then get the public key, then extract it in binary form, then chop the >leading dozen bytes, then base64 that, or: > >$ openssl genpkey -algorithm ed25519 -outfile test=2Epem >$ openssl pkey -outform DER -pubout -in test=2Epem | tail -c +13 | >openssl >base64 > >Meanwhile, DKIM users are already used to something more like: > >$ openssl genpkey -algorithm ed25519 -outfile test=2Epem >$ openssl pkey -outform PEM -pubout -in test=2Epem > >=2E=2E=2E=2Eand then taking that base64 blob and sticking it in the DNS a= s-is=2E >Since that's guaranteed to fit, why don't we stick with it? > >Or, if we really think the integer-only approach is the right one, >don't we >have to specify stuff like byte order? > >-MSK, participating It's sufficiently defined by RFC 8032 and Base64=2E I don't think there'= s a standardized ASN=2E1 structure for this=2E I think ASN=2E1 is needless= complexity=2E Scott K From nobody Tue Mar 27 20:14:51 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5399126BF3 for ; Tue, 27 Mar 2018 20:14:49 -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 7Aq-n_58EyaA for ; Tue, 27 Mar 2018 20:14:48 -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 0EA5B124B0A for ; Tue, 27 Mar 2018 20:14:48 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id u3-v6so1334115lff.5 for ; Tue, 27 Mar 2018 20:14:47 -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=xTNwUFeV7eZwydY61Pn8/cBVvbbk6Z6jCrn7UNggPDI=; b=Yc9FCCeJFTuVzNne9HK6yNFYnCxsMYZQqHbSczHZUJSwZoR4q/7nyJ1+JSOXHhVsOQ 6bY2WEoAlEpfF/cusmPqxwIV+liKqPB6vKWVh+W6YEZB3i0m2E/38YocqBpggCQ+qCep Xu54OGYV2Ynb9T6AU4qK0wQ5wpxCTgf2GQcKB+bSC6l2h9+q1FcwTzYsLidIQUoH2bci O10w8Ukl5ITXY/bJrmCypoq6PF5IOHWLZp1n91TbqTNuzPcKEo5OQw8kMlrzzoScFYWT RHv73h4ngRo6mj7kxI1hD/tTg58JHt+zg1W/UUVqvoFCMs2umtxeFlMAW0h/K9z+oLIr NYig== 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=xTNwUFeV7eZwydY61Pn8/cBVvbbk6Z6jCrn7UNggPDI=; b=ElI51W/6znJWFti1zfcFPnWqwtcBx56tRTsT/YMy7zU8lHQH189yCswESlDadM7gwG RECqB7r7QfRMJtnB93mWAvQ3SdkwjD/qqY9lticYJWrLicMKIVX17+QJtHIe55knr59m C0/WOeoqN2JIgfUzD/jdfgY3DKvMU0NTuY00urhvkOhKCayjMD0wEGT84ejmxI0MktgC TVTqFF5pdp2a8KdEQHU2CVENuZr9Zm8ax+60XJOlyVTddfaYXuIwpzt6mWoJrQxYIh4J 3mkFe3Gsqg4t4zC9WE7M1cF586LTyTfhPvJH0G5cc/O8xDSQkITOLSYcjNiNm25gU+uV OAbw== X-Gm-Message-State: AElRT7GaesWONEleWyHRX5VKpHVsZDtdLqqwT9tOdB65bXfxINkCWQpG 0qSKgEE4itDR6UML+13or+VOHjDwOCVLdjPsHsKV2g== X-Google-Smtp-Source: AIpwx4/1fr8MPU9BdDmuLXhL5RBEw0ivDYQnl0udfCEwbc2/r/JGAlaNcbGKftSmCQEaLkLxd1oVUIaIkVt5m49Asbo= X-Received: by 10.46.23.70 with SMTP id l67mr1066677lje.132.1522206886296; Tue, 27 Mar 2018 20:14:46 -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> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 28 Mar 2018 03:14:35 +0000 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114af28abb826e0568706849" 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, 28 Mar 2018 03:14:49 -0000 --001a114af28abb826e0568706849 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 27, 2018 at 11:16 PM, Scott Kitterman wrote: > It's sufficiently defined by RFC 8032 and Base64. I don't think there's > a standardized ASN.1 structure for this. I think ASN.1 is needless > complexity. > But DKIM applications are already used to that complexity, or they use APIs to make it invisible to them. The entire ASN.1 output from OpenSSL for an Ed25519 public key, expanded: 0:d=0 hl=2 l= 46 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :00 5:d=1 hl=2 l= 5 cons: SEQUENCE 7:d=2 hl=2 l= 3 prim: OBJECT :ED25519 12:d=1 hl=2 l= 34 prim: OCTET STRING [HEX DUMP]:0420A5C55ABC4EEF3160EDDA69134DE4A1EF3FFCB769D7243BD5D774D33585B66924 That doesn't seem overly complex, certainly when compared to what an RSA key looks like, and we've dealt with those for a decade. -MSK --001a114af28abb826e0568706849 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 27, 2018 at 11:16 PM, Scott Kitterman <skl= ist@kitterman.com> wrote:
It&= #39;s sufficiently defined by=C2=A0 RFC 8032 and Base64.=C2=A0 I don't = think there's a standardized ASN.1 structure for this.=C2=A0 I think AS= N.1 is needless complexity.

But DKIM applications are already used to that complexity, or they use A= PIs to make it invisible to them.

The entire ASN.1 output= from OpenSSL for an Ed25519 public key, expanded:

=C2=A0=C2=A0=C2= =A0 0:d=3D0=C2=A0 hl=3D2 l=3D=C2=A0 46 cons: SEQUENCE
=C2=A0=C2=A0=C2=A0= 2:d=3D1=C2=A0 hl=3D2 l=3D=C2=A0=C2=A0 1 prim: INTEGER=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 :00
=C2=A0=C2=A0=C2=A0 5:d=3D1= =C2=A0 hl=3D2 l=3D=C2=A0=C2=A0 5 cons: SEQUENCE
=C2=A0=C2=A0=C2=A0 7:d= =3D2=C2=A0 hl=3D2 l=3D=C2=A0=C2=A0 3 prim: OBJECT=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 :ED25519
=C2=A0=C2=A0 12:d=3D= 1=C2=A0 hl=3D2 l=3D=C2=A0 34 prim: OCTET STRING=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 [HEX DUMP]:0420A5C55ABC4EEF3160EDDA69134DE4A1EF3FFCB769D7243BD5D774D335= 85B66924

That doesn't seem overly complex, certainly = when compared to what an RSA key looks like, and we've dealt with those= for a decade.

-MSK
--001a114af28abb826e0568706849-- From nobody Tue Mar 27 21:10: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 1C286126CD6 for ; Tue, 27 Mar 2018 21:09:59 -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, 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=kO/l/8UM; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=cNHjRCyc 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 DS7gRO1sD-gb for ; Tue, 27 Mar 2018 21:09:57 -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 93504124217 for ; Tue, 27 Mar 2018 21:09:57 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1522210196; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=ViNehJNt65VgpwKtew9RTYadigBDViBlzDSlWQB3GMc=; b=kO/l/8UMpTZLy7+lhr10KgP8Lb6r3tz3VPZZiBc9RRncRkdPDH0v/vxN S7KYEZdAJaGxIlJ2lu2kBZMCBWfBCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1522210196; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=ViNehJNt65VgpwKtew9RTYadigBDViBlzDSlWQB3GMc=; b=cNHjRCyc3GkgelpnUoC8G888KEckrd8CsBvvbB6zQKJTJieZwR4GAODv vi6qlOXTYwOGHHoCmiW5vw/qnkH6yTgS1Bkqn0X0ISL8l08F0iyw8E5R10 QDEC+fYrGEBv+tk6fiiezpXZcXKmHJYtqurZNwcyfWPl4tdzrH/1/Kw3mb hCeAbsYZj/sPP8N59BaoMKp8x2b+Ts6JfMg7sW7MKOPoRoqzyH+JbARKir 53CF9tx4EPRff5bb5zmokspb3PwJCm8f4+MBUxWRcDY3caajroMkH6WmqY tCmYFAaSiiCe6Md0z41FrauHQIotI5XvtoNaazii8mVpFc/dHqsT7g== 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 015A2C40259; Tue, 27 Mar 2018 23:09:55 -0500 (CDT) Date: Wed, 28 Mar 2018 04:09:52 +0000 In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <51f0090d-ab16-54f4-9ff0-3a043e0d831a@dcrocker.net> <1707459.QODvfERKoP@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <2FFD1884-56A2-42CD-B21D-A70AB0905C68@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, 28 Mar 2018 04:09:59 -0000 On March 28, 2018 3:14:35 AM UTC, "Murray S=2E Kucherawy" wrote: >On Tue, Mar 27, 2018 at 11:16 PM, Scott Kitterman > >wrote: > >> It's sufficiently defined by RFC 8032 and Base64=2E I don't think >there's >> a standardized ASN=2E1 structure for this=2E I think ASN=2E1 is needle= ss >> complexity=2E >> > >But DKIM applications are already used to that complexity, or they use >APIs >to make it invisible to them=2E > >The entire ASN=2E1 output from OpenSSL for an Ed25519 public key, >expanded: > > 0:d=3D0 hl=3D2 l=3D 46 cons: SEQUENCE > 2:d=3D1 hl=3D2 l=3D 1 prim: INTEGER :00 > 5:d=3D1 hl=3D2 l=3D 5 cons: SEQUENCE > 7:d=3D2 hl=3D2 l=3D 3 prim: OBJECT :ED25519 > 12:d=3D1 hl=3D2 l=3D 34 prim: OCTET STRING [HEX >DUMP]:0420A5C55ABC4EEF3160EDDA69134DE4A1EF3FFCB769D7243BD5D774D33585B6692= 4 > >That doesn't seem overly complex, certainly when compared to what an >RSA >key looks like, and we've dealt with those for a decade=2E True and I could certainly deal with it, but why? It's simpler than RSA, = but more complex than RFC 8032 pubkey -> base64, which is what we have now= =2E Everything except the HEX DUMP OCTET STRING in the above is overhead w= e don't need=2E Where is this ASN=2E1 structure standardized? As far as I can tell, it's = an openssl implementation detail=2E Why do the harder, non-standard thing? Let's not fetishize ASN=2E1 because we've been stuck with it for so long= =2E I don't think "we've long dealt with the extra complexity when we had = to, so let's keep doing it when we don't" is a great argument=2E =20 RSA keys have enough structure that, particularly for the private key, I c= an see ASN=2E1 making sense=2E None of that applies to ed25519=2E Scott K From nobody Tue Mar 27 22: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 D0E601205D3 for ; Tue, 27 Mar 2018 22:13:08 -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 tbety7qI679r for ; Tue, 27 Mar 2018 22:13:07 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E0E126CD6 for ; Tue, 27 Mar 2018 22:13:06 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id e5-v6so1594571lfb.7 for ; Tue, 27 Mar 2018 22:13: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=izNXZ26M7YZuAYJWjVVSYF7aSVl6uP6LWPCD5PUzD+A=; b=LSPZK5SQSxF/Tllp9PzXGWcC2zZIArwkChwk5PRY8pOpvumdHahDP4dmqeB7qjlh5/ VUFhHU60fpz8SXIz+lutyMuvfLdyyaxH0Jgjjm2bej8wnfAMj0pj52Zhaq15i153oVq+ lQrZ8YOmWgFpr9AnJWcXVpfrOnrI6OYGstwxv9MHF1MdzJjnIsjf8djxHKJbigIYxmzn AocLwULJhjbUs0aGNMDvuWBN8e4pudXStKBm9yQ/En/HEPHeoK+AJ3buK+f8FgEcLjZH CVqL0yysKwIzRC6WRViyR+ahFIQq+f9Oc8UUJlK7i9sEHAdKHQjSzjKQz6ICdZ1jHxk0 mCpQ== 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=izNXZ26M7YZuAYJWjVVSYF7aSVl6uP6LWPCD5PUzD+A=; b=kVceqjjY/GEmL8K2xvNm18sjOM9bwVXgnf16VXowRRtC7XVCC6ForYzIfHRq1uZpup /FjHcuk8/tABH5j98jtj85XtZGms9gFCFS0ZBM0RskesTTvAEpObP3rrEsPImVB32b1G CpPsMTFo7Dtxrr5YPsk0dMEsnDWVPoISUAhRSRhlEXtFgA0I9W33NGKXwlEHlzm+9v2/ UXp5iD11+eItukBsxtR4sjbOKgvE6drar2uR7WtIZWqBkVj0N/Az+zniq5Ti9qus9ZIx kWW2l8uc+GvquoRM/w4+0rIe4x0LQ4nxhzxBio8WlF9rHZNIHYFvcmJAMg/h46rvFe36 gFqQ== X-Gm-Message-State: AElRT7HF8rx2i+TkHUp8updeUqQ1+mOtR1G6DjNtAgFHgB6z9eFW+VRh o4sC7zYolfHtYC8NFZ/k0v/mkkf/eaP/+aJwY4f1ugiF X-Google-Smtp-Source: AIpwx4/TwyUC8CD1lF13Lo5rf6gpVSJFs5Os3qLNbxXGvKCgFE2eaMeM94ErQwNTUnfWUTv10ySIIBqe7CiHJAtfu/s= X-Received: by 10.46.65.73 with SMTP id o70mr1377148lja.140.1522213984865; Tue, 27 Mar 2018 22:13:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.115.7 with HTTP; Tue, 27 Mar 2018 22:13:03 -0700 (PDT) In-Reply-To: <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.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> From: "Murray S. Kucherawy" Date: Wed, 28 Mar 2018 05:13:03 +0000 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c05bfd2d7121f0568720fb1" 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, 28 Mar 2018 05:13:09 -0000 --94eb2c05bfd2d7121f0568720fb1 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 28, 2018 at 4:09 AM, Scott Kitterman wrote: > True and I could certainly deal with it, but why? As I said earlier, because it's the de facto standard way of representing crypto objects in general, and it mirrors the way DKIM already does things. > It's simpler than RSA, but more complex than RFC 8032 pubkey -> base64, > which is what we have now. Everything except the HEX DUMP OCTET STRING in > the above is overhead we don't need. > It's 12 bytes you just ignore. > Where is this ASN.1 structure standardized? As far as I can tell, it's an > openssl implementation detail. Why do the harder, non-standard thing? > Looks like it's in draft-ietf-curdle-pkix, I think, which is on the standards track, while RFC8032 is informational. Let's not fetishize ASN.1 because we've been stuck with it for so long. I > don't think "we've long dealt with the extra complexity when we had to, so > let's keep doing it when we don't" is a great argument. > > RSA keys have enough structure that, particularly for the private key, I > can see ASN.1 making sense. None of that applies to ed25519. > I have no particular love for ASN.1, but I'm swayed by the fact that "public keys in DKIM are in ASN.1 encoded in PEM" is a lot easier to explain to someone than "public keys in DKIM are in ASN.1 encoded in PEM for key type A, or a little-endian 32-byte integer encoded in base64 for key type B, or ... or ... or ...", and the cost of the former is, well, 12 bytes. -MSK --94eb2c05bfd2d7121f0568720fb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28, 2018 at 4:09 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
True= and I could certainly deal with it, but why?

As I said earlier, because it's the de facto standard way of represe= nting crypto objects in general, and it mirrors the way DKIM already does t= hings.
=C2=A0
It's simpler than RSA, but more complex than RFC 8032 pubkey -> bas= e64, which is what we have now.=C2=A0 Everything except the HEX DUMP OCTET = STRING in the above is overhead we don't need.
It's 12 bytes you just ignore.
=C2=A0
Where is this ASN.1 structure standardized?=C2=A0 As far as I can tell, it&= #39;s an openssl implementation detail.=C2=A0 Why do the harder, non-standa= rd thing?

Looks like it's in draft-= ietf-curdle-pkix, I think, which is on the standards track, while RFC8032 i= s informational.

Let's not fetishize ASN.1 because we've been stuck with it for so l= ong.=C2=A0 I don't think "we've long dealt with the extra comp= lexity when we had to, so let's keep doing it when we don't" i= s a great argument.

RSA keys have enough structure that, particularly for the private key, I ca= n see ASN.1 making sense.=C2=A0 None of that applies to ed25519.

I have no particular love for ASN.1, but I'm = swayed by the fact that "public keys in DKIM are in ASN.1 encoded in P= EM" is a lot easier to explain to someone than "public keys in DK= IM are in ASN.1 encoded in PEM for key type A, or a little-endian 32-byte i= nteger encoded in base64 for key type B, or ... or ... or ...", and th= e cost of the former is, well, 12 bytes.

-MSK
--94eb2c05bfd2d7121f0568720fb1-- From nobody Tue Mar 27 23:00: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 BFD561241F3 for ; Tue, 27 Mar 2018 23:00: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 IBVONsbhpkuI for ; Tue, 27 Mar 2018 23:00:03 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394C7120727 for ; Tue, 27 Mar 2018 23:00:03 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id v2so1270549qkh.10 for ; Tue, 27 Mar 2018 23:00:03 -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=SA7eYhm6sYutQ1AUVTTz2G+AwD6YoqXsRMUmoCLAwSc=; b=CFjCKKIwf50+QfeLk+PigBlmgGrGci+c3ilsAqrH6QtjnVJaedor1IxIEfTZEkVPRF I+3SxffFmL+9WmuT3AoiA3SZE9uY9G+EasJHYTUFSOuYMoBnMDAhh0x4y2pVBvVUsZd6 QFrWNqOe8Sb3U68iKysJu3KrfiDKSTFBz6O1S1HAxEIw+d9xc0tlsP+UAGSTlcwmiwou oMdq6hd/euEoP3zBS90BoXJM0CCa1JtscOX5p7NF9B33StTCUX3mhSBzKk+jyc1vDUJ9 T27w55TE94LCorzSfGxYVkYyitse5BDBlp7pFl3dZDKBJILSq/UtOF1AQ7OBjkIuVZhh gjrw== 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=SA7eYhm6sYutQ1AUVTTz2G+AwD6YoqXsRMUmoCLAwSc=; b=MWCLDXubnTraoxKxFldvVgi7KESVlnVgqTxYWVgTcTNDrYytKvhxEgQmR1F6j5G+4+ JvM42sq8kYuN8cxRf5E6DLI7dw8H9KkWtRbo77J14hoEpqOnZpa7CQM7e1kPiTh/epj5 gBYDExdNv4Neqzd2mU2FNNy+7ZHtlC2wBKLJ6RUf0rirtU8dEshmltFwKs8nuBP/PP80 d/xXyeK0L1id2TlYXyur1s/sLf143pDOtxl4yb24GUVsYjpTQVWwgM5794JETP58KlIA HlyxfPOyoblssu7c9HA4e40GDnawp+gRFAp5CPo3+V+/cVrH/pLu2LVOe72DPFgfiIqc i5ig== X-Gm-Message-State: ALQs6tBA5rKPuBTEDeuRsmwj/LTGyJHD3Grfcr7Tj8wjxttJhwBMAUFg 6xl2EoWCMJnPj0iOi+XbNXn5/0FPx4TzkhVtOHo= X-Google-Smtp-Source: AIpwx48jRIk634wASlGwkJLTBrveCqoIiemvho4XKWNKlLQkcmWHK4Gnp6m+pq+I/AfH/spExirr/7aGmXjS21SxvGk= X-Received: by 10.55.79.81 with SMTP id d78mr3200019qkb.20.1522216802246; Tue, 27 Mar 2018 23:00:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Tue, 27 Mar 2018 23:00:01 -0700 (PDT) In-Reply-To: <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.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> From: denis bider Date: Wed, 28 Mar 2018 01:00:01 -0500 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114a758ec4e31a056872b74b" 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, 28 Mar 2018 06:00:10 -0000 --001a114a758ec4e31a056872b74b Content-Type: text/plain; charset="UTF-8" I agree with Scott here 100%. ASN.1 is crud. Even in situations where some kind of metadata is needed, ASN.1 is a premature space optimization at cost of practicability (complexity of ASN.1 handling) and security (ASN.1 parsing flaws). Even where metadata is needed, if it's possible to get rid of ASN.1, it should be gotten rid of. Here no metadata is needed at all. 32-byte Ed25519 keys are well specified. That's their preferred format. Adding ASN.1 would be total crud. denis On Tue, Mar 27, 2018 at 11:09 PM, Scott Kitterman wrote: > > > On March 28, 2018 3:14:35 AM UTC, "Murray S. Kucherawy" < > superuser@gmail.com> wrote: > >On Tue, Mar 27, 2018 at 11:16 PM, Scott Kitterman > > > >wrote: > > > >> It's sufficiently defined by RFC 8032 and Base64. I don't think > >there's > >> a standardized ASN.1 structure for this. I think ASN.1 is needless > >> complexity. > >> > > > >But DKIM applications are already used to that complexity, or they use > >APIs > >to make it invisible to them. > > > >The entire ASN.1 output from OpenSSL for an Ed25519 public key, > >expanded: > > > > 0:d=0 hl=2 l= 46 cons: SEQUENCE > > 2:d=1 hl=2 l= 1 prim: INTEGER :00 > > 5:d=1 hl=2 l= 5 cons: SEQUENCE > > 7:d=2 hl=2 l= 3 prim: OBJECT :ED25519 > > 12:d=1 hl=2 l= 34 prim: OCTET STRING [HEX > >DUMP]:0420A5C55ABC4EEF3160EDDA69134DE4A1EF3FFCB769D7243BD5D774D335 > 85B66924 > > > >That doesn't seem overly complex, certainly when compared to what an > >RSA > >key looks like, and we've dealt with those for a decade. > > True and I could certainly deal with it, but why? It's simpler than RSA, > but more complex than RFC 8032 pubkey -> base64, which is what we have > now. Everything except the HEX DUMP OCTET STRING in the above is overhead > we don't need. > > Where is this ASN.1 structure standardized? As far as I can tell, it's an > openssl implementation detail. Why do the harder, non-standard thing? > > Let's not fetishize ASN.1 because we've been stuck with it for so long. I > don't think "we've long dealt with the extra complexity when we had to, so > let's keep doing it when we don't" is a great argument. > > RSA keys have enough structure that, particularly for the private key, I > can see ASN.1 making sense. None of that applies to ed25519. > > Scott K > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a114a758ec4e31a056872b74b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Scott here 100%.

ASN.1 is = crud. Even in situations where some kind of metadata is needed, ASN.1 is a = premature space optimization at cost of practicability (complexity of ASN.1= handling) and security (ASN.1 parsing flaws). Even where metadata is neede= d, if it's possible to get rid of ASN.1, it should be gotten rid of.

Here no metadata is needed at all. 32-byte Ed25519 k= eys are well specified. That's their preferred format. Adding ASN.1 wou= ld be total crud.

denis

=

On Tue, Mar 27, 2= 018 at 11:09 PM, Scott Kitterman <sklist@kitterman.com> w= rote:


On March 28, 2018 3:14:35 AM UTC, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
>On Tue, Mar 27, 2018 at 11:16 PM, Scott Kitterman
><sklist@kitterman.com>= ;
>wrote:
>
>> It's sufficiently defined by=C2=A0 RFC 8032 and Base64.=C2=A0 = I don't think
>there's
>> a standardized ASN.1 structure for this.=C2=A0 I think ASN.1 is ne= edless
>> complexity.
>>
>
>But DKIM applications are already used to that complexity, or they use<= br> >APIs
>to make it invisible to them.
>
>The entire ASN.1 output from OpenSSL for an Ed25519 public key,
>expanded:
>
>=C2=A0 =C2=A0 0:d=3D0=C2=A0 hl=3D2 l=3D=C2=A0 46 cons: SEQUENCE
>=C2=A0 =C2=A0 2:d=3D1=C2=A0 hl=3D2 l=3D=C2=A0 =C2=A01 prim: INTEGER=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:00
>=C2=A0 =C2=A0 5:d=3D1=C2=A0 hl=3D2 l=3D=C2=A0 =C2=A05 cons: SEQUENCE >=C2=A0 =C2=A0 7:d=3D2=C2=A0 hl=3D2 l=3D=C2=A0 =C2=A03 prim: OBJECT=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :ED25519
>=C2=A0 =C2=A012:d=3D1=C2=A0 hl=3D2 l=3D=C2=A0 34 prim: OCTET STRING=C2= =A0 =C2=A0 =C2=A0 [HEX
>DUMP]:0420A5C55ABC4EEF3160EDDA69134DE4A1EF3FFCB769D7243BD5D77= 4D33585B66924
>
>That doesn't seem overly complex, certainly when compared to what a= n
>RSA
>key looks like, and we've dealt with those for a decade.

True and I could certainly deal with it, but why?=C2=A0 It's sim= pler than RSA, but more complex than RFC 8032 pubkey -> base64, which is= what we have now.=C2=A0 Everything except the HEX DUMP OCTET STRING in the= above is overhead we don't need.

Where is this ASN.1 structure standardized?=C2=A0 As far as I can tell, it&= #39;s an openssl implementation detail.=C2=A0 Why do the harder, non-standa= rd thing?

Let's not fetishize ASN.1 because we've been stuck with it for so l= ong.=C2=A0 I don't think "we've long dealt with the extra comp= lexity when we had to, so let's keep doing it when we don't" i= s a great argument.

RSA keys have enough structure that, particularly for the private key, I ca= n see ASN.1 making sense.=C2=A0 None of that applies to ed25519.

Scott K

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

--001a114a758ec4e31a056872b74b-- From nobody Tue Mar 27 23:05:46 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 EF8DC1241F3 for ; Tue, 27 Mar 2018 23:05:44 -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, 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=mWQhuIAW; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=WFVjJgLM 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 hClye4510LFm for ; Tue, 27 Mar 2018 23:05:43 -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 6B0C5120727 for ; Tue, 27 Mar 2018 23:05:43 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1522217140; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=p+dn/dAcRc8ynC/tl7MaXdXEb8tS1OMSPJSkL98YEqg=; b=mWQhuIAW03dvbPmZV2KqtKS2jtP6OT+hOY/P8RGqSscj2lJiUoAMpjVM 897KcZv1zuyzw2kCETliWLBNZWyTDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1522217140; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=p+dn/dAcRc8ynC/tl7MaXdXEb8tS1OMSPJSkL98YEqg=; b=WFVjJgLMsG4TlQTR0DkicPET7n28qHq/utxLODSKolqtALL77jwHzgRI eTKmI/h+7PQyoRQubipOpEv+9iWagBqcXcgF3aR3Y/zOUOVl7ZaCAgBxrs nM9mdwG4szKR/VRLIJqDQm+nRbp1wNBreatnSmD5VXCOH4MSpHNKqa6OMB JGfAqExDk3WwPQ/pp1FpNIz6K6CxmkFBXZKndZspyRV6kmbuECtH6iRGcE lklqc8L1beoe+d2JgFXiaNowXjThehnTJR7qkKyqsqtcobZaz+K/DeyVgF QwZ4vUOAFc1Amwu0OwCrTZxMpsAGB+gsgq/+2Bc88DUqNx5eZwWfUQ== 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 00E4FC401A6; Wed, 28 Mar 2018 01:05:39 -0500 (CDT) Date: Wed, 28 Mar 2018 06:05:33 +0000 In-Reply-To: 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> 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] 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, 28 Mar 2018 06:05:45 -0000 On March 28, 2018 5:13:03 AM UTC, "Murray S=2E Kucherawy" wrote: >On Wed, Mar 28, 2018 at 4:09 AM, Scott Kitterman >wrote: > >> True and I could certainly deal with it, but why? > > >As I said earlier, because it's the de facto standard way of >representing >crypto objects in general, and it mirrors the way DKIM already does >things=2E > > >> It's simpler than RSA, but more complex than RFC 8032 pubkey -> >base64, >> which is what we have now=2E Everything except the HEX DUMP OCTET >STRING in >> the above is overhead we don't need=2E >> > >It's 12 bytes you just ignore=2E > > >> Where is this ASN=2E1 structure standardized? As far as I can tell, >it's an >> openssl implementation detail=2E Why do the harder, non-standard >thing? >> > >Looks like it's in draft-ietf-curdle-pkix, I think, which is on the >standards track, while RFC8032 is informational=2E > >Let's not fetishize ASN=2E1 because we've been stuck with it for so long= =2E > I >> don't think "we've long dealt with the extra complexity when we had >to, so >> let's keep doing it when we don't" is a great argument=2E >> >> RSA keys have enough structure that, particularly for the private >key, I >> can see ASN=2E1 making sense=2E None of that applies to ed25519=2E >> > >I have no particular love for ASN=2E1, but I'm swayed by the fact that >"public keys in DKIM are in ASN=2E1 encoded in PEM" is a lot easier to >explain to someone than "public keys in DKIM are in ASN=2E1 encoded in >PEM >for key type A, or a little-endian 32-byte integer encoded in base64 >for >key type B, or =2E=2E=2E or =2E=2E=2E or =2E=2E=2E", and the cost of the = former is, well, >12 >bytes=2E This isn't x=2E509, so I still think it's overkill, but at least it's writ= ten down somewhere=2E Each new algorithm will come with it's own format, e= ven if it's a different ASN=2E1 variant, so I still don't see the fact that= RSA uses ASN=2E1 as relevant=2E I still don't see value in the added comp= lexity=2E Let's see what others think=2E Scott K From nobody Wed Mar 28 00:46: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 B33D012025C for ; Wed, 28 Mar 2018 00:46:48 -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=wwS1H4jk; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=hq9t+wnu 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 v0SwFMniRDHw for ; Wed, 28 Mar 2018 00:46:46 -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 100BF1200C1 for ; Wed, 28 Mar 2018 00:46:45 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=andreasschulze.de; i=@andreasschulze.de; q=dns/txt; s=ed25519; t=1522223202; h=date : message-id : from : to : subject : references : in-reply-to : content-type : mime-version : date : from : subject; bh=V8Lofr+1a2T4Dk2eDP1xVcz3ietY6REL9S5qZaQ655Y=; b=wwS1H4jksei/fhwHrAGppFXuFz9X4zuQ42OJMdXKtpjaJ1n8XbR0O9Ed f3PQmoymtzlKEw7c5WZRw6l2cG6VAw== Date: Wed, 28 Mar 2018 09:46:36 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=ybz; t=1522223200; x=1527223200; bh=V8Lofr+1a2T4Dk2eDP1xVcz3ietY6REL9S5qZaQ655Y=; h=Date:Message-ID:From:To:Subject:References:In-Reply-To: Content-Type:from:reply-to:subject:date:to:cc:content-type: message-id; b=hq9t+wnuPMLTgwb5mAU0HUvTDIm2T85sxbTD2+I9c30BdIHrqdnEXwUZ9+1NS/aA8 1axZ8Y/cZqnrG6ReK3mb79ryc7DLPXDpzIRaxabcPsloGyVsPnViOsz5ERGx6aL9zt TvEi6hapVbrC+ho/nRugle4wynsCqPGHRcCUlgFzi9x5NCQcCzWNYv7+HyKwHcbTfo gATHAuilmwO+hHcH4EX9UpA+JbnJ7iWEP/Beos6OOFCvHeqQRSftwgqmm62kf6iUmQ uA5adN9LxRNNFoAI1So2mKLLSLdzOEU4spGfhhnTuC8e8UFiKmWVkryJ1DSQDhuOwm jy2NaZbpiMCbQ== Message-ID: <20180328094636.Horde.Np3GCcO8iEPwmQzOaaUjbrh@andreasschulze.de> From: "A. Schulze" To: dcrup@ietf.org 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> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline 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, 28 Mar 2018 07:46:49 -0000 Scott Kitterman: > Let's see what others think. I'm not as technical involved but speak more as user. As long as standard tools provide a convenient to handle keys I'm fine. What are the usual tasks? - create a new DKIM key -> opendkim-genkey -> openssl genrsa -out $keyfile $keysize -> dknewkey --ktype ... $keyname - extract the public part -> opendkim-genzone -> use the file generated by dknewkey or opendkim-genkey -> some cut&pasted openssl-voodoo The user don't (want to) care about ASN.1 is used or not. From this perspective it makes sense to avoid ASN.1 in new program code. Andreas From nobody Wed Mar 28 12:25: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 9B5AA1275AB for ; Wed, 28 Mar 2018 12:25:34 -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=ya5/NgIz; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=Rsjt1z9x 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 Dnt2GQI_INwy for ; Wed, 28 Mar 2018 12:25:32 -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 D020E126DC2 for ; Wed, 28 Mar 2018 12:25:32 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1522265131; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=3zRpJYXTIrtclRXp0ILvaUtxR0k0045OKApd5v/DI0U=; b=ya5/NgIzTeFXZPmOxBdHcDquAZL5xMrhmtFLbMoBqSOedKhkeG184nr/ hAtnUMGTJs+VTJvqYjKVnZ4lp2tNBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1522265131; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=3zRpJYXTIrtclRXp0ILvaUtxR0k0045OKApd5v/DI0U=; b=Rsjt1z9xJ0RhcQxWcCYBy4IBrLN3kRgEh2ssp4hNPcV97zKZ5nBWTqcX 4WWLSsDDeEvO6eydP2h5Y1LMMeT/50xH33EXGWIerOrKpRJ9x6Hynu8QPl gLh6J/vctXme8ffJ4144FWZed3LXQ4GQcaKwRNbrQsvaT4ALy3IZRiHfsn WgDbj12xEwFguEY4megIg/+Bqqdn8tDWGjLXO5FQFODcq7qHWbdnCuu2WI xnvG0kZaRbgnJxhwFm6cjPzsVjptmFspxU5Nm42mvZncuLCMctcomLy+e5 /Sa3bVPzaTfuEVYeiGLgkagbabTFRvZ5+/OcaCsXu8+/Nw3l97EmPQ== 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 CB162C401CA for ; Wed, 28 Mar 2018 14:25:31 -0500 (CDT) From: Scott Kitterman To: dcrup@ietf.org Date: Wed, 28 Mar 2018 15:25:30 -0400 Message-ID: <2700938.OFZebBfOPt@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-139-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.com> 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: Wed, 28 Mar 2018 19:25:35 -0000 Somewhat ironic in terms of timing, it's not like ASN.1 processing issues never happen (first issue): https://www.openssl.org/news/secadv/20180327.txt Scott K On Wednesday, March 28, 2018 01:00:01 AM denis bider wrote: > I agree with Scott here 100%. > > ASN.1 is crud. Even in situations where some kind of metadata is needed, > ASN.1 is a premature space optimization at cost of practicability > (complexity of ASN.1 handling) and security (ASN.1 parsing flaws). Even > where metadata is needed, if it's possible to get rid of ASN.1, it should > be gotten rid of. > > Here no metadata is needed at all. 32-byte Ed25519 keys are well specified. > That's their preferred format. Adding ASN.1 would be total crud. > > denis > > > On Tue, Mar 27, 2018 at 11:09 PM, Scott Kitterman > > wrote: > > On March 28, 2018 3:14:35 AM UTC, "Murray S. Kucherawy" < > > > > superuser@gmail.com> wrote: > > >On Tue, Mar 27, 2018 at 11:16 PM, Scott Kitterman > > > > > > > > >wrote: > > >> It's sufficiently defined by RFC 8032 and Base64. I don't think > > > > > >there's > > > > > >> a standardized ASN.1 structure for this. I think ASN.1 is needless > > >> complexity. > > > > > >But DKIM applications are already used to that complexity, or they use > > >APIs > > >to make it invisible to them. > > > > > >The entire ASN.1 output from OpenSSL for an Ed25519 public key, > > > > > >expanded: > > > 0:d=0 hl=2 l= 46 cons: SEQUENCE > > > 2:d=1 hl=2 l= 1 prim: INTEGER :00 > > > 5:d=1 hl=2 l= 5 cons: SEQUENCE > > > 7:d=2 hl=2 l= 3 prim: OBJECT :ED25519 > > > > > > 12:d=1 hl=2 l= 34 prim: OCTET STRING [HEX > > > > > >DUMP]:0420A5C55ABC4EEF3160EDDA69134DE4A1EF3FFCB769D7243BD5D774D335 > > > > 85B66924 > > > > >That doesn't seem overly complex, certainly when compared to what an > > >RSA > > >key looks like, and we've dealt with those for a decade. > > > > True and I could certainly deal with it, but why? It's simpler than RSA, > > but more complex than RFC 8032 pubkey -> base64, which is what we have > > now. Everything except the HEX DUMP OCTET STRING in the above is overhead > > we don't need. > > > > Where is this ASN.1 structure standardized? As far as I can tell, it's an > > openssl implementation detail. Why do the harder, non-standard thing? > > > > Let's not fetishize ASN.1 because we've been stuck with it for so long. I > > don't think "we've long dealt with the extra complexity when we had to, so > > let's keep doing it when we don't" is a great argument. > > > > RSA keys have enough structure that, particularly for the private key, I > > can see ASN.1 making sense. None of that applies to ed25519. > > > > Scott K > > > > _______________________________________________ > > Dcrup mailing list > > Dcrup@ietf.org > > https://www.ietf.org/mailman/listinfo/dcrup From nobody Thu Mar 29 00:21:52 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 7E8EB12D86E for ; Thu, 29 Mar 2018 00:21:51 -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 ypjQ08kz5mrj for ; Thu, 29 Mar 2018 00:21:49 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E897120727 for ; Thu, 29 Mar 2018 00:21:49 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id g203-v6so6965741lfg.11 for ; Thu, 29 Mar 2018 00:21:49 -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=4/gBe73xM8+aqTer0pN1fDGGjIkSHLcfizQd62NBAcA=; b=p//YQm14paL005bpusdwISyrDk6umvbLLH8tGoMQW5sDef2hVO+DvQMIa46t123dhG D8EnjBqXX6HitibmlT5EnWhBnNTt39uD9xpw1kDVshU657/BHsURcWcMXWS66ZClwpfx Xrj+0UED/h6CRbf4jCpjRDQl3ArGR0xCiPaGXD4AyluOFWJBCK7WZtM4h8TdmYgiticm qXATI4H5VfLo82JHQH5UvyeRtRxxhX7DSX3ueXynUqYsAZPcfCToP94vM3auC/4gS1md kMQc0WELlzhrR7aofyN7/1/6+18d20iQ+WmKHQI55W0hLxhoEl2Y5UntL32lNqWRhmg/ MTWw== 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=4/gBe73xM8+aqTer0pN1fDGGjIkSHLcfizQd62NBAcA=; b=NulhP7291pX8g3TW4jqgp3YBrpkU19PL27Psv+9myr92X8E18v9cLmHhyDTtEhEeuc Faqht5XC7pmrZ4uAylV0YyoXV7hRioS8ZihpEmJZsCaZOlF39Pz9Ewtoxw7myveqVNMf zmso8UxjbLfKuThT7pZ9+Vi3lRenNvELkqV55/o5Wjya3CkiDAhIio/tascUobFUGgbP CO4JuiOxye4+nfrUiTJB0Ku6BhyR+WhJNlSPih6aManHsLxaEkfjU+E6BK+FLJWDmKY0 Iiwy49hwLvUHMdlslOO+Oby49m/zE+fSbtH24sDj41rVqYB+hrhD2hWdg5SYdu2kaNl1 eWeQ== X-Gm-Message-State: AElRT7H2SO73xFsbHcKHqacRzX1B6XOmgfheebAU5jZBBJhk2ICBLgwA hKKcFdnOB5S/cUaKVXotNdl87chMh7Vkhkw2W0u2629L X-Google-Smtp-Source: AIpwx4/e4S1TRQEleMiaL2Hi8ZTdKIZMQNpgUDCk0R9wCwO3EkhMeMc6RI1BZqDmls2ZYdVvyxccVrYSGjdaYg45aCM= X-Received: by 10.46.91.143 with SMTP id m15mr4498391lje.75.1522308107751; Thu, 29 Mar 2018 00:21:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.115.7 with HTTP; Thu, 29 Mar 2018 00:21:47 -0700 (PDT) In-Reply-To: <20180328094636.Horde.Np3GCcO8iEPwmQzOaaUjbrh@andreasschulze.de> 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> From: "Murray S. Kucherawy" Date: Thu, 29 Mar 2018 00:21:47 -0700 Message-ID: To: "A. Schulze" Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1ab0bc0056fe056887fa7a" 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, 29 Mar 2018 07:21:51 -0000 --94eb2c1ab0bc0056fe056887fa7a Content-Type: text/plain; charset="UTF-8" On Wed, Mar 28, 2018 at 12:46 AM, A. Schulze wrote: > - create a new DKIM key > -> opendkim-genkey > opendkim-genkey does two things: 1) generate an RSA private key in PEM-formatted ASN.1; this is just an execution of "openssl genrsa" 2) read that key and extract its matching RSA public key in PEM-formatted ASN.1, and then just reformats it (without even decoding it) into a DNS TXT record - extract the public part > >> -> opendkim-genzone > This is used to turn an OpenDKIM-specific data set into a zone file. It doesn't do key generation. > The user don't (want to) care about ASN.1 is used or not. > Users don't see ASN.1 in any case. They see base64. >From this perspective it makes sense to avoid ASN.1 in new program code. > But old program code doesn't use ASN.1 either, so I don't understand what's changing at the user level. I'm talking about the protocol level here. -MSK --94eb2c1ab0bc0056fe056887fa7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28, 2018 at 12:46 AM, A. Schulze <sca@and= reasschulze.de> wrote:
=C2=A0- create a new DKIM= key
=C2=A0 =C2=A0-> opendkim-genkey

open= dkim-genkey does two things:

1) generate an RSA private key in PEM-f= ormatted ASN.1; this is just an execution of "openssl genrsa"
= 2) read that key and extract its matching RSA public key in PEM-formatted A= SN.1, and then just reformats it (without even decoding it) into a DNS TXT = record

=C2=A0- extract the public part
=C2=A0=C2=A0 -> opendkim-genzone

Thi= s is used to turn an OpenDKIM-specific data set into a zone file.=C2=A0 It = doesn't do key generation.
=C2=A0
The user don't (want to) care about ASN.1 is used or not.=

Users don't see ASN.1 in any case.= =C2=A0 They see base64.

>From this perspective it makes sense to avoid ASN.1 in new program code.

But old program code doesn't use ASN.= 1 either, so I don't understand what's changing at the user level.<= br>
I'm talking about the protocol level here.

-MSK
--94eb2c1ab0bc0056fe056887fa7a-- From nobody Thu Mar 29 01:43: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 D07131270A7 for ; Thu, 29 Mar 2018 01:42:59 -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 4uoF7fLx_y-v for ; Thu, 29 Mar 2018 01:42:58 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C958A124207 for ; Thu, 29 Mar 2018 01:42:57 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id v11so5461359qtj.6 for ; Thu, 29 Mar 2018 01:42:57 -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=DS76g+GbfS5XLt9k5BPVBs69TvZsBSqyKw8AwtHYfGc=; b=fptODqBe0cCRIPMqPhpnJw6GnG9x75EC6hPlmVq1hh2K3Qr7rLdKaEoCs/YfcLRa2H L6TnoUava3rUaG2k+1PQ/TJVqvSs0Le5NUU7tD2X4Ntj+FtF/pw0j4sa0jQnyEO2/8VJ kmW7wCHpWw+XXFtfHDVXdXU7LxSZTP89niBZY6sCVtI5FMIBOtEoOwUbtEb9PB21ByNU Vgzf8HT+sapHG5dq2vLKs164o/6gjzvS9OTYd0hsiflhyuiT0PSspc1bQ8tpOJrhPL+D o3WtTQUaiGbbypahaHoP9+8/y//BqFNXyva7AamZq/ouv08brUomgcWP75cNx8Tmcz9+ f56A== 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=DS76g+GbfS5XLt9k5BPVBs69TvZsBSqyKw8AwtHYfGc=; b=mgK2Hc0szPvbVeD5IIY1PaLVd3mmidJlHrcBpUgI0I1tN3WP0D1J+oZCHJCxVN95RU 7zmzzUWHEyYBSnpXi+4f89G6h2LUMfV+/HDdqtoVl3wcP0ROLo+/ykTxbyl7Eif8RI2k DuMtddSagPitg8lUoFqbaSXApoblh+QbJiWmQJZ0MwekxQhYSzE8cFsGnchdOhKRXVFw 2ezlGhGRyTKGKOcBtSduoY+daRpGjeVp1sWCV1GwFrbplIw7lrcVwPV4Yj07nvHbhHg6 HeBBLpcPi67tAFizyumSI8AlVBn7gTzWvDe/8QE/Q+J3umGcZN48UCLjmLSTtUSOSrV7 bmeQ== X-Gm-Message-State: ALQs6tD1N33SuKPo6FC1RSEWaphlHACm1LkxwJhee2qs7a62u4WThl+i 6XFYwVl9p9VaPZay+qGDPTZ/f/A4g4MJlikMFGs= X-Google-Smtp-Source: AIpwx4/0SnB3HuIfNESk9xrUJL+u0Twk+n7Qeg3nfOJYk2+z2bc47JUAuBdnoOHujxf8e/6YicCTYCHkzfaOf44QEps= X-Received: by 10.200.38.123 with SMTP id v56mr10248620qtv.106.1522312977020; Thu, 29 Mar 2018 01:42:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Thu, 29 Mar 2018 01:42:56 -0700 (PDT) In-Reply-To: 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> From: denis bider Date: Thu, 29 Mar 2018 03:42:56 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: "A. Schulze" , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11407ed63b79dc0568891cde" 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, 29 Mar 2018 08:43:00 -0000 --001a11407ed63b79dc0568891cde Content-Type: text/plain; charset="UTF-8" Hello Murray, instead of arguing about the lack of harm in including crud that is not necessary in this case, could you perhaps explain the COMPELLING NEED to include crud that is not necessary in this case? Your suggestion violates the principle of parsimonious design. This is that nothing unnecessary should be included. Can you form an argument about why this crud is NECESSARY, rather than expressing a preference for baroque decorations? denis On Thu, Mar 29, 2018 at 2:21 AM, Murray S. Kucherawy wrote: > On Wed, Mar 28, 2018 at 12:46 AM, A. Schulze > wrote: > >> - create a new DKIM key >> -> opendkim-genkey >> > > opendkim-genkey does two things: > > 1) generate an RSA private key in PEM-formatted ASN.1; this is just an > execution of "openssl genrsa" > 2) read that key and extract its matching RSA public key in PEM-formatted > ASN.1, and then just reformats it (without even decoding it) into a DNS TXT > record > > - extract the public part >> >>> -> opendkim-genzone >> > > This is used to turn an OpenDKIM-specific data set into a zone file. It > doesn't do key generation. > > >> The user don't (want to) care about ASN.1 is used or not. >> > > Users don't see ASN.1 in any case. They see base64. > > >From this perspective it makes sense to avoid ASN.1 in new program code. >> > > But old program code doesn't use ASN.1 either, so I don't understand > what's changing at the user level. > > I'm talking about the protocol level here. > > -MSK > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > --001a11407ed63b79dc0568891cde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Murray,

instead of arguing about = the lack of harm in including crud that is not necessary in this case, coul= d you perhaps explain the COMPELLING NEED to include crud that is not neces= sary in this case?

Your suggestion violates the pr= inciple of parsimonious design. This is that nothing unnecessary should be = included. Can you form an argument about why this crud is NECESSARY, rather= than expressing a preference for baroque decorations?

=
denis=C2=A0=C2=A0



On Thu, Mar 29, 2018 at 2:2= 1 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
=
On Wed, Ma= r 28, 2018 at 12:46 AM, A. Schulze <sca@andreasschulze.de> wrote:
<= span class=3D"">
=C2=A0- create a new DKIM= key
=C2=A0 =C2=A0-> opendkim-genkey

opendkim-genkey does two things:

1) generate an RSA private key i= n PEM-formatted ASN.1; this is just an execution of "openssl genrsa&qu= ot;
2) read that key and extract its matching RSA public key in PEM-form= atted ASN.1, and then just reformats it (without even decoding it) into a D= NS TXT record

=C2=A0- extract the public part
=C2=A0=C2=A0 -> opendkim-genzone

<= div>This is used to turn an OpenDKIM-specific data set into a zone file.=C2= =A0 It doesn't do key generation.
=C2=A0=
The user don't (want to) care abou= t ASN.1 is used or not.

Users do= n't see ASN.1 in any case.=C2=A0 They see base64.

>From this perspective it makes sense to avoid ASN.1 in new program code= .

But old program code doesn'= ;t use ASN.1 either, so I don't understand what's changing at the u= ser level.

I'm talking about the protocol level here.=

=
-MSK
<= /span>

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


--001a11407ed63b79dc0568891cde-- From nobody Thu Mar 29 03:43:49 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 90284126B7E for ; Thu, 29 Mar 2018 03:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonnection.nl 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 RqflO-6Pur-f for ; Thu, 29 Mar 2018 03:43:45 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC1112D883 for ; Thu, 29 Mar 2018 03:43:43 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 40BhDt0x7jz1L8k2; Thu, 29 Mar 2018 12:43:42 +0200 (CEST) Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx14.mailtransaction.com (Postfix) with ESMTP id 40BhDs6mD6z5Mh6R; Thu, 29 Mar 2018 12:43:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id C66394222CA; Thu, 29 Mar 2018 12:43:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fC8Dxkf3qAAz; Thu, 29 Mar 2018 12:43:41 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [192.168.30.2]) by tiger.sonnection.nl (Postfix) with ESMTP id A68874222C9; Thu, 29 Mar 2018 12:43:41 +0200 (CEST) Date: Thu, 29 Mar 2018 12:43:41 +0200 (CEST) From: "Rolf E. Sonneveld" To: denis bider Cc: "Murray S. Kucherawy" , dcrup@ietf.org, "A. Schulze" Message-ID: <1352163925.1049534.1522320221417.JavaMail.zimbra@sonnection.nl> In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.com> <20180328094636.Horde.Np3GCcO8iEPwmQzOaaUjbrh@andreasschulze.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1049533_1556839323.1522320221417" X-Originating-IP: [192.168.20.2] X-Mailer: Zimbra 8.6.0_GA_1182 (ZimbraWebClient - FF59 (Linux)/8.6.0_GA_1182) Thread-Topic: ed25519 in DNS Thread-Index: 2ipCmqsnx9YebH+HtKRIGlxiAWtcrw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1522320222; bh=klCjGiANRJ+z3v8TXHMvPIPTdM6hudA2EfMO4aAf2WI=; h=Date:From:To:Message-ID:Subject:From; b=QeQCx8csJ5Oh1Lpi+SPgy6CJE5j591gqCoSKRCJ+lDBtnhXCTJgA5149FJl82vcno coFfocWoyzPjsJROXw4WzNHE7ftHU2SCkWG7vlLr0KbAgnBfyWFPhlzeWu8lfGqStS SISXssTPLoIyanCUE22GEnGe4VXU7KWNxna3wNoQ= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 40BhDt0x7jz1L8k2 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, 29 Mar 2018 10:43:47 -0000 ------=_Part_1049533_1556839323.1522320221417 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, > instead of arguing about the lack of harm in including crud that is not > necessary in this case, could you perhaps explain the COMPELLING NEED to > include crud that is not necessary in this case? > Your suggestion violates the principle of parsimonious design. This is that > nothing unnecessary should be included. If we were to design a new protocol this principle certainly applies. However, while the 'D' in DCRUP is about DKIM, we need to take the existing standards, practices and installed base into account as well. That means there are other principles that apply as well. > Can you form an argument about why this crud is NECESSARY, rather than > expressing a preference for baroque decorations? I don't think this is a fair characterization of Murrays contribution to the discussion. [...] > On Thu, Mar 29, 2018 at 2:21 AM, Murray S. Kucherawy < superuser@gmail.com > > wrote: >> On Wed, Mar 28, 2018 at 12:46 AM, A. Schulze < sca@andreasschulze.de > wrote: >>> - create a new DKIM key >>> -> opendkim-genkey >> opendkim-genkey does two things: >> 1) generate an RSA private key in PEM-formatted ASN.1; this is just an execution >> of "openssl genrsa" >> 2) read that key and extract its matching RSA public key in PEM-formatted ASN.1, >> and then just reformats it (without even decoding it) into a DNS TXT record >>> - extract the public part >>> -> opendkim-genzone >> This is used to turn an OpenDKIM-specific data set into a zone file. It doesn't >> do key generation. >>> The user don't (want to) care about ASN.1 is used or not. >> Users don't see ASN.1 in any case. They see base64. >>> >From this perspective it makes sense to avoid ASN.1 in new program code.. >> But old program code doesn't use ASN.1 either, so I don't understand what's >> changing at the user level. >> I'm talking about the protocol level here. Can the DCRUP charter help us? Changes will be limited to existing implemented algorithms and key forms. Other changes to DKIM, such as new message canonicalization schemes, are out of scope. The WG will as far as possible avoid changes incompatible with deployed DKIM signers and verifiers. Especially the last sentence... /rolf ------=_Part_1049533_1556839323.1522320221417 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,
instead of arguing about the lack of harm in including crud t= hat is not necessary in this case, could you perhaps explain the COMPELLING= NEED to include crud that is not necessary in this case?

You= r suggestion violates the principle of parsimonious design. This is that no= thing unnecessary should be included.

If we were to design a new protocol this principle certainly applie= s. However, while the 'D' in DCRUP is about DKIM, we need to take the exist= ing standards, practices and installed base into account as well. That mean= s there are other principles that apply as well.

<= div dir=3D"ltr">
Can you form an argument about why this crud is NECESS= ARY, rather than expressing a preference for baroque decorations?

I don't think this is a fair characteriz= ation of Murrays contribution to the discussion.

[...]
=

On Thu, Mar 29, 2018 at 2:2= 1 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
=
On Wed, Ma= r 28, 2018 at 12:46 AM, A. Schulze <sca@andreasschulze.de> wrote:
<= span class=3D"">
 - create a new DKIM= key
   -> opendkim-genkey

opendkim= -genkey does two things:

1) generate an RSA private key in PEM-forma= tted ASN.1; this is just an execution of "openssl genrsa"
2) read that k= ey and extract its matching RSA public key in PEM-formatted ASN.1, and then= just reformats it (without even decoding it) into a DNS TXT record

=
 - extract = the public part
   -> opendkim-genzone

This is= used to turn an OpenDKIM-specific data set into a zone file.  It does= n't do key generation.
The user don't (want to) care about ASN.1 is used or not.

Users don't see ASN.1 in any case.  They see base6= 4.

>From this perspective it makes sense to avoid ASN.1 in new program code= ..

But old program code doesn't use ASN.1 e= ither, so I don't understand what's changing at the user level.

I'm talking about the protocol level here.
<= /blockquote>

Can the DCRUP charter help us?

<quote>
Changes will be limited to existing
imp= lemented algorithms and key forms. Other changes to DKIM, such as new
me= ssage canonicalization schemes, are out of scope. The WG will as far
as= possible avoid changes incompatible with deployed DKIM signers and
ver= ifiers.
</quote>

Especially the last sentence...

/rolf

------=_Part_1049533_1556839323.1522320221417-- From nobody Thu Mar 29 04:23: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 681B912DDD2 for ; Thu, 29 Mar 2018 04:23:34 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=4FGx9wEP; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=ErGoM7/q 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 mN-xqiKNlUgv for ; Thu, 29 Mar 2018 04:23:32 -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 79CC912DA14 for ; Thu, 29 Mar 2018 04:23:32 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1522322611; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=fZBRjNobPx3YvYqcu7z3qP7A4rdz3xJBDIGreabFGZk=; b=4FGx9wEPh7JVCwKDDylZQe/n4N+xXxXvOD0+3zl0evBxlTfhk8SByq8y nL5NX3LNqgPEZigquzHi+iMJJ1p2AA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1522322611; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=fZBRjNobPx3YvYqcu7z3qP7A4rdz3xJBDIGreabFGZk=; b=ErGoM7/qLWHujEOiVR2TX5g18kh/MKF6gBeQ7Ws/88ImMIy6tpv/7Kd4 UX5K01rJ/FcY2VybH56ncctq860koavLBPjaBoZhVPceySk84ok/fKz/5t v8icUFBkglFTiXUFeYDCirFmFsmkKaHDLKfyriI0EJ/b/15ecsi/dFnSo4 bUYMefH/nQEEUKc4u7L4XRu5i4lAmeR68W+LSmr+DvNynMlMAr9TwKyFUX 8aHJr0rM5xIRz6hVnOuirYy2GRnn4MwRc8ta5zfkzgsaN1EKsIgnv/hOGq GdJzn41HcEi4+/GFISBgd00hsKKwL++7V/YKXsEc6UIjcYS18V1JVQ== Received: from [10.62.59.54] (mobile-166-171-56-19.mycingular.net [166.171.56.19]) (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 CF608C40230; Thu, 29 Mar 2018 06:23:30 -0500 (CDT) Date: Thu, 29 Mar 2018 11:23:27 +0000 In-Reply-To: <1352163925.1049534.1522320221417.JavaMail.zimbra@sonnection.nl> References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.com> <20180328094636.Horde.Np3GCcO8iEPwmQzOaaUjbrh@andreasschulze.de> <1352163925.1049534.1522320221417.JavaMail.zimbra@sonnection.nl> 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: <080EDCBF-5AC6-4FB4-B447-E4968F1B0C75@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, 29 Mar 2018 11:23:37 -0000 On March 29, 2018 10:43:41 AM UTC, "Rolf E=2E Sonneveld" wrote: >Hi,=20 > >> instead of arguing about the lack of harm in including crud that is >not >> necessary in this case, could you perhaps explain the COMPELLING NEED >to >> include crud that is not necessary in this case? > >> Your suggestion violates the principle of parsimonious design=2E This >is that >> nothing unnecessary should be included=2E > >If we were to design a new protocol this principle certainly applies=2E >However, while the 'D' in DCRUP is about DKIM, we need to take the >existing standards, practices and installed base into account as well=2E >That means there are other principles that apply as well=2E=20 > >> Can you form an argument about why this crud is NECESSARY, rather >than >> expressing a preference for baroque decorations? > >I don't think this is a fair characterization of Murrays contribution >to the discussion=2E=20 > >[=2E=2E=2E]=20 > >> On Thu, Mar 29, 2018 at 2:21 AM, Murray S=2E Kucherawy < >superuser@gmail=2Ecom > >> wrote: > >>> On Wed, Mar 28, 2018 at 12:46 AM, A=2E Schulze < sca@andreasschulze=2E= de >> wrote: > >>>> - create a new DKIM key >>>> -> opendkim-genkey > >>> opendkim-genkey does two things: > >>> 1) generate an RSA private key in PEM-formatted ASN=2E1; this is just >an execution >>> of "openssl genrsa" >>> 2) read that key and extract its matching RSA public key in >PEM-formatted ASN=2E1, >>> and then just reformats it (without even decoding it) into a DNS TXT >record > >>>> - extract the public part >>>> -> opendkim-genzone > >>> This is used to turn an OpenDKIM-specific data set into a zone file=2E >It doesn't >>> do key generation=2E > >>>> The user don't (want to) care about ASN=2E1 is used or not=2E > >>> Users don't see ASN=2E1 in any case=2E They see base64=2E > >>>> >From this perspective it makes sense to avoid ASN=2E1 in new program >code=2E=2E > >>> But old program code doesn't use ASN=2E1 either, so I don't understand >what's >>> changing at the user level=2E > >>> I'm talking about the protocol level here=2E > >Can the DCRUP charter help us?=20 > >=20 >Changes will be limited to existing=20 >implemented algorithms and key forms=2E Other changes to DKIM, such as >new=20 >message canonicalization schemes, are out of scope=2E The WG will as far= =20 >as possible avoid changes incompatible with deployed DKIM signers and=20 >verifiers=2E=20 >=20 > >Especially the last sentence=2E=2E=2E=20 How does that relate to the formatting of public keys in DNS for a new alg= orithm? It's inherently new and incompatible with deployed DKIM signers an= d verifiers=2E Scott K From nobody Thu Mar 29 05:53:23 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 8191E12D88F for ; Thu, 29 Mar 2018 05:53:22 -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 CqvNG2KPH3by for ; Thu, 29 Mar 2018 05:53:21 -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 D8CB212D951 for ; Thu, 29 Mar 2018 05:53:20 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2TClYYV024061; Thu, 29 Mar 2018 13:52:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=8VQa8cp9i3Zy6X6DWLaHoZVcCsWuMTb0xylEdXlKloI=; b=ioI93rF8Rtiy0L8D7+y6LGXZX6ukeZScNpP660tEatj5GtBNYba4p7x04MtTE82wWWQ6 UiNhO9uPwVqdOZPSWFmCctCkzzxgFNyqwng2KC3Cweg3oxYX/6PqbYQgfT+NS+rXmVld zmulxaJ2iIxXY8gSlplQNyz695vRBCYTL/+WdkEAnWI2OnR/wOxOgMQLJaB0LL46ldD9 n/BnahmDlbqZtORUoARQ07WklmtOKXk/VxYVuJy0YuiinvEi/jNCZbtqpdH5Mq5QWAQq Vfw6pVcxGIwf2G3IucqWwCHr39QN9m4kwSo4vwR+3W9PlSW1ZV+GWycBik51rn5sAYtE +Q== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2gysqd53w2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Mar 2018 13:52:58 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w2TCpMRp022100; Thu, 29 Mar 2018 08:52:57 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2gwj0vqh7n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 29 Mar 2018 08:52:57 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 29 Mar 2018 08:52:56 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 29 Mar 2018 08:52:56 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Thu, 29 Mar 2018 08:52:56 -0400 From: "Salz, Rich" To: "Rolf E. Sonneveld" , denis bider CC: "dcrup@ietf.org" , "Murray S. Kucherawy" , "A. Schulze" Thread-Topic: [Dcrup] ed25519 in DNS Thread-Index: AQHTx1zbwEzv6G72TkaFYBLMFCEbCQ== Date: Thu, 29 Mar 2018 12:52:55 +0000 Message-ID: <47A6ED1C-D848-4DD3-86EB-E6D28286F82F@akamai.com> 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.32.218] Content-Type: multipart/alternative; boundary="_000_47A6ED1CD8484DD386EBE6D28286F82Fakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-29_08:, , 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=358 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803290138 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-29_08:, , 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=297 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803290138 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, 29 Mar 2018 12:53:22 -0000 --_000_47A6ED1CD8484DD386EBE6D28286F82Fakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3BlYWtpbmcgYXMgYW4gaW5kaXZpZHVhbC4NCg0KVGhlcmUgYXJlIGZldyBBU04xIGZhbnMgaW4g dGhlIElFVEYuICBJIHRoaW5rIHRoYXQsIGF0IHRoZSB0aW1lLCBldmVyeW9uZSB0aG91Z2h0IGl0 IHdvdWxkIGJlIGVhc2llciB0byBoYXZlIHJhdyBrZXlzLiBJdCB0dXJucyBvdXQgdGhhdCBtb3N0 IG9mIHRoZSB0b29sa2l0cyBiZWluZyB1c2VkIG1ha2UgaXQgZWFzaWVyIHRvIGhhdmUgQVNOMS13 cmFwcGVkIGtleXMuICBUaGVyZWZvcmUsIGV2ZW4gdGhvdWdoIGl0IGlzIGtpbmRhIHVnbHksIEkg d291bGQgYmUgaW4gZmF2b3Igb2YgQVNOMS13cmFwcGluZyBFZDI1NTE5IGtleXMuDQoNCg== --_000_47A6ED1CD8484DD386EBE6D28286F82Fakamaicom_ 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 c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5o b2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVha2lu ZyBhcyBhbiBpbmRpdmlkdWFsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgZmV3 IEFTTjEgZmFucyBpbiB0aGUgSUVURi4mbmJzcDsgSSB0aGluayB0aGF0LCBhdCB0aGUgdGltZSwg ZXZlcnlvbmUgdGhvdWdodCBpdCB3b3VsZCBiZSBlYXNpZXIgdG8gaGF2ZSByYXcga2V5cy4gSXQg dHVybnMgb3V0IHRoYXQgbW9zdCBvZiB0aGUgdG9vbGtpdHMgYmVpbmcgdXNlZCBtYWtlIGl0IGVh c2llciB0byBoYXZlIEFTTjEtd3JhcHBlZCBrZXlzLiZuYnNwOyBUaGVyZWZvcmUsIGV2ZW4gdGhv dWdoIGl0DQogaXMga2luZGEgdWdseSwgSSB3b3VsZCBiZSBpbiBmYXZvciBvZiBBU04xLXdyYXBw aW5nIEVkMjU1MTkga2V5cy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_47A6ED1CD8484DD386EBE6D28286F82Fakamaicom_-- From nobody Thu Mar 29 07:31: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 804F81242F7 for ; Thu, 29 Mar 2018 07:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, URIBL_BLOCKED=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 7_SU25q5j9xJ for ; Thu, 29 Mar 2018 07:31:13 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF08126C3D for ; Thu, 29 Mar 2018 07:31:13 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id w12-v6so6607932otj.7 for ; Thu, 29 Mar 2018 07:31:13 -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=OQtBpyjnz1vSqK4/mB5Yr616I5QuZ7lONtgRk9UKF78=; b=BQbHtcDM3p+pnZyWHgnV5XEEI4A/GP1s1z3uCNTqci/vBodyv2AP7orH0eQJO84e3a MGMi3IwKEgODnZ0/KjD595qfTwnMunGhPk6FO+fYhHM/PYLCEt66QBhQHW5Crqurr9az 34On9YmvgFEowhCPGTEGAcJciMOZ6iEhglIZuKHbZjTuN+xnuNhujZZT8huOaB+oFu9+ 4JzGNYJZY/AOA3tWYmZMbME9lGHmDbs5Z9CLxS+bssfWsPJD8d1K1L5W8LJ8lq1EwAJu kO9rudj4Sk5JuyJ+Ztb1AAhHu4m7jkcFyqRFwWs8GLLUT70PVxg3wPG+vnixOyF8Kfit ovPQ== 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=OQtBpyjnz1vSqK4/mB5Yr616I5QuZ7lONtgRk9UKF78=; b=QFfrpWyS/cTRYsUiJeGSiavDhDZlcEiNAMNmqLhX2ugSDZudY3NKwXKdNz4CbrDMHX 8OCQV1VZ/miR412AtmosTE2wuo8E6QlvjKsL3PA/aIl9XM1sBDcRITPQ4co+C2BLbfZB ivRAnAh+NLwSudzclg3H010v23D0+T2ToIb5AOJub79VzDqLmnEO7dnAujpAz3hpog6K MYK+ceu5ZcdRBbVSsdsSl4dGYDRLzekWdtVkiMKdRIJnGVMUT9OrHN51LK0FprBu7om3 JYwMZ9vkzHgyrY4jHhXEEeGux7wzCMwcDZ57J2/aw1+VoHJvF1EOptE5F5+lwN+Oh0+q SNrA== X-Gm-Message-State: AElRT7ElcnlKUBkl1mvevgsX99PxCZtpCE8VcraJvbj9vQwNr1dFe/jA vxvPOr54Zj2G++EHtOkoKOP2E8FCNDou50fOIu4= X-Google-Smtp-Source: AIpwx48i7/q4oDSNzMgL71iEnFQCj1wuIiYvRtWJUBCjdFAYYrqYBZNrPY6q6FQ1w9heWx7YPPwV7hv8nwq+knsq4OQ= X-Received: by 2002:a9d:4a52:: with SMTP id d18-v6mr292328otj.380.1522333872377; Thu, 29 Mar 2018 07:31:12 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Thu, 29 Mar 2018 07:31:11 -0700 (PDT) In-Reply-To: <47A6ED1C-D848-4DD3-86EB-E6D28286F82F@akamai.com> References: <47A6ED1C-D848-4DD3-86EB-E6D28286F82F@akamai.com> From: Phillip Hallam-Baker Date: Thu, 29 Mar 2018 10:31:11 -0400 X-Google-Sender-Auth: zK_fZzqZsI74hWl6-sapGXpLZ44 Message-ID: To: "Salz, Rich" Cc: "Rolf E. Sonneveld" , denis bider , "dcrup@ietf.org" , "Murray S. Kucherawy" , "A. Schulze" Content-Type: multipart/alternative; boundary="000000000000b1543505688df94b" 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, 29 Mar 2018 14:31:15 -0000 --000000000000b1543505688df94b Content-Type: text/plain; charset="UTF-8" OK so this is not the first time we have faced this issue with elliptic curves. The financial services world defined elliptic curve public keys in an entirely different matter. I don't use ASN.1 schema, but here are the relevant lines from my code: Class SubjectPublicKeyInfo Algorithm AlgorithmIdentifier SubjectPublicKey Bits A SPKI is simply a tag and a string of bits. The encoding of that string of bits is defined by the algorithm identifier. We already have algorithm identifiers for the CFRG curves and those specify that the public key info be encoded as specified in RFC 7748 and RFC 8032. So if you take any library that implements the CFRG curves, mine included, they will pack and unpack that format because it is the one specified in the document. It is the one that you have to use when using the CFRG curves with PKIX which is the only time I use ASN.1. So that bit string is the bitstring that DNSSEC etc. MUST use for public keys. Anything else will require additional code to be written. Anything else will not be compatible with RFC 7748 and RFC 8032. If you wanted to 'wrap the key in ASN.1', what you would do is to express it in exactly the same form as in PKIX, i.e. a SubjectPublicKeyInfo blob combining the algorithm and the public key data and you would not specify the algorithm id anywhere else. We did not go down that path in JOSE, I can't imagine we will in XML Dig Sig or anything else. SubjectPublicKeyInfo blob handlers are not generally exposed by PKIX implementations. What we have here is a layering confusion. The typical crypto app is a stack: Layer 3: [Application stuff] Layer 2: [PKIX Library] Layer 1: [ASN.1 Library] While PKIX implementations do include some ASN.1 handling code, they are not usually generic ASN.1 processors and in particular, many can only parse but not generate. Accessing layer 1 from layer 3 is a layer violation. It is bad design to ask. Parsing that ASN.1 fragment is indeed quite simple. But just you try generating it in DER format and then tell me how easy it was. Even a list of two items is actually very difficult to code correctly. I have written many ASN.1 generators over the years and it is a week reading the docs every time because they are awful and the generation of DER is perverse. So no, I see absolutely no value in more ASN.1 * It is a layering violation. * It is unnecessarily complex * ASN.1 is poorly specified * ASN.1 DER is even worse, it was an afterthought. * The public key is encoded as a string of bits regardless The only 'easy' way to get at this data is to either make use of a full feature ASN.1 parser/generator library which means a run time overhead or make use of what are typically undocumented calls in the PKIX support libraries. On Thu, Mar 29, 2018 at 8:52 AM, Salz, Rich wrote: > Speaking as an individual. > > > > There are few ASN1 fans in the IETF. I think that, at the time, everyone > thought it would be easier to have raw keys. It turns out that most of the > toolkits being used make it easier to have ASN1-wrapped keys. Therefore, > even though it is kinda ugly, I would be in favor of ASN1-wrapping Ed25519 > keys. > > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > --000000000000b1543505688df94b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK = so this is not the first time we have faced this issue with elliptic curves= . The financial services world defined elliptic curve public keys in an ent= irely different matter.

I= don't use ASN.1 schema, but here are the relevant lines from my code:<= /div>


Class SubjectPublicKeyInfo
Algorithm AlgorithmIdentifier
SubjectPublicKey Bits

A SPKI is simply a tag and a string of bits. The = encoding of that string of bits is defined by the algorithm identifier. We = already have algorithm identifiers for the CFRG curves and those specify th= at the public key info be encoded as specified in RFC 7748 and RFC 8032.

So i= f you take any library that implements the CFRG curves, mine included, they= will pack and unpack that format because it is the one specified in the do= cument. It is the one that you have to use when using the CFRG curves with = PKIX which is the only time I use ASN.1.
=

So that bit string is the bitstring that DNSSEC etc. MUST use for public= keys. Anything else will require additional code to be written. Anything e= lse will not be compatible with=C2=A0RFC 7748 and RFC 8032.

If you wanted to &= #39;wrap the key in ASN.1', what you would do is to express it in exact= ly the same form as in PKIX, i.e. a=C2=A0 SubjectPublicKeyInfo blob combining the algorithm= and the public key data and you would not specify the algorithm id anywher= e else.
=
We did not= go down that path in JOSE, I can't imagine we will in XML Dig Sig or a= nything else.=C2=A0 SubjectPublicKeyInfo=C2=A0blob handlers ar= e not generally exposed by=C2=A0PKIX implementations.


What we have here is a layering confusion. The typical= crypto app is a stack:

L= ayer 3: [Application stuff]
Layer 2:=C2=A0[PKIX Library]<= /div>
Layer 1:=C2=A0[ASN.1 Library]=

While PKIX implementatio= ns do include some ASN.1 handling code, they are not usually generic ASN.1 = processors and in particular, many can only parse but not generate. Accessi= ng layer 1 from layer 3 is a layer violation. It is bad design to ask.

Parsing that ASN.1 fragment i= s indeed quite simple. But just you try generating it in DER format and the= n tell me how easy it was. Even a list of two items is actually very diffic= ult to code correctly. I have written many ASN.1 generators over the years = and it is a week reading the docs every time because they are awful and the= generation of DER is perverse.


So = no, I see absolutely no value in more ASN.1

* It is a layering violation.
* It is unnecessarily complex
* ASN.1 is poorly specif= ied
* ASN.1 DER= is even worse, it was an afterthought.
* The public key is encoded as a string of bits re= gardless

The only 'ea= sy' way to get at this data is to either make use of a full feature ASN= .1 parser/generator library which means a run time overhead or make use of = what are typically undocumented calls in the PKIX support libraries.
<= div class=3D"gmail_default" style=3D"font-size:small">


On Thu, Mar 29, 2018 at 8:52 AM= , Salz, Rich <rsalz@akamai.com> wrote:

Speaking as an individual.

=C2=A0

There are few ASN1 fans in the IETF.=C2=A0 I think t= hat, at the time, everyone thought it would be easier to have raw keys. It = turns out that most of the toolkits being used make it easier to have ASN1-= wrapped keys.=C2=A0 Therefore, even though it is kinda ugly, I would be in favor of ASN1-wrapping Ed25519 keys.


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


--000000000000b1543505688df94b-- From nobody Thu Mar 29 13:18:30 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 A8FE912D80E for ; Thu, 29 Mar 2018 13:18:28 -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 j6bKlnuaISoY for ; Thu, 29 Mar 2018 13:18:26 -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 3AD4A126B6E for ; Thu, 29 Mar 2018 13:18:26 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id x70-v6so3206848lfa.0 for ; Thu, 29 Mar 2018 13:18:26 -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=e2hOreRXB8fALthv2rQuQe/BOQpSScUKK+FIMcs9WgM=; b=Jn/154SqLn4ojtxR2XVidfd0gqJSG4wIqCcCNjjcWccT9+q8Z7ZgkOD6zADCtmbtLm LDcTG9rHjEisONCNpTpif16U9wFKvQP6L+efgvAVbZzGLUkKe5gzdCdDYSKw+eiBePzw N/6JGVjKUVoaZv28Q88ANdF3d30y2Lh0opK/G40aFA1HuqJc705Bzpr0Fpi24nswJWa8 W/AM7e4AUqFVT3jQjSQw5RlBGExNn+OVgHCegUW0ROhGEiFKs3jaGqCVHc9xAcU1kcBl daSYRDR9YDy2d2rPaBd/k52rck12Mcc1vtZPEk+IBa3U4tCYxytfWOI0HLQVB6P/YaGL NKgw== 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=e2hOreRXB8fALthv2rQuQe/BOQpSScUKK+FIMcs9WgM=; b=GAikxWgvjXLbE0urZv8jwKsB6j+WT/t+vm1rTn680QYLzGJv5zu0Ssaw/tlo1ncmlj rNodXcDPG5u+dJuxlaeJFsWmkrhGoL8d6n6jvVYWFbR1QSQtY+LyDcxTurnZU+vI61G5 JBoCKR5sweOScMbUEzjc3QFQFzNxrXtzylHIxtiBuCXKov75YO3uq1A8sYozHUFWw3sk z7pv2PAkMgWt125TkmU8ulJ0sCirkKIMpGTwm+is2DmeY/WWT6pMzLTz9f7OrrgKBqDT oqvV/hsdy7FCfHjiZjM91z1oo9K2wSSjU1QYuErkQi5xDFHVFaoFcNtYbR1d67BW0WH8 f+bA== X-Gm-Message-State: AElRT7HE8ggz3WGhzJF7Ft3+9ksH5gvVMHvwypmHV/xOsFIzSQSkfiW4 TgocAStWnFQuBhBCsBN9bAF78OJ2jdHJMMN1GaI= X-Google-Smtp-Source: AIpwx49dGn2hcy3CJlVYFkN7+U50YU5d0OSdZiWiMxXi0kYbnTOX3byTD0Ag5jLKVXF691w9XfM4feb4GDSi0FZ0vgk= X-Received: by 10.46.44.2 with SMTP id s2mr6441105ljs.117.1522354704313; Thu, 29 Mar 2018 13:18:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.115.7 with HTTP; Thu, 29 Mar 2018 13:18:23 -0700 (PDT) In-Reply-To: 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> From: "Murray S. Kucherawy" Date: Thu, 29 Mar 2018 13:18:23 -0700 Message-ID: To: denis bider Cc: "A. Schulze" , dcrup@ietf.org Content-Type: multipart/alternative; boundary="f4f5e807c07c5f71fb056892d386" 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, 29 Mar 2018 20:18:29 -0000 --f4f5e807c07c5f71fb056892d386 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 29, 2018 at 1:42 AM, denis bider wrote: > instead of arguing about the lack of harm in including crud that is not > necessary in this case, could you perhaps explain the COMPELLING NEED to > include crud that is not necessary in this case? > I thought I'd already done that, but I can re-summarize: 1) ASN.1 is, whether we like it or not, the standard way to marshal crypto objects between applications. 2) ASN.1 is, for better or worse, the way this is already done in DKIM with RSA keys. 3) Having to explain that, in the DKIM context, "key type A is encoded with method 1, key type B is encoded with method 2, key type C is ..." seems at odds with claims of simplicity being mandatory. Your suggestion violates the principle of parsimonious design. > We are optimizing for different things. You're reducing bytes on the wire; I'm reducing specification complexity and the need for a code branch for each key type. > This is that nothing unnecessary should be included. Can you form an > argument about why this crud is NECESSARY, rather than expressing a > preference for baroque decorations? > As I believe I also already said, I have no particular affinity for ASN.1 apart from consistency with what the security community, and indeed DKIM, already does. -MSK --f4f5e807c07c5f71fb056892d386 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 29, 2018 at 1:42 AM, denis bider <den= isbider.ietf@gmail.com> wrote:
=
= instead of arguing about the lack of harm in including crud that is not nec= essary in this case, could you perhaps explain the COMPELLING NEED to inclu= de crud that is not necessary in this case?

I thought I'd already done that, but I can re-summarize:

=
1) ASN.1 is, whether we like it or not, the standard way to mars= hal crypto objects between applications.

2) ASN.1 is, for= better or worse, the way this is already done in DKIM with RSA keys.
3) Having to explain that, in the DKIM context, "key type= A is encoded with method 1, key type B is encoded with method 2, key type = C is ..." seems at odds with claims of simplicity being mandatory.
=
Your suggest= ion violates the principle of parsimonious design.

We are optimizing for different things.=C2=A0 You&#= 39;re reducing bytes on the wire; I'm reducing specification complexity= and the need for a code branch for each key type.
=C2=A0
This is that nothing unnece= ssary should be included. Can you form an argument about why this crud is N= ECESSARY, rather than expressing a preference for baroque decorations?

As I believe I also already said, I= have no particular affinity for ASN.1 apart from consistency with what the= security community, and indeed DKIM, already does.

-MSK
--f4f5e807c07c5f71fb056892d386-- From nobody Thu Mar 29 13:29:24 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 2ADB9120227 for ; Thu, 29 Mar 2018 13:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, URIBL_BLOCKED=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 cjfNg3xeWL86 for ; Thu, 29 Mar 2018 13:29:19 -0700 (PDT) Received: from mail-ot0-x243.google.com (mail-ot0-x243.google.com [IPv6:2607:f8b0:4003:c0f::243]) (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 7F5611250B8 for ; Thu, 29 Mar 2018 13:29:19 -0700 (PDT) Received: by mail-ot0-x243.google.com with SMTP id m22-v6so7690085otf.10 for ; Thu, 29 Mar 2018 13:29:19 -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=KQ9NCiLAYnTM8G1iEhVacZk3BstRQ8RKGcLSAZMxoGU=; b=tj/Da6kuFzkGZ7fwOjK9oBNXX/tkTtnWFT+waTT8WgMJrOkaOHN8pophBJpLkrwGxA lW2LpFfu5BwuWNzYriT96XaSyJrCE4YZ29mgzQ8UG3wQTbcchqpKdnIiH1CvAsREruSx Q62NQ8ZVWb92T5Jm0Bi3ufN8ftyqw55qIotU7aXWwQa8uKd/Nw4yw3nEtHGHyojTDSeh Q6+4u77oPVfc7qVOb/8nurmcWGQ5FvUXQ3LQcn+odlnapjqQMtl/mARMs8DFXnA2z2iy aZObRpZa9m6HK5Lr0KSuz8AjnIvZmkM+nVgLQI+H2yyDVCXhuYY2yT97/JJ0YPxoYGpk xzqA== 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=KQ9NCiLAYnTM8G1iEhVacZk3BstRQ8RKGcLSAZMxoGU=; b=k/esNjusSeq/wzYmxH3igxJlHyPnl5ODbhCMVNF74MttikpdZs1BrL63zsPJrnS/ji VE4IjYnFOXZx+P1x20M9VzpTTLC2OKbJHnp0+OFlChlyfavlQ35xcNerCEUXjetPwT9r BxbZYP72b3+NcuzBym/yis8Z0hdw3F2c48tEp2IGSWWOzxtlAtNg2z7FkfGFKmKezdvu 9yLQRLTKUT7gBh+I7I+3boSA5fXNnPz2OYm3uOeg8e7OZzjMA5/LQ3xYAXhLcb92VxXr dFXmO1SCqbAc29aH28JcM6z01Le3chHTEJxVe6h7HXexaHVFIDOv/OZQzms4zpDQ02xX YF7g== X-Gm-Message-State: AElRT7EVPSST5+8L1ZSmZBZ9IlQ7W21UaOOV9028LeBtO16fMQlWF2v1 Fi6eg16BKxOrbudGcFm+TzL89/dQoAduR055ABI= X-Google-Smtp-Source: AIpwx4/I8ZMQCMmUqhcNd7UWPZjbrngtRFioof+SLBLCijXuOjz8ZWXicBotn2tjDDwDRi1dmLVWqXyrdToyKf5v5EE= X-Received: by 2002:a9d:ec8:: with SMTP id 66-v6mr5524123otj.167.1522355358702; Thu, 29 Mar 2018 13:29:18 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Thu, 29 Mar 2018 13:29:18 -0700 (PDT) In-Reply-To: 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> From: Phillip Hallam-Baker Date: Thu, 29 Mar 2018 16:29:18 -0400 X-Google-Sender-Auth: tjoVUg_6dHhX1XFaqXTEXrC8JvM Message-ID: To: "Murray S. Kucherawy" Cc: denis bider , dcrup@ietf.org, "A. Schulze" Content-Type: multipart/alternative; boundary="00000000000060a560056892fabb" 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, 29 Mar 2018 20:29:22 -0000 --00000000000060a560056892fabb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2018 at 4:18 PM, Murray S. Kucherawy wrote: > On Thu, Mar 29, 2018 at 1:42 AM, denis bider > wrote: > >> instead of arguing about the lack of harm in including crud that is not >> necessary in this case, could you perhaps explain the COMPELLING NEED to >> include crud that is not necessary in this case? >> > > I thought I'd already done that, but I can re-summarize: > > 1) ASN.1 is, whether we like it or not, the standard way to marshal crypt= o > objects between applications. > =E2=80=8BIt is one of the standards. It is not the only one used. It is not= the one we used in the CFRG work. =E2=80=8B > 2) ASN.1 is, for better or worse, the way this is already done in DKIM > with RSA keys. > =E2=80=8BThe RSA key structure is originally defined in the PKCS#1 specific= ation as ASN.1. The CFRG key formats are specified in the RFCs and they are not ASN.1=E2=80=8B > 3) Having to explain that, in the DKIM context, "key type A is encoded > with method 1, key type B is encoded with method 2, key type C is ..." > seems at odds with claims of simplicity being mandatory. > =E2=80=8BRSA keys are encoded according to PKCS#1 Ed25519 keys are encoded according to RFC =E2=80=8B8032 > Your suggestion violates the principle of parsimonious design. >> > > We are optimizing for different things. You're reducing bytes on the > wire; I'm reducing specification complexity and the need for a code branc= h > for each key type. > =E2=80=8BThat is what you think you are doing but as an implementer, I can = assure you that you are not. You are committing a layer violation as I explain in my last message.=E2=80=8B This is that nothing unnecessary should be included. Can you form an >> argument about why this crud is NECESSARY, rather than expressing a >> preference for baroque decorations? >> > > As I believe I also already said, I have no particular affinity for ASN.1 > apart from consistency with what the security community, and indeed > =E2=80=8B=E2=80=8B > DKIM, already does. > =E2=80=8B =E2=80=8B DKIM merely specifies an opaque blob which happens to be encoded as ASN.1 internally. =E2=80=8B k=3D Key type (plain-text; OPTIONAL, default is "rsa"). Signers and Verifiers MUST support the "rsa" key type. The "rsa" key type indicates that an ASN.1 DER-encoded [ITU-X660-1997 ] RSAPublicKey (see [RFC3447 ], Sections 3.1 and A.1.1) is being used in the "p=3D" tag. (Note: the "p=3D" tag further encodes the value using the base64 algorithm.) Unrecognized key types MUST be ignored. Note that the specification of ASN.1 encoding is implicit in the algorithm tag. Other tags may specify different encodings. The RSAPublicKey structure is: An RSA public key should be represented with the ASN.1 type RSAPublicKey: RSAPublicKey ::=3D SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER -- e } Just the parameters, nothing else. We do not wrap RSA keys in a SubjectPublicKeyInfo wrapper so to do so for any other type of key would be inconsistent. --00000000000060a560056892fabb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Ma= r 29, 2018 at 4:18 PM, Murray S. Kucherawy <superuser@gmail.com><= /span> wrote:
On Thu, Mar 29, 2018 at 1:42 AM, denis bider <<= a href=3D"mailto:denisbider.ietf@gmail.com" target=3D"_blank">denisbider.ie= tf@gmail.com> wrote:
instead of arguing about the lack of harm in including crud t= hat is not necessary in this case, could you perhaps explain the COMPELLING= NEED to include crud that is not necessary in this case?

I thought I'd already done that, but I can = re-summarize:

1) ASN.1 is, whether we like it or not, the= standard way to marshal crypto objects between applications.

=E2=80=8BIt is one of the standards. It is not t= he only one used. It is not the one we used in the CFRG work. =E2=80=8B

=C2=A0
2) ASN.1 is, for better or worse, the way this is already done in D= KIM with RSA keys.

<= div>
=E2=80=8BThe RSA= key structure is originally defined in the PKCS#1 specification as ASN.1. = The CFRG key formats are specified in the RFCs and they are not ASN.1=E2=80= =8B

=C2=A0
<= div>
3) Having to explain that, in the DKIM context, "key ty= pe A is encoded with method 1, key type B is encoded with method 2, key typ= e C is ..." seems at odds with claims of simplicity being mandatory.

=E2=80=8BRSA keys are encoded accord= ing to PKCS#1
E= d25519 keys are encoded according to RFC =E2=80=8B8032

=
=C2=A0
Your suggestion vio= lates the principle of parsimonious design.

We are optimizing for different things.=C2=A0 You&#= 39;re reducing bytes on the wire; I'm reducing specification complexity= and the need for a code branch for each key type.
<= /blockquote>

=E2=80=8BThat is what you think you are doing but as an impleme= nter, I can assure you that you are not. You are committing a layer violati= on as I explain in my last message.=E2=80=8B

This is that nothing unnecessary should be inc= luded. Can you form an argument about why this crud is NECESSARY, rather th= an expressing a preference for baroque decorations?

As I believe I also already said, I have no par= ticular affinity for ASN.1 apart from consistency with what the security co= mmunity, and indeed
=E2=80=8B=E2=80=8B
DKIM, already does.

=E2=80=8B
=E2=80=8B
DKIM=C2=A0merely specifies an opaque blob which happens to be en= coded as ASN.1 internally. =E2=80=8B

   k=3D Key type (plain-t=
ext; OPTIONAL, default is "rsa").  Signers and
      Verifiers MUST support the "rsa" key type.  The "rsa&q=
uot; key type
      indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey
      (see [RFC3447], Sections 3.1 and A.1.1) is being used in the "=
p=3D"
      tag.  (Note: the "p=3D" tag further encodes the value using=
 the
      base64 algorithm.)  Unrecognized key types MUST be ignored.

Note that = the specification of ASN.1 encoding is implicit in the algorithm tag. Other= tags may specify different encodings.

The RSAPublicKey structure is:

   An RSA public key shou=
ld be represented with the ASN.1 type
   RSAPublicKey:

      RSAPublicKey ::=3D SEQUENCE {
          modulus           INTEGER,  -- n
          publicExponent    INTEGER   -- e
      }

Just the p= arameters, nothing else.

= We do not wrap RSA keys in a SubjectPublicKeyInfo wrapper so to do so for a= ny other type of key would be inconsistent.
--00000000000060a560056892fabb-- From nobody Thu Mar 29 13:43:27 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 9DF2312D946 for ; Thu, 29 Mar 2018 13:43:25 -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 wZ0QTh1c3akK for ; Thu, 29 Mar 2018 13:43:23 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 7107612741D for ; Thu, 29 Mar 2018 13:43:22 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id j68-v6so10077845lfg.13 for ; Thu, 29 Mar 2018 13:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3b0GRGGwXNqY6lCSJoA8PDJP+Ax9frzZ1uVsJCTXiWM=; b=CJCkV6t4C+ZeKs0Ywo9ICyp8uCi+n3iMqAXjnGyCyijIvAV5vT2vzsGEXfCRZ99RSA JGpkonwuo6O73gxWee/FIwcxbNEnXAfACNc3BbZFpsPsna3j3NowgRJ3SzNAQHCjifTW PIeAWJS/oZXqiym+QBd5TTFEqFpVYvUUtdxf+ryb90LbPjGGO17W37gdY4ok0VZkoWnt kDdktsjtu/TGgUibfk45SUqE8HaYDOnGiNPXFLKnQvsqxN4Hy3LvLjoxdM5tR/aazTMS lLh1BJB8s4IJF6vFA7Qc7Xn8gjHGMgI4T1uOkO/t+Ehcn1B56FW/z8WKULVbqnf2IN3d 4+FA== 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=3b0GRGGwXNqY6lCSJoA8PDJP+Ax9frzZ1uVsJCTXiWM=; b=ZR2T5KIdkRzlA9XljW1yT2VmgmNV8mWF71IA+cchiz5DYYVMG3B1hhHsXWz+UxDWNp Ns59N1RPS4jVT47B0zewSsRBNOr3kRlAyXSdGoytOviz06y7tXpeW1GEs6BKoQlyUkrr Jad8+DiM6yzc+yG9rSpPXU2fIkuqCGh2GpWioJB1yN9DA5SZ7/Qb1mOmGyC2oJ1W7NUF onIgwwDFnQz8UOugGVxJx5nuEtNom9HRptttO4H02v5hgfVtOirWpFGVP5wP2K1Ec2n3 k+Nj2PrXlvbQ2u4rTxBDXvPRuZk3G5V59qGCVbOMtNBSaHceuRPB6j+r49Ha5/Twf8JE IVUw== X-Gm-Message-State: AElRT7HP4xFkSRNW1AxXDM7kLm3H/r1nQWu7J5jiCXn8UyeupQIEx9ER HQxOuh4Yay03YHjD0c3u9NRPm3wKl4D5HYQeJ3w= X-Google-Smtp-Source: AIpwx48JwuWT2Upo8xnp/+0lwMF5RK5OecRM5eAe77gCKWOFKvs4PCUUuiZ62/rSUTKepzPaEIvAbnylcgkURpxkjKs= X-Received: by 2002:a19:2655:: with SMTP id m82-v6mr6070867lfm.107.1522356200343; Thu, 29 Mar 2018 13:43:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.115.7 with HTTP; Thu, 29 Mar 2018 13:43:19 -0700 (PDT) In-Reply-To: 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> From: "Murray S. Kucherawy" Date: Thu, 29 Mar 2018 13:43:19 -0700 Message-ID: To: Phillip Hallam-Baker Cc: denis bider , dcrup@ietf.org, "A. Schulze" Content-Type: multipart/alternative; boundary="0000000000008b0d6f0568932c9e" 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, 29 Mar 2018 20:43:26 -0000 --0000000000008b0d6f0568932c9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2018 at 1:29 PM, Phillip Hallam-Baker wrote: > =E2=80=8B > =E2=80=8B > DKIM merely specifies an opaque blob which happens to be encoded as ASN.1 > internally. =E2=80=8B > > k=3D Key type (plain-text; OPTIONAL, default is "rsa"). Signers and > Verifiers MUST support the "rsa" key type. The "rsa" key type > indicates that an ASN.1 DER-encoded [ITU-X660-1997 ] RSAPublicKey > (see [RFC3447 ], Sections 3.1 = and A.1.1) is being used = in the "p=3D" > tag. (Note: the "p=3D" tag further encodes the value using the > base64 algorithm.) Unrecognized key types MUST be ignored. > > > Note that the specification of ASN.1 encoding is implicit in the algorith= m > tag. Other tags may specify different encodings. > As I recall, we picked this because that's the format exported by the openssl CLI for public RSA keys, and we were fine with that. What's different with Ed25519 keys? -MSK --0000000000008b0d6f0568932c9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 29, 2018 at 1:29 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=E2=80=8B
=E2=80=8B
DKIM=C2=A0mer= ely specifies an opaque blob which happens to be encoded as ASN.1 internall= y. =E2=80=8B

   =
k=3D Key type (plain-text; OPTIONAL, default is "rsa").  Signers =
and
      Verifiers MUST support the "rsa" key type.  The "rsa&q=
uot; key type
      indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAP=
ublicKey
      (see [RFC3447], Sections 3.1 an=
d A.1.1) is being used in the "p=3D"
      tag.  (Note: the "p=3D" tag further encodes the value using=
 the
      base64 algorithm.)  Unrecognized key types MUST be ignored.

Note that the specification of ASN= .1 encoding is implicit in the algorithm tag. Other tags may specify differ= ent encodings.

As I= recall, we picked this because that's the format exported by the opens= sl CLI for public RSA keys, and we were fine with that.=C2=A0 What's di= fferent with Ed25519 keys?

-MSK
--0000000000008b0d6f0568932c9e-- From nobody Thu Mar 29 13:51: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 BFB16129C59 for ; Thu, 29 Mar 2018 13:51:28 -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 twHlAjuw0_gk for ; Thu, 29 Mar 2018 13:51:26 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD711250B8 for ; Thu, 29 Mar 2018 13:51:26 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id a22-v6so10128801lfg.9 for ; Thu, 29 Mar 2018 13:51:25 -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=qAenM0pcAArluC0uApHMtAUdDPRW3c/RIOUp3B/K7E4=; b=IlevNWH0dCAWkwAyKRY0Zxw3vr/S81dU5p3w6mEnC7o1wxuXYQY544D+bIVGhfXHOZ d3bn9obOO8fNuOs/aluVZ1pffoUwRYr7+Cion3GE9k6CfoDWu3hMEh58fucSvi7q5cTW AsT4d4lBxB858nr++hUJg4aOV+hQ36tTZzQOVSV+o7WBiNShKl4a8EnfrVyWM0DdGopv 86RyoQTMhSLKembsLqTUekvDhui5+mxKidPL2A0Y8drGEqK8BSH28Ny75KQwwuAVmPVo rA6wNB4dvFv9x2aslGsvkXiwjan18f5BJD53QOrpsJ6WIB8ZC48UmdOUnY6yw3xld4JK hcFA== 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=qAenM0pcAArluC0uApHMtAUdDPRW3c/RIOUp3B/K7E4=; b=djwMg7wAJX8lwcAFtKV6DxszXzu/VewkO17MwNhVxQkv25twKgrNXTkDdUPkt90H44 L1vb1uCJd+Pf5MN+1BmZQoz7UKMi3jrBM4+W6R4pF5x7HaEzVndG7y0Aqe5xEyF7foOf JqXIwSD1NE2VTG1w16DBctsEV4jQ6470wdIQvsWn0IhikIF/8jpwqD3wz8UnfSVyIJf/ VkU9B76qle+6y+U3HaBPKil6KfwOdJDxTleKnSTmfr82B6vzGAdgN/xtwf6NNfWxJMyB pnJvxJXqP0gIYjOfq85vHC+qYIa4PwRmT3Tz8fAzecQOUB9wQXGLepv/cwGZKJa5mhTY kuTA== X-Gm-Message-State: AElRT7FkHfVxwQnsFaUnf2rUyy7bnINqiR20oOWX8PH6Emz+w9aNFJ76 LvM1b6N+gmDCfN/kR9QX1HTyZPL+T6377EAFEJM= X-Google-Smtp-Source: AIpwx4/PSTaTY3fchfsxFHUjC27hlvEdDyxvV4PI1zSw569lHs44lEPmzIzBmCMtD6h2E+MTgOXyq2BR1srVOIPxIf8= X-Received: by 10.46.41.156 with SMTP id p28mr6319370ljp.32.1522356684186; Thu, 29 Mar 2018 13:51:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.115.7 with HTTP; Thu, 29 Mar 2018 13:51:23 -0700 (PDT) In-Reply-To: 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> From: "Murray S. Kucherawy" Date: Thu, 29 Mar 2018 13:51:23 -0700 Message-ID: To: Phillip Hallam-Baker Cc: denis bider , dcrup@ietf.org, "A. Schulze" Content-Type: multipart/alternative; boundary="001a114b5bb861ea3d056893494f" 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, 29 Mar 2018 20:51:29 -0000 --001a114b5bb861ea3d056893494f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2018 at 1:29 PM, Phillip Hallam-Baker wrote: > > >> Your suggestion violates the principle of parsimonious design. >>> >> >> We are optimizing for different things. You're reducing bytes on the >> wire; I'm reducing specification complexity and the need for a code bran= ch >> for each key type. >> > > =E2=80=8BThat is what you think you are doing but as an implementer, I ca= n assure > you that you are not. You are committing a layer violation as I explain i= n > my last message.=E2=80=8B > I'm also an implementer, and it sure seems like I am when the code needs a different function to read each key type, plain and simple. And I don't think that's the fault of the crypto library I'm using, because one means "load a DER key" and one means "load a raw key", which is forced by the current proposal to encode them differently. I think I'm being forced to cope with a layering deviation, rather than imposing one. -MSK --001a114b5bb861ea3d056893494f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 29, 2018 at 1:29 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=C2=A0
Your suggestion viol= ates the principle of parsimonious design.

We are optimizing for different things.=C2=A0 You= 9;re reducing bytes on the wire; I'm reducing specification complexity = and the need for a code branch for each key type.

=E2=80= =8BThat is what you think you are doing but as an implementer, I can assure= you that you are not. You are committing a layer violation as I explain in= my last message.=E2=80=8B
<= br>
I'm also an implementer, and it sure seems like I am when= the code needs a different function to read each key type, plain and simpl= e.=C2=A0 And I don't think that's the fault of the crypto library I= 'm using, because one means "load a DER key" and one means &q= uot;load a raw key", which is forced by the current proposal to encode= them differently.

I think I'm being forced to cope w= ith a layering deviation, rather than imposing one.

-MSK
--001a114b5bb861ea3d056893494f-- From nobody Thu Mar 29 13:54: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 CE7D412D956 for ; Thu, 29 Mar 2018 13:54:49 -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 i461-rNmT7z2 for ; Thu, 29 Mar 2018 13:54:47 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838521250B8 for ; Thu, 29 Mar 2018 13:54:47 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2TKq2X3031205; Thu, 29 Mar 2018 21:54:31 +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=mEAOhG8/WxznLmUkwv5YLn4HbswbkWOBjnScIbXxFjo=; b=bndEZsNO2gnDFd5XyNUYQzH/CJ8pZ25mx3K3xDN1Mbm7BPB0cYVqnw688LUTo4Z/+a+A TMK1NhNzxUFZG6UtZjUtdnV/0S6qI2qWHI6C4kNBws6IziFWuFE3LtoKnDbsiBRbOsYS c0riFp9CVgMHlUWZsnaanMpT5/Ar2VaYF62tOxQCd65XdxnlIQiZURS/sfLEE6A1P+Dd RO99tHgxLsDn3bAbu8/m+g5ERrTwOthTgtxDIRbfUtMl0Zg1U+IFCOENSJyeQauLsLnw A9cPs7xoqP5Fi4QEz7ID7ABCooJawFYgB/oFa5EadGMG9lsUgN1lhonYd9FZAqb90/wL /g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2h03r1vypx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Mar 2018 21:54:31 +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 w2TKpdXp030471; Thu, 29 Mar 2018 16:54:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2gwj0vhh35-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 29 Mar 2018 16:54:30 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 29 Mar 2018 16:54:29 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Thu, 29 Mar 2018 16:54:29 -0400 From: "Salz, Rich" To: "Murray S. Kucherawy" , Phillip Hallam-Baker CC: "dcrup@ietf.org" , denis bider , "A. Schulze" Thread-Topic: [Dcrup] ed25519 in DNS Thread-Index: AQHTwELMBQuIVyAaXkGxq4oyoJ8nq6PZYOKAgAt2FYCAAC7BgIAAQpyAgAAPcgCAABGngIAADquAgAAcPACAAYtmgIAAFqwAgADCToCAAAMNAIAABiyA//+9z4A= Date: Thu, 29 Mar 2018 20:54:29 +0000 Message-ID: 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> 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.37.62] Content-Type: multipart/alternative; boundary="_000_EDC49D21703A474CA5D6FFC3A796ACEBakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-29_12:, , 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=564 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803290216 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-29_12:, , 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=506 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803290216 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, 29 Mar 2018 20:54:50 -0000 --_000_EDC49D21703A474CA5D6FFC3A796ACEBakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSSBzYWlkIGJlZm9yZSwgcG9wdWxhciB0b29sa2l0cyBkbyB0aGUgQVNOMS9ERVIgd3JhcHBp bmcuDQoNCkxldOKAmXMgdHJ5IHRvIGtlZXAgcGVyc29uYWxpdGllcyBvdXQgb2YgdGhpcywgcGxl YXNlLg0KDQo= --_000_EDC49D21703A474CA5D6FFC3A796ACEBakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <6E61EBBD02CE524B8E9C5FD4E21585F0@akamai.com> 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 c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5n bWFpbC0NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBJIHNh aWQgYmVmb3JlLCBwb3B1bGFyIHRvb2xraXRzIGRvIHRoZSBBU04xL0RFUiB3cmFwcGluZy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV04oCZcyB0cnkgdG8ga2VlcCBwZXJzb25hbGl0aWVzIG91 dCBvZiB0aGlzLCBwbGVhc2UuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJvZHkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9hPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EDC49D21703A474CA5D6FFC3A796ACEBakamaicom_-- From nobody Thu Mar 29 14:31:46 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 4CB9A127078 for ; Thu, 29 Mar 2018 14:31:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=xdKK40/z; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=p2GmASDn 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 t_jpsti8YQty for ; Thu, 29 Mar 2018 14:31:43 -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 128091200F1 for ; Thu, 29 Mar 2018 14:31:43 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1522359102; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=M5dYJCM5nKspt7ATgdcPuaKecx6sDcMdwaLxQf2PFXg=; b=xdKK40/z5+W0Rr6gDJuy8ng2nwtyTchWyGQ6EC0G0Syo3BTPWy083Mii OpOhbRfJ3AfHp+GAhYkZ8fehkn3yBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1522359102; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=M5dYJCM5nKspt7ATgdcPuaKecx6sDcMdwaLxQf2PFXg=; b=p2GmASDnmKGMiqLboXn1xJLWpgjFFX0OYrsKBFagHBRU3M11H4yYUNAo U931sG9eao70P9jWi0sFpjz9LZFg1QXZZJvFs52L6npl4vjzGjtYVjHj6y nY5MjR40qkl+v3JJqcAlF0bd60la7ziG/Z/swtM+Knn4TCz7UUJOJOmDed uYIY+XPJxDcLLewa+KBggb5Qwiiw8kZ12C/sa/Ne5WvxnhaCfGdrbIJXan zh0IqsCKhvvKmKf4NTG19ZYd5WQNiLAqkYfOzKE9GY3b+QrNN8U6JhH1Wp KsP1vKuPJOoVs6ECOZtJxw43tqcBUy7M0HV1mF9PmGcQvUiu+kFntQ== Received: from [10.62.59.54] (mobile-166-171-56-60.mycingular.net [166.171.56.60]) (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 DE149C401CA; Thu, 29 Mar 2018 16:31:41 -0500 (CDT) Date: Thu, 29 Mar 2018 21:31:37 +0000 In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.com> <20180328094636.Horde.Np3GCcO8iEPwmQzOaaUjbrh@andreasschulze.de> 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: <4AA34DC9-1B8F-44A6-A680-7A97552F7644@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, 29 Mar 2018 21:31:45 -0000 On March 29, 2018 8:54:29 PM UTC, "Salz, Rich" wrote: >As I said before, popular toolkits do the ASN1/DER wrapping=2E =2E=2E=2E Some do and some don't=2E I'm going to have to add custom application cod= e to go beyond RFC 8032, since libsodium matches that=2E I can do that, bu= t I still haven't seen anything that looks to me like anything other than "= because we've always done it this way"=2E I still am not seeing a solid rationale for adding complexity from x=2E509= to this application of RFC 8032=2E We've already demonstrated interoperab= ility between two dissimilar implementations just using what's in RFC 8032= =2E I believe that is a reasonably solid proof that x=2E509/ASN=2E1 isn't = needed=2E I don't find the toolset argument very interesting either=2E There is sup= port in different tools for doing it either way=2E I, of course, like the = way that makes it easier given my tools and others will tend to like the wa= y that makes it easier given theirs=2E The specifics of the tools are ephe= mera that, I don't think should drive protocol design=2E If using ASN=2E1 makes the protocol simpler, it might be useful to have so= meone describe what text could be removed from the draft if we went that di= rection=2E Any volunteers? Scott K From nobody Thu Mar 29 16:11: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 91679127876 for ; Thu, 29 Mar 2018 16:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, URIBL_BLOCKED=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 1kOH-YUFVCGL for ; Thu, 29 Mar 2018 16:11:48 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62AA127775 for ; Thu, 29 Mar 2018 16:11:48 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id n40-v6so8044509otd.3 for ; Thu, 29 Mar 2018 16:11:48 -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=uXLcVuXGyCB3iY+shfFac99I2drz4iJQsLi5rDwx4U4=; b=WHltTUE1F4+nsgrItq5P6wGXA+o5BPMMafIXa27O7p58mp8ma2rRkY5AGM8INFcmTf G2rNbjNE4EX7+a60KotQ6tSXeE/q9kIqmCBGycKPzrlONZSYq3gBsF5OQ6s6nYQxMefn vGuY/LYaDQ9jzpANhStd5Sid+TPri6g9k9ARK+k5JXJxZE+JEkGO6ib0Ube0GqEnohZe pwrNcVH5wLB5CUxOtwL7p8s0yXB1N8jIbFuOH0NJgzCORpbTr+ivG+lHcYnoJJUdIAOm hlm3N4xSe9Z55i1ibazPO/FCmOFCKv0B6cEhwGytO8XO8mNOYaywole8FeQ9MiPpCRGi 8E/A== 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=uXLcVuXGyCB3iY+shfFac99I2drz4iJQsLi5rDwx4U4=; b=VX27UUQKjQn4R5k9dJCuKeedhpe9Vhaj77Q9oOuJS08bNzwqNaDmw/Hk3tu14rKmBq 4OJ1HxW9Oc7YM1vTVWoPFOxZnX8w9JdvOkdEPJNbPV4rsP5XUD+1kF+5Vf3yxKRRfOjQ yyR8n/i4RNsCj++dgJYJS4gxT9m3Jeo5SDBXd/SelPGz8YbTPsnQ6IFLBh2kfg3nv1a1 0YUfF4tq5DKYvtNQ1cW+crn8Z/7Tly0LV+iyFg3qmBeLADR+ZHNHHFb2M3mxPzgc/3Nl AZN6CUpBoUVqCp4lan6ETbA5dB3SYhzH636UoHfBPAuBuC1KVqHwnsgd24j1958KVWqo NxVw== X-Gm-Message-State: AElRT7G4w/ZJ4rd20SZ157dn/PjeF0MZykjEHzARJ0DkmfQ6pmEi4qpC LQNJxWc+UwfUH8o+JR6FVbsnsXS73T1VTj88sY4= X-Google-Smtp-Source: AIpwx4/jOIPOpoCBve2053OonL7bLHX7PU8Kk1B4Nh6qyNQH4mt+sFygRvKdF4TUfjBFldumTmoG2+W5tFlfZsxyDJ4= X-Received: by 2002:a9d:4a52:: with SMTP id d18-v6mr1461700otj.380.1522365107924; Thu, 29 Mar 2018 16:11:47 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Thu, 29 Mar 2018 16:11:47 -0700 (PDT) In-Reply-To: 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> From: Phillip Hallam-Baker Date: Thu, 29 Mar 2018 19:11:47 -0400 X-Google-Sender-Auth: 5tTR4JNR_hafkW1jIFCVRbmQesk Message-ID: To: "Murray S. Kucherawy" Cc: denis bider , dcrup@ietf.org, "A. Schulze" Content-Type: multipart/alternative; boundary="00000000000079f9810568953fbc" 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, 29 Mar 2018 23:11:52 -0000 --00000000000079f9810568953fbc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2018 at 4:43 PM, Murray S. Kucherawy wrote: > On Thu, Mar 29, 2018 at 1:29 PM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> =E2=80=8B >> =E2=80=8B >> DKIM merely specifies an opaque blob which happens to be encoded as >> ASN.1 internally. =E2=80=8B >> >> k=3D Key type (plain-text; OPTIONAL, default is "rsa"). Signers and >> Verifiers MUST support the "rsa" key type. The "rsa" key type >> indicates that an ASN.1 DER-encoded [ITU-X660-1997 ] RSAPublicKey >> (see [RFC3447 ], Sections 3.1= and A.1.1) is being used= in the "p=3D" >> tag. (Note: the "p=3D" tag further encodes the value using the >> base64 algorithm.) Unrecognized key types MUST be ignored. >> >> >> Note that the specification of ASN.1 encoding is implicit in the >> algorithm tag. Other tags may specify different encodings. >> > > As I recall, we picked this because that's the format exported by the > openssl CLI for public RSA keys, and we were fine with that. What's > different with Ed25519 keys? > =E2=80=8BWhat is different is that the use of RSA is described in PKCS #1 a= nd its successors which used ASN.1 to describe the public key blob format. The use of the CFRG curves is described=E2=80=8B in the RFCs mentioned earl= ier and we decided to stop using ASN.1 when we shipped them. The public key blob format does not use ASN.1. It is just a bignum with an implicit length and the sign encoded in a spare bit: =E2=80=8B /// /// Encode this point in the compressed buffer representation /// /// The point encoded in the compressed buffer representation. public byte[] Encode() { Translate(out var X0, out var Y0); byte[] Buffer =3D new byte[32]; var YBuf =3D Y0.ToByteArray(); Array.Copy (YBuf, Buffer, YBuf.Length); if (!X0.IsEven) { // Encode the sign bit Buffer[31] =3D (byte)(Buffer[31] | 0x80); } return Buffer; }=E2=80=8B See, no ASN.1 at all. That is the implementation I use for JOSE, PKIX, S/MIME and for everything else. --00000000000079f9810568953fbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Ma= r 29, 2018 at 4:43 PM, Murray S. Kucherawy <superuser@gmail.com><= /span> wrote:
On Thu, Mar 29, 2018 at 1:29 PM, Phillip Ha= llam-Baker <phill@hallambaker.com> wrote:
=E2=80=8B
=E2=80=8B
DKIM=C2=A0mer= ely specifies an opaque blob which happens to be encoded as ASN.1 internall= y. =E2=80=8B

   k=3D Key type (plain-text; OPTIONAL, default is =
"rsa").  Signers and
      Verifiers MUST support the "rsa" key type.  The "rsa&q=
uot; key type
      indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAP=
ublicKey
      (see [RFC3447], Sections 3.1 an=
d A.1.1) is being used in the "p=3D"
      tag.  (Note: the "p=3D" tag further encodes the value using=
 the
      base64 algorithm.)  Unrecognized key types MUST be ignored.

Note that the specification of ASN= .1 encoding is implicit in the algorithm tag. Other tags may specify differ= ent encodings.

As I recall, we picked this because that's the format exported by th= e openssl CLI for public RSA keys, and we were fine with that.=C2=A0 What&#= 39;s different with Ed25519 keys?
=
=E2= =80=8BWhat is different is that the use of RSA is described in PKCS #1 and = its successors which used ASN.1 to describe the public key blob format.

The use of the CFRG curves i= s described=E2=80=8B in the RFCs mentioned earlier and we decided to stop u= sing ASN.1 when we shipped them. The public key blob format does not use AS= N.1. It is just a bignum with an implicit length and the sign encoded in a = spare bit:

=E2=80=8B=C2=A0 =C2=A0 =C2=A0 =C2=A0 /// <summary>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /// Encode t= his point in the compressed buffer representation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /// </summary>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /// <returns>The point= encoded in the compressed buffer representation.</returns>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public byte[] Encode()= {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Translate(out var X0, out var Y0= );

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 byte[] Buffer =3D new byte[32];<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= var YBuf =3D Y0.ToByteArray();
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Array.Copy (YBuf, Buffer, YBuf.Length);<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= if (!X0.IsEven) {=C2=A0 =C2=A0 =C2=A0 =C2=A0 // Encode the sign bit
<= div class=3D"gmail_default">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Buffer[31] =3D (byte)(Buffer[31] | 0x80);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retu= rn Buffer;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 }=E2=80=8B

See, no ASN.1 at = all. That is the implementation I use for JOSE, PKIX, S/MIME and for everyt= hing else.=C2=A0
--00000000000079f9810568953fbc-- From nobody Thu Mar 29 16:29: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 5866512E85B for ; Thu, 29 Mar 2018 16:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, URIBL_BLOCKED=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 HOL2cMnnHUy0 for ; Thu, 29 Mar 2018 16:29:43 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4146F12E741 for ; Thu, 29 Mar 2018 16:29:43 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id 23-v6so8095756otj.0 for ; Thu, 29 Mar 2018 16:29:43 -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=OQgjSZQRlzjiLo1YVnL8nh2/OZv9aIw1g+yWU29w5So=; b=Ck1HUWBhS1ZxvZAfp4c/YsKBZB9FH9H1LumCMECILM5LfNzNc0dp7zmjC7QP5hVn+e u0tj5kw+JUR3c1df3kigxNdRLKaAr+1dYz4KWH1wdyD1CMnFRvVYn5sWgy6dB04H/7L8 C++mtYypXE5noJI9q0ETGgJrochoeWa4l9Ixm/mSEKvwkdgFpuOcZdzRgnlwkXs6axLU ALG5uVU2qhMQiuw2UvRu3CTIAfgILNBgehe9Cioa2dwMjYuREwXWTm/uD6PoTYbVzXPo kdns6EhmNSM7bTYV8lh3E59CNMXHSw9Kf5AJRgaFncernrxGieHF2T9MMcFZkT63MWUb cxrQ== 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=OQgjSZQRlzjiLo1YVnL8nh2/OZv9aIw1g+yWU29w5So=; b=ZIzHo8WXgd/e7WvFKYiu0jljBx2YcVm3EOC8DJs4dNGGrL/bR4ESCLtoyGYcDGzE2l hBj1S61aOEHX7emrfwfxRflx7M7U2WAuMV7W6MgI/svBSxY2xFAVzmVFKUNHOT5hPPn3 Nu0SijmU12FqudHXFd7N1C1ZAAh4LPiHAXg0t8rY+QSOs9NlpSB9hcZOWzBHNPPcvy6K 62Hu6Q2wcHlU4abT7thqw2iUx9K48GSMzvWEp7+1/EpQ/kFggfIGK4F/gRBPNpRYz1R0 qVf3eiS6iUmo7QO63ifMnLPq3sNeULTp3X+iEq2T/rJ9ou0FXiPB/CSqPsKiNFQOtBfp hLeQ== X-Gm-Message-State: AElRT7Hy9NzkT16bAMQp8axSLf3vqxI1ImoNJGFCRNO3wo6ro7NAy3dI 4RDxVEPXbpI9RgE8i2bG8aHUZ+G5JQ4cKGrMlNc= X-Google-Smtp-Source: AIpwx4/iRRUBuhtgh46oWQmj71rodl0fQRBx1lcb50E6zk0Zaz7OhMgI9uA/54rqTsISpcWEJodyQBWczsT4U3XT32o= X-Received: by 2002:a9d:4a52:: with SMTP id d18-v6mr1490711otj.380.1522366182328; Thu, 29 Mar 2018 16:29:42 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Thu, 29 Mar 2018 16:29:41 -0700 (PDT) In-Reply-To: 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> From: Phillip Hallam-Baker Date: Thu, 29 Mar 2018 19:29:41 -0400 X-Google-Sender-Auth: LGnv7f4sN_EeWEylkktX5VZRXYc Message-ID: To: "Murray S. Kucherawy" Cc: denis bider , dcrup@ietf.org, "A. Schulze" Content-Type: multipart/alternative; boundary="000000000000840f270568957f22" 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, 29 Mar 2018 23:29:46 -0000 --000000000000840f270568957f22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2018 at 4:43 PM, Murray S. Kucherawy wrote: > On Thu, Mar 29, 2018 at 1:29 PM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> =E2=80=8B >> =E2=80=8B >> DKIM merely specifies an opaque blob which happens to be encoded as >> ASN.1 internally. =E2=80=8B >> >> k=3D Key type (plain-text; OPTIONAL, default is "rsa"). Signers and >> Verifiers MUST support the "rsa" key type. The "rsa" key type >> indicates that an ASN.1 DER-encoded [ITU-X660-1997 ] RSAPublicKey >> (see [RFC3447 ], Sections 3.1= and A.1.1) is being used= in the "p=3D" >> tag. (Note: the "p=3D" tag further encodes the value using the >> base64 algorithm.) Unrecognized key types MUST be ignored. >> >> >> Note that the specification of ASN.1 encoding is implicit in the >> algorithm tag. Other tags may specify different encodings. >> > > As I recall, we picked this because that's the format exported by the > openssl CLI for public RSA keys, and we were fine with that. What's > different with Ed25519 keys? > =E2=80=8BWhen it comes to standards, OpenSSL is a trailing, not a leading i= ndicator. JOSE, PKIX, S/MIME, everything requires the ability to export the key in the RFC 8032 format which involves no ASN.1. I would be astonished if OpenSSL did not support that. I try to use existing code implementations but I have my own super-structure that provides a means of applying keys in PKIX, JOSE, XMLDigSig etc. applications. This means that as a matter of course I have properties that expose: A The raw key blob =E2=80=8BB The raw key blob wrapped in SubjectKeyPublicInfo C The UDF fingerprint of the SubjectKeyPublicInfo To generate a DKIM RSA key blob, I use Base64 (A). To be consistent, the Ed25519 key should also be Base64 (A). --000000000000840f270568957f22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Ma= r 29, 2018 at 4:43 PM, Murray S. Kucherawy <superuser@gmail.com><= /span> wrote:
On Thu, Mar 29, 2018 at 1:29 PM, Phillip Hallam-Baker <phill@ha= llambaker.com> wrote:
=E2=80=8B
=E2=80=8B
DKIM=C2=A0mer= ely specifies an opaque blob which happens to be encoded as ASN.1 internall= y. =E2=80=8B

   k=3D Key type (plain-text; OPTIONAL, default is "=
;rsa").  Signers and
      Verifiers MUST support the "rsa" key type.  The "rsa&q=
uot; key type
      indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAP=
ublicKey
      (see [RFC3447], Sections 3.1 an=
d A.1.1) is being used in the "p=3D"
      tag.  (Note: the "p=3D" tag further encodes the value using=
 the
      base64 algorithm.)  Unrecognized key types MUST be ignored.

Note that the specification of ASN= .1 encoding is implicit in the algorithm tag. Other tags may specify differ= ent encodings.

As I recall, we picked this because that's the format exported by th= e openssl CLI for public RSA keys, and we were fine with that.=C2=A0 What&#= 39;s different with Ed25519 keys?
=
=E2=80=8BW= hen it comes to standards, OpenSSL is a trailing, not a leading indicator.<= /div>

JOSE, PKIX, S/MIME, every= thing requires the ability to export the key in the RFC 8032 format which i= nvolves no ASN.1. I would be astonished if OpenSSL did not support that.

I try to use existing code = implementations but I have my own super-structure that provides a means of = applying keys in PKIX, JOSE, XMLDigSig etc. applications. This means that a= s a matter of course I have properties that expose:

A The raw key blob
=E2=80=8BB The raw key blob wrapped in Subje= ctKeyPublicInfo
C The UDF fingerprint of the=C2=A0SubjectKeyPublicInfo

To generate a DKIM RSA key blob, = I use Base64 (A).

To be c= onsistent, the Ed25519 key should also be =C2=A0Base64 (A). =C2=A0
--000000000000840f270568957f22-- From nobody Fri Mar 30 00:42: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 4B718126B72 for ; Fri, 30 Mar 2018 00:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drymqoDhffSm for ; Fri, 30 Mar 2018 00:42:44 -0700 (PDT) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 AB946124D37 for ; Fri, 30 Mar 2018 00:42:43 -0700 (PDT) Received: by mail-qk0-x242.google.com with SMTP id s9so8421039qke.12 for ; Fri, 30 Mar 2018 00:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y3DfR7CTvvrj5QhB30wtHiZbUtjVWT4oaml6uMChV7M=; b=FqZtaRvWgGzZSYChdiq/Yo1usqLNwBo8el1wQGpngAmAkCAQM04RCGrE7DJgCHeKJh SkgAkIYIlsQlxF4oZhOFKTZiRxlFjVaiqbkNaK7zDWIpCtyS/HNCWyaZhzddYR2klCTZ T6AClOi2DrQPQdL6CZmrTohOVED24gZp6oYYm0SZUhoaADhPgssJm3IqA2yveUGLKuy/ 3AJHNZA80kKZdZBlDduM9LfPV6p6o+/CDnW4RVLtSaQFUuCSSTiae2pqLoxUs60xtMnN +bzOw9Dh3uGw7Thv6PLcANc1vQkV0nZTSn7im4bxN9bV4yOu5YXPpaMgeK0BGTBrdFrw wIbg== 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=y3DfR7CTvvrj5QhB30wtHiZbUtjVWT4oaml6uMChV7M=; b=DzAK27ntQJ+q/OiHPhLgwcCf9UJeA9UV1sc8+No+bnWvc2B05MEzFJeJYdolD7FdTO cc1Wm2UenH9onYRSBqa4X/R7nAVhxyDlQGyGl3i17lo5tH519QmJ3Rzq91draxcBBvyM G+u13tyV3nO30ADsYBq03ve27qLxTrtBYxXxgLeinQuvd5RHjvb0uA5n+RcpGJpbwPUx MDdvl7Atl9kLJsJBKLIHxUPj17+0eOi02r711ObuTpWXTw0fhT2AbTZDXCyTIeVkwyG/ 3uZnIZdoFT3EfIcOGT/o3XNrLNKvRR2J6qWQvG9uNhxN1IJ6Dx85XRA3Wbep/UvO5Ev3 1u+g== X-Gm-Message-State: ALQs6tAXNIgZarjFPqicnLsZ+Qu0dNOah5TD/IEpRZdq+4KISRvkRw/D m1lqdA/zXBGtpbnHlf7CweEPf3K3uxpxMB9YU4E= X-Google-Smtp-Source: AIpwx48MnJGIL/dVfyGTMk4W49ckiUetoVzmK+OylGX2eFgXPbTjdfztT3jfNWcwgE0iFx2QNs8AnDpm0VU0BlOhnNw= X-Received: by 10.55.43.234 with SMTP id r103mr15399468qkr.37.1522395762560; Fri, 30 Mar 2018 00:42:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Fri, 30 Mar 2018 00:42:41 -0700 (PDT) In-Reply-To: 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> From: denis bider Date: Fri, 30 Mar 2018 02:42:41 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: "A. Schulze" , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11496e50a2918605689c6267" 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, 30 Mar 2018 07:42:46 -0000 --001a11496e50a2918605689c6267 Content-Type: text/plain; charset="UTF-8" > ASN.1 is, whether we like it or not, the standard way > to marshal crypto objects between applications. Not so. It is standard for a limited selection of protocols, such as in TLS and X.509; but not others, such as SSH. It is standard with some algorithms, such as RSA and ECDSA; but not others, such as DH or Ed25519. It is standard with some libraries, such as OpenSSL, but not others, such as NaCl. > ASN.1 is, for better or worse, the way this is already > done in DKIM with RSA keys. Yes - *RSA* keys. You cannot safely assume that a DKIM signer or verifier has access to a general-purpose ASN.1 library. It's possible that a DKIM verifier uses one crypto library for RSA, and another for EdDSA. EdDSA typically does not come with ASN.1 support because it's designed to not need it. The library that the verifier uses for RSA may not expose ASN.1 primitives. It's possible that in a decade after EdDSA is added, a DKIM signer will not even want to, or have to, implement RSA keys. This means it would have no use for ASN.1 unless we add it now for EdDSA. This means you're: - Forcing DKIM verifiers to use a library that exposes ASN.1 primitives, or that wraps EdDSA with ASN.1. - Cajoling crypto libraries that implement EdDSA into supporting ASN.1 as a first-class encoding when it's not meant to be. > Having to explain that, in the DKIM context, "key type A is encoded with method 1, > key type B is encoded with method 2, key type C is ..." seems at odds with claims > of simplicity being mandatory. It's not difficult to explain. - An RSA key is encoded in the form generally intended for use with RSA. - An EdDSA key is encoded in the form generally intended for use with EdDSA. An RSA key is structured, so an encoding has been required since day 1 for implementations to be interoperable. At the time this decision was made, ASN.1 was the choice du jour, so that's the interoperable format for RSA. An EdDSA key is opaque, and already specifies its own encoding. It's intended to be the simplest possible. This is the interoperable format for EdDSA. It's not hard! On Thu, Mar 29, 2018 at 3:18 PM, Murray S. Kucherawy wrote: > On Thu, Mar 29, 2018 at 1:42 AM, denis bider > wrote: > >> instead of arguing about the lack of harm in including crud that is not >> necessary in this case, could you perhaps explain the COMPELLING NEED to >> include crud that is not necessary in this case? >> > > I thought I'd already done that, but I can re-summarize: > > 1) ASN.1 is, whether we like it or not, the standard way to marshal crypto > objects between applications. > > 2) ASN.1 is, for better or worse, the way this is already done in DKIM > with RSA keys. > > 3) Having to explain that, in the DKIM context, "key type A is encoded > with method 1, key type B is encoded with method 2, key type C is ..." > seems at odds with claims of simplicity being mandatory. > > Your suggestion violates the principle of parsimonious design. >> > > We are optimizing for different things. You're reducing bytes on the > wire; I'm reducing specification complexity and the need for a code branch > for each key type. > > >> This is that nothing unnecessary should be included. Can you form an >> argument about why this crud is NECESSARY, rather than expressing a >> preference for baroque decorations? >> > > As I believe I also already said, I have no particular affinity for ASN.1 > apart from consistency with what the security community, and indeed DKIM, > already does. > > -MSK > --001a11496e50a2918605689c6267 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0ASN.1 is, whether we = like it or not, the standard way
>= to marshal crypto objects between applications.

Not so.

=
It is standard for a limited selectio= n of protocols, such as in TLS and X.509; but not others, such as SSH.

It is standard with some algorithms, such as RSA and ECDSA;= but not others, such as DH or Ed25519.

It is standard wi= th some libraries, such as OpenSSL, but not others, such as NaCl.


>=C2=A0 ASN.1 is, for better or worse, the way this is a= lready
> done in DKIM with RSA keys.
Yes -=C2=A0= RSA keys.=

<= /div>
You cannot safely assume th= at a DKIM signer or verifier has access to a general-purpose ASN.1 library.=

<= /span>
It's possible that a = DKIM verifier uses one crypto library for RSA, and another for EdDSA. EdDSA= typically does not come with ASN.1 support because it's designed to no= t need it. The library that the verifier uses for RSA may not expose ASN.1 = primitives.

It's possibl= e that in a decade after EdDSA is added, a DKIM signer will not even want t= o, or have to, implement RSA keys. This means it would have no use for ASN.= 1 unless we add it now for EdDSA.

This means you&#= 39;re:

- F= orcing DKIM verifiers to use a library that exposes ASN.1 primitives, or th= at wraps EdDSA with ASN.1.

- Cajoling crypto = libraries that implement EdDSA into supporting ASN.1 as a first-class encod= ing when it's not meant to be.


>=C2=A0 Having to explain that, in the DKIM context, &qu= ot;key type A is encoded with method 1,
> key type B is encoded= with method 2, key type C is ..." seems at odds with claims
= > of simplicity being mandatory.

It's not difficult to explain.

- A= n RSA key is encoded in the form generally intended for use with RSA.

- An EdDSA key is encoded in the form generally intended for u= se with EdDSA.

An RSA key is structured, so an encoding h= as been required since day 1 for implementations to be interoperable. At th= e time this decision was made, ASN.1 was the choice du jour, so that's = the interoperable format for RSA.

An EdDSA key is o= paque, and already specifies its own encoding. It's intended to be the = simplest possible. This is the interoperable format for EdDSA.
=

It's not hard!



On Thu, Mar 29= , 2018 at 3:18 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Thu, Mar 29, 2018 at 1:42 AM, denis bider <denisbider.ietf@g= mail.com> wrote:
instead of arguing about the lack of harm in including crud that = is not necessary in this case, could you perhaps explain the COMPELLING NEE= D to include crud that is not necessary in this case?

I thought I'd already done that, but I can re-s= ummarize:

1) ASN.1 is, whether we like it or not, the sta= ndard way to marshal crypto objects between applications.

2) ASN.1 is, for better or worse, the way this is already done in DKIM wit= h RSA keys.

3) Having to explain that, in the DKIM contex= t, "key type A is encoded with method 1, key type B is encoded with me= thod 2, key type C is ..." seems at odds with claims of simplicity bei= ng mandatory.

=
Your suggestion violates the principle of parsimoniou= s design.

We are opt= imizing for different things.=C2=A0 You're reducing bytes on the wire; = I'm reducing specification complexity and the need for a code branch fo= r each key type.
=C2=A0
This is that nothing unnecessary should be i= ncluded. Can you form an argument about why this crud is NECESSARY, rather = than expressing a preference for baroque decorations?

As I believe I also already said, I have no p= articular affinity for ASN.1 apart from consistency with what the security = community, and indeed DKIM, already does.

-MSK

--001a11496e50a2918605689c6267-- From nobody Fri Mar 30 01:02: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 28F49120727 for ; Fri, 30 Mar 2018 01:02:00 -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 4RXHyBcJWz80 for ; Fri, 30 Mar 2018 01:01:58 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EC21200E5 for ; Fri, 30 Mar 2018 01:01:58 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id o184so8448570qkd.13 for ; Fri, 30 Mar 2018 01:01:58 -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=9Eh0kikrcgOYif4Ld42+fe9XViqsQaegNrIG8gq/F/0=; b=do4Upt0YblzRG5fFRHpukx0fJs7Sg7+R4Ixt6hzrLjJre1zkuyBvnhd28B7Cl4eaNw zmJBCuE6Jnlj8w5+8P9b2wMFWYcB4IEHnBag5gBjf/0pOizoUH1ybknGRcTf5wY0XX6L Qd1J3/JNcG2XrwbpLsIBqqLHFSpDVm8IUs+wGMz7erp+a+VNlz7ctG0TzgYdIPoeJ4Xp tLm9jO5Z55+07MydG++hIltwNu5jzeAson/o7AoKZe3k4okeRDmdqiDno4LzwxnVO03c iITSuBi70T8oC47Ps5PPVhhjBZ/HA/IPvTOw4UG5aA3t4rbad7LYL4AU1s4UsepKlmWW fOVQ== 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=9Eh0kikrcgOYif4Ld42+fe9XViqsQaegNrIG8gq/F/0=; b=QZv96gdiKW+NOA9zPzXs8xS4O4/Ln3RhxN2z2jZWTltD/Gg3bv0wNgfvNWhLCq/4Cy Wqym5Vu5N/RtLR4bG8kMJLo8EuAe284CMOJpkYlKmv9/uG5sekFIo+Z2EtF9TLR+mQUo m6BbWWYOAgMpwDZjD4zPQfH9r/nQ7dsVswx0jLr3hOSmFTUlGRd/vAkT8w4bdaXpQlkY f5j1nKQlK0q+bwQflNi5Wn4JQPPcx8PuKyZXAZQzjLkmAHElVb9/XQsfhiLrHdVPd/+7 cxZCGHIPf8wg25xal0qhmh8k7YecQhCefOjBti0NOFM9UYbKo8TPNWmNlz+Qq4qr3IEu mDkw== X-Gm-Message-State: ALQs6tB61/OULp6z5iH4X+yDToZq1M+Gfg6JZcA20D3uCx1xyicb3H/J gmnFmzdSrfwPgfG0lziZsCkblg3uoWIC90NNYuQ= X-Google-Smtp-Source: AIpwx49NZrmluw6bQKN/nG7yFUx3YrjCVXjfbmCpRAgI7lxvWT27+9QDdEKrqwEQnFcHMIAChECIk+NFOYTY/eTMZz8= X-Received: by 10.55.107.70 with SMTP id g67mr15543184qkc.105.1522396917593; Fri, 30 Mar 2018 01:01:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.146 with HTTP; Fri, 30 Mar 2018 01:01:57 -0700 (PDT) In-Reply-To: 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> From: denis bider Date: Fri, 30 Mar 2018 03:01:57 -0500 Message-ID: To: "Salz, Rich" Cc: "Murray S. Kucherawy" , Phillip Hallam-Baker , "dcrup@ietf.org" , "A. Schulze" Content-Type: multipart/alternative; boundary="001a114873f27afca805689ca714" 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, 30 Mar 2018 08:02:00 -0000 --001a114873f27afca805689ca714 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "Popular toolkits" is both too generic and too generous. Let us name the toolkits in question. 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. This kind of push is the result of an assumption that "everyone" uses (insert project), and therefore everyone should dance the way (insert project) makes it easy to dance. There's no consideration for what fundamentally makes sense, or what's convenient for people on other systems= . On Windows, one might use Windows CNG for RSA, and an external library for EdDSA. To wrap an EdDSA key in ASN.1 may mean writing hundreds of lines of DER encoding and BER decoding code, which is hundreds of lines of opportunity for bugs. Imposing this on other implementations simply because OpenSSL users would find this slightly more convenient is not cool. Not to mention it fundamentally does not make sense if viewing the protocol in a way that's implementation agnostic! On Thu, Mar 29, 2018 at 3:54 PM, Salz, Rich wrote: > As I said before, popular toolkits do the ASN1/DER wrapping. > > > > Let=E2=80=99s try to keep personalities out of this, please. > > > --001a114873f27afca805689ca714 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"Popular toolkits" is both too generic and too g= enerous. Let us name the toolkits in question.

The toolk= it in question is OpenSSL, and this push is an example of the open source c= ommunity assuming it is the end-all and be-all of all things.
This kind of push is the result of an assumption that "eve= ryone" uses (insert project), and therefore everyone should dance the = way (insert project) makes it easy to dance. There's no consideration f= or what fundamentally makes sense, or what's convenient for people on o= ther systems.

On Windows, one might use Windows CN= G for RSA, and an external library for EdDSA. To wrap an EdDSA key in ASN.1= may mean writing hundreds of lines of DER encoding and BER decoding code, = which is hundreds of lines of opportunity for bugs.

Imposing this on other implementations simply because OpenSSL users would= find this slightly more convenient is not cool. Not to mention it fundamen= tally does not make sense if viewing the protocol in a way that's imple= mentation agnostic!




On Thu, Mar 29, = 2018 at 3:54 PM, Salz, Rich <rsalz@akamai.com> wrote:

As I said before, popular toolkits do the ASN1/DER w= rapping.

=C2=A0

Let=E2=80=99s try to keep personalities out of this,= please.


--001a114873f27afca805689ca714-- From nobody Fri Mar 30 05:06: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 F3DE8126D73 for ; Fri, 30 Mar 2018 05:05:59 -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 q_lE2NDkN2Hk for ; Fri, 30 Mar 2018 05:05:58 -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 7B2C7126BFD for ; Fri, 30 Mar 2018 05:05:58 -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 w2UC36sx000556; Fri, 30 Mar 2018 13:05:31 +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=rBwbZBh/QbNEE+YmdoomU1xRW4fh5ZBRyB7uqJ2wR5c=; b=BMyyJ/dQ12x5geM7ucOkH9SOWP0fwI3739do+ncsmJ1cimpKnKJ3F+9oZ5KIQZd+gJVg FW/ahbBxlRzDMK4lxzKugdXa7zWweD6b0SeuDSwpRmeF7PMaCEsZwVX+uOwIZDhPdYIL cszPY5fH2Zwoc6yokhrydzCpKbT3iXbJMrjJ3SbpJsjm+iyYTd+Ws7dnzBOKTiZQ1DR3 WNTeIa/oC1aCxrn/UjoSzqqiEo3Qp7AxVdpMopQ35gTA5j/Aw5VJZAftrXi2SK/3tUA5 /rh+KzW+eJkpBltfjlfMEx0eLs94oF0z/pit32PkbF0HslaYDTIzGlGgZa2RsGhp5vC9 +g== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2h09kanx4m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Mar 2018 13:05:30 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w2UC18L6027828; Fri, 30 Mar 2018 08:05:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2gwj0vufpd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 30 Mar 2018 08:05:29 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 30 Mar 2018 08:05:28 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Fri, 30 Mar 2018 08:05:29 -0400 From: "Salz, Rich" To: denis bider CC: "Murray S. Kucherawy" , Phillip Hallam-Baker , "dcrup@ietf.org" , "A. Schulze" Thread-Topic: [Dcrup] ed25519 in DNS Thread-Index: AQHTwELMBQuIVyAaXkGxq4oyoJ8nq6PZYOKAgAt2FYCAAC7BgIAAQpyAgAAPcgCAABGngIAADquAgAAcPACAAYtmgIAAFqwAgADCToCAAAMNAIAABiyA//+9z4CAAP2LgIAAAPwA Date: Fri, 30 Mar 2018 12:05:28 +0000 Message-ID: <2897E6E0-4535-4EC1-9686-E080CCA82D21@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> 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.37.62] Content-Type: multipart/alternative; boundary="_000_2897E6E045354EC19686E080CCA82D21akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-30_05:, , 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=739 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803300126 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-30_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=684 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803300126 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, 30 Mar 2018 12:06:00 -0000 --_000_2897E6E045354EC19686E080CCA82D21akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgVGhlIHRvb2xraXQgaW4gcXVlc3Rpb24gaXMgT3BlblNTTCwgYW5kIHRoaXMgcHVzaCBp cyBhbiBleGFtcGxlIG9mIHRoZSBvcGVuIHNvdXJjZSBjb21tdW5pdHkgYXNzdW1pbmcgaXQgaXMg dGhlIGVuZC1hbGwgYW5kIGJlLWFsbCBvZiBhbGwgdGhpbmdzLg0KDQpJIHdhc27igJl0IHRyeWlu ZyB0byBwdXNoIGFueXRoaW5nLCBzb3JyeSBpZiBpdCBjYW1lIGFjcm9zcyB0aGF0IHdheS4NCg0K V2Ugd2lsbCBoYXZlIHRvIGhhdmUgYSBjb25zZW5zdXMgZGVjaXNpb24gb24gdGhpcy4gIExldOKA mXMgbGV0IHRoZSBkaXNjdXNzaW9uIHJ1biBmb3IgYSBmZXcgbW9yZSBkYXlzLiAgSWYgeW91IGhh dmUgYW55dGhpbmcgbmV3IHRvIG1lbnRpb24sIHBsZWFzZSBzcGVhayB1cC4gIE90aGVyd2lzZSBp dCBzZWVtcyB0byBtZSB0aGF0IHRoZSBjaG9pY2Ugd2lsbCBiZQ0KICAgICAgICAgICAgICAgIEFT TjEvREVSIHdyYXAgdGhlIEVkMjU1MTkga2V5DQogICAgICAgICAgICAgICAgSnVzdCB0aGUga2V5 IHdpdGhvdXQgd3JhcHBpbmcuDQoNCg== --_000_2897E6E045354EC19686E080CCA82D21akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <8B124BAA9384BF4593E32B74EBD1659B@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 YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMzA0Mzg3MzUyOw0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozOTYwMTg5NzQgMjQ0NzczNTY2IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTc0 NzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OY Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYW5zaS1m b250LXdlaWdodDpib2xkO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxhIG5hbWU9Il9NYWls T3JpZ2luYWxCb2R5Ij5UaGUgdG9vbGtpdCBpbiBxdWVzdGlvbiBpcyBPcGVuU1NMLCBhbmQgdGhp cyBwdXNoIGlzIGFuIGV4YW1wbGUgb2YgdGhlIG9wZW4gc291cmNlIGNvbW11bml0eSBhc3N1bWlu ZyBpdCBpcyB0aGUgZW5kLWFsbCBhbmQgYmUtYWxsIG9mIGFsbCB0aGluZ3MuPG86cD48L286cD48 L2E+PC9saT48L3VsPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPkkgd2FzbuKAmXQgdHJ5aW5nIHRvIHB1c2ggYW55dGhpbmcsIHNvcnJ5IGlm IGl0IGNhbWUgYWNyb3NzIHRoYXQgd2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPldlIHdpbGwgaGF2ZSB0byBo YXZlIGEgY29uc2Vuc3VzIGRlY2lzaW9uIG9uIHRoaXMuJm5ic3A7IExldOKAmXMgbGV0IHRoZSBk aXNjdXNzaW9uIHJ1biBmb3IgYSBmZXcgbW9yZSBkYXlzLiZuYnNwOyBJZiB5b3UgaGF2ZSBhbnl0 aGluZyBuZXcgdG8gbWVudGlvbiwgcGxlYXNlIHNwZWFrIHVwLiZuYnNwOyBPdGhlcndpc2UgaXQg c2VlbXMgdG8gbWUgdGhhdCB0aGUNCiBjaG9pY2Ugd2lsbCBiZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBU04xL0RFUiB3 cmFwIHRoZSBFZDI1NTE5IGtleTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKdXN0IHRoZSBrZXkgd2l0aG91dCB3cmFwcGlu Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2897E6E045354EC19686E080CCA82D21akamaicom_-- From nobody Fri Mar 30 07:20: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 4CA3D127023 for ; Fri, 30 Mar 2018 07:20:13 -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 HPsVu8xYk0Qa for ; Fri, 30 Mar 2018 07:20:11 -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 AAF0B126DCA for ; Fri, 30 Mar 2018 07:20:11 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id m22-v6so9659505otf.10 for ; Fri, 30 Mar 2018 07:20:11 -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=aJa7vdaM4lLIM3QWp56l1+OrODBWHmRq7i+g4LrGyGM=; b=IbCDejYBim6cAM3n6+PjCvA+nQjFymIeacTXPmcRg6VbbPeo2X9DOt3IdcnL4sBHas XIOVBM08wluLLh9iURKvc3wDtl8aNUOAX61kzS74gNwy+6mK1IT3tcKqEtuCAlKhHbAd R+JQzjDhvSlAsVPvRxlCOQ+mzP8++5Dg9yJ7rbklGXHAwj6C/jC0h3yr2yWm6dwBXO48 2QRV4Lkl+cMBgSkw0kXitfoGpGjW0L+fiaS+aVFDesqDt74mrsgC2SegVnRCd6mtcfQi l9MHA1hhjqz1VKJg+8I3g/vaitYwssXG1hRQHTWyE3ItN2eT1oMyfyWDs6qZqqGSE1AF 4nFQ== 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=aJa7vdaM4lLIM3QWp56l1+OrODBWHmRq7i+g4LrGyGM=; b=HOQ6UVXUV7WzDOqLLtTgNYwy2xs5UmzsDJjs2+b6uZIVsMaFYmS4hQm2TY5H4BS9LW vdcKsgsCpJrDGVYXl/O3HzG79+VMViIhaPT5p71dbV0egsfRVpfwAXBb6g3CbBET21Um T8fJT/EXZb1jhSSiAf7FNJlX6Vi5RBr0nbwqRycFEovstpocL2+0wjPc5bC8xNP3T39e Q3JqqQK7hwNpz1dYFIxi/q28K5d49X3TIUwnpt/YAEvhAqpG1cPb2UDB3GfQFUnWQykM lpm7brS797sJLIyAYowJPcU8kKBwvDkNBU9rcw3eyrgigOrhaVv+aVompOMTpXYrgt3J 7tZw== X-Gm-Message-State: AElRT7EtKvLmc88k5nch5sJAfsg/m1DznNCUwmPNUYuL+nw8JHF0hexB iSUzKEwat9vDKIS6LtfwpIE8AFZ7/xpN/E4u79g= X-Google-Smtp-Source: AIpwx4+PQ8cWop6KZMxg+CCRyFovIfkS+9VoKhkOhU9fnxNRVwJZAK4PtEtuEcmagb8Vnpp+IcU8hSBD0QIz9jIPCsY= X-Received: by 2002:a9d:282f:: with SMTP id m44-v6mr7079319otb.218.1522419610982; Fri, 30 Mar 2018 07:20:10 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Fri, 30 Mar 2018 07:20:10 -0700 (PDT) In-Reply-To: <2897E6E0-4535-4EC1-9686-E080CCA82D21@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> From: Phillip Hallam-Baker Date: Fri, 30 Mar 2018 10:20:10 -0400 X-Google-Sender-Auth: cnM4b7SoP-e08zyxdbQYRzkDvgY Message-ID: To: "Salz, Rich" Cc: denis bider , "Murray S. Kucherawy" , "dcrup@ietf.org" , "A. Schulze" Content-Type: multipart/alternative; boundary="0000000000001c9e800568a1f039" 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, 30 Mar 2018 14:20:13 -0000 --0000000000001c9e800568a1f039 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 30, 2018 at 8:05 AM, Salz, Rich wrote: > > We will have to have a consensus decision on this. Let=E2=80=99s 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. > =E2=80=8BWe did discuss this at length when we =E2=80=8Bwrote RFC8032. To get to clarity, I suggest that we STOP talking about ASN1/DER wrap and instead talk about what is being proposed, a SubjectPublicKeyInfo wrap. RSA Public keys are encoded in a RSAPublic structure to create a binary blob. Ed25519 Keys are encoded as a BigNum + sign bit to create a binary blob. DKIM does not wrap the RSAPublic structure in a SubjectPublicKeyInfo wrapper so to do so for Ed25519 is inconsistent. PKIX wraps RSAPublic and Ed25519 keys in a SubjectPublicKeyInfo wrapper The point I am making here is that the PKIX ASN.1 has an intentional break in the encoding. It is not correct to say that the RSA Public key is encoded in ASN.1 in PKIX, it is actually encoded as a binary blob whose encoding is specified by the embedded OID. =E2=80=8BThis is distinct from the way we encode RSA public keys in JSON an= d XML Dig Sig where we do express the parameters directly. The structure of a SubjectPublicKeyInfo is essentially no different from alg=3D"RSA", key=3D"ekfFwLDhPiM79vAazmy71v1FdOMLcVTZ...". It is the ASN.1 version of {id, base64(value)}. And as far as OpenSSL goes, the question is not whether it can emit Ed25519 keys in a SubjectPublicKeyInfo wrapper, it is whether it can emit the RFC80= 32 encoding which it needs to in order to support JOSE etc. Every implementation of RFC8032 must implement the raw encoding because it is an essential part of the spec. Only those libraries that support PKIX based protocols require SubjectPublicKeyInfo --0000000000001c9e800568a1f039 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 30, 2018 at 8:05 AM, Salz, Rich <rsalz@akamai.com> wr= ote:
<= div class=3D"gmail-m_3948687753944443281m_-2242841709830444733WordSection1"= >

We will have to have a consensus decision on t= his.=C2=A0 Let=E2=80=99s let the discussion run for a few more days.=C2=A0 = If you have anything new to mention, please speak up.=C2=A0 Otherwise it se= ems to me that the choice will be

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ASN1/DER wrap the Ed25519 key=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Just the key without wrapping= .=C2=A0


=E2=80=8BWe did discuss this at length = when we =E2=80=8Bwrote RFC8032.

To get to clarity, I suggest that we STOP talking about ASN1/DER wra= p and instead talk about what is being proposed, a SubjectPublicKeyInfo wra= p.=C2=A0

RSA Public keys = are encoded in a RSAPublic structure to create a binary blob.
Ed25519 Keys are encoded as = a BigNum + sign bit to create a binary blob.

DKIM does not wrap the=C2=A0= RSAPublic structure in a=C2=A0SubjectPublicKeyInf= o wrapper so to do so for=C2=A0Ed25519 is inconsi= stent.

PKIX wraps=C2=A0RSAPub= lic and=C2=A0Ed25519 keys in a=C2=A0SubjectPublicKeyInfo wrapper


The point I am making here is that the PKIX ASN.1 has an intentional = break in the encoding. It is not correct to say that the RSA Public key is = encoded in ASN.1 in PKIX, it is actually encoded as a binary blob whose enc= oding is specified by the embedded OID.

=E2=80= =8BThis is distinct from the way we encode RSA public keys in JSON and XML = Dig Sig where we do express the parameters directly.

The structure of a=C2=A0 SubjectPublicKeyInfo=C2=A0 is essentially n= o different from alg=3D"RSA", key=3D"ekfFwLDhP= iM79vAazmy71v1FdOMLcVTZ...". It is the= ASN.1 version of {id, base64(value)}.


And as far as OpenSSL goes, the question is not whether it can e= mit Ed25519 keys in a=C2=A0SubjectPublicKeyInfo wrapper, it is whether it can emit the=C2= =A0RFC8032 encoding which it needs to in order to= support JOSE etc.

<= /span>
<= span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:sm= all;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norma= l;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;te= xt-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(= 255,255,255);text-decoration-style:initial;text-decoration-color:initial;fl= oat:none;display:inline">Every implementation of= =C2=A0RFC8032 must implement the raw encoding bec= ause it is an essential part of the spec. Only those libraries that support= PKIX based protocols require=C2=A0 SubjectPublicKeyInfo=C2=A0

--0000000000001c9e800568a1f039-- From nobody Fri Mar 30 08:55: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 CA83D1241F8 for ; Fri, 30 Mar 2018 08:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jv5Q345xpdRW for ; Fri, 30 Mar 2018 08:55:06 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 D575F120454 for ; Fri, 30 Mar 2018 08:55:05 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2UFoTtL021571; Fri, 30 Mar 2018 08:54:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : date : message-id : sender : mime-version : content-type; s=PPS1017; bh=cKgIfGU6TYRhRZlhMft83UoYXQitW+t9O08eSTS65K8=; b=QOt7LcRzEES0TZdYm/PJKW+2ucqj2nx1oonR9+b75/JttCR/zqWlT2oQtYh78x8yK2KT k/EfSxmyu3NgKwoIhYwW6yDxH4cnVVHMX+Ts0+I6BD/vBqwDUV2ZVvj2eciQitMT85Xo Sbu4DDU2tzUCEOyxXtdPsrSdx2Ux1SXHv57LZr03mVzgaWhwoYGQSbdKAAsu9uLLoXJW vrlcY733d+3rZIL3PQtaVg1Df3zU3QEecheuz9D0eAqfypWv+1LxGs4QErpKqXCo/TWx LgjC9ekSle4/YaImMrAs8IQL54gdYZFwZeB8HFdvUULgaWwrvD1IJSugV4TBkL7OB0km UA== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0086.outbound.protection.outlook.com [207.46.163.86]) by mx0b-00273201.pphosted.com with ESMTP id 2h1nt0g91d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 30 Mar 2018 08:54:46 -0700 Received: from CO2PR05CA0093.namprd05.prod.outlook.com (2603:10b6:104:1::19) by CY4PR05MB3672.namprd05.prod.outlook.com (2603:10b6:910:5b::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.5; Fri, 30 Mar 2018 15:54:44 +0000 Received: from BY2NAM05FT015.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::204) by CO2PR05CA0093.outlook.office365.com (2603:10b6:104:1::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.653.5 via Frontend Transport; Fri, 30 Mar 2018 15:54:44 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT015.mail.protection.outlook.com (10.152.100.152) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.631.2 via Frontend Transport; Fri, 30 Mar 2018 15:54:44 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 30 Mar 2018 08:54:43 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id w2UFsaa1009816; Fri, 30 Mar 2018 08:54:36 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 5D3EC1144E; Fri, 30 Mar 2018 08:54:36 -0700 (PDT) To: "Salz, Rich" CC: denis bider , "dcrup@ietf.org" , Phillip Hallam-Baker , "Murray S. Kucherawy" , "A. Schulze" In-Reply-To: <2897E6E0-4535-4EC1-9686-E080CCA82D21@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> Comments: In-reply-to: "Salz, Rich" message dated "Fri, 30 Mar 2018 12:05:28 -0000." From: "Mark D. Baushke" Date: Fri, 30 Mar 2018 08:54:36 -0700 Message-ID: <52970.1522425276@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(39380400002)(346002)(2980300002)(199004)(189003)(6392003)(4326008)(6246003)(446003)(53416004)(76506005)(105596002)(117636001)(106466001)(54906003)(39060400002)(16586007)(478600001)(48376002)(316002)(7126003)(558084003)(50466002)(5660300001)(11346002)(76176011)(4743002)(6266002)(356003)(186003)(7846003)(6916009)(305945005)(26005)(77096007)(97736004)(486005)(229853002)(336012)(53936002)(51416003)(476003)(7696005)(426003)(486005)(126002)(55016002)(81156014)(81166006)(69596002)(8936002)(93886005)(8676002)(68736007)(2906002)(97876018)(86362001)(47776003)(2810700001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3672; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT015; 1:CHDepXVZStN4oZtJor++mL8ZLP6k14i1fdu9qEDXvtQerWSDNjZWqHTdYWHdE9gOnOkMt+RfYkBcY3NVzAZti4nZygOJYauYgUcwqH24nvOMPeJyGrGElBlOBmmEBvYP X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4176d060-8f73-453c-f30f-08d596568eb0 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060); SRVR:CY4PR05MB3672; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3672; 3:hxcyIQ4KhNp/+NXm7aSyjOLwI2YccNPQMRr+cmR/p1HQzgn+9zG/2+MwjV5F7E2k08TAri5xud38g+QgHEcBxuHpKfkuVkatVSvExVuXMNzV7+/xxEsLxHXeejz8ca1/DRpKcKI2sOJV6tn1va7wxTqMxOBLOKs02qtv4MV09D+Xwt79nKlp4aeSoKMcYoxlygkyHEl13tnKjgW1DvWxSYgVR52oFYv8SqcDJW5WaOp2Vqbn4sMmY0hzJa5gt1bakCNMlbuX5OAMYT/TKdBUMOFaIGRBI2GB3Mzpa3IeSA8GM27QOop+wqR9VcG0pWDRIYF7SCDeH7FsTGiSALCev5ECbMlGiqARDRIfv36vz4k=; 25:/xNInEYrmGC51QfLmwU074m9Vjuf/QQOo4C6xI4+tGdToeKiBfZ02BucfTRR3tQq24nqqjHOwfbCQF0MX/zDhgNQ7fufb1/JjU+ABNLQZkCvBHlXJdrKGqPTbpr9T/LRY3DEj2UzP6xhAvVYkW/Vbt5uh5R79zYvZLk47rua3r3E8VhLyt+LBnezb9omZSsBZqMGRtYXlD595yX8TQlGcLq3AQhJGn314Cko3dO+y/3siQzVG4K6ky1vIY0JPWxG9RivDT3x73nXdJKYln41Cy8E2MWvgJT7/uJkdK76rlvtt/wJ8bgAt2eP4KBP8a26N7TPuNItMjLIGJpUqToCIw== X-MS-TrafficTypeDiagnostic: CY4PR05MB3672: X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3672; 31:UCTUsAT8DHgrzPOcJcVQCeGexZBehw2aP5oZqc/hf1XGVl1dlJVcjheZG51WR1RWaA2iq2r1Gzbbde2q8Mrl/fapPuiYfRp/SkABhYmM9tsneuZDBqu3juKzRXGDmEGqiJdXA1RNfA1x9zlMeyKUf6F5vDUHXzI+tfWffDEFzHw1r0qH2ylFWoVA49p9n+h5PzFKMVU0cmlIyGIq/E3yKWxsxm5rAyhUTTCO5aOC0N4=; 20:a5FtARdBXjX8Ozkv2nNdgQ705JUcwuB19Ct2xkXMfWMHqcfbCK/tjRXAUq1ku3SEvH6vPL8hoaa98W06b5UKB0ZjKxMM3dSUbUNUqLYXBaN5JGS42W6YR2ogM9dWqlaP8YenyGiAN3t72t5gfd7fsAuCHde+3KWt1awtkdEkNMhRb1KKiLQNlnVvpnsQAAFV40OQ1LcLYp8tI4Vs6BHqrmat8f5bmpUwmKyigpicdlrl3dJ1xtW8QnnKhLdEwgpQIVaQb+n1tdKQNBH7k4VbLSsSYeEOxTytLFrNXKWbQDyWw/IvUg0IIEDruqPyQ5ZN/DUtGs7O0SgkpHXFRLm1brudLyMv4bCPW4kBqxYn/+phzu0c4DQNusajMM5lUyGyEmeMF1WsUKEkM5H+AbEFj76StpTuPtknmyJtIV4nqKJzfBpZ2wqAk2bgxLrF5IVbKHSWNFyPIIGNZ3FrVXGA/YTikRrqld3mAYMK29h6AnmiUOlOGYGJ+z5K8Im1ORH6 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93003095)(3002001)(10201501046)(3231221)(944501327)(52105095)(6055026)(6041310)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR05MB3672; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3672; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3672; 4:QfvC+QRSbQmNc47WI3BE/ZSPbQ3OqwpNl+99mDZ7v6Zy7fh1IKJgzfKYs8nm9jOvhBx3Xpghwa6XpS5356umU5l2FE+8V89EjO6wg6Xmrc5xOftxdqxXMS+GTZzJ4z9/OK7Bwg3oKwCPYt2DyNMdrxY+nlbXYDR95VHDkFoqnQIp6FsJB985wjXy6py1BNrAP63cDpPA2TmDcf5IWJ8WZgiMdhN2xlSv6bKpiRAJvDtcOihw2QN8vA/Ftne2/IMgUynuprQ5w0qacT3/2i4ENA== X-Forefront-PRVS: 06274D1C43 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB3672; 23:HYxrA5CKnViLmV6Lb9aDpCzGuc/QKn33xDrna68mz?= =?us-ascii?Q?bNib0SozbphqSSxklkWLmSL/I16/i9YFeCnElVWvICYp+v6Z7tXYNPO1pzdH?= =?us-ascii?Q?3kbq9fn0H0M5+BcLrT4Rksp+qWVMaqaP403oEnJBOmie/dENsXAevkfxS+7s?= =?us-ascii?Q?vaS9Ulxvi1AZDCNteDIrMRGr/gHJK8hSioHm2THrEYr+hibkpY/lyZsQbwSR?= =?us-ascii?Q?9/JF1coR12J3IUFvKkOHNNTE8gX3eqtHJKDFoRhgvFDJTIK7nxQ3e6o8rx7J?= =?us-ascii?Q?nIHiUaE7j86Jd5nSwXhcFoCCxis/1QkKIVEHFqi5AE6tQMt/6eMm8XUaILoP?= =?us-ascii?Q?ONc3Th2UGs5ARV0YtXGf3zmQUXncmCQDhsCJwi4RjVc+rR8Q+uHsOHImfTLh?= =?us-ascii?Q?qB+EZK+07Nc9dTEju+96NszXt2nozETDLNlp+dV4vC6Y0fPkJ2VIIteLPtxa?= =?us-ascii?Q?Pbph6eFLH1hPaIHVQXbs5uhIQTjzEVqEzJPCIi8Bry+KZCO52BQL9KQjs3aJ?= =?us-ascii?Q?1hbIsmsu4vb3KyOGqp9QtWBDIrWerz932aREdq2wAMFuga+bkzn49pS4kiOm?= =?us-ascii?Q?mjrBzQSZA+MPxTmafLVolZqELeTtywm+QFPN/9bPnj5hOJ0KhMRfd8rMdRM1?= =?us-ascii?Q?/prpzFZ9hwxJh0JE64L5X3PNBDzoocBa0GkuZeWC3SgB3SosUCq0kcPDZlfj?= =?us-ascii?Q?I/amiTLjhWBOAkEbxUEIc/LvnrWgTUyGQUB7/KLtEIB1fQGHenWziZ1dC//Q?= =?us-ascii?Q?3u98x1JrNuPObdk76LrKcKuDoJ0gMBy0kAGOCyO8ldvAvXAuPkQCpDL2F0FC?= =?us-ascii?Q?XrQorN4L7qREMkbNCCLDWOawXXBL7NGp53X0PN2OVBzUNR0eiY4QvTgbzoEb?= =?us-ascii?Q?E0kEhhsTnb+VsahAbBvHfwd91VbAm70dbsnxj9qH8Tr1BNBhPVC2v/tq1tBk?= =?us-ascii?Q?cyIbBbE35OxrKCuTnmCn6XLHBycQUufiDibjxqOhQASJgSsKCiwX5EMWJd5/?= =?us-ascii?Q?dcf5y9eQg2cBjczDOMps8Pi3tOz1DPuV5d6E6WEgItvKmcIz0KIbzxya1jN7?= =?us-ascii?Q?Db+M1NrAugVRH1czZ4IfgBrAGGtCra64Mj2Yq5yFJlSWXmpNOoWcooJ8G5fm?= =?us-ascii?Q?XrO97byCylqgxZgMXMS5a96FoP5rc6lKTj8Z3KCiKleLl3PiI/2Kl7+BnaJ3?= =?us-ascii?Q?K+sj2aXWFBbf11EZhut4DvUIdCsFBac7a2OcUzzZbHfR4Vyg+oQHL7a1lROO?= =?us-ascii?Q?OjzQL8HV+L7Zho/iqKzdvQPXSYV1GMyFl+KV+GLWbq7caGBBeQ7kIJEhFiwk?= =?us-ascii?Q?FGNaFRhLX8T6YQ5zrEUIhtSg8MFwPtFD6opTe+USnui1sM2v6o11DKHkUuEd?= =?us-ascii?Q?6eSLShDTMW9N5VnIzkDe1uyjnha1JhHhyZvoF6ddbnCY02E?= X-Microsoft-Antispam-Message-Info: /xBFhmzlwMcPkBkZZokE36NCCBPWdYHsz+i8qDqgpTwNCbXE/ckrHzcvaVW+1+1GDIs2eSUzxFM8JjPu1F1PZalVf9svIRtBMMbIHqD4SwRr2wCzcpBxe8do5qlKheVu1gmMFtk54WP/aEjFAKfza2SxnHuK/IWtKciqXz2/dlXlV0w5YIZw4d8jim/2NXun X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3672; 6:61jaROg7VDExk7jB71ONnu9oa/xu5Kg+S60VrCX3WXpBpsaLmiJ/51Xljd8JAA5i8wL6mkt4gPhTjU1VNm7AguweXLPPrTx1+RwSLI1USm1emRm8RHBBZukwCa0OFzUfz2CVmQci66iD+CKJHD6fgq3kdQc2viHYRcth5QNJrysk9RBBpuUFSDCM5HcC/RGA0Ck5u2+vMOiC/cc/XT1rtvzKDu+pPUSl3qzZBsuw7S58U2kSRKKkSi4Bb8CLI3McFf1j1qe0a76HZ1rxcesL4DsfZ/W0ny/jN1O1C6XL8RlYJiQnWWZCqVXaL215P+ffmz3kZ8ifyXtjvA6Ns+cb2Dk+JLg6NtE+v5gUSov6K6HURzvqpTlUTTuXP7hDKbwGd/VJ67t+rgPaQ4Q0HU/dqFyGnI50nYkeqCpaOk4keOMdGN8rhFefL2iD5klboIkto36OIr8slOJcCj1q3+BOew==; 5:X+LCZfl1dtTpAlcQjiKD9mvI5dBQc2KVnBRAefD0eNpAZybKNeHMLy6XNDnCCpzvcrLxodj66ZP3WJOzwAZ93IV32ECv/gqCLwgQntifbv2yGoOtZnDD+iGWvCVdsiIOSwzoVnKA+Y600SMyqhjIjwn80eDX0JUZ1pPL0Vd7Zlg=; 24:rYwuajjBm9cOZg5vUZ3xKyAFvj6f0YyllYM4XfFt95+nfmOGL9sj3PeiXcNKXrgIT9rXKfkV1OznLp/IV52Ya/Y52GwHK1/l+VlyqrP9uGc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3672; 7:Jr9/o/qXgFEPvfg6e49A0lNQtdz4/7jtCwYvfcxzmAmsK44mvZS/E+aUdA9cB8x+V2Cf3A1eqc2hXhCMocUIXUGPBlITmDB6V3jay0fdlYnkS/WAzb0PnaDwc0R1EfIsq7WXp3RKaaM+u698U+w3WnsS8qRNzP4Img+dLB2V4JszBkbJmYALWyzkbTKnaGRXXPUuc0OkC12N6rnUbiCmOMMMo7z0vn2agGtK+04jROjbnrPGxZlAJKGrlX5JnmXv X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2018 15:54:44.5764 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4176d060-8f73-453c-f30f-08d596568eb0 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3672 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-30_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=303 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803300166 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, 30 Mar 2018 15:55:08 -0000 I am not in favor of ASN.1 and I believe it is not needed here. +1 Just the key without wrapping. -- Mark From nobody Fri Mar 30 10:11: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 633B6126FDC for ; Fri, 30 Mar 2018 10:11:56 -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 Gm7g4XFnHtAh for ; Fri, 30 Mar 2018 10:11:55 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 6D92B124F57 for ; Fri, 30 Mar 2018 10:11:54 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id g203-v6so13279116lfg.11 for ; Fri, 30 Mar 2018 10:11:54 -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=+dMtsBakI8qq4HntswnY+jAlmfnHO9Ub+lJIolAOqH4=; b=DbDKBtzSOMdS/kx5kR4gyNtk6eipfXL0AfZ4WqEDed1lB8OO3Vnp8C1qJ26vIs24Fs 3I/lY+YC1ySuJb4VoUQdflDIx7SXEA9yexKwT6soX6BR1rf47kbXHs8SZj1tL6aarq1/ uJs3KiiCUGf8mqC3rMCIoWWUzrqWJxvv5h1uitCwAgQYGTqV242CCy09UeBR8zriMLnE 0EPQFCy39VMXDvORhAear/DHTGaxYNuZCBgpLK66ikCD4882HpT+BJr3sECnvAxpXU5W Y8T0GEajyVYKl/mqofHTjaJiFsYDTLksxh+TFm9Z0dsJnFbg9yBmS7YqsrLszxqo9M+F ZdVQ== 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=+dMtsBakI8qq4HntswnY+jAlmfnHO9Ub+lJIolAOqH4=; b=KkxDso/FPrFhqgBveUNp0qfFfSWg9ckSVGwz6pfJD2i6hWfrADgN32QxZ4mGGBE40y i4D/3UuXJstZ9vlZe8IXViCNQeMFPUVkPcirHmfuWiRufJLKudRn2cBDe1wPf7Pn7/R9 QKnrKVXbl8XNSfQvKCW+PKKFz/2vleLYxUuLEoDkDe1N2AV3Nlv75yZP1f6GnBN0ceg7 eZPV6gzppfSa1uVOCA7AmzBFKAw5sH56QWZzg6cR5e01eyWgQkopRnrtoE79EZrnqDAH ZXjbguDyBsmdWTcx2x10eFqAvW1jCtfWdq2bXzFBqNFTGLZonXwOj2Uyw9iTG+oLyVd3 ljmg== X-Gm-Message-State: AElRT7HIPfAowOTMNVJTcyRC5Bx0DTWpbAHzRxOw28O6Vm76tEBiEOA5 jOqnJ3cYOd22Jkg1XJmhlQ1O4C6ogQF36Zjp7No= X-Google-Smtp-Source: AIpwx4/TebI0ujmYRKaYlUPNP6Bi2pLfKhyE49lpuK+F1y/sXbh0OBPlffa/kVAr8sVnbsGDDEHOXnInYSljCKZHW+k= X-Received: by 2002:a19:6d03:: with SMTP id i3-v6mr8421813lfc.34.1522429912558; Fri, 30 Mar 2018 10:11:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.115.7 with HTTP; Fri, 30 Mar 2018 10:11:51 -0700 (PDT) In-Reply-To: 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> From: "Murray S. Kucherawy" Date: Fri, 30 Mar 2018 10:11:51 -0700 Message-ID: To: denis bider Cc: "A. Schulze" , dcrup@ietf.org Content-Type: multipart/alternative; boundary="0000000000002235270568a45638" 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, 30 Mar 2018 17:11:56 -0000 --0000000000002235270568a45638 Content-Type: text/plain; charset="UTF-8" On Fri, Mar 30, 2018 at 12:42 AM, denis bider wrote: > You cannot safely assume that a DKIM signer or verifier has access to a > general-purpose ASN.1 library. > I made no such assumption. My own implementation has no idea about ASN.1; it relies instead on libcrypto to take care of that. All I need is the object that I need to pass to the verification function, whatever that is. The only encoding/decoding it does directly is base64 because it has to be stored in a DNS TXT RR. I would really prefer not to have to call different functions for key types, or have to describe any of that in a specification document, if it's possible to converge on one thing. Simplicity is my goal. It's possible that a DKIM verifier uses one crypto library for RSA, and > another for EdDSA. EdDSA typically does not come with ASN.1 support because > it's designed to not need it. The library that the verifier uses for RSA > may not expose ASN.1 primitives. > Yes, that's possible, but those are implementation details. I'm talking here only of the specification. > It's not hard! > At no time did I claim it's hard. It just seems unnecessary to me. Please don't be condescending. -MSK --0000000000002235270568a45638 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Mar 30, 2018 at 12:42 AM, denis bider <de= nisbider.ietf@gmail.com> wrote:
You cannot safely assume that a= DKIM signer or verifier has access to a general-purpose ASN.1 library.
=

I made no such a= ssumption.=C2=A0 My own implementation has no idea about ASN.1; it relies i= nstead on libcrypto to take care of that.=C2=A0 All I need is the object th= at I need to pass to the verification function, whatever that is.=C2=A0 The= only encoding/decoding it does directly is base64 because it has to be sto= red in a DNS TXT RR.

I would really prefer not to have to= call different functions for key types, or have to describe any of that in= a specification document, if it's possible to converge on one thing.= =C2=A0 Simplicity is my goal.

<= div dir=3D"ltr">
It's possible that a DKIM verifier uses one crypto l= ibrary for RSA, and another for EdDSA. EdDSA typically does not come with A= SN.1 support because it's designed to not need it. The library that the= verifier uses for RSA may not expose ASN.1 primitives.
<= /blockquote>

Yes, that's possible, but those are imp= lementation details.=C2=A0 I'm talking here only of the specification.<= br>=C2=A0
It's not hard!

At no time did I claim it's hard.=C2=A0 It just seems unnecessary to = me.

Please don't be condescending.

-MSK
--0000000000002235270568a45638-- From nobody Fri Mar 30 10:30: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 6539F127076 for ; Fri, 30 Mar 2018 10:30:31 -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 5tsLqLxG4Q8T for ; Fri, 30 Mar 2018 10:30:29 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7026E12704A for ; Fri, 30 Mar 2018 10:30:29 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id h55-v6so8627395ote.9 for ; Fri, 30 Mar 2018 10:30:29 -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=6tovs2zZNwsUJX7PMWeXbNov8nkD2ZrNX7tEPHsDRyg=; b=CThhAnexlyanucPnRD9WFlcUdUfGWOiO+cnJSnbRU73vGUv66oHO13v6/p1E6L/d2K iE4ZPG7s0/NVSIdLTLlHiYgo+AAUziXW7/sbxTOmPQhPK5S5nTTbUwwF/JQZzRhKAdfD a0PTsHja3Aw97oPo/yFZcjVVzEMhMwNXovo3waZEAYIQoLM5Hz0JTvDnSrxZUMQ9BeGx wWZJpYOahfulFk0q0tMc3oaTJMaBRFiVnbB29WQTJqhufxliVPirXD9hURu+dJXS3uAV lNxBpgJI2squuq9VPk5v471TWb8cVLbDjubqgejRFk+87yQVECkaCK7/g4iD0lDPybz3 TCwQ== 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=6tovs2zZNwsUJX7PMWeXbNov8nkD2ZrNX7tEPHsDRyg=; b=si/THYlapCAUAOgfcB9zzlbukiIpDb9NgDXt5s5F6YVFXiWpkm6BctL0mvkLbuGMvP V+O+6vPV3i6tpbSwjCN+P2yTDF9GlC6Ujy3DY60MdDG0/sUoHIF/URGI7XCXOEFWXY7Z DtjlpAE4aPKZvU0yvoI4h6Rs5oRAyEUAp6cHhlUmMgzBpVGDLqo8b9incNyaqZBHc+ks 3MHSzTS6mu+G8Peho5K9eKKvekF4dkbCOmf0MZKgnS0gyvS+y7QXp2CglyTZnlnrCGBO Ou/S1OEMViCr5Y4WuCSsuwk7WsjNLLWSlFFR3Xyu3PkcYlzLTsOBvdw5ssQYuhlpvXfX bqyA== X-Gm-Message-State: AElRT7GPw1pvzAtmVfiaS3UPqxC36AR6/GVucM73CifyCWMnnRJEoFxA +B90au3nI3gBzpiIa8hg3QyWVPuEwuoXZFGxCsA= X-Google-Smtp-Source: AIpwx4962kRUXG4AQ0GJsTGxW9HsLeBYai43EbEo55Zr0jtAU91O7ZtxV7/7ONJRRgTxmPYwjabcRvGQox3t8MQLnxA= X-Received: by 2002:a9d:ec8:: with SMTP id 66-v6mr7543165otj.167.1522431028777; Fri, 30 Mar 2018 10:30:28 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Fri, 30 Mar 2018 10:30:28 -0700 (PDT) In-Reply-To: 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> From: Phillip Hallam-Baker Date: Fri, 30 Mar 2018 13:30:28 -0400 X-Google-Sender-Auth: JBtz0LK-i_w3QdmhH_P6TcgAMoA Message-ID: To: "Murray S. Kucherawy" Cc: denis bider , dcrup@ietf.org, "A. Schulze" Content-Type: multipart/alternative; boundary="000000000000aa57b10568a49899" 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, 30 Mar 2018 17:30:31 -0000 --000000000000aa57b10568a49899 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 30, 2018 at 1:11 PM, Murray S. Kucherawy wrote: > On Fri, Mar 30, 2018 at 12:42 AM, denis bider > wrote: > >> You cannot safely assume that a DKIM signer or verifier has access to a >> general-purpose ASN.1 library. >> > > I made no such assumption. My own implementation has no idea about ASN.1= ; > it relies instead on libcrypto to take care of that. All I need is the > object that I need to pass to the verification function, whatever that is= . > The only encoding/decoding it does directly is base64 because it has to b= e > stored in a DNS TXT RR. > > I would really prefer not to have to call different functions for key > types, or have to describe any of that in a specification document, if it= 's > possible to converge on one thing. Simplicity is my goal. > =E2=80=8BWhich is exactly what we want and exactly the reason that we do no= t want to wrap our opaque binary blob for Ed25519 because we do not wrap our opaque blob for RSA.=E2=80=8B --000000000000aa57b10568a49899 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Fri, Mar 30, 2018 at 1:11 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
O= n Fri, Mar 30, 2018 at 12:42 AM, denis bider <denisbider.ietf@gma= il.com> wrote:
You cannot safely assum= e that a DKIM signer or verifier has access to a general-purpose ASN.1 libr= ary.

I= made no such assumption.=C2=A0 My own implementation has no idea about ASN= .1; it relies instead on libcrypto to take care of that.=C2=A0 All I need i= s the object that I need to pass to the verification function, whatever tha= t is.=C2=A0 The only encoding/decoding it does directly is base64 because i= t has to be stored in a DNS TXT RR.

I would really prefer= not to have to call different functions for key types, or have to describe= any of that in a specification document, if it's possible to converge = on one thing.=C2=A0 Simplicity is my goal.

=E2=80=8BWhich is exactly what we want and exactly the reason that = we do not want to wrap our opaque binary blob for Ed25519 because we do not= wrap our opaque blob for RSA.=E2=80=8B

--000000000000aa57b10568a49899-- From nobody Fri Mar 30 10:38:45 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 6415B12704A for ; Fri, 30 Mar 2018 10:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=mailforce.net header.b=1tduopoZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MYJKOQ7y 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 5rYhr0L4teCY for ; Fri, 30 Mar 2018 10:38:41 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF801270AB for ; Fri, 30 Mar 2018 10:38:40 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5B276219E3; Fri, 30 Mar 2018 13:38:40 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute7.internal (MEProxy); Fri, 30 Mar 2018 13:38:40 -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=MZ/0Bqokv2LeePrVZ /9VfV/yq8KmQaRfEavwUNY/ymk=; b=1tduopoZS6vYVtQSLzKrQqA40N31eRDRH Y+r4Qi5NOoTlcR5NkU+HHEpX2W9tyazVmGmcsvev1zhFEx4fjv22KdwmmLBH7gEy Ah7lyiCuOsvk96CAbh1Aul7ZDbsx0e9D4mNDBPJ+CaCAkrbqrnbuVS6P1nZem6v/ IBi8g8vWJTmzv4ygNm4lImV/m9jiNX9TwTgfXazWiHOgnGr1d/YlvAQSLVab5vx+ YmOmlRm50DLagQdo6CsYoF7t+F8OsAiwZVe+5a6b27ZNuf9z5NXxcR+Zn7DrvBHa ZYX5pODEajS1mnwbHzdoBEgMCb2tRsuoSZfMcN+uFWXoNBUhKzs1Q== 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=MZ/0Bq okv2LeePrVZ/9VfV/yq8KmQaRfEavwUNY/ymk=; b=MYJKOQ7yBwfFemHsFDyQy9 eyTeCKupf0q3TkkeYG9hOsSFng7Ds4TApREnGP0IljY0FuD75+ybvACYmJ/u2bH1 jMUJ7WZZtP55ugTwNvcv7xM43aHuFaXsT1Oy+1fv2UkDWSvqbJ3omAFg1y+wMcga H7M+rtYQBfHwkvHUCTZqgc9xpOHewim9L4uQacvgH9qOlwE5UTdSW9OXqs7LEgb2 5fZVnzgGaM01ch7mfMKi5alY/5adRfdeImrgX22eFoTMJvuh8L1bYIIheLM2zyru hCmzSyNi2+s/Nnfi/gRhfF7Yv+FjedanR0m68ByXx8bTelmDPvkILtqYiBiYtl7w == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3781ABA43C; Fri, 30 Mar 2018 13:38:40 -0400 (EDT) Message-Id: <58C61DB9-1483-4376-9F20-369DFBAC0CC5@glyphein.mailforce.net> From: Stan Kalisch To: "Phillip Hallam-Baker" Cc: "Murray S. Kucherawy" , dcrup@ietf.org, denis bider , "A. Schulze" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15224315204360986" X-Mailer: MessagingEngine.com Webmail Interface - ajax-bb419338 In-Reply-To: Date: Fri, 30 Mar 2018 13:38:40 -0400 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> 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, 30 Mar 2018 17:38:44 -0000 This is a multi-part message in MIME format. --_----------=_15224315204360986 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mar 29, 2018, at 7:11 PM, Phillip Hallam-Baker wrote:> > On Thu, Mar 29, 2018 at 4:43 PM, Murray S. Kucherawy > wrote:[...] >> As I recall, we picked this because that's the format exported by the >> openssl CLI for public RSA keys, and we were fine with that. What's >> different with Ed25519 keys?> > What is different is that the use of RSA is described in PKCS #1 > and its successors which used ASN.1 to describe the public key > blob format.> > The use of the CFRG curves is described in the RFCs mentioned earlier > and we decided to stop using ASN.1 when we shipped them. The public > key blob format does not use ASN.1. It is just a bignum with an > implicit length and the sign encoded in a spare bit[...] In the interest of clarifying matters a bit, does anyone dispute these two paragraphs? Stan --_----------=_15224315204360986 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mar 29, 2018, at 7:11 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

On Thu, Mar 29, 2018 at 4:43 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
[...]
As I recall, we picked this because that's the format exported by the openssl CLI for public RSA keys, and we were fine with that.  What's different with Ed25519 keys?

What is different is that the use of RSA is described in PKCS #1 and its successors which used ASN.1 to describe the public key blob format.

The use of the CFRG curves is described in the RFCs mentioned earlier and we decided to stop using ASN.1 when we shipped them. The public key blob format does not use ASN.1. It is just a bignum with an implicit length and the sign encoded in a spare bit
[...]

In the interest of clarifying matters a bit, does anyone dispute these two paragraphs?


Stan

--_----------=_15224315204360986-- From nobody Fri Mar 30 13:00:27 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 74983126CBF for ; Fri, 30 Mar 2018 13:00:25 -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 JFDXtedwFLFD for ; Fri, 30 Mar 2018 13:00:23 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC18120725 for ; Fri, 30 Mar 2018 13:00:23 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 03FD11E242; Fri, 30 Mar 2018 20:00:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1522440022; bh=fxbfl05daPlSSUXw8LX2wGhCOcdM29ciadA4JAe6sWA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=yFvG3agT5v66MOXIBXwb62AwfO7dcGMd/bl1z3HAuiSbtLskTWYzFd5UguXnv7QtD kRtj1xYHYI/7IQ1+elAvXr+T9E5lc8XymcgouLa5wgK5EqIGhioLIf3GBdmBNq9NIz BJq7nQNXsX0gZfH+xpslBvFG0SpEp5vDj+07zw6MBp2C+rgfch7f3vogUW1EHZWLlC nRXjnZDKyE91Qo5QkzD3s32BSeF8UF9mGK2GsY/f0l9LFkkEQhQBeUQrbE14kIuWdm Nve/0Z6h0ZAAfrKbNg65SW1oMxs8hw2AeO8BK502icoJXomlRBTELIyoL8XE1LTiba wquju2AYRWWvw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 4239710A6FF2F; Fri, 30 Mar 2018 20:00:15 +0000 (UTC) From: James Cloos To: "Mark D. Baushke" Cc: "Salz\, Rich" , "dcrup\@ietf.org" , Phillip Hallam-Baker , "Murray S. Kucherawy" , denis bider , "A. Schulze" In-Reply-To: <52970.1522425276@eng-mail01.juniper.net> (Mark D. Baushke's message of "Fri, 30 Mar 2018 08:54:36 -0700") 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> <52970.1522425276@eng-mail01.juniper.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2017 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 30 Mar 2018 16:00:15 -0400 Message-ID: Lines: 47 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: Fri, 30 Mar 2018 20:00:25 -0000 > +1 Just the key without wrapping. Just to show how easy a raw key is, here is a quick bit of code to generate and print out a key pair in base64 using libsodium: /************************************************************************************************************/ /* Generate an ed25519 key pair for dkim using libsodium */ #include #include #define SK64LEN sodium_base64_ENCODED_LEN(crypto_sign_SECRETKEYBYTES, sodium_base64_VARIANT_ORIGINAL) #define PK64LEN sodium_base64_ENCODED_LEN(crypto_sign_PUBLICKEYBYTES, sodium_base64_VARIANT_ORIGINAL) int main( int argc, char* argv[] ) { unsigned char sk[crypto_sign_SECRETKEYBYTES]; unsigned char pk[crypto_sign_PUBLICKEYBYTES]; unsigned char sk64[SK64LEN]; unsigned char pk64[PK64LEN]; if (sodium_init() == -1) { return 1; } crypto_sign_keypair( pk, sk ); puts( "PRIVATE:" ); /* PK64LEN and PUBLICKEYBYTES in the next line to outputs only the private key */ puts( sodium_bin2base64 (sk64, PK64LEN, sk, crypto_sign_PUBLICKEYBYTES, sodium_base64_VARIANT_ORIGINAL ) ); puts( "PUBLIC:" ); puts( sodium_bin2base64 (pk64, PK64LEN, pk, crypto_sign_PUBLICKEYBYTES, sodium_base64_VARIANT_ORIGINAL ) ); } /************************************************************************************************************/ It is released to the public domain or via the CC0 license, as anyone prefers. And if one wanted hex, using sodium_bin2hex() instead of sodium_bin2base64() is enough. ASN.1 has no value whatsoever for eddsa. Eliminating additional attack vectors like asn.1 was part of DJB's stated motivation and that continued into the eddsa rfc. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sat Mar 31 08:37:28 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5C112D881 for ; Sat, 31 Mar 2018 08:37:26 -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 RaelTzex8Mlw for ; Sat, 31 Mar 2018 08:37:24 -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 743F112D880 for ; Sat, 31 Mar 2018 08:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1522510642; bh=b1J9LQya4sNN5dT2qcJdcGp7y733FRhg6Or4rXeka7g=; l=441; h=To:References:From:Date:In-Reply-To; b=ADIxMgHgAB459SqEiEb20QkSv3my+Dnw+oBVrDRvULfGdHY/eWFech6CXcmL//76C AjFIEG0j4GC8SdHCec3TiG7L5Rog1V240oNOQwLxfuTIb/3P84Gf1tr1msm+aingMF bJtTlt47cmHaOKghLXoLGjj3xCPXjmjMMyzlda1mFnRfZ4nCE1CQAOeWwf+Wv 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; Sat, 31 Mar 2018 17:37:22 +0200 id 00000000005DC06D.000000005ABFAB32.000069CA To: dcrup@ietf.org References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <1707459.QODvfERKoP@kitterma-e6430> <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.com> <20180328094636.Horde.Np3GCcO8iEPwmQzOaaUjbrh@andreasschulze.de> <2897E6E0-4535-4EC1-9686-E080CCA82D21@akamai.com> <52970.1522425276@eng-mail01.juniper.net> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <669131e3-7606-6720-b976-af0ed5e4cc85@tana.it> Date: Sat, 31 Mar 2018 17:37:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: 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: Sat, 31 Mar 2018 15:37:26 -0000 On Fri 30/Mar/2018 22:00:15 +0200 James Cloos wrote:  > > And if one wanted hex, using sodium_bin2hex() instead of sodium_bin2base64() > is enough. > > ASN.1 has no value whatsoever for eddsa. FWIW, on a stock Debian stable install, I get: $ grep -i base64 /usr/include/sodium/*.h $ grep -i bin2hex /usr/include/sodium/*.h /usr/include/sodium/utils.h:char *sodium_bin2hex(char * const hex, const size_t hex_maxlen, Ale -- From nobody Sat Mar 31 08:59:55 2018 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4105512D880 for ; Sat, 31 Mar 2018 08:59:54 -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 d9ejY8I_33ZM for ; Sat, 31 Mar 2018 08:59:52 -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 9AF8E126C3D for ; Sat, 31 Mar 2018 08:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1522511991; bh=8nGXdxZj1AW9P+BCzcbZ/pHZtOCgppe8a7tiML37VjQ=; l=1924; h=To:References:From:Date:In-Reply-To; b=Cql/o7YSOmm35lS6dt8A9ZraFBAfaqvEPW0AIcJdB1vey9Yw04TlRztWAkZJkTi5g n3XKYFd4ZuDPkVTD9VXbiHDF417OdU4+25FmxPIkjB4g1WzzF9WH0Hcs+I1TFkGd+X sJ5W61Ks8ffvykIRe+3YXfzI362ReAm0FsYyz3ASUd2stm8S5OGPAfJrIQZjY 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; Sat, 31 Mar 2018 17:59:50 +0200 id 00000000005DC056.000000005ABFB076.00006C00 To: dcrup@ietf.org References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.com> <20180328094636.Horde.Np3GCcO8iEPwmQzOaaUjbrh@andreasschulze.de> <4AA34DC9-1B8F-44A6-A680-7A97552F7644@kitterman.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Sat, 31 Mar 2018 17:59:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <4AA34DC9-1B8F-44A6-A680-7A97552F7644@kitterman.com> 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: Sat, 31 Mar 2018 15:59:54 -0000 On Thu 29/Mar/2018 23:31:37 +0200 Scott Kitterman wrote:  > > If using ASN.1 makes the protocol simpler, it might be useful to have > someone describe what text could be removed from the draft if we went that > direction. Any volunteers? I'd try and imagine an eventual rfc6376bis. First the "complicated" alternative that Murray dreads: k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers MUST support the "rsa" key type and SHOULD support the "ed25519" key type. Verifiers MUST support both "rsa" and "ed25519" key types. The "rsa" key type indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey (see [RFC3447], Sections 3.1 and A.1.1) is being used in the "p=" tag. The "ed25519" key type indicates there is the little-endian binary number (see [RFC8032], Sections 5.1.5 and 7.1) in the same place. (Note: the "p=" tag further encodes the value using the base64 algorithm.) Unrecognized key types MUST be ignored. ABNF: key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type key-k-tag-type = "rsa" / "ed25519" / x-key-k-tag-type x-key-k-tag-type = hyphenated-word ; for future extension No doubt it can be bettered, I just naively mixed text from the draft and rfc6376. And alas I'm not good at wording... Ditto for the next, more concise alternative (it nearly saves two lines of text): k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers MUST support the "rsa" key type and SHOULD support the "ed25519" key type. Verifiers MUST support both "rsa" and "ed25519" key types. The key type indicates which ASN.1 DER-encoded [ITU-X660-1997] key is being used in the "p=" tag. (See [RFC3447], Sections 3.1 and A.1.1 for RSAPublicKey encoding; [draft-josefsson-tls-ed25519] for SubjectPublicKeyInfo.) (Note: the "p=" tag further encodes the value using the base64 algorithm.) Unrecognized key types MUST be ignored. jm2c Ale -- From nobody Sat Mar 31 09: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 EC68312D880 for ; Sat, 31 Mar 2018 09:02:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=dsioyPvF; dkim=neutral reason="invalid (public key: unsupported version)" header.d=kitterman.com header.b=lFMN9tJr 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 XmYgjy_RjJ0U for ; Sat, 31 Mar 2018 09:02:34 -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 AE6BC124BE8 for ; Sat, 31 Mar 2018 09:02:34 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1522512153; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=erPbCsT2ZP8CoK1aT975TQgufrIQQf6EaMnd2C5qTyQ=; b=dsioyPvFlX4eLOXeCzVR5FYCO76+XL1vlTHSTRl186AskSbiyd3AUKa2 MjPdnuKt/ldwahryu/dmJA5mrK/kBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1522512153; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=erPbCsT2ZP8CoK1aT975TQgufrIQQf6EaMnd2C5qTyQ=; b=lFMN9tJrho8bnBYSbtkrB6EKRHRjp2F5ibe2WWai0n/ez6yeBS9FkFP2 XRLTb+OpNsfAduE/I9zjng8SopntOO0p0O4W7ZSYEprIG+XPkU/yD5kHYK 4Je7KSdYZAWaSe+m/bvvmXgq108aYhUSvztj9h6PRGIp4Y4QFu/AEMEJIk Hbvokx5Tv224c3OXUSodhFEGHhSAWWtAX+/Z33YstRfpwJ/AyDJXfl1Q6l XmMCf46+8rviI5BkdJnPukdPpLZCMkFpFYuQF28U+9rEZIX8Ets+X7D3d2 wdL3Gg0m1nYN8DEBZvdL8dXAJeMaHsBoUckS5hfHeqNHRPi+nKkk/g== 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 6BA3AC401CA; Sat, 31 Mar 2018 11:02:33 -0500 (CDT) Date: Sat, 31 Mar 2018 16:02:30 +0000 In-Reply-To: <669131e3-7606-6720-b976-af0ed5e4cc85@tana.it> 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> <52970.1522425276@eng-mail01.juniper.net> <669131e3-7606-6720-b976-af0ed5e4cc85@tana.it> 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: <8EE03C3C-C4ED-4615-83AB-C9AA7EB0E9C6@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: Sat, 31 Mar 2018 16:02:37 -0000 On March 31, 2018 3:37:22 PM UTC, Alessandro Vesely wro= te: >On Fri 30/Mar/2018 22:00:15 +0200 James Cloos wrote:=C2=A0 >>=20 >> And if one wanted hex, using sodium_bin2hex() instead of >sodium_bin2base64() >> is enough=2E >>=20 >> ASN=2E1 has no value whatsoever for eddsa=2E > >FWIW, on a stock Debian stable install, I get: > >$ grep -i base64 /usr/include/sodium/*=2Eh >$ grep -i bin2hex /usr/include/sodium/*=2Eh >/usr/include/sodium/utils=2Eh:char *sodium_bin2hex(char * const hex, >const size_t hex_maxlen, That's because it was added in libsodium 1=2E0=2E14 and Debian Stable was = released with 1=2E0=2E12=2E The Python wrapper I used, PyNaCl, uses Python= 's native base64 function, so for my purposes, it didn't matter (my dkimpy-= milter, that supports ed25519, is available in the Debian backports reposit= ory and works fine with libsodium 1=2E0=2E12)=2E In any case, support for = something in a Debian stable release is hardly a leading indicator of thing= s=2E If anyone needs a newer libsodium in Debian stable backports, feel free to= contact me off list, so this doesn't veer even more off topic=2E Scott K From nobody Sat Mar 31 11:07: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 3FBDB127077 for ; Sat, 31 Mar 2018 11:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, URIBL_BLOCKED=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 l-xzFrq6LLjx for ; Sat, 31 Mar 2018 11:07:04 -0700 (PDT) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (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 BA39C124F57 for ; Sat, 31 Mar 2018 11:07:04 -0700 (PDT) Received: by mail-oi0-x244.google.com with SMTP id u84-v6so10006330oie.10 for ; Sat, 31 Mar 2018 11:07:04 -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=4ob+AjogicuU/rnpnHoAPMPJmxaKxmfsnwQvvsObpPw=; b=s0JcICxqVnYNd25g0/lgMqRsHMNGGoArJVJRbP7HzgXNi5X//jWFuW8Rgn29+Ss19q Bg9L85CMQTA+DCWDHBsmv8qWS0jdIg7bX3EmRf6Ga9e+8LnmzOfB0nzzoMBissy9q83w dvpNpCvm4/3pKPc2yaPt6snEuXH7+TcuMDrUq7VWfoHgRseNqK2ya6n+P9W+qVrptBeE s8HLrIvWj9R38bxpe7ip0Qz75mjjRp0LhIlmemusuL54NRjmxjjh7SNeAXflY0PZxxmY Bv74WZK8LSDChqlLGwB9I3PxqimSttB4rOprOjobAOFSmXLFM5Jd+GLOC546nffHjDoY Zuzw== 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=4ob+AjogicuU/rnpnHoAPMPJmxaKxmfsnwQvvsObpPw=; b=oIA/ZUvU+cfA+Na5BCshEbLdTk5hT8V6Hp19Noduxp84synR123jsxagLP6G9KaUX5 mik0Bck5gZRqcD5mnJ+PyFWINY1BoKcBsQrz6NtjmElEGyVGjSwQVbnblORkSufTk8ki OVmgrZNvCuZnDeWMnx3TYGtDyqPdaEJgN7vlv0gCQH64fkKM4uoEaafxc1hLUhRtjuei gUWX8clP5H/i+HV4vC7c4mgqkGiF8PifmeMuOeUvGf8PzcMODlA2fdapELJLVT3LmGgT a60N5v2rI7M3e8LquFbOvEZftJiaq6n5SBF/dt09bjuUBZ3AxoQGCJxOQr34xZNyPqOn KOeg== X-Gm-Message-State: ALQs6tA3uq1kPavbEh8R0s5v2+B/X3uZ3iXBws0paHmj3/raiej5Ltxv MkhqY9ZpKK4ghVqnngEr0swDxOMK5ywrUS3BdkQ= X-Google-Smtp-Source: AIpwx4+Rj9DpIePG21ENIka1a5cO8DbiT/rVv5PngOPn0R5e1qe3QAel/0ac6qW2s7V/VYTtd75e7AzD24HqeXUJLOo= X-Received: by 2002:aca:ce0d:: with SMTP id e13-v6mr2045128oig.34.1522519624013; Sat, 31 Mar 2018 11:07:04 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Sat, 31 Mar 2018 11:07:03 -0700 (PDT) In-Reply-To: References: <3a64bdb6-ea02-b124-7ac5-f9aad0287a87@bbiw.net> <2FFD1884-56A2-42CD-B21D-A70AB0905C68@kitterman.com> <20180328094636.Horde.Np3GCcO8iEPwmQzOaaUjbrh@andreasschulze.de> <4AA34DC9-1B8F-44A6-A680-7A97552F7644@kitterman.com> From: Phillip Hallam-Baker Date: Sat, 31 Mar 2018 14:07:03 -0400 X-Google-Sender-Auth: Ni3JKZRblrXjRqOjc72E0Q2kmcg Message-ID: To: Alessandro Vesely Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="0000000000005a5e4b0568b939ed" 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: Sat, 31 Mar 2018 18:07:08 -0000 --0000000000005a5e4b0568b939ed Content-Type: text/plain; charset="UTF-8" Agreed, it is like fifteen minutes to write and another 30 checking you have the big-endian thing right and haven't introduced an extra flip on the byte order somewhere. This took me no time at all in c#. On Sat, Mar 31, 2018 at 11:59 AM, Alessandro Vesely wrote: > On Thu 29/Mar/2018 23:31:37 +0200 Scott Kitterman wrote: > > > > If using ASN.1 makes the protocol simpler, it might be useful to have > > someone describe what text could be removed from the draft if we went > that > > direction. Any volunteers? > I'd try and imagine an eventual rfc6376bis. > > First the "complicated" alternative that Murray dreads: > > k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers MUST > support the "rsa" key type and SHOULD support the "ed25519" key > type. Verifiers MUST support both "rsa" and "ed25519" key types. > The "rsa" key type indicates that an ASN.1 DER-encoded > [ITU-X660-1997] RSAPublicKey (see [RFC3447], Sections 3.1 and > A.1.1) is being used in the "p=" tag. The "ed25519" key type > indicates there is the little-endian binary number (see > [RFC8032], Sections 5.1.5 and 7.1) in the same place. (Note: > the "p=" tag further encodes the value using the base64 > algorithm.) Unrecognized key types MUST be ignored. > > ABNF: > > key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type > key-k-tag-type = "rsa" / "ed25519" / x-key-k-tag-type > x-key-k-tag-type = hyphenated-word ; for future extension > > No doubt it can be bettered, I just naively mixed text from the draft and > rfc6376. And alas I'm not good at wording... Ditto for the next, more > concise > alternative (it nearly saves two lines of text): > > k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers MUST > support the "rsa" key type and SHOULD support the "ed25519" key > type. Verifiers MUST support both "rsa" and "ed25519" key types. > The key type indicates which ASN.1 DER-encoded [ITU-X660-1997] > key is being used in the "p=" tag. (See [RFC3447], Sections 3.1 > and A.1.1 for RSAPublicKey encoding; [draft-josefsson-tls-ed25519] > for SubjectPublicKeyInfo.) (Note: the "p=" tag further encodes the > value using the base64 algorithm.) Unrecognized key types MUST be > ignored. > > > jm2c > Ale > -- > > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --0000000000005a5e4b0568b939ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agr= eed, it is like fifteen minutes to write and another 30 checking you have t= he big-endian thing right and haven't introduced an extra flip on the b= yte order somewhere.

This= took me no time at all in c#.=C2=A0
=
On Sat, Mar 31, 2018 at 11:59 AM, Alessandro= Vesely <vesely@tana.it> wrote:
On Thu 29/Mar/2018 23:31:37 +0200 Scott Kitterman wrote= :=C2=A0
>
> If using ASN.1 makes the protocol simpler, it might be useful to have<= br> > someone describe what text could be removed from the draft if we went = that
> direction.=C2=A0 Any volunteers?
I'd try and imagine an eventual rfc6376bis.

First the "complicated" alternative that Murray dreads:

=C2=A0 =C2=A0k=3D Key type (plain-text; OPTIONAL, default is "rsa"= ;).=C2=A0 Signers MUST
=C2=A0 =C2=A0 =C2=A0 support the "rsa" key type and SHOULD suppor= t the "ed25519" key
=C2=A0 =C2=A0 =C2=A0 type.=C2=A0 Verifiers MUST support both "rsa"= ; and "ed25519" key types.
=C2=A0 =C2=A0 =C2=A0 The "rsa" key type indicate= s that an ASN.1 DER-encoded
=C2=A0 =C2=A0 =C2=A0 [ITU-X660-1997] RSAPublicKey (see [RFC3447], Sections = 3.1 and
=C2=A0 =C2=A0 =C2=A0 A.1.1) is being used in the "p=3D" ta= g.=C2=A0 The "ed25519" key type
=C2=A0 =C2=A0 =C2=A0 indicates there is the little-endian binary number (se= e
=C2=A0 =C2=A0 =C2=A0 [RFC8032], Sections 5.1.5 and 7.1) in the same place.= =C2=A0 (Note:
=C2=A0 =C2=A0 =C2=A0 the "p=3D" tag further enco= des the value using the base64
=C2=A0 =C2=A0 =C2=A0 algorithm.)=C2=A0 Unrecognized key types MUST be ignor= ed.

=C2=A0 =C2=A0 =C2=A0 ABNF:

=C2=A0 =C2=A0 =C2=A0 key-k-tag=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D %x76 [FWS] &q= uot;=3D" [FWS] key-k-tag-type
=C2=A0 =C2=A0 =C2=A0 key-k-tag-type=C2=A0 =C2=A0=3D "rsa" / "= ;ed25519" / x-key-k-tag-type
=C2=A0 =C2=A0 =C2=A0 x-key-k-tag-type =3D hyphenated-word=C2=A0 =C2=A0; for= future extension

No doubt it can be bettered, I just naively mixed text from the draft and rfc6376.=C2=A0 And alas I'm not good at wording...=C2=A0 Ditto for the = next, more concise
alternative (it nearly saves two lines of text):

=C2=A0 =C2=A0k=3D Key type (plain-text; OPTIONAL, default is "rsa"= ;).=C2=A0 Signers MUST
=C2=A0 =C2=A0 =C2=A0 support the "rsa" key type and SHOULD suppor= t the "ed25519" key
=C2=A0 =C2=A0 =C2=A0 type.=C2=A0 Verifiers MUST support both "rsa"= ; and "ed25519" key types.
=C2=A0 =C2=A0 =C2=A0 The key type indicates which ASN.1 DER-encoded [ITU-X6= 60-1997]
=C2=A0 =C2=A0 =C2=A0 key is being used in the "p=3D" tag.=C2=A0 (= See [RFC3447], Sections 3.1
=C2=A0 =C2=A0 =C2=A0 and A.1.1 for RSAPublicKey encoding;=C2=A0 [draft-jose= fsson-tls-ed25519]
=C2=A0 =C2=A0 =C2=A0 for SubjectPublicKeyInfo.)=C2=A0 (Note: the "p=3D= " tag further encodes the
=C2=A0 =C2=A0 =C2=A0 value using the base64 algorithm.)=C2= =A0 Unrecognized key types MUST be
=C2=A0 =C2=A0 =C2=A0 ignored.


jm2c
Ale
--



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

--0000000000005a5e4b0568b939ed-- From nobody Sat Mar 31 11:46: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 8D68D127076 for ; Sat, 31 Mar 2018 11:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=NZUNKejw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dnbr5hUo 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 zXn6xTdN6jFC for ; Sat, 31 Mar 2018 11:46:44 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6462127077 for ; Sat, 31 Mar 2018 11:46:44 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0599B20D39 for ; Sat, 31 Mar 2018 14:46:44 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute7.internal (MEProxy); Sat, 31 Mar 2018 14:46:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=XuqCXK3YPW2S6BCMROXV9any42HZI cSD1GK9+RtXUMw=; b=NZUNKejwjHup8zu/k/Xi6mfWEkttfHY79a3+T8ExxxTOY 7pefa+EIjCYQtQcT2M/Fmaj44YUcxL+/840RdSrtFdMbm4H0BDGr9hV29fKXR3Nj QJjxFf+CeRrgwv3FbcuOlq7rE1rvkEDkcu3o3zQ1vfbqiBzvyU8I4SWnqMLgQoN1 gmCubnZjE7T169A/K1lckQpvnJ7T40x6dmnbQ0BcU1S21sGppGDlhTgv8v1ilE0v afY1+xfA8A8BoJgwpZI9/kwoB57cxRaMjWwXn7lM4xp48/W9bnSbQ74cG5xs4X8C O4eZd2oHnG3LFuLmqYTfDx5KqYvwv/EsScXZ66D6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=XuqCXK 3YPW2S6BCMROXV9any42HZIcSD1GK9+RtXUMw=; b=dnbr5hUoK/RbfJrM1edO+c X1U45EjpKTpgnNN8sPyWw/Ca+U1iU/cUfIcO9hGnS/nI2r3UXz0M64v+Ji1+D7/v tHJqzfMffuUGebQhhFKvSV6/sUKG8w+P2oZwzTSn6+H4j1YhymzoeR9h6yQIicgx 6u7PjALKLkxwEd3V3LekjzZHeQo1DOXhBN/cC3V/9fqvGdwKrIgw3l84Otdd4ziT l2KwXklkrPFm3Bs+BYXlFahrhFC68+sxxXNyRCWDcTvfgVu/cyEpxt5SB8Fp5h1M zcKYLFqd/a/OE0OyLVtGXq3Cjbq/OJ8wShHInHFaX6CTJYuWoxNowD29wboD58qA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D8ADEBA43B; Sat, 31 Mar 2018 14:46:43 -0400 (EDT) Message-Id: <85675DEC-B121-438F-8F27-DF0B22F558A6@glyphein.mailforce.net> From: Stan Kalisch To: dcrup@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152252200320652960" X-Mailer: MessagingEngine.com Webmail Interface - ajax-bb419338 In-Reply-To: <8EE03C3C-C4ED-4615-83AB-C9AA7EB0E9C6@kitterman.com> Date: Sat, 31 Mar 2018 14:46:43 -0400 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> <52970.1522425276@eng-mail01.juniper.net> <669131e3-7606-6720-b976-af0ed5e4cc85@tana.it> <8EE03C3C-C4ED-4615-83AB-C9AA7EB0E9C6@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: Sat, 31 Mar 2018 18:46:46 -0000 This is a multi-part message in MIME format. --_----------=_152252200320652960 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" > On Mar 31, 2018, at 12:02 PM, Scott Kitterman > wrote:> > In any case, support for something in a Debian stable release is > hardly a leading indicator of things. Agreed. Debian's level of deliberate reserve in adding features to stable (which, of course, is a feature) doesn't really serve this for illustrative purposes. Thanks, Stan --_----------=_152252200320652960 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
> On Mar 31, 2018, at 12:02 PM, Scott Kitterman <sklist@kitterman.com> wrote:
>
> In any case, support for something in a Debian stable release is hardly a leading indicator of things.

Agreed.  Debian's level of deliberate reserve in adding features to stable (which, of course, is a feature) doesn't really serve this for illustrative purposes.


Thanks,
Stan
--_----------=_152252200320652960--