From nobody Mon Aug 1 02:17:29 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1741C12D5CF for ; Mon, 1 Aug 2016 02:17:27 -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 KqK1oCX69NY2 for ; Mon, 1 Aug 2016 02:17:25 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AEB812D590 for ; Mon, 1 Aug 2016 02:16:57 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id i5so234408070wmg.0 for ; Mon, 01 Aug 2016 02:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g+3+smZ5SSimz662ZVebQ4oV4VEloPwgRZOTpynV8NQ=; b=gkKTBuW9zoyykH1M4rpoF6ziYdX1sdpX+e/gnBf74yyRuO8Srw7nfscLNlppfJWyL/ ccRKJYvWAAzNeaO8Q8ycO/znx6pyEY4OpFe9UOSkPOyQSkgtftnnssb4nDU5cCjnEE53 YvV0zudsUPfQUGWn7KtdbFn96KCgD3pTJ6xcRpp2dCF2DVt3BRfx+Ha+kpJ5tWRCnQ/1 JeXtL4IZyUXtNBmeSMDP2VKlwgUpHJC7TEU4lQTbH1Uy31bsHmsORxAR0GfqCvlDfQsD 2uBEqTGgONRkRhCdNncYRa8IfuSSQ3MlA7Kq7Mf8JwCaqp3+jScz/A1f3DNNe70VRjpW p50A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g+3+smZ5SSimz662ZVebQ4oV4VEloPwgRZOTpynV8NQ=; b=QHH7EyvmcF9m3CTj4pe/grR00gaFnmE1XbDOqxgXyD00tom4NTHGxrPNB6aPsayjik PT1N1hITQjvhH2MKKDx2OAJSgs4xXa1UOU1QDaruY8TB4x+vHU0O2bmSfVjtN6s+8Isw etP+V6OyRKUkf5pr6sdoO3VUMuuepyEDpnpOYfWcoQpu1t++BLAEHnlm3XAV056f+1QZ Aopj7PvF2dcexLKAK1MM+A6zxFYw8oz0a90eXL3NBu4dgrVEzlZYyedgxFabj2aulZwC ga2z1zvVj9Gbp5bh/xMzaBZnq/l5CCkQXr3bgUFazOo3nDCPGSbvIM53ulTF3P9R+7Ns JGug== X-Gm-Message-State: AEkoousPjtWs4zHd6hKXdnAM4tFrNX9fSONHhUV6g7bK6+gec+fGnxKwDseEXnLuO2NNqt84/oXdY+SYjPxGCQ== X-Received: by 10.28.225.4 with SMTP id y4mr56065007wmg.98.1470043015639; Mon, 01 Aug 2016 02:16:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.59.35 with HTTP; Mon, 1 Aug 2016 02:16:54 -0700 (PDT) Received: by 10.194.59.35 with HTTP; Mon, 1 Aug 2016 02:16:54 -0700 (PDT) In-Reply-To: <011a01d1ebba$c98eabf0$5cac03d0$@augustcellars.com> References: <011a01d1ebba$c98eabf0$5cac03d0$@augustcellars.com> From: Blake Ramsdell Date: Mon, 1 Aug 2016 02:16:54 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a114b110cc077700538ff0ff5 Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 09:17:27 -0000 --001a114b110cc077700538ff0ff5 Content-Type: text/plain; charset=UTF-8 On Jul 31, 2016 11:06 PM, "Jim Schaad" wrote: > Proposed for S/MIME 3.5 > > MUST: RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519 Why are there three MUST algorithms? --001a114b110cc077700538ff0ff5 Content-Type: text/html; charset=UTF-8

On Jul 31, 2016 11:06 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:
> Proposed for S/MIME 3.5
>
> MUST: RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519

Why are there three MUST algorithms?

--001a114b110cc077700538ff0ff5-- From nobody Mon Aug 1 07:14:03 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AA012D782 for ; Mon, 1 Aug 2016 07:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7y8IGLYUJXS for ; Mon, 1 Aug 2016 07:13:57 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A8012D8AF for ; Mon, 1 Aug 2016 07:13:55 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id p74so146237535qka.0 for ; Mon, 01 Aug 2016 07:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=xelpH7CZNsONMmJL2/UBW9zPVpay7HNjjwLnBnFCtzE=; b=Opc8DjEYGdocv6YB0KHvM8QJ4ZdUjeVDlbt7r+L4roOYjoBO4O0EZjhr4oK74fb6g4 5f+p64/1+N9x2aB7KDw6yq+eA7/WC8pATk6E0rbs6u7xdB//MtyvJMZFRphSBcch91ga 59G2PGWmI4V8hYCu6LsLoOOyHk2d6RmOY3oQjAFgOQr9WIa/jZKGEmoGBwwv0PT4O2De O4kII5BxfunYpABHMvezG2DgsKwhpECfjHILQITYi7aZMkvMOGktqIIjhCS7sqdUXt0z O3de8z3uyEAf0rjvO/MMeAfHSJRoHP71bcMrm3ecUF34tz0yhkJBAlBneAu9Mal0nesK bjtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=xelpH7CZNsONMmJL2/UBW9zPVpay7HNjjwLnBnFCtzE=; b=hn0EuicmqCrK4usO+4cyWrmJShZKYFj39e9HYq4ovCQAchT+dgi7HLhabpY5pHxv+A ulmuCpSslT/Mg1Xt/I4qzXos5MMbtrLQL+9mbXB7M5lz5IsUDqNr1K37YUBuYb4cz/9Y cppa63ePfBHV/bqDlWx/Qt85D1kJERS7Zx6qg4jfWAC+Pp0SQ2YmDJOkDvu33+fk1oOc tCJbWVU2S27pe4Kq3FH9s6cnIaR6tMTqrh5hYFcjX6IsFhjL0DRfTLOd0SeqNnKPDYy1 c842yYfZcrELydTeoXYliBd318ooXst2jaQqr3lForqkT7MVqqCSNEyltuOVNVDg0leB KAlA== X-Gm-Message-State: AEkoouv8zliCj2X77hVId6ZhS9GGiszl0Y+EVghF8JspR8cOUPqDMdWg/2HJPKC9Nt4Gpg== X-Received: by 10.55.162.138 with SMTP id l132mr64798848qke.85.1470060834211; Mon, 01 Aug 2016 07:13:54 -0700 (PDT) Received: from SantoshBrain (pool-173-73-91-110.washdc.fios.verizon.net. [173.73.91.110]) by smtp.gmail.com with ESMTPSA id i192sm17720269qke.5.2016.08.01.07.13.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Aug 2016 07:13:53 -0700 (PDT) From: "Santosh Chokhani" To: "'Jim Schaad'" , "'SPASM'" References: <011a01d1ebba$c98eabf0$5cac03d0$@augustcellars.com> In-Reply-To: <011a01d1ebba$c98eabf0$5cac03d0$@augustcellars.com> Date: Mon, 1 Aug 2016 10:14:00 -0400 Message-ID: <007f01d1ebfe$f3b549e0$db1fdda0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGtkLMQJwATQMXJYsph6EImpvGC/aB82snw Content-Language: en-us Archived-At: Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 14:14:02 -0000 Jim, For S/MIME 3.5 is SHA 256 with P521 intentional or typo? -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, August 1, 2016 2:06 AM To: 'SPASM' Subject: [Spasm] Change of Algorithms: Signature Algorithms This message looks at Signature Algorithms. Please restrict your discussions to this set of algorithms, I will be sending out messages on other algorithms over time. Current Document for S/MIME 3.1 MUST: RSA w/ SHA-256 SHOULD+: DSA w/ SHA-256, RSASSA-PSS w/ SHA-256 SHOULD-: RSA w/ SHA-1, DSA w/SHA-1, RSA w/ MD5 Historic: Key Sizes: RSA and DSA - sign SHOULD NOT Key size <= 1023 SHOULD 1024 <= key size <= 2048 MAY 2048 < key size RSA and DSA - Verify MAY key size <= 1023 MUST 1024 <= key size <= 2048 MAY 2048 < key size RSA - Certificate Verify MAY key size <= 1023 MUST 1024 <= key size <= 4096 MAY 4096 < key size DSA - Certificate Verify MAY key size <= 1023 MUST 1024 <= key size <= 3072 Proposed for S/MIME 3.5 MUST: RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519 MUST-: RSA w/ SHA-256 SHOULD+: SHOULD: RSA-PSS w/ SHA-512, ECDSA P-521 w/ SHA-256, EdDSA448 SHOULD-: DSA w/ SHA-256 Historic: RSA w/ SHA-1, DSA w/ SHA-1, RSA w/ MD5 Key Sizes: RSA and DSA - sign SHOULD NOT Key size <= 2048 SHOULD 2048 <= key size <= 4096 MAY 4096 < key size RSA and DSA - Verify MAY key size <= 2048 MUST 2048 <= key size <= 4096 MAY 4096 < key size RSA - Certificate Verify MAY key size <= 2048 MUST 2048 <= key size <= 4096 MAY 4096 < key size DSA - Certificate Verify MAY key size <= 1023 MUST 1024 <= key size <= 3072 Questions: 1. Should DSA be dropped to historic for messages and just left as SHOULD- for certificates, I don't know how many DSA certificates actually exist. 2. I have changed to lower limits on RSA but not DSA for certificate verification - should it be changed as well? Again I don't know how many DSA certificates exist. 3. I don't think that any statements for ECDSA on key size need to be made separately from the algorithm support list. Does any body disagree? Jim _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Aug 1 08:23:09 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB8912DC53 for ; Mon, 1 Aug 2016 08:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, 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 F0dbfshXz6F7 for ; Mon, 1 Aug 2016 08:23:05 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E6112DC2E for ; Mon, 1 Aug 2016 08:23:05 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 1 Aug 2016 08:29:08 -0700 From: Jim Schaad To: 'Blake Ramsdell' References: <011a01d1ebba$c98eabf0$5cac03d0$@augustcellars.com> In-Reply-To: Date: Mon, 1 Aug 2016 08:22:55 -0700 Message-ID: <01bb01d1ec08$94d0a410$be71ec30$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BC_01D1EBCD.E8726850" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGtkLMQJwATQMXJYsph6EImpvGC/QKQim/5oGhrLkA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 15:23:07 -0000 ------=_NextPart_000_01BC_01D1EBCD.E8726850 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Can=E2=80=99t really get rid of RSA as a signature algorithm. Need the P-256 algorithm for the world of NIST Need EdDSA for the world of NIST is not to be trusted. =20 Jim =20 =20 From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Blake Ramsdell Sent: Monday, August 01, 2016 2:17 AM To: Jim Schaad Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms =20 On Jul 31, 2016 11:06 PM, "Jim Schaad" > wrote: > Proposed for S/MIME 3.5 > > MUST: RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519 Why are there three MUST algorithms? ------=_NextPart_000_01BC_01D1EBCD.E8726850 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Can=E2=80=99t= really get rid of RSA as a signature algorithm.

Need the = P-256 algorithm for the world of NIST

Need EdDSA = for the world of NIST is not to be trusted.

 

Jim

 

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Blake = Ramsdell
Sent: Monday, August 01, 2016 2:17 AM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: [Spasm] Change of = Algorithms: Signature Algorithms

 

On Jul 31, 2016 11:06 PM, = "Jim Schaad" <ietf@augustcellars.com> = wrote:
> Proposed for S/MIME 3.5
>
> MUST: RSA-PSS w/ = SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519

Why are = there three MUST algorithms?

------=_NextPart_000_01BC_01D1EBCD.E8726850-- From nobody Mon Aug 1 08:23:56 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873EC12DC41 for ; Mon, 1 Aug 2016 08:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 iwxGPPwTXfaz for ; Mon, 1 Aug 2016 08:23:53 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C871112DC2E for ; Mon, 1 Aug 2016 08:23:52 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 1 Aug 2016 08:30:01 -0700 From: Jim Schaad To: 'Santosh Chokhani' , 'SPASM' References: <011a01d1ebba$c98eabf0$5cac03d0$@augustcellars.com> <007f01d1ebfe$f3b549e0$db1fdda0$@gmail.com> In-Reply-To: <007f01d1ebfe$f3b549e0$db1fdda0$@gmail.com> Date: Mon, 1 Aug 2016 08:23:48 -0700 Message-ID: <01c001d1ec08$b5054510$1f0fcf30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGtkLMQJwATQMXJYsph6EImpvGC/QLJibHcoGajlTA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 15:23:54 -0000 Yes, it is a typo. It should have been P521 w/ SHA 512. jim > -----Original Message----- > From: Santosh Chokhani [mailto:santosh.chokhani@gmail.com] > Sent: Monday, August 01, 2016 7:14 AM > To: 'Jim Schaad' ; 'SPASM' > Subject: RE: [Spasm] Change of Algorithms: Signature Algorithms > > Jim, > > For S/MIME 3.5 is SHA 256 with P521 intentional or typo? > > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Monday, August 1, 2016 2:06 AM > To: 'SPASM' > Subject: [Spasm] Change of Algorithms: Signature Algorithms > > This message looks at Signature Algorithms. Please restrict your discussions to > this set of algorithms, I will be sending out messages on other algorithms over > time. > > Current Document for S/MIME 3.1 > > MUST: RSA w/ SHA-256 > SHOULD+: DSA w/ SHA-256, RSASSA-PSS w/ SHA-256 > SHOULD-: RSA w/ SHA-1, DSA w/SHA-1, RSA w/ MD5 > Historic: > > Key Sizes: > RSA and DSA - sign > SHOULD NOT Key size <= 1023 > SHOULD 1024 <= key size <= 2048 > MAY 2048 < key size > > RSA and DSA - Verify > MAY key size <= 1023 > MUST 1024 <= key size <= 2048 > MAY 2048 < key size > > RSA - Certificate Verify > MAY key size <= 1023 > MUST 1024 <= key size <= 4096 > MAY 4096 < key size > > DSA - Certificate Verify > MAY key size <= 1023 > MUST 1024 <= key size <= 3072 > > > > Proposed for S/MIME 3.5 > > MUST: RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519 > MUST-: RSA w/ SHA-256 > SHOULD+: > SHOULD: RSA-PSS w/ SHA-512, ECDSA P-521 w/ SHA-256, EdDSA448 > SHOULD-: DSA w/ SHA-256 > Historic: RSA w/ SHA-1, DSA w/ SHA-1, RSA w/ MD5 > > Key Sizes: > RSA and DSA - sign > SHOULD NOT Key size <= 2048 > SHOULD 2048 <= key size <= 4096 > MAY 4096 < key size > > RSA and DSA - Verify > MAY key size <= 2048 > MUST 2048 <= key size <= 4096 > MAY 4096 < key size > > RSA - Certificate Verify > MAY key size <= 2048 > MUST 2048 <= key size <= 4096 > MAY 4096 < key size > > DSA - Certificate Verify > MAY key size <= 1023 > MUST 1024 <= key size <= 3072 > > > Questions: > > 1. Should DSA be dropped to historic for messages and just left as SHOULD- for > certificates, I don't know how many DSA certificates actually exist. > > 2. I have changed to lower limits on RSA but not DSA for certificate verification - > should it be changed as well? Again I don't know how many DSA certificates > exist. > > 3. I don't think that any statements for ECDSA on key size need to be made > separately from the algorithm support list. Does any body disagree? > > Jim > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Aug 1 10:03:56 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE68E12D0FF for ; Mon, 1 Aug 2016 10:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 m0bkNkx7FwXI for ; Mon, 1 Aug 2016 10:03:53 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2390312D0E3 for ; Mon, 1 Aug 2016 10:03:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E6D5D300596 for ; Mon, 1 Aug 2016 13:03:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BJvY7aanubc9 for ; Mon, 1 Aug 2016 13:03:49 -0400 (EDT) Received: from [192.168.1.28] (nc-71-50-129-15.dyn.embarqhsd.net [71.50.129.15]) by mail.smeinc.net (Postfix) with ESMTPSA id 813ED300265; Mon, 1 Aug 2016 13:03:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> Date: Mon, 1 Aug 2016 13:03:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 17:03:55 -0000 Jim: In my view, AES-192 should not be included in the MUST or SHOULD = statements. We should be silent about it, which means that it MAY be = implemented. Further, I think that AES-128 CBC MUST be implemented, to provide a = point of transition for 3.1 to 3.5. Russ On Aug 1, 2016, at 1:05 AM, Jim Schaad wrote: > I am not back onto a normal daylight schedule and have gotten through = a > couple of other documents so I am ready to start dealing with issues = in the > S/MIME documents. So this is the first of a series of open issue = messages > that I will start dribbling out as things seem to come to a = conclusion. >=20 > This message looks at Content Encryption Algorithms. Please restrict = your > discussions to this set of algorithms, I will be sending out messages = on > other algorithm times over time. >=20 > Current Document for S/MIME 3.1 >=20 > MUST: AES-128 CBC > SHOULD+: AES-192 CBC and AES-256 CBC > SHOULD-: DES EDE3 CBC (tripleDES) > Historic: RC2/40 >=20 > Proposed for S/MIME 3.5 >=20 > MUST: AES-192 CBC, AES-256 CBC, AES-256 GCM > SHOULD+: ChaCha20/Poly1305 (256-bit) > SHOULD-: AES-128 CBC > Historic: RC2/40, DES EDE3 CBC (tripleDES) >=20 > Questions: > 1. The jump from MUST to SHOULD- may be too aggressive for AES-128 = CBC, we > should potentially state this as MUST- but I think being aggressive = makes > more sense as we want to go to all AEAD algorithms in next version. >=20 > 2. No recommendation for: AES-128 GCM or AES-192 GCM, should there = be? How > do people feel about 128 and 192 bit algorithms? >=20 > 3. Do we want to downgrade all of the CBC algorithms in favor of GCM > algorithms? >=20 > Jim >=20 >=20 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Aug 1 10:41:41 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86B012DB5B for ; Mon, 1 Aug 2016 10:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 WMn31YCJ0hBC for ; Mon, 1 Aug 2016 10:41:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889D812B018 for ; Mon, 1 Aug 2016 10:41:37 -0700 (PDT) Received: from [10.158.17.221] (unknown [199.119.233.156]) by tuna.sandelman.ca (Postfix) with ESMTPSA id A5EDF200A3; Mon, 1 Aug 2016 13:51:47 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----MRNOGJ2SWNMUOYMX19NQSHN54MW7P8" Content-Transfer-Encoding: 8bit From: Michael Richardson Date: Mon, 01 Aug 2016 13:41:26 -0400 To: Russ Housley ,Jim Schaad Message-ID: <4D5AFDDA-C1C8-460F-90D3-A45A0E84F7C6@sandelman.ca> Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 17:41:40 -0000 ------MRNOGJ2SWNMUOYMX19NQSHN54MW7P8 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 why do you say that AES192 is not an interesting algorithm in the progress towards support of stronger algs? not worth the step, market confusion... On 1 August 2016 13:03:49 GMT-04:00, Russ Housley wrote: >Jim: > >In my view, AES-192 should not be included in the MUST or SHOULD >statements. We should be silent about it, which means that it MAY be >implemented. > >Further, I think that AES-128 CBC MUST be implemented, to provide a >point of transition for 3.1 to 3.5. > >Russ > > >On Aug 1, 2016, at 1:05 AM, Jim Schaad wrote: > >> I am not back onto a normal daylight schedule and have gotten through >a >> couple of other documents so I am ready to start dealing with issues >in the >> S/MIME documents. So this is the first of a series of open issue >messages >> that I will start dribbling out as things seem to come to a >conclusion. >> >> This message looks at Content Encryption Algorithms. Please restrict >your >> discussions to this set of algorithms, I will be sending out messages >on >> other algorithm times over time. >> >> Current Document for S/MIME 3.1 >> >> MUST: AES-128 CBC >> SHOULD+: AES-192 CBC and AES-256 CBC >> SHOULD-: DES EDE3 CBC (tripleDES) >> Historic: RC2/40 >> >> Proposed for S/MIME 3.5 >> >> MUST: AES-192 CBC, AES-256 CBC, AES-256 GCM >> SHOULD+: ChaCha20/Poly1305 (256-bit) >> SHOULD-: AES-128 CBC >> Historic: RC2/40, DES EDE3 CBC (tripleDES) >> >> Questions: >> 1. The jump from MUST to SHOULD- may be too aggressive for AES-128 >CBC, we >> should potentially state this as MUST- but I think being aggressive >makes >> more sense as we want to go to all AEAD algorithms in next version. >> >> 2. No recommendation for: AES-128 GCM or AES-192 GCM, should there >be? How >> do people feel about 128 and 192 bit algorithms? >> >> 3. Do we want to downgrade all of the CBC algorithms in favor of GCM >> algorithms? >> >> Jim >> >> >> >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm > >_______________________________________________ >Spasm mailing list >Spasm@ietf.org >https://www.ietf.org/mailman/listinfo/spasm -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------MRNOGJ2SWNMUOYMX19NQSHN54MW7P8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit why do you say that AES192 is not an interesting algorithm in the progress towards support of stronger algs? not worth the step, market confusion...

On 1 August 2016 13:03:49 GMT-04:00, Russ Housley <housley@vigilsec.com> wrote:
Jim:

In my view, AES-192 should not be included in the MUST or SHOULD statements.  We should be silent about it, which means that it MAY be implemented.

Further, I think that AES-128 CBC MUST be implemented, to provide a point of transition for 3.1 to 3.5.

Russ


On Aug 1, 2016, at 1:05 AM, Jim Schaad <ietf@augustcellars.com> wrote:

 I am not back onto a normal daylight schedule and have gotten through a
 couple of other documents so I am ready to start dealing with issues in the
 S/MIME documents.  So this is the first of a series of open issue messages
 that I will start dribbling out as things seem to come to a conclusion.
 
 This message looks at Content Encryption Algorithms.  Please restrict your
 discussions to this set of algorithms, I will be
sending out messages on
 other algorithm times over time.
 
 Current Document for S/MIME 3.1
 
 MUST: AES-128 CBC
 SHOULD+: AES-192 CBC and AES-256 CBC
 SHOULD-: DES EDE3 CBC (tripleDES)
 Historic: RC2/40
 
 Proposed for S/MIME 3.5
 
 MUST:  AES-192 CBC, AES-256 CBC, AES-256 GCM
 SHOULD+: ChaCha20/Poly1305 (256-bit)
 SHOULD-: AES-128 CBC
 Historic: RC2/40, DES EDE3 CBC (tripleDES)
 
 Questions:
 1.  The jump from MUST to SHOULD- may be too aggressive for AES-128 CBC, we
 should potentially state this as MUST- but I think being aggressive makes
 more sense as we want to go to all AEAD algorithms in next version.
 
 2.  No recommendation for: AES-128 GCM or AES-192 GCM, should there be?  How
 do people feel about 128 and 192 bit algorithms?
 
 3.  Do we want to downgrade all of the CBC algorithms in favor of GCM
 algorithms?
 
 Jim
 


 
 

 Spasm mailing list
 Spasm@ietf.org
 https://www.ietf.org/mailman/listinfo/spasm


Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------MRNOGJ2SWNMUOYMX19NQSHN54MW7P8-- From nobody Mon Aug 1 10:56:02 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19BA12D755 for ; Mon, 1 Aug 2016 10:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 Rzz0yNY0Xu8v for ; Mon, 1 Aug 2016 10:55:59 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9721512B018 for ; Mon, 1 Aug 2016 10:55:59 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 1 Aug 2016 11:01:48 -0700 From: Jim Schaad To: 'Russ Housley' References: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> In-Reply-To: Date: Mon, 1 Aug 2016 10:55:34 -0700 Message-ID: <01eb01d1ec1d$e8cdc060$ba694120$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIPrQ0rVM71b5yax3rKTP2+WC5mNAIeHAson6fwu7A= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 17:56:02 -0000 Would MUST- be reasonable for AES-128 CBC? jim > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Monday, August 01, 2016 10:04 AM > To: Jim Schaad > Cc: SPASM > Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms > > Jim: > > In my view, AES-192 should not be included in the MUST or SHOULD statements. > We should be silent about it, which means that it MAY be implemented. > > Further, I think that AES-128 CBC MUST be implemented, to provide a point of > transition for 3.1 to 3.5. > > Russ > > > On Aug 1, 2016, at 1:05 AM, Jim Schaad wrote: > > > I am not back onto a normal daylight schedule and have gotten through > > a couple of other documents so I am ready to start dealing with issues > > in the S/MIME documents. So this is the first of a series of open > > issue messages that I will start dribbling out as things seem to come to a > conclusion. > > > > This message looks at Content Encryption Algorithms. Please restrict > > your discussions to this set of algorithms, I will be sending out > > messages on other algorithm times over time. > > > > Current Document for S/MIME 3.1 > > > > MUST: AES-128 CBC > > SHOULD+: AES-192 CBC and AES-256 CBC > > SHOULD-: DES EDE3 CBC (tripleDES) > > Historic: RC2/40 > > > > Proposed for S/MIME 3.5 > > > > MUST: AES-192 CBC, AES-256 CBC, AES-256 GCM > > SHOULD+: ChaCha20/Poly1305 (256-bit) > > SHOULD-: AES-128 CBC > > Historic: RC2/40, DES EDE3 CBC (tripleDES) > > > > Questions: > > 1. The jump from MUST to SHOULD- may be too aggressive for AES-128 > > CBC, we should potentially state this as MUST- but I think being > > aggressive makes more sense as we want to go to all AEAD algorithms in next > version. > > > > 2. No recommendation for: AES-128 GCM or AES-192 GCM, should there > > be? How do people feel about 128 and 192 bit algorithms? > > > > 3. Do we want to downgrade all of the CBC algorithms in favor of GCM > > algorithms? > > > > Jim > > > > > > > > > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Aug 1 11:21:14 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECA212DD37 for ; Mon, 1 Aug 2016 11:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seyr1nKkiTIY for ; Mon, 1 Aug 2016 11:21:11 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C7612DD38 for ; Mon, 1 Aug 2016 11:21:11 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id f65so380347650wmi.0 for ; Mon, 01 Aug 2016 11:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c33AJY/540LQs7HBpONyks/QjVdJsyQBP2tMgtzjhfI=; b=ajToO0hm84UU5M8RwfjN0dgDySxe2zw0su3BIm1kjUQ7J+BKYYxq6ubu0Cp4chfpQh 0X9JT+ehX2Z1Uy5LBLua59lIYqZw6PRRNXhL31qLG7AEPxDCTJ/9mKP+31A3wUbdy69q IYjcr4zojJu1KDHgoGC3EF9wSMW2B4O1MEJ5D5XsBdQMFaZUGB7tyn/oFYuEbCkX5pRc mdkFWP+bgKGUox9ymifTKAZryFmfmmZAddfscTphmZXhjzw1xvWGJnAIIlwaM9j3VXZL I8lvHqTfEC2PfoTGhllOqvVZylnnC0LZrFyhXBw+yYe+OIj+JkIysi6HTHI2n9c1mqRD g8wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c33AJY/540LQs7HBpONyks/QjVdJsyQBP2tMgtzjhfI=; b=TNEf5eQLK8spnZuO4b+Ug45VAxQ4r+7mNlLi/eFeQmfofZlhCHK1qRMr/AJAbXcDmW ug8ZFvHnqmSZ1EzeqbtIt4ncTFs06whNSzVwbPZmvhSvr6shE6psFkb1Gy4pAQU41ooe 0vEQQTlXb9Ezkk7CYS87HTCZ8XfVZ1WPY5ptL68qGvPP8pebu2amzau778rJN4X5gLAC DLEG4lgubGEcBWOjPtsyENy4n7f8GWOeoNdVKeKn/DrcziYR+bYGRZC27W6pfbqQSQ9D S87BXKoECfh9S3Ll+CLPDrdsKdIFdJwbvL7Hzq5E/dHINO9WNGS/ZddVJscld42502D1 AYNw== X-Gm-Message-State: AEkooutVDSkLinyWW6xfKNKlWCkFGF15UsyDZhOmHJHQg16UV+0EGp6twXmE7M51ksXs6T+ADP/Ky3rjYIZF9w== X-Received: by 10.28.222.8 with SMTP id v8mr15859912wmg.55.1470075669459; Mon, 01 Aug 2016 11:21:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.59.35 with HTTP; Mon, 1 Aug 2016 11:21:08 -0700 (PDT) In-Reply-To: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> References: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> From: Blake Ramsdell Date: Mon, 1 Aug 2016 11:21:08 -0700 Message-ID: To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 18:21:13 -0000 I am going to ask this for every MUST that has multiple options for every algorithm type, so you might consider pre-emptively having a statement for why there are multiple options. On Sun, Jul 31, 2016 at 10:05 PM, Jim Schaad wrote: > Proposed for S/MIME 3.5 > > MUST: AES-192 CBC, AES-256 CBC, AES-256 GCM Why are there three MUST algorithms? I'll further elaborate that I think there should be one for compatibility with that old algorithm that we used to use, one for teh new hotness algorithm that we're going to use now, and one SHOULD or SHOULD+ for the "on deck" algorithm. From nobody Mon Aug 1 11:36:28 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C0912D13E for ; Mon, 1 Aug 2016 11:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 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, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 JrnNF3nBEWAM for ; Mon, 1 Aug 2016 11:36:25 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id CB95B12B00B for ; Mon, 1 Aug 2016 11:36:25 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4184B433409; Mon, 1 Aug 2016 18:36:25 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 2A39F433404; Mon, 1 Aug 2016 18:36:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1470076585; bh=5pmdgkZY9E6yDvcuYyamlcPNoxADLtFVVqunfNMG+hg=; l=564; h=From:To:CC:Date:References:In-Reply-To:From; b=TiREdl6hPyMNWXxAnzn36YrWESuTliAPLhbvcK86S91vs0TX31PrYW/igBEWmgLsA lNW2Ug+hTieJWYXvIPn+BhmDqETtZXjbSVwaYWWk7ypiLw86LGsyKRpYhLX/mPc2Zb cqZql8xHu2YMsVDpMfww5vvXW8NUbyS9jiMNMW9Y= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 25D1E1FC86; Mon, 1 Aug 2016 18:36:25 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 1 Aug 2016 14:36:24 -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.1178.000; Mon, 1 Aug 2016 14:36:24 -0400 From: "Salz, Rich" To: Michael Richardson , Russ Housley , Jim Schaad Thread-Topic: [Spasm] Change of Algorithms: Content Encryption Algorithms Thread-Index: AdHrrpzyX3DwxgkpTuS8xt5E6Mmi6AAiZYmAAAFQUgAAB3V24A== Date: Mon, 1 Aug 2016 18:36:23 +0000 Message-ID: <7ac40b105318481d81f63983c9b92fe0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> <4D5AFDDA-C1C8-460F-90D3-A45A0E84F7C6@sandelman.ca> In-Reply-To: <4D5AFDDA-C1C8-460F-90D3-A45A0E84F7C6@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 18:36:26 -0000 PiB3aHkgZG8geW91IHNheSB0aGF0IEFFUzE5MiBpcyBub3QgYW4gaW50ZXJlc3RpbmcgYWxnb3Jp dGhtIGluIHRoZSBwcm9ncmVzcyB0b3dhcmRzIHN1cHBvcnQgb2Ygc3Ryb25nZXIgYWxncz8gbm90 IHdvcnRoIHRoZSBzdGVwLCBtYXJrZXQgY29uZnVzaW9uLi4uIA0KDQoNCkkgYWdyZWUgd2l0aCBS dXNzIHRoYXQgQUVTMTkyIGlzIG5vdCBpbnRlcmVzdGluZy4gIE5vdCB0byBzcGVhayBmb3IgUnVz cywgYnV0IG15IHJlYXNvbnMgaW5jbHVkZSB3aGF0IHlvdSBsaXN0ZWQgYWJvdmUgYW5kIGFsc28g dGhhdCB0aW1lcyBoYXZlIGNoYW5nZWQgYW5kIHdlIG5vIGxvbmdlciBkbyB0aGUgImtpdGNoZW4g c2luayIgYXBwcm9hY2ggb2YgdGhyb3dpbmcgaW4gZXZlcnkgY2lwaGVyIHRoYXQgInNlZW1zIHJl YXNvbmFibGUiDQo= From nobody Mon Aug 1 11:40:36 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D16012D127 for ; Mon, 1 Aug 2016 11:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 L1yUNlXQJmFp for ; Mon, 1 Aug 2016 11:40:27 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBE112D186 for ; Mon, 1 Aug 2016 11:40:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A66483004C3 for ; Mon, 1 Aug 2016 14:40:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iehED4c7mVkL for ; Mon, 1 Aug 2016 14:40:23 -0400 (EDT) Received: from [192.168.1.28] (nc-71-50-129-15.dyn.embarqhsd.net [71.50.129.15]) by mail.smeinc.net (Postfix) with ESMTPSA id 48607300422; Mon, 1 Aug 2016 14:40:23 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_70FE11EB-0634-42F3-B063-D660A28AE97C" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <4D5AFDDA-C1C8-460F-90D3-A45A0E84F7C6@sandelman.ca> Date: Mon, 1 Aug 2016 14:40:23 -0400 Message-Id: <072D7929-04A4-43AA-9FB8-92A0EE48F942@vigilsec.com> References: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> <4D5AFDDA-C1C8-460F-90D3-A45A0E84F7C6@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM , Jim Schaad Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 18:40:35 -0000 --Apple-Mail=_70FE11EB-0634-42F3-B063-D660A28AE97C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michael: Jim suggested that AES-256 as SHOULD+. We have seen people select = AES-128 or AES-256, but ignore the middle ground in other applications. = So, AES-192 will not help with the interoperability goal. Russ On Aug 1, 2016, at 1:41 PM, Michael Richardson wrote: > why do you say that AES192 is not an interesting algorithm in the = progress towards support of stronger algs? not worth the step, market = confusion...=20 >=20 > On 1 August 2016 13:03:49 GMT-04:00, Russ Housley = wrote: > Jim: >=20 > In my view, AES-192 should not be included in the MUST or SHOULD = statements. We should be silent about it, which means that it MAY be = implemented. >=20 > Further, I think that AES-128 CBC MUST be implemented, to provide a = point of transition for 3.1 to 3.5. >=20 > Russ >=20 >=20 > On Aug 1, 2016, at 1:05 AM, Jim Schaad wrote: >=20 > I am not back onto a normal daylight schedule and have gotten through = a > couple of other documents so I am ready to start dealing with issues = in the > S/MIME documents. So this is the first of a series of open issue = messages > that I will start dribbling out as things seem to come to a = conclusion. > =20 > This message looks at Content Encryption Algorithms. Please restrict = your > discussions to this set of algorithms, I will be > sending out messages on > other algorithm times over time. > =20 > Current Document for S/MIME 3.1 > =20 > MUST: AES-128 CBC > SHOULD+: AES-192 CBC and AES-256 CBC > SHOULD-: DES EDE3 CBC (tripleDES) > Historic: RC2/40 > =20 > Proposed for S/MIME 3.5 > =20 > MUST: AES-192 CBC, AES-256 CBC, AES-256 GCM > SHOULD+: ChaCha20/Poly1305 (256-bit) > SHOULD-: AES-128 CBC > Historic: RC2/40, DES EDE3 CBC (tripleDES) > =20 > Questions: > 1. The jump from MUST to SHOULD- may be too aggressive for AES-128 = CBC, we > should potentially state this as MUST- but I think being aggressive = makes > more sense as we want to go to all AEAD algorithms in next version. > =20 > 2. No recommendation for: AES-128 GCM or AES-192 GCM, should there = be? How > do people feel about 128 and 192 bit algorithms? > =20 > 3. Do we want to downgrade all of the CBC algorithms in favor of GCM > algorithms? > =20 > Jim > =20 >=20 >=20 > =20 > =20 >=20 > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 >=20 > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_70FE11EB-0634-42F3-B063-D660A28AE97C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Michael:

Jim suggested that = AES-256 as SHOULD+.  We have seen people select AES-128 or AES-256, = but ignore the middle ground in other applications.  So, AES-192 = will not help with the interoperability = goal.

Russ


On Aug 1, 2016, at 1:41 PM, Michael Richardson <mcr@sandelman.ca> = wrote:

why do you say that AES192 is not an interesting = algorithm in the progress towards support of stronger algs? not worth = the step, market confusion...

On 1 = August 2016 13:03:49 GMT-04:00, Russ Housley <housley@vigilsec.com> = wrote:
Jim:

In my view, AES-192 should not be =
included in the MUST or SHOULD statements.  We should be silent about =
it, which means that it MAY be implemented.

Further, I think that =
AES-128 CBC MUST be implemented, to provide a point of transition for =
3.1 to 3.5.

Russ


On Aug 1, 2016, at 1:05 AM, Jim =
Schaad <ietf@augustcellars.com> =
wrote:

 I am not =
back onto a normal daylight schedule and have gotten through a
 =
couple of other documents so I am ready to start dealing with issues in =
the
 S/MIME documents.  So this is the first of a series of open =
issue messages
 that I will start dribbling out as things seem to =
come to a conclusion.
 
 This message looks at Content Encryption =
Algorithms.  Please restrict your
 discussions to this set of =
algorithms, I will be
sending out messages on
 other algorithm times over time.
 
 =
Current Document for S/MIME 3.1
 
 MUST: AES-128 CBC
 SHOULD+: =
AES-192 CBC and AES-256 CBC
 SHOULD-: DES EDE3 CBC (tripleDES)
 =
Historic: RC2/40
 
 Proposed for S/MIME 3.5
 
 MUST:  =
AES-192 CBC, AES-256 CBC, AES-256 GCM
 SHOULD+: ChaCha20/Poly1305 =
(256-bit)
 SHOULD-: AES-128 CBC
 Historic: RC2/40, DES EDE3 CBC =
(tripleDES)
 
 Questions:
 1.  The jump from MUST to SHOULD- =
may be too aggressive for AES-128 CBC, we
 should potentially state =
this as MUST- but I think being aggressive makes
 more sense as we =
want to go to all AEAD algorithms in next version.
 
 2.  No =
recommendation for: AES-128 GCM or AES-192 GCM, should there be?  =
How
 do people feel about 128 and 192 bit algorithms?
 
 3.  Do =
we want to downgrade all of the CBC algorithms in favor of GCM
 =
algorithms?
 
 Jim
 


 
 

 Spasm mailing list
 Spasm@ietf.org
 https://www.ietf.org/=
mailman/listinfo/spasm


Spasm mailing =
list
Spasm@ietf.org
https://www.ietf.org/=
mailman/listinfo/spasm

--
Sent from my Android device with K-9 Mail. Please excuse my = brevity.
_______________________________________________
Spasm = mailing list
Spasm@ietf.org
https://www.ietf.org/= mailman/listinfo/spasm

= --Apple-Mail=_70FE11EB-0634-42F3-B063-D660A28AE97C-- From nobody Mon Aug 1 11:41:08 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798E812D18F for ; Mon, 1 Aug 2016 11:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 IIWdNdaf0Rj6 for ; Mon, 1 Aug 2016 11:41:05 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A68212D13E for ; Mon, 1 Aug 2016 11:41:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4809A3005A5 for ; Mon, 1 Aug 2016 14:41:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VkYei4jNio3O for ; Mon, 1 Aug 2016 14:41:02 -0400 (EDT) Received: from [192.168.1.28] (nc-71-50-129-15.dyn.embarqhsd.net [71.50.129.15]) by mail.smeinc.net (Postfix) with ESMTPSA id C0984300422; Mon, 1 Aug 2016 14:41:01 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <01eb01d1ec1d$e8cdc060$ba694120$@augustcellars.com> Date: Mon, 1 Aug 2016 14:41:02 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> <01eb01d1ec1d$e8cdc060$ba694120$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 18:41:06 -0000 Jim: Yes, that would be fine with me. Russ On Aug 1, 2016, at 1:55 PM, Jim Schaad wrote: > Would MUST- be reasonable for AES-128 CBC? > > jim > >> -----Original Message----- >> From: Russ Housley [mailto:housley@vigilsec.com] >> Sent: Monday, August 01, 2016 10:04 AM >> To: Jim Schaad >> Cc: SPASM >> Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms >> >> Jim: >> >> In my view, AES-192 should not be included in the MUST or SHOULD > statements. >> We should be silent about it, which means that it MAY be implemented. >> >> Further, I think that AES-128 CBC MUST be implemented, to provide a point > of >> transition for 3.1 to 3.5. >> >> Russ >> >> >> On Aug 1, 2016, at 1:05 AM, Jim Schaad wrote: >> >>> I am not back onto a normal daylight schedule and have gotten through >>> a couple of other documents so I am ready to start dealing with issues >>> in the S/MIME documents. So this is the first of a series of open >>> issue messages that I will start dribbling out as things seem to come to > a >> conclusion. >>> >>> This message looks at Content Encryption Algorithms. Please restrict >>> your discussions to this set of algorithms, I will be sending out >>> messages on other algorithm times over time. >>> >>> Current Document for S/MIME 3.1 >>> >>> MUST: AES-128 CBC >>> SHOULD+: AES-192 CBC and AES-256 CBC >>> SHOULD-: DES EDE3 CBC (tripleDES) >>> Historic: RC2/40 >>> >>> Proposed for S/MIME 3.5 >>> >>> MUST: AES-192 CBC, AES-256 CBC, AES-256 GCM >>> SHOULD+: ChaCha20/Poly1305 (256-bit) >>> SHOULD-: AES-128 CBC >>> Historic: RC2/40, DES EDE3 CBC (tripleDES) >>> >>> Questions: >>> 1. The jump from MUST to SHOULD- may be too aggressive for AES-128 >>> CBC, we should potentially state this as MUST- but I think being >>> aggressive makes more sense as we want to go to all AEAD algorithms in > next >> version. >>> >>> 2. No recommendation for: AES-128 GCM or AES-192 GCM, should there >>> be? How do people feel about 128 and 192 bit algorithms? >>> >>> 3. Do we want to downgrade all of the CBC algorithms in favor of GCM >>> algorithms? >>> >>> Jim >>> >>> >>> >>> >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://www.ietf.org/mailman/listinfo/spasm > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Aug 1 11:59:31 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4CA12D867 for ; Mon, 1 Aug 2016 11:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 lptyV9ADiFoT for ; Mon, 1 Aug 2016 11:59:28 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0488F12D186 for ; Mon, 1 Aug 2016 11:59:28 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 1 Aug 2016 12:05:04 -0700 From: Jim Schaad To: 'Blake Ramsdell' References: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> In-Reply-To: Date: Mon, 1 Aug 2016 11:58:50 -0700 Message-ID: <020901d1ec26$bf698110$3e3c8330$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIPrQ0rVM71b5yax3rKTP2+WC5mNAIjysX2n6fUVhA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 18:59:30 -0000 I would say that as a general rule, we should always have a minimum of two MUST algorithms everywhere so that we have a backup in case of failure. I would therefore accept arguments about having three items but not two items. Jim > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Blake Ramsdell > Sent: Monday, August 01, 2016 11:21 AM > To: Jim Schaad > Cc: SPASM > Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms > > I am going to ask this for every MUST that has multiple options for every > algorithm type, so you might consider pre-emptively having a statement for why > there are multiple options. > > On Sun, Jul 31, 2016 at 10:05 PM, Jim Schaad wrote: > > Proposed for S/MIME 3.5 > > > > MUST: AES-192 CBC, AES-256 CBC, AES-256 GCM > > Why are there three MUST algorithms? > > I'll further elaborate that I think there should be one for compatibility with that > old algorithm that we used to use, one for teh new hotness algorithm that we're > going to use now, and one SHOULD or > SHOULD+ for the "on deck" algorithm. > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Aug 2 03:14:10 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCE812B058 for ; Tue, 2 Aug 2016 03:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.081 X-Spam-Level: X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 IOIj7b9TR6tx for ; Tue, 2 Aug 2016 03:14:07 -0700 (PDT) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) (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 BF1BA12B049 for ; Tue, 2 Aug 2016 03:14:06 -0700 (PDT) Received: from Morten ([62.44.135.142]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id 4201608021214011166 for ; Tue, 02 Aug 2016 12:14:01 +0200 From: "Erik Andersen" To: "SPASM" Date: Tue, 2 Aug 2016 12:14:04 +0200 Message-ID: <000001d1eca6$99252650$cb6f72f0$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D1ECB7.5CAF2ED0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdHsmI3gX+PA4ANDSvS/HUw/GPUgDA== Content-Language: en-gb Archived-At: Subject: [Spasm] Use of CMS X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 10:14:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D1ECB7.5CAF2ED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am working on a new edition of X.1080.1. The current version claims to use CMS without any details. It is also crap otherwise. It is supposed to provide a general framework for telebiometrics protocols. It the general model there is an exchange that sets up a session. Within the session there may be several exchanges. The envelopedData contents type using the keyAgreement options is used together with the signedData content type. However, it seems a little heavy to use the key agreement method for every exchange. My thinking is to use the AuthenticatedData content type together with AES-GCM (aes256-GCM) as defined in RFC 5480 for all exchanges except for the first one and then reuse the pairwise key-encryption key generated during the first exchange by using the KEKRecipientInfo type specified in section 6.2.3. However, the KEKRecipientInfo data type requires a mandatory key Identifier. I have not seen that the pairwise key-encryption key is allocated a key identifier. (Such an key identifier is not actually needed, as there is only one key in play. ) It seems it is a little against the spirit of CMS to do what I am suggesting. Kind regards, Erik ------=_NextPart_000_0001_01D1ECB7.5CAF2ED0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am working = on a new edition of X.1080.1. The current version claims to use CMS = without any details. It is also crap otherwise. It is supposed to = provide a general framework for telebiometrics = protocols.

 

It the general model there is an exchange that sets up = a session. Within the session there may be several exchanges. The = envelopedData contents type using the keyAgreement options is used = together with the signedData content type. However, it seems a little = heavy to use the key agreement method for every exchange. =

 

My thinking is to use the AuthenticatedData content = type together with AES-GCM (aes256-GCM) as defined in RFC 5480 for all = exchanges except for the first one and then reuse the pairwise = key-encryption key generated during the first exchange by using the = KEKRecipientInfo type specified in section 6.2.3. However, the = KEKRecipientInfo data type requires a mandatory key

Identifier. I have not seen that the pairwise = key-encryption key is allocated a key identifier. (Such an key = identifier is not actually needed, as there is only one key in play. = )

 

It seems it is a little against the spirit of CMS to = do what I am suggesting.

 

Kind = regards,

 

Erik

=

------=_NextPart_000_0001_01D1ECB7.5CAF2ED0-- From nobody Tue Aug 2 04:55:32 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B6212D549 for ; Tue, 2 Aug 2016 04:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 hguGRY5O9eN3 for ; Tue, 2 Aug 2016 04:55:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D7312D50C for ; Tue, 2 Aug 2016 04:55:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 491682009E; Tue, 2 Aug 2016 08:05:43 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A5914638D1; Tue, 2 Aug 2016 07:55:28 -0400 (EDT) From: Michael Richardson To: Jim Schaad In-Reply-To: <020901d1ec26$bf698110$3e3c8330$@augustcellars.com> References: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> <020901d1ec26$bf698110$3e3c8330$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: 'Blake Ramsdell' , 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 11:55:31 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > I would say that as a general rule, we should always have a minimum of two > MUST algorithms everywhere so that we have a backup in case of failure. I > would therefore accept arguments about having three items but not two > items. okay, but I don't entirely consider AES128 and AES256 to be different algorithms. Depends upon the nature of the failure. CGM (or other CTR-type modes) and not-CGM are more different, but, the right failure could take them all out at the same time, I think. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV6CKLYCLcPvd0N1lAQI6BQf8CQLlreS3Gd38IxtKphMfoUq8P5FLs0yp Jto0zmgbjOHTFeOjqc2FoP7NPxM91J886zzXwbTUZXhEBmnLvMFKOOzZTNQF/ZVb IZ3kpK2sjnGuXWjXYaX9Aumx41ph2qrS83vUnJhETmgMYHOkXczZxtaEclWTV9Mg wpr4GVM3JmT+PGtn/VNlUDblxADBcZLI4IB3mLMHQcDxGNtl5GHkY3ZvoB3/ORLq jTIDlDaTiB0kUbWMRCjaiu4XgwK+mU8YQh/wCnkjy/LmxejtSt7sugjAiZTmrEIq oAhyw/j/ZpCzw7gCdholpMNXBeDlXspYc3G3YgtNtaiIIDJXW8RItg== =c9Pu -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 2 07:15:21 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4251512D743 for ; Tue, 2 Aug 2016 07:15:19 -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 (1024-bit key) header.d=sn3rd.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 IanN_8HY0cL0 for ; Tue, 2 Aug 2016 07:15:15 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3320412D630 for ; Tue, 2 Aug 2016 07:15:11 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id v123so42916631qkh.3 for ; Tue, 02 Aug 2016 07:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sXynpYmVsXkXlAupgugzw/q0vcKrEBlW9Tt7rY0xx5s=; b=YHmSoeFC1nnNHRZmGjR64XkK6ysFFrN2uyReWIm1s7fElcFtbT7x1u9ZxAkzXCVFVp xQwVEV2hMgCBnGRnkjMgR2J8M/hhdU6zTn2v+buUWsbJiq+XtvEOEAP7bpuUVX0Se3TQ RfnNoOH8M2fVOEDk/dDnNsHuNmEJ2sasrZmog= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sXynpYmVsXkXlAupgugzw/q0vcKrEBlW9Tt7rY0xx5s=; b=OFOMXRsJKCX0mSbfg7Udr1Q2AFiC/R3iE8ddacPWpBpeCZBZU7LZfsjmHVm1preeFf 15kTbE7DwfX1mec00VS+EtPN2iVcbr9h2G7ALOni/g7CHgR85fBEaOUIV3twXHc8GFui G3Bk69PJJZF5qJN8wrBIjrNOTgZx4+VGUaVnciDmn32EN45n2+ub1Q0low9r6zhH5V4O 2NhfzvA37Bxsxwo3wfqjDCeVc9q9JlrrP127ENXBeLoG+e8yky1SDX9O1IGT+xUZqXgb XJCimndgFJRb0IzJ8+nUkmYRo/OpSKTCOE0QkdWugAXvxrm/lINCYyPkjC5spKDEAxjl uWiA== X-Gm-Message-State: AEkooutfqSjgk05PkhfPrMij+gkrWX/gwzRC5MKLENoEWOneKH2Rcd7G7D1D0WUPTSiM/Q== X-Received: by 10.55.144.6 with SMTP id s6mr72637324qkd.6.1470147310258; Tue, 02 Aug 2016 07:15:10 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-123-93.washdc.east.verizon.net. [173.73.123.93]) by smtp.gmail.com with ESMTPSA id j38sm1430103qtj.35.2016.08.02.07.15.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Aug 2016 07:15:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <011a01d1ebba$c98eabf0$5cac03d0$@augustcellars.com> Date: Tue, 2 Aug 2016 10:15:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <011a01d1ebba$c98eabf0$5cac03d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 14:15:19 -0000 On Aug 01, 2016, at 02:06, Jim Schaad wrote: >=20 > Proposed for S/MIME 3.5 I=E2=80=99m really thinking this should be v4, but I guess that=E2=80=99s = for another thread. > MUST: RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519 > MUST-: RSA w/ SHA-256 > SHOULD+: > SHOULD: RSA-PSS w/ SHA-512, ECDSA P-521 w/ SHA-256, EdDSA448 {snark}Sigh I guess we=E2=80=99ll do this for those that are paranoid = =E2=80=A6 here=E2=80=99s to the race to =E2=80=9C11=E2=80=9D.{/snark} > SHOULD-: DSA w/ SHA-256 > Historic: RSA w/ SHA-1, DSA w/ SHA-1, RSA w/ MD5 >=20 > Key Sizes: > RSA and DSA - sign > SHOULD NOT Key size <=3D 2048 > SHOULD 2048 <=3D key size <=3D 4096 > MAY 4096 < key size =20 >=20 > RSA and DSA - Verify > MAY key size <=3D 2048 > MUST 2048 <=3D key size <=3D 4096 > MAY 4096 < key size >=20 > RSA - Certificate Verify > MAY key size <=3D 2048 > MUST 2048 <=3D key size <=3D 4096 > MAY 4096 < key size >=20 > DSA - Certificate Verify > MAY key size <=3D 1023 > MUST 1024 <=3D key size <=3D 3072 I=E2=80=99m sure there was a reason to include the MAYs back in the day = but maybe we can drop them entirely? I mean you may shoot yourself in = the foot, but we don=E2=80=99t MAY that. If they=E2=80=99re going to = remain I think they=E2=80=99re supposed to be "<=3D 2047=E2=80=9D = otherwise 2048 is both a MUST an a MAY. > Questions: >=20 > 1. Should DSA be dropped to historic for messages and just left as = SHOULD- > for certificates, I don't know how many DSA certificates actually = exist. I=E2=80=99m all for moving DSA to historic. I=E2=80=99m also not sure = how many DSA certificates are out there either, but the real question is = if anybody is actually going to update their code to do S/MIME v4 with = DSA. I doubt it. I know it=E2=80=99s not apples to apples but we asked about DSA = certificates in the TLS WG we got crickets. > 2. I have changed to lower limits on RSA but not DSA for certificate > verification - should it be changed as well? Again I don't know how = many > DSA certificates exist. See 1 so this is OBE. > 3. I don't think that any statements for ECDSA on key size need to be = made > separately from the algorithm support list. Does any body disagree? I agree with you that I think we could drop these. I=E2=80=99ve not = seen people go oh an ECDSA key on p-256 needs a 192-bit key. spt= From nobody Tue Aug 2 09:10:33 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E42A12D137 for ; Tue, 2 Aug 2016 09:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, 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 wHwF5Qd22HY8 for ; Tue, 2 Aug 2016 09:10:29 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2788212D580 for ; Tue, 2 Aug 2016 09:10:29 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 2 Aug 2016 09:21:30 -0700 From: Jim Schaad To: 'Erik Andersen' , 'SPASM' References: <000001d1eca6$99252650$cb6f72f0$@x500.eu> In-Reply-To: <000001d1eca6$99252650$cb6f72f0$@x500.eu> Date: Tue, 2 Aug 2016 09:09:56 -0700 Message-ID: <02f801d1ecd8$510bbd70$f3233850$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F9_01D1EC9D.A4ADA8C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGymIGRMGgUPn9JgSzof+M4Im4gyKB0f3zA Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Spasm] Use of CMS X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 16:10:31 -0000 ------=_NextPart_000_02F9_01D1EC9D.A4ADA8C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Try taking a look at 3185, this did something similar to what you are discussing. jim From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Erik Andersen Sent: Tuesday, August 02, 2016 3:14 AM To: SPASM Subject: [Spasm] Use of CMS Hi, I am working on a new edition of X.1080.1. The current version claims to use CMS without any details. It is also crap otherwise. It is supposed to provide a general framework for telebiometrics protocols. It the general model there is an exchange that sets up a session. Within the session there may be several exchanges. The envelopedData contents type using the keyAgreement options is used together with the signedData content type. However, it seems a little heavy to use the key agreement method for every exchange. My thinking is to use the AuthenticatedData content type together with AES-GCM (aes256-GCM) as defined in RFC 5480 for all exchanges except for the first one and then reuse the pairwise key-encryption key generated during the first exchange by using the KEKRecipientInfo type specified in section 6.2.3. However, the KEKRecipientInfo data type requires a mandatory key Identifier. I have not seen that the pairwise key-encryption key is allocated a key identifier. (Such an key identifier is not actually needed, as there is only one key in play. ) It seems it is a little against the spirit of CMS to do what I am suggesting. Kind regards, Erik ------=_NextPart_000_02F9_01D1EC9D.A4ADA8C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Try taking a look at 3185, this did something similar = to what you are discussing.

 

jim

 

From: Spasm = [mailto:spasm-bounces@ietf.org] On Behalf Of Erik = Andersen
Sent: Tuesday, August 02, 2016 3:14 AM
To: = SPASM <spasm@ietf.org>
Subject: [Spasm] Use of = CMS

 

Hi,

 

I am working on a new edition of X.1080.1. The current = version claims to use CMS without any details. It is also crap = otherwise. It is supposed to provide a general framework for = telebiometrics protocols.

 

It the general model there is an = exchange that sets up a session. Within the session there may be several = exchanges. The envelopedData contents type using the keyAgreement = options is used together with the signedData content type. However, it = seems a little heavy to use the key agreement method for every exchange. =

 

My thinking is to use the AuthenticatedData content type = together with AES-GCM (aes256-GCM) as defined in RFC 5480 for all = exchanges except for the first one and then reuse the pairwise = key-encryption key generated during the first exchange by using the = KEKRecipientInfo type specified in section 6.2.3. However, the = KEKRecipientInfo data type requires a mandatory = key

Identifier. I have not seen that the pairwise = key-encryption key is allocated a key identifier. (Such an key = identifier is not actually needed, as there is only one key in play. = )

 

It seems it is a little against the spirit of CMS to do = what I am suggesting.

 

Kind regards,

 

Erik

 

------=_NextPart_000_02F9_01D1EC9D.A4ADA8C0-- From nobody Tue Aug 2 09:11:16 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B24712D580 for ; Tue, 2 Aug 2016 09:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, 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 87lEsn1bGBTH for ; Tue, 2 Aug 2016 09:11:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036C312D137 for ; Tue, 2 Aug 2016 09:11:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7A6702009E; Tue, 2 Aug 2016 12:21:28 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 41D62638D1; Tue, 2 Aug 2016 12:11:13 -0400 (EDT) From: Michael Richardson To: Sean Turner In-Reply-To: References: <011a01d1ebba$c98eabf0$5cac03d0$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: SPASM , Jim Schaad Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 16:11:15 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sean Turner wrote: > I=E2=80=99m sure there was a reason to include the MAYs back in the d= ay but > maybe we can drop them entirely? I mean you may shoot yourself in the > foot, but we don=E2=80=99t MAY that. If they=E2=80=99re going to rem= ain I think > they=E2=80=99re supposed to be "<=3D 2047=E2=80=9D otherwise 2048 is = both a MUST an a > MAY. The reason to include a MAY is so that you can interoperate with an old product (where it was a SHOULD or MUST). Having it in the code base doesn't mean it is enabled... We aren't all running browsers that can upgraded wil= ly-nilly... Having it in the code base, of course, might mean having a bug. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV6DGHoCLcPvd0N1lAQJxqQf/VOHXuQUhL3AIFhEChds4QBBYfACs/S6B ZAn0l6Hz1aX+2MULAD2Z0yImnK6V9BDmuNjaUDc51XhWoF1/KYWApheIi3JWdaoY fIQUzKDvwPZjFmLjaQbe4JL9poGSCw9w7UD6iA44h9/RmqMjsg5llkCgcNfBRVvZ AwJ5OnX9A53RgOykxOY0k0+bQK913a2kfWyGx4USfiqpmlAb3JYFiv9d3/yb3Y31 9lp3Sz/CEmY8TnQ5KnlsVRuprC3qJUkRd30GaXYia8Wc5o0p6fivxOrO4nmHcK1h KwtPG0b1kxvSrQH4Wz0sby3uDzVhCFgyq1eDcs84z/ZEJD2aONsuig== =G0iX -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 2 09:15:07 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A2E12D7D9 for ; Tue, 2 Aug 2016 09:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 OhdOQc2D0H3e for ; Tue, 2 Aug 2016 09:15:04 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C8912D7CA for ; Tue, 2 Aug 2016 09:15:04 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 2 Aug 2016 09:26:13 -0700 From: Jim Schaad To: 'Michael Richardson' References: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> <020901d1ec26$bf698110$3e3c8330$@augustcellars.com> <13700.1470138928@obiwan.sandelman.ca> In-Reply-To: <13700.1470138928@obiwan.sandelman.ca> Date: Tue, 2 Aug 2016 09:14:38 -0700 Message-ID: <02fd01d1ecd8$f9dff470$ed9fdd50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIPrQ0rVM71b5yax3rKTP2+WC5mNAIjysX2AVvHsHMClTXVv5+JsMtQ Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'Blake Ramsdell' , 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 16:15:06 -0000 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Michael > Richardson > Sent: Tuesday, August 02, 2016 4:55 AM > To: Jim Schaad > Cc: 'Blake Ramsdell' ; 'SPASM' > Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms > > > Jim Schaad wrote: > > I would say that as a general rule, we should always have a minimum of two > > MUST algorithms everywhere so that we have a backup in case of failure. I > > would therefore accept arguments about having three items but not two > > items. > > okay, but I don't entirely consider AES128 and AES256 to be different algorithms. > Depends upon the nature of the failure. CGM (or other CTR-type > modes) and not-CGM are more different, but, the right failure could take them > all out at the same time, I think. I would agree with you that the different modes with AES are not really different algorithms as the core primitive is the same. I don't believe that we are yet justified to making ChaCha20 into a MUST algorithm. We cannot get rid of CBC because of backwards compatibility. We need to get into GCM for AEAD support, which is a significant step forward. I may be overly agreessive about trying to jump to all 256 bit key lengths however. Im > > -- > Michael Richardson , Sandelman Software Works -= > IPv6 IoT consulting =- > > From nobody Tue Aug 2 12:11:55 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B4212D8E5 for ; Tue, 2 Aug 2016 12:11:53 -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 (1024-bit key) header.d=sn3rd.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 tgQ2G89wLOrl for ; Tue, 2 Aug 2016 12:11:52 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2714412D8E6 for ; Tue, 2 Aug 2016 12:11:52 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id s63so184207624qkb.2 for ; Tue, 02 Aug 2016 12:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3q6O5RuyEe4pN0o87jD8+/YI6Fq562SoQuTB1GCM96o=; b=FkVMJ3xoXAhKP04Ax4FKAGCmTlqcL+qaU71R1gA/Qg/IQGaYaQfSHI6M9MIhy8QmUB ojxu93jxbFFkf2YwRTA8z/nJ4Ls+QSG7rlutmSz1hkaWtLgMkMAznkCb5AJce8OeyhZS 66x6qpvxav6Vw7rcOZMlYUftk+T4merlfhJMM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3q6O5RuyEe4pN0o87jD8+/YI6Fq562SoQuTB1GCM96o=; b=XSgGzrUQLoXTBc7CZfO17TWfwNo9jDmqynwm6TrA6Fx81UQfGcd/9TtAD2w2nNGKAg aqOqb+T+fc9OE/N4tQo0lLk3jBKWHZQHk8nKdMaUdNfc4YUTvR7Alp9XlAk41RYbIDvd dNv41BPUW4MGSK12hJkKJ3RuTCDhdcLAmqNJju3SsNPNtbrA+npmr6bweapMmVKTa1Rp DT58BHtuM7MCdr/HtPyJV8yRF6TUZHFB51JRdiCtmZ2M0lKqAr9njJoF5LCZOTKwqEfp KmF8TpPur8SBgnDGytn82tlOJnfRNzs7Prr8oQWKcUId2SAZwWlmCdoMwAHCmmgphXUM mypg== X-Gm-Message-State: AEkoousroq9y5BLn9ZMsGquTpWzMu+SABB30kcSF204lxIc1jYUxp8GWnbuemrIUkVWC+w== X-Received: by 10.55.4.133 with SMTP id 127mr79461172qke.207.1470165111213; Tue, 02 Aug 2016 12:11:51 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-123-93.washdc.east.verizon.net. [173.73.123.93]) by smtp.gmail.com with ESMTPSA id d142sm2069239qkc.33.2016.08.02.12.11.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Aug 2016 12:11:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <2551.1470154273@obiwan.sandelman.ca> Date: Tue, 2 Aug 2016 15:11:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <011a01d1ebba$c98eabf0$5cac03d0$@augustcellars.com> <2551.1470154273@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SPASM , Jim Schaad Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 19:11:54 -0000 On Aug 02, 2016, at 12:11, Michael Richardson = wrote: >=20 >=20 > Sean Turner wrote: >> I=E2=80=99m sure there was a reason to include the MAYs back in the = day but >> maybe we can drop them entirely? I mean you may shoot yourself in = the >> foot, but we don=E2=80=99t MAY that. If they=E2=80=99re going to = remain I think >> they=E2=80=99re supposed to be "<=3D 2047=E2=80=9D otherwise 2048 is = both a MUST an a >> MAY. >=20 > The reason to include a MAY is so that you can interoperate with an = old > product (where it was a SHOULD or MUST). Having it in the code base = doesn't > mean it is enabled... We aren't all running browsers that can = upgraded willy-nilly... >=20 > Having it in the code base, of course, might mean having a bug. I can get on board with that rationale for the MAY, but it might be = better to be explicit about what=E2=80=99s required to interop with = older versions. spt= From nobody Tue Aug 2 12:16:46 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5754A12D8E8 for ; Tue, 2 Aug 2016 12:16:44 -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 (1024-bit key) header.d=sn3rd.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 VQcr8jk9GOhL for ; Tue, 2 Aug 2016 12:16:43 -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 E6D8712D8C1 for ; Tue, 2 Aug 2016 12:16:42 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id s63so184335071qkb.2 for ; Tue, 02 Aug 2016 12:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZcOsx0z/xirbyCfbLmGdywIfAXjIMo+2o/bBVakYDaI=; b=HwP1Ai3SzqlH8cCuYK6LwpPjaejwBTtJGHykCeZmd1GGcGWyilCu8B+C0LsxOsgO11 qmXhQeJyJQArXp8geXB2FB7KDB+dQideI2FVJdYdG+ohj09lHcJy/p3jwDLNcgRDVfQg +ZbMgliAxDetZwwxz15Fzl7Sn9Vkdksgxxj7s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZcOsx0z/xirbyCfbLmGdywIfAXjIMo+2o/bBVakYDaI=; b=FvTNkLa+Py/rcdGeWRgf6y9wnUL+Pa3TKfPBKG9pOvL72M09LouupfJsD2M41cAdqL oAFge7jRq8QWKYM9pDMU8vEtFB5W9tUQVLrp+JpvLVv0GQDSPPcJX25R2OVGgylkEtEB /cyeq90LKQ2STZeG8tspePBHLLc3H4rzSsPhu/8gSermOhFPNRwlVFM09/nvcOFqnjXw dmTSWbWVQiTr2PQP2Co5+MDPwrgpa6Rxbqhdy38W9W3LvEX9rUei9g+AoiygBCEMe7t5 aRUUFM/xy0+t5VCGq6iLjReI6hZxHL+YNBwyOQ9gjPJro32fHDuMsY2XJUSxL4nMhpBG 2AQA== X-Gm-Message-State: AEkoouulGMn/uRGxnh7NfdXYmcBqSD9rRxtCF7HVGSD78kllfAwbModeFQWf2P4j+fX3Ow== X-Received: by 10.233.216.2 with SMTP id u2mr79703690qkf.203.1470165402075; Tue, 02 Aug 2016 12:16:42 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-123-93.washdc.east.verizon.net. [173.73.123.93]) by smtp.gmail.com with ESMTPSA id w10sm2094925qtc.28.2016.08.02.12.16.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Aug 2016 12:16:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <02fd01d1ecd8$f9dff470$ed9fdd50$@augustcellars.com> Date: Tue, 2 Aug 2016 15:16:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <011101d1ebb2$442449f0$cc6cddd0$@augustcellars.com> <020901d1ec26$bf698110$3e3c8330$@augustcellars.com> <13700.1470138928@obiwan.sandelman.ca> <02fd01d1ecd8$f9dff470$ed9fdd50$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Blake Ramsdell , Michael Richardson , SPASM Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 19:16:44 -0000 On Aug 02, 2016, at 12:14, Jim Schaad wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Michael >> Richardson >> Sent: Tuesday, August 02, 2016 4:55 AM >> To: Jim Schaad >> Cc: 'Blake Ramsdell' ; 'SPASM' >> Subject: Re: [Spasm] Change of Algorithms: Content Encryption = Algorithms >>=20 >>=20 >> Jim Schaad wrote: >>> I would say that as a general rule, we should always have a minimum > of two >>> MUST algorithms everywhere so that we have a backup in case of > failure. I >>> would therefore accept arguments about having three items but not > two >>> items. >>=20 >> okay, but I don't entirely consider AES128 and AES256 to be different > algorithms. >> Depends upon the nature of the failure. CGM (or other CTR-type >> modes) and not-CGM are more different, but, the right failure could = take > them >> all out at the same time, I think. >=20 > I would agree with you that the different modes with AES are not = really > different algorithms as the core primitive is the same. I don't = believe > that we are yet justified to making ChaCha20 into a MUST algorithm.=20 >=20 > We cannot get rid of CBC because of backwards compatibility. We need = to get > into GCM for AEAD support, which is a significant step forward. I may = be > overly agreessive about trying to jump to all 256 bit key lengths = however. Maybe I=E2=80=99m not on the same page as everybody else, but I=E2=80=99ve= been thinking that we=E2=80=99re going to add AuthEnvelopedData as the = MUST implement for this version and retain EnvelopedData, SignedData, = and EnvelopedData+SignedData for backward compatibility. If that=E2=80=99= s the case do we need to up the CBC sizes at all? spt From nobody Sun Aug 7 14:03:39 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5893212D591 for ; Sun, 7 Aug 2016 14:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, 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 wX1OzKEKvU95 for ; Sun, 7 Aug 2016 14:03:36 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E2B12B069 for ; Sun, 7 Aug 2016 14:03:35 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 7 Aug 2016 14:15:09 -0700 From: Jim Schaad To: 'SPASM' Date: Sun, 7 Aug 2016 14:03:04 -0700 Message-ID: <01d801d1f0ef$18a68030$49f38090$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D9_01D1F0B4.6C4B0390" X-Mailer: Microsoft Outlook 16.0 thread-index: AdHw7J5OEFMA7q1BRdqlI6xLCewd1g== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Spasm] Change of Algorithms: Content Encryption Algorithms - Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 21:03:38 -0000 ------=_NextPart_000_01D9_01D1F0B4.6C4B0390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have looked at the responses to the original mail and am updating the mail to reflect what I thought I saw as comments. This message looks at Content Encryption Algorithms. Please restrict your discussions to this set of algorithms, I will be sending out messages on other algorithm times over time. Current Document for S/MIME 3.1 MUST: AES-128 CBC SHOULD+: AES-192 CBC and AES-256 CBC SHOULD-: DES EDE3 CBC (tripleDES) Historic: RC2/40 Proposed for S/MIME 3.5 MUST: AES-192 CBC, AES-256 CBC, AES-256 GCM MUST-: AES-128 CBC SHOULD+: ChaCha20/Poly1305 (256-bit) SHOULD-: AES-128 CBC Historic: RC2/40, DES EDE3 CBC (tripleDES) Take 2 State: With this set we now have two MUST algorithms with the same primitive. We are indicating that we think that ChaCha20/Poly1305 will become a MUST in the future so we have stated a potential fail over algorithm if AES or GCM go into the tank for any reason. More comments are welcome. Questions: 1. The jump from MUST to SHOULD- may be too aggressive for AES-128 CBC, we should potentially state this as MUST- but I think being aggressive makes more sense as we want to go to all AEAD algorithms in next version. Take 2 state: Russ said that yes I was. As I suggested on the list I have pushed this back up to a MUST-. 2. No recommendation for: AES-128 GCM or AES-192 GCM, should there be? How do people feel about 128 and 192 bit algorithms? Take 2 state: List appears to say that we should not say anything about 192-bit algorithms. However people did not comment on the -128 vs -256 question so I have left the recommendation of AES-256 GCM alone. 3. Do we want to downgrade all of the CBC algorithms in favor of GCM algorithms? Take 2 state: SPT is the only one who commented on this. I have a tendency to agree with his proposal that we are adding AEAD and we should be pushing that as the preferred algorithm. Making a MUST statement about AES-256 CBC seems to counter act this statement so I have removed it. Jim ------=_NextPart_000_01D9_01D1F0B4.6C4B0390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have looked at the responses to the original mail = and am updating the mail to reflect what I thought I saw as = comments.

 

This message looks at Content Encryption = Algorithms.  Please restrict your discussions to this set of = algorithms, I will be sending out messages on other algorithm times over = time.

 

Current Document for S/MIME 3.1

 

MUST: = AES-128 CBC

SHOULD+: AES-192 CBC = and AES-256 CBC

SHOULD-: DES EDE3 = CBC (tripleDES)

Historic: = RC2/40

 

Proposed for S/MIME 3.5

 

MUST:  AES-192 CBC, AES-256 CBC, = AES-256 GCM

MUST-: AES-128 = CBC

SHOULD+: ChaCha20/Poly1305 = (256-bit)

SHOULD-: = AES-128 CBC

Historic: RC2/40, = DES EDE3 CBC (tripleDES)

 

Take 2 = State: With this set we now have two MUST algorithms with the same = primitive.  We are indicating that we think that ChaCha20/Poly1305 = will become a MUST in the future so we have stated a potential fail over = algorithm if AES or GCM go into the tank for any reason.   = More comments are welcome.

 

Questions:

1.      = The jump from MUST to SHOULD- may be too = aggressive for AES-128 CBC, we should potentially state this as MUST- = but I think being aggressive makes more sense as we want to go to all = AEAD algorithms in next version.

Take 2 state: Russ said = that yes I was.  As I suggested on the list I have pushed this back = up to a MUST-.

 

2.      = No recommendation for: AES-128 GCM or AES-192 = GCM, should there be?  How do people feel about 128 and 192 bit = algorithms?

Take 2 state: List appears to say that we = should not say anything about 192-bit algorithms.  However people = did not comment on the -128 vs -256 question so I have left the = recommendation of AES-256 GCM alone.

 

3.      = Do we want to downgrade all of the CBC = algorithms in favor of GCM algorithms?

Take 2 state:  = SPT is the only one who commented on this.  I have a tendency to = agree with his proposal that we are adding AEAD and we should be pushing = that as the preferred algorithm.  Making a MUST statement about = AES-256 CBC seems to counter act this statement so I have removed = it.

 

Jim

 

 

 

------=_NextPart_000_01D9_01D1F0B4.6C4B0390-- From nobody Sun Aug 7 14:08:32 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4A712D591 for ; Sun, 7 Aug 2016 14:08:30 -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 TR0bReNlt3vp for ; Sun, 7 Aug 2016 14:08:28 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c: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 4B10B12B069 for ; Sun, 7 Aug 2016 14:08:28 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id o80so105210828wme.1 for ; Sun, 07 Aug 2016 14:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+WbMYgZv0mMr+ryrxpu+3u0uP0hdlYePY2QUJRHpLoY=; b=i1aDKBRFW2BwRZRx/C2lIgIF43UbfmNV8Mwf6walSt5lwzskCcz2/dL5V/VUafUo/n mOOKFQelTqrQvThNPoLmudRPNLb5KneC73bxeEIlD4IHXmlIXbMdXy7lsPAXF6NCXLSn JCnEdeLKZ8D4QSqFEbw0ohSZxw7SAsvaKzPWwbKiTyfn19MWHiK5zGN3l9qI9u/gEmxV i7ltw2i12q5Y4EBKvw9cL957mUH2hUKrEw/GvGLM2RmMc4IQ2jsKBPJiX2XormCWHQdM OwYVuVJoKQ+AVBCHEVyNFrKKvDmIY6lafYMitlfDWSU6swBF94BOXczFiSHJpQU5AMEk JVTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+WbMYgZv0mMr+ryrxpu+3u0uP0hdlYePY2QUJRHpLoY=; b=LsypspGDO1uno8f9E/SxUpO24bzXv9VWDbPgiQoE/Pb6BxLZUmaStBtEu7rj3Akw3E +6NBzoXCrxLQzMtRmFp3VUTqkau0Vd9SPTlIvKLstQtq2KcQLAGZL293I496vdxpbM3X vzqfR1W2ZPu3eRuqdlOzOT4v5D2HbJnn1PUxlVfGdbGoFkKTONWdoBfmcFoi+t726gy7 7QLODsREnVe5BLwM/LAIVFiMVAohvmWfnOFfCOCvdZ90vBL592k61aOIrPRWzhUnGGKa dz0852HlNt4AHFb5Y4qWycEwNPoIt7nn8DBrFEVOMDc3nc9ghhhsS1Xz33qmvbWMRgea pnMg== X-Gm-Message-State: AEkooutFt0eejGppQGFZsDyHh1XQb/SPYaRoJmt3PlYw9FqPAGBVaamShlHBRbGPu+05IkIhFfvQAI55V4zv3A== X-Received: by 10.194.23.166 with SMTP id n6mr92219627wjf.36.1470604106755; Sun, 07 Aug 2016 14:08:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.59.35 with HTTP; Sun, 7 Aug 2016 14:08:26 -0700 (PDT) In-Reply-To: <01d801d1f0ef$18a68030$49f38090$@augustcellars.com> References: <01d801d1f0ef$18a68030$49f38090$@augustcellars.com> From: Blake Ramsdell Date: Sun, 7 Aug 2016 14:08:26 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=047d7b5d9ca963753d053981b3b3 Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms - Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 21:08:30 -0000 --047d7b5d9ca963753d053981b3b3 Content-Type: text/plain; charset=UTF-8 +1 plus another one if allowed. I'm happy with this structure. On Sun, Aug 7, 2016 at 2:03 PM, Jim Schaad wrote: > I have looked at the responses to the original mail and am updating the > mail to reflect what I thought I saw as comments. > > > > This message looks at Content Encryption Algorithms. Please restrict your > discussions to this set of algorithms, I will be sending out messages on > other algorithm times over time. > > > > Current Document for S/MIME 3.1 > > > > MUST: AES-128 CBC > > SHOULD+: AES-192 CBC and AES-256 CBC > > SHOULD-: DES EDE3 CBC (tripleDES) > > Historic: RC2/40 > > > > Proposed for S/MIME 3.5 > > > > MUST: AES-192 CBC, AES-256 CBC, AES-256 GCM > > *MUST-: AES-128 CBC* > > SHOULD+: ChaCha20/Poly1305 (256-bit) > > SHOULD-: AES-128 CBC > > Historic: RC2/40, DES EDE3 CBC (tripleDES) > > > > *Take 2 State*: With this set we now have two MUST algorithms with the > same primitive. We are indicating that we think that ChaCha20/Poly1305 > will become a MUST in the future so we have stated a potential fail over > algorithm if AES or GCM go into the tank for any reason. More comments > are welcome. > > > > Questions: > > 1. The jump from MUST to SHOULD- may be too aggressive for AES-128 > CBC, we should potentially state this as MUST- but I think being aggressive > makes more sense as we want to go to all AEAD algorithms in next version. > > *Take 2 state*: Russ said that yes I was. As I suggested on the list I > have pushed this back up to a MUST-. > > > > 2. No recommendation for: AES-128 GCM or AES-192 GCM, should there > be? How do people feel about 128 and 192 bit algorithms? > > *Take 2 state*: List appears to say that we should not say anything about > 192-bit algorithms. However people did not comment on the -128 vs -256 > question so I have left the recommendation of AES-256 GCM alone. > > > > 3. Do we want to downgrade all of the CBC algorithms in favor of GCM > algorithms? > > *Take 2 state*: SPT is the only one who commented on this. I have a > tendency to agree with his proposal that we are adding AEAD and we should > be pushing that as the preferred algorithm. Making a MUST statement about > AES-256 CBC seems to counter act this statement so I have removed it. > > > > Jim > > > > > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --047d7b5d9ca963753d053981b3b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 plus another one if allowed. I'm happy with this st= ructure.

On Sun, A= ug 7, 2016 at 2:03 PM, Jim Schaad <ietf@augustcellars.com> wrote:

I have looked at the responses to the orig= inal mail and am updating the mail to reflect what I thought I saw as comme= nts.

=C2=A0

This message looks at C= ontent Encryption Algorithms.=C2=A0 Please restrict your discussions to thi= s set of algorithms, I will be sending out messages on other algorithm time= s over time.

=C2=A0

Current Documen= t for S/MIME 3.1

=C2=A0

MUST: AES-1= 28 CBC

SHOULD+: AES-192 CBC and AES-256 CBC

SHOULD-: DES EDE3 CBC (tripleDES)

Historic: RC= 2/40

=C2=A0

Proposed for S/MIME 3.5=

=C2=A0

MUST:=C2=A0 AES-192 CBC,= AES-256 CBC, AES-256 GCM

MUST-: AES-128 CBC<= /u>

SHOULD+: ChaCha20/Poly1305 (256-bit)<= /s>

SHOULD-: AES-128 CBC

Historic: RC2/40,= DES EDE3 CBC (tripleDES)

=C2=A0

Take 2 State: With this set we now have two MUST a= lgorithms with the same primitive.=C2=A0 We are indicating that we think th= at ChaCha20/Poly1305 will become a MUST in the future so we have stated a p= otential fail over algorithm if AES or GCM go into the tank for any reason.= =C2=A0=C2=A0 More comments are welcome.

=C2=A0

Questions:

1.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 The jump from MUST to SHOULD- ma= y be too aggressive for AES-128 CBC, we should potentially state this as MU= ST- but I think being aggressive makes more sense as we want to go to all A= EAD algorithms in next version.

Take 2 state: Russ said that = yes I was.=C2=A0 As I suggested on the list I have pushed this back up to a= MUST-.

=C2=A0

2.3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do we want to downgrade all of the CBC algorithms in favor of GCM algo= rithms?

Take 2 state:=C2=A0 SPT is the only one who commented= on this.=C2=A0 I have a tendency to agree with his proposal that we are ad= ding AEAD and we should be pushing that as the preferred algorithm.=C2=A0 M= aking a MUST statement about AES-256 CBC seems to counter act this statemen= t so I have removed it.

<= p>=C2=A0

Jim

=C2=A0

=C2=A0

=C2=A0


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


--047d7b5d9ca963753d053981b3b3-- From nobody Sun Aug 7 14:54:40 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F0812D5A4 for ; Sun, 7 Aug 2016 14:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, 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 jYYZyA1doWqP for ; Sun, 7 Aug 2016 14:54:35 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0707B12D593 for ; Sun, 7 Aug 2016 14:54:35 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 7 Aug 2016 15:06:09 -0700 From: Jim Schaad To: 'SPASM' Date: Sun, 7 Aug 2016 14:54:04 -0700 Message-ID: <01eb01d1f0f6$383f5230$a8bdf690$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EC_01D1F0BB.8BE24EF0" X-Mailer: Microsoft Outlook 16.0 thread-index: AdHw7zjRr7pNe4uWRVmZLKRppVz4Xw== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Spasm] Change of Algorithms: Signature Algorithms Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 21:54:38 -0000 ------=_NextPart_000_01EC_01D1F0BB.8BE24EF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This message looks at Signature Algorithms. Please restrict your discussions to this set of algorithms, I will be sending out messages on other algorithms over time. Current Document for S/MIME 3.1 MUST: RSA w/ SHA-256 SHOULD+: DSA w/ SHA-256, RSASSA-PSS w/ SHA-256 SHOULD-: RSA w/ SHA-1, DSA w/SHA-1, RSA w/ MD5 Historic: Key Sizes: RSA and DSA - sign SHOULD NOT Key size <= 1023 SHOULD 1024 <= key size <= 2048 MAY 2048 < key size RSA and DSA - Verify MAY key size <= 1023 MUST 1024 <= key size <= 2048 MAY 2048 < key size RSA - Certificate Verify MAY key size <= 1023 MUST 1024 <= key size <= 4096 MAY 4096 < key size DSA - Certificate Verify MAY key size <= 1023 MUST 1024 <= key size <= 3072 Proposed for S/MIME 3.5 MUST: RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519 MUST-: RSA w/ SHA-256 SHOULD+: SHOULD: RSA-PSS w/ SHA-512, ECDSA P-521 w/ SHA-256512, EdDSA448 SHOULD-: DSA w/ SHA-256 Historic: RSA w/ SHA-1, DSA w/ SHA-1, RSA w/ MD5, DSA w/ SHA-256 Key Sizes: RSA and DSA - sign SHOULD NOT Key size <= 2048 2047 SHOULD 2048 <= key size <= 4096 MAY 4096 < key size RSA and DSA - Verify Historic MAY key size <= 2048 2047 MUST 2048 <= key size <= 4096 MAY 4096 < key size RSA - Certificate Verify Historic MAY key size <= 2048 2047 MUST 2048 <= key size <= 4096 MAY 4096 < key size DSA - Certificate Verify Historic MAY key size <= 1023 Historic MUST 1024 <= key size <= 3072 Questions: 1. Should DSA be dropped to historic for messages and just left as SHOULD- for certificates, I don't know how many DSA certificates actually exist. Take 2 state: I have removed all DSA from the current set of algorithms for both messages and certificates. This is now historic only 2. I have changed to lower limits on RSA but not DSA for certificate verification - should it be changed as well? Again I don't know how many DSA certificates exist. Take 2 state: I have removed DSA certificates to historic so the question is moot. 3. I don't think that any statements for ECDSA on key size need to be made separately from the algorithm support list. Does anybody disagree? Take 2 state: Nobody said anything to the contrary. So no plans to make a key size section for ECDSA algorithms. 4. NEW: SPT suggested that we should not be making any statements on doing anything with 512 hash values. (Although with tons of standard snark :)). My reasoning for including this was less to do with the fact that I thought the 512-bit hash functions were more efficient on 64-bit hardware (a statement that I cannot find support for with a quick web search for SHA-2) and therefore it made sense from a throughput point of view. I don't think we need the for security and if they are not more efficient I would be in favor not making them SHOULDs 5. NEW: Blake has complained about the number of MUST algorithms that comes out from this list. There are effectively 4 in the list above, as opposed to the 1 that is in the current set of documents. We cannot kill the current MUST so it has to stay. However, all of the new MUSTs could be downgraded from MUST to SHOULD without out any problems. The only issue is that one of them needs to be a MUST so that we have a true MUST not just a MUST- algorithm. Looking at the list my breakdown would be: * RSA-PSS - Given that it has been slow on update the only reason to have it be a MUST is that most people are probably going to have RSA keys today. There are some arguments that say RSA-PSS is no better than RSA-v1.5 when doing real-world analysis. I don't know that I agree with this as I have problems with arguments by analogy. This could easily be a SHOULD instead of a MUST * ECDSA - This is the world of NIST requirements today. I think this justifies it being a MUST * EdDSA - This is the world of NOT MIST requirements today. I think this justifies it being a MUST Jim ------=_NextPart_000_01EC_01D1F0BB.8BE24EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This message looks at Signature Algorithms.  = Please restrict your discussions to this set of algorithms, I will be = sending out messages on other algorithms over time.

 

Current Document for S/MIME 3.1

 

MUST:   RSA w/ SHA-256

SHOULD+:  DSA w/ SHA-256, RSASSA-PSS w/ = SHA-256

SHOULD-:  RSA w/ = SHA-1, DSA w/SHA-1, RSA w/ MD5

Historic:

 

Key = Sizes:

RSA and DSA - = sign

SHOULD = NOT            = Key size <=3D 1023

SHOULD      1024 <=3D = key size <=3D 2048

MAY        &= nbsp;   2048 < key size  

 

RSA = and DSA - Verify

MAY        &= nbsp;       key size <=3D = 1023

MUST      1024 <=3D key = size <=3D 2048

MAY        2048 = < key size

 

RSA - = Certificate Verify

MAY        &= nbsp;    key size <=3D 1023

MUST  1024 <=3D key size <=3D = 4096

MAY      4096  < = key size

 

DSA - Certificate Verify

MAY        &= nbsp;    key size <=3D 1023

MUST    1024 <=3D key size = <=3D 3072

 

 

 

Proposed for S/MIME 3.5

 

MUST: = RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519

MUST-: RSA w/ SHA-256

SHOULD+:

SHOULD:  RSA-PSS w/ SHA-512, ECDSA P-521 w/ = SHA-256512, EdDSA448

SHOULD-: DSA w/ SHA-256

Historic: RSA w/ SHA-1, DSA w/ SHA-1, RSA w/ MD5, = DSA w/ SHA-256

 

Key = Sizes:

RSA and DSA - = sign

SHOULD = NOT            = Key size <=3D 2048 2047

SHOULD      2048 <=3D = key size <=3D 4096

MAY        &= nbsp;    4096 < key size  

 

RSA = and DSA - Verify

Historic = MAY           =      key size <=3D 2048 = 2047

MUST      2048 <=3D key = size <=3D 4096

MAY        4096 = < key size

 

RSA - = Certificate Verify

Historic = MAY           =   key size <=3D 2048 2047

MUST  2048 <=3D key size <=3D = 4096

MAY      4096  < = key size

 

DSA - Certificate Verify

Historic = MAY           =   key size <=3D 1023

Historic MUST   1024 <=3D key = size <=3D 3072

 

 

Questions:

 

1.      = Should DSA be dropped to historic for messages = and just left as SHOULD- for certificates, I don't know how many DSA = certificates actually exist.

Take 2 state: I have removed = all DSA from the current set of algorithms for both messages and = certificates.  This is now historic only

 

2.      = I have changed to lower limits on RSA but not = DSA for certificate verification - should it be changed as well?  = Again I don't know how many DSA certificates exist.

Take 2 = state: I have removed DSA certificates to historic so the question = is moot.

 

3.      = I don't think that any statements for ECDSA on = key size need to be made separately from the algorithm support = list.  Does anybody disagree?

Take 2 state:  = Nobody said anything to the contrary.  So no plans to make a key = size section for ECDSA algorithms.

 

4.      = NEW: SPT suggested that we should not be = making any statements on doing anything with 512 hash values.  = (Although with tons of standard snark J).   My reasoning for = including this was less to do with the fact that I thought the 512-bit = hash functions were more efficient on 64-bit hardware (a statement that = I cannot find support for with a quick web search for SHA-2) and = therefore it made sense from a throughput point of view.   I = don’t think we need the for security and if they are not more = efficient I would be in favor not making them SHOULDs

 

5.      = NEW:  Blake has complained about the = number of MUST algorithms that comes out from this list.  There are = effectively 4 in the list above, as opposed to the 1 that is in the = current set of documents.  We cannot kill the current MUST so it = has to stay.  However, all of the new MUSTs could be downgraded = from MUST to SHOULD without out any problems.  The only issue is = that one of them needs to be a MUST so that we have a true MUST not just = a MUST- algorithm.  Looking at the list my breakdown would = be:

 

·        = RSA-PSS – Given that it has been = slow on update the only reason to have it be a MUST is that most people = are probably going to have RSA keys today.  There are some = arguments that say RSA-PSS is no better than RSA-v1.5 when doing = real-world analysis.  I don’t know that I agree with this as = I have problems with arguments by analogy.   This could easily = be a SHOULD instead of a MUST

·        = ECDSA – This is the world of NIST = requirements today.  I think this justifies it being a = MUST

·        = EdDSA – This is the world of NOT = MIST requirements today.  I think this justifies it being a = MUST

 

Jim

 

------=_NextPart_000_01EC_01D1F0BB.8BE24EF0-- From nobody Sun Aug 7 15:49:25 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A116A12D10F for ; Sun, 7 Aug 2016 15:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247, 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 x3D-234PRvZV for ; Sun, 7 Aug 2016 15:49:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3AF12B019 for ; Sun, 7 Aug 2016 15:49:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0C2E52009E for ; Sun, 7 Aug 2016 18:59:55 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 129D7638BE for ; Sun, 7 Aug 2016 18:49:22 -0400 (EDT) From: Michael Richardson To: "'SPASM'" In-Reply-To: <01eb01d1f0f6$383f5230$a8bdf690$@augustcellars.com> References: <01eb01d1f0f6$383f5230$a8bdf690$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 22:49:24 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > This message looks at Signature Algorithms. Please restrict your > discussions to this set of algorithms, I will be sending out messages > on other algorithms over time. > Current Document for S/MIME 3.1 > MUST: RSA w/ SHA-256 > SHOULD+: DSA w/ SHA-256, DSA has been limited to 1024 keys. I think that this limit was removed, but I'd like to know what you intended here? I guess I also don't understand the 3.1/3.5 distinction. That's my ignorance. I see that you have been trying to capture a key difference between encryption at rest (emails on disk) from IPsec/TLS. We clearly need to be able to look at email that was encrypted years (decades..) ago. I think that the presentation of this distinction might need more clarity. > Questions: > 1. Should DSA be dropped to historic for messages and just left as > SHOULD- for certificates, I don't know how many DSA certificates > actually exist. By "DSA certificates", do you mean end-users here? For awhile, DSA was considered "more secure" by many EU based open source crypto packages. (Not something I agreed with) I don't know how many of those keys were used to create S/MIME messages. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV6e674CLcPvd0N1lAQKP0wgAh+cvOlKvMfJwktf0kmr2T8H53jzLYkOP Qzg30+0XTqIEYSdUG1PXheJ/AKiqvu7eUREZ8jCJ2Z5PSlo3v15UbKz4I4HyAyV9 4fwyDfzfKVbz6dBs/TYvQrgDryzIku8yb0Z3MmDwC0HBQWLL5JHgGNEy8cpl1V79 NtF8hwYkhUs+T70Wy5TxVk9qXEfOuiUc+CumX+Na0RYsjBcoTSXgeeWfC4O/ymj2 DFBZKco6HgluUxC8YKOPsavuPJ67rVZTNMxMgDe3oAUhDmLHRL/a0DkK7N+g0uHV oYPKCu46saqGBqfzdRFM8jbZi0ep+GkkUMVCamMlv/jqNc+3yEFZXA== =v2UR -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 7 16:08:39 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2561C12D177 for ; Sun, 7 Aug 2016 16:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 ctjh3oXpSAdo for ; Sun, 7 Aug 2016 16:08:36 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78BDF12D12E for ; Sun, 7 Aug 2016 16:08:36 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 7 Aug 2016 16:20:09 -0700 From: Jim Schaad To: 'Michael Richardson' , 'SPASM' References: <01eb01d1f0f6$383f5230$a8bdf690$@augustcellars.com> <2146.1470610162@obiwan.sandelman.ca> In-Reply-To: <2146.1470610162@obiwan.sandelman.ca> Date: Sun, 7 Aug 2016 16:08:04 -0700 Message-ID: <01ff01d1f100$8eceda30$ac6c8e90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 thread-index: AQH6Zs1F+AZ+g9clK0MJDseClGlVVAGLZEuon+DWkPA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 23:08:38 -0000 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Michael > Richardson > Sent: Sunday, August 07, 2016 3:49 PM > To: 'SPASM' > Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms Take 2 > > > Jim Schaad wrote: > > This message looks at Signature Algorithms. Please restrict your > > discussions to this set of algorithms, I will be sending out messages > > on other algorithms over time. > > > Current Document for S/MIME 3.1 > > > MUST: RSA w/ SHA-256 > > > SHOULD+: DSA w/ SHA-256, > > DSA has been limited to 1024 keys. > I think that this limit was removed, but I'd like to know what you intended here? > I guess I also don't understand the 3.1/3.5 distinction. That's my ignorance. Yes, this limit was removed. NIST defined a DSA key size for use with the SHA-2 algorithms. > > I see that you have been trying to capture a key difference between encryption > at rest (emails on disk) from IPsec/TLS. We clearly need to be able to look at > email that was encrypted years (decades..) ago. > I think that the presentation of this distinction might need more clarity. I think you need to be looking at the document rather than these mails to get this distinction. S/MIME 3.1 was published as an RFC in 2009. We are in the process of doing an update of these RFCs and thus we are looking at the difference between what was said then (3.1) and what we want to say in the new document (3.5). Old email is covered by the category "Historic". > > > Questions: > > > 1. Should DSA be dropped to historic for messages and just left as > > SHOULD- for certificates, I don't know how many DSA certificates > > actually exist. > > By "DSA certificates", do you mean end-users here? > For awhile, DSA was considered "more secure" by many EU based open source > crypto packages. (Not something I agreed with) I don't know how many of those > keys were used to create S/MIME messages. No, we are looking at DSA certificates throughout the entire certificate chain. When I say certificates, I am talking about certificates and not email. This is why the sentence draws a distinction between certificates and messages. Jim > > -- > Michael Richardson , Sandelman Software Works -= > IPv6 IoT consulting =- > > From nobody Sun Aug 7 19:35:01 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A286F12D50D for ; Sun, 7 Aug 2016 19:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 1tlo40p7pGi0 for ; Sun, 7 Aug 2016 19:34:58 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9A512D1E7 for ; Sun, 7 Aug 2016 19:34:58 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 7 Aug 2016 19:46:59 -0700 From: Jim Schaad To: 'SPASM' Date: Sun, 7 Aug 2016 19:34:53 -0700 Message-ID: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 thread-index: AdHxHLkb/WKu8kQbR8mp88+4cNgIfw== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 02:34:59 -0000 This message looks at Digest Algorithms. Please restrict your discussion to this set of algorithms. I will be sending out messages on other algorithms over time. Note: Digest Algorithms are used for computing the digest of the content. These are not the "same" as the digest algorithms that are used as part of signature algorithms. There may be things one wants to try and keep similar, as we suggest that you use the same digest algorithm, but they are not the same things. Current Document for S/MIME 3.1 MUST: SHA-256 SHOULD-: SHA-1, MD5(for backwards compatibility) Proposed for S/MIME 3.5 MUST: SHA-256 Historic: SHA-1, MD5 Questions: 1. There is only one MUST and no path forward. Is this a problem that needs to be dealt with? EdDSA25519 uses SHA-512 under the covers, does that mean we should make SHA-512 at least a SHOULD here? 2. Is there anybody who wants to standup and argue for adopting in any of the SHA-3 algorithms? Jim From nobody Mon Aug 8 06:36:26 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038A312D5CC for ; Mon, 8 Aug 2016 06:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 r-UazaOLczSk for ; Mon, 8 Aug 2016 06:36:24 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 03D4712D84B for ; Mon, 8 Aug 2016 06:36:06 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E65FD3F4018; Mon, 8 Aug 2016 13:36:05 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id CF8BE3F4004; Mon, 8 Aug 2016 13:36:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1470663365; bh=+Sa93HmTLh6LJRTXipLFGkHdxtvro2Zk0NZc41huGHM=; l=84; h=From:To:CC:Date:References:In-Reply-To:From; b=Z24ImiSYRRZhkJS41b9YTG9bcuVrUSRVZeGpM18LqIrofuOnZCPOdaFDwmtKaSRdA JBx9pom49HSuQJjoT6YPfto/APz9Us6tSL2ctLji1HnNngnB5LbKZQ27d4QRddLqj5 Hlxmf07/BvCRXTu8kJ87Swl/pcZHQDLfIOhE3qS0= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B3CD21FC8D; Mon, 8 Aug 2016 13:36:05 +0000 (GMT) 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.1178.4; Mon, 8 Aug 2016 09:36:05 -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.1178.000; Mon, 8 Aug 2016 09:36:05 -0400 From: "Salz, Rich" To: Jim Schaad Thread-Topic: [Spasm] Change of Algorithms: Content Encryption Algorithms - Take 2 Thread-Index: AdHw7J5OEFMA7q1BRdqlI6xLCewd1gAJL9wAABoZ7KA= Date: Mon, 8 Aug 2016 13:36:05 +0000 Message-ID: References: <01d801d1f0ef$18a68030$49f38090$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.87] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms - Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 13:36:26 -0000 KzEuICBJIGFzc3VtZSB0aGUgcmF0aW9uYWxlIHdpbGwgbWFrZSBpdCBpbnRvIHRoZSBkcmFmdC4N Cg0K From nobody Mon Aug 8 07:07:56 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE50212D746 for ; Mon, 8 Aug 2016 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 7UltwAxJ9VoN for ; Mon, 8 Aug 2016 07:07:55 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFFA126D74 for ; Mon, 8 Aug 2016 07:07:55 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 86991496C19; Mon, 8 Aug 2016 14:07:54 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 70E05496C16; Mon, 8 Aug 2016 14:07:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1470665274; bh=jB5K8mp/pV5kmkTcGvS+cmB6DG5n7LdnH1xrQObdg6M=; l=457; h=From:To:Date:References:In-Reply-To:From; b=cN8nkpeMzzaB3pbC99cMSLPdUVCr2yBeESQFcnUc2gJ5qdgmOq1YhU1Ui63z5wS1F fmTQNi2z/hI1OA0Yh9T2ltkSHRqgkHxwKdp2VFqpQipv22w/rccTa/BFt9mrEtRAD3 DUqWPPhzyxXEOOrliC1ndRnymZo0Hx/xt85UxrRs= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 597151E080; Mon, 8 Aug 2016 14:07:54 +0000 (GMT) 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.1178.4; Mon, 8 Aug 2016 10:07:53 -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.1178.000; Mon, 8 Aug 2016 10:07:53 -0400 From: "Salz, Rich" To: Jim Schaad , 'SPASM' Thread-Topic: [Spasm] Change of Algorithms: Digest Algorithms Thread-Index: AdHxHLkb/WKu8kQbR8mp88+4cNgIfwAYW4fw Date: Mon, 8 Aug 2016 14:07:52 +0000 Message-ID: <3f325b55fd814e6fb45360550c42f74a@usma1ex-dag1mb1.msg.corp.akamai.com> References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> In-Reply-To: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.87] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 14:07:56 -0000 > 1. There is only one MUST and no path forward. Is this a problem that n= eeds > to be dealt with? EdDSA25519 uses SHA-512 under the covers, does that > mean we should make SHA-512 at least a SHOULD here? >=20 > 2. Is there anybody who wants to standup and argue for adopting in any o= f > the SHA-3 algorithms? I'd like to see *something* as a should. I have a slight preference for = SHA512, but could live with SHA3 if others feel strongly. From nobody Mon Aug 8 07:21:38 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1119F12D0D3 for ; Mon, 8 Aug 2016 07:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 4Ju2QoCXKaof for ; Mon, 8 Aug 2016 07:21:33 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E689312D125 for ; Mon, 8 Aug 2016 07:21:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id ED504300572 for ; Mon, 8 Aug 2016 10:21:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id C8w-dRQmaDb2 for ; Mon, 8 Aug 2016 10:21:29 -0400 (EDT) Received: from [192.168.1.28] (nc-71-50-129-15.dyn.embarqhsd.net [71.50.129.15]) by mail.smeinc.net (Postfix) with ESMTPSA id 6A6A73002C2; Mon, 8 Aug 2016 10:21:27 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C33D27C7-9498-419E-903F-458C15EACC20" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <01d801d1f0ef$18a68030$49f38090$@augustcellars.com> Date: Mon, 8 Aug 2016 10:21:13 -0400 Message-Id: References: <01d801d1f0ef$18a68030$49f38090$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms - Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 14:21:35 -0000 --Apple-Mail=_C33D27C7-9498-419E-903F-458C15EACC20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would like to see AES-128 GCM on the MUST list as well. Russ On Aug 7, 2016, at 5:03 PM, Jim Schaad wrote: > I have looked at the responses to the original mail and am updating = the mail to reflect what I thought I saw as comments. > =20 > This message looks at Content Encryption Algorithms. Please restrict = your discussions to this set of algorithms, I will be sending out = messages on other algorithm times over time. > =20 > Current Document for S/MIME 3.1 > =20 > MUST: AES-128 CBC > SHOULD+: AES-192 CBC and AES-256 CBC > SHOULD-: DES EDE3 CBC (tripleDES) > Historic: RC2/40 > =20 > Proposed for S/MIME 3.5 > =20 > MUST: AES-192 CBC, AES-256 CBC, AES-256 GCM > MUST-: AES-128 CBC > SHOULD+: ChaCha20/Poly1305 (256-bit) > SHOULD-: AES-128 CBC > Historic: RC2/40, DES EDE3 CBC (tripleDES) > =20 > Take 2 State: With this set we now have two MUST algorithms with the = same primitive. We are indicating that we think that ChaCha20/Poly1305 = will become a MUST in the future so we have stated a potential fail over = algorithm if AES or GCM go into the tank for any reason. More comments = are welcome. > =20 > Questions: > 1. The jump from MUST to SHOULD- may be too aggressive for = AES-128 CBC, we should potentially state this as MUST- but I think being = aggressive makes more sense as we want to go to all AEAD algorithms in = next version. >=20 > Take 2 state: Russ said that yes I was. As I suggested on the list I = have pushed this back up to a MUST-. > =20 > 2. No recommendation for: AES-128 GCM or AES-192 GCM, should = there be? How do people feel about 128 and 192 bit algorithms? >=20 > Take 2 state: List appears to say that we should not say anything = about 192-bit algorithms. However people did not comment on the -128 vs = -256 question so I have left the recommendation of AES-256 GCM alone. > =20 > 3. Do we want to downgrade all of the CBC algorithms in favor of = GCM algorithms? >=20 > Take 2 state: SPT is the only one who commented on this. I have a = tendency to agree with his proposal that we are adding AEAD and we = should be pushing that as the preferred algorithm. Making a MUST = statement about AES-256 CBC seems to counter act this statement so I = have removed it. > =20 > Jim > =20 > =20 > =20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_C33D27C7-9498-419E-903F-458C15EACC20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = would like to see AES-128 GCM on the MUST list as = well.

Russ


On = Aug 7, 2016, at 5:03 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

I have looked at the = responses to the original mail and am updating the mail to reflect what = I thought I saw as comments.
 
This = message looks at Content Encryption Algorithms.  Please restrict = your discussions to this set of algorithms, I will be sending out = messages on other algorithm times over time.
 
Current Document for S/MIME 3.1
 
MUST: = AES-128 CBC
SHOULD+: AES-192 CBC = and AES-256 CBC
SHOULD-: DES EDE3 = CBC (tripleDES)
Historic: = RC2/40
 
Proposed = for S/MIME 3.5
 
MUST:  AES-192 CBC, AES-256 = CBC, AES-256 = GCM
MUST-: AES-128 = CBC
SHOULD+: = ChaCha20/Poly1305 (256-bit)
SHOULD-: AES-128 CBC
Historic: RC2/40, DES EDE3 CBC = (tripleDES)
 
Take 2 = State: With this set we now have two MUST algorithms with the same = primitive.  We are indicating that we think that ChaCha20/Poly1305 = will become a MUST in the future so we have stated a potential fail over = algorithm if AES or GCM go into the tank for any reason.   = More comments are welcome.
 
Questions:
1.      The jump from = MUST to SHOULD- may be too aggressive for AES-128 CBC, we should = potentially state this as MUST- but I think being aggressive makes more = sense as we want to go to all AEAD algorithms in next = version.

Take 2 state: Russ said that yes I was.  As = I suggested on the list I have pushed this back up to a = MUST-.
 
2.      No = recommendation for: AES-128 GCM or AES-192 GCM, should there be?  = How do people feel about 128 and 192 bit algorithms?

Take 2 = state: List appears to say that we should not say anything about = 192-bit algorithms.  However people did not comment on the -128 vs = -256 question so I have left the recommendation of AES-256 GCM = alone.
 
3.      Do we want to = downgrade all of the CBC algorithms in favor of GCM = algorithms?

Take 2 state:  SPT is the only one who = commented on this.  I have a tendency to agree with his proposal = that we are adding AEAD and we should be pushing that as the preferred = algorithm.  Making a MUST statement about AES-256 CBC seems to = counter act this statement so I have removed it.
 
Jim
 
 
 
________________________________= _______________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_C33D27C7-9498-419E-903F-458C15EACC20-- From nobody Mon Aug 8 07:39:32 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238FA12D605 for ; Mon, 8 Aug 2016 07:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 6-MOeovD846E for ; Mon, 8 Aug 2016 07:39:28 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D012E12D83F for ; Mon, 8 Aug 2016 07:39:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DF4123005C9 for ; Mon, 8 Aug 2016 10:39:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tolyjC8FGY8P for ; Mon, 8 Aug 2016 10:39:20 -0400 (EDT) Received: from [192.168.1.28] (nc-71-50-129-15.dyn.embarqhsd.net [71.50.129.15]) by mail.smeinc.net (Postfix) with ESMTPSA id 14C70300410; Mon, 8 Aug 2016 10:39:19 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6AB281F0-C60C-449E-B60C-4F6126149E45" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <01eb01d1f0f6$383f5230$a8bdf690$@augustcellars.com> Date: Mon, 8 Aug 2016 10:39:12 -0400 Message-Id: References: <01eb01d1f0f6$383f5230$a8bdf690$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 14:39:31 -0000 --Apple-Mail=_6AB281F0-C60C-449E-B60C-4F6126149E45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I would like to see ECDSA P-384 w/ SHA-384 on the SHOULD list. Russ On Aug 7, 2016, at 5:54 PM, Jim Schaad wrote: > This message looks at Signature Algorithms. Please restrict your = discussions to this set of algorithms, I will be sending out messages on = other algorithms over time. > =20 > Current Document for S/MIME 3.1 > =20 > MUST: RSA w/ SHA-256 > SHOULD+: DSA w/ SHA-256, RSASSA-PSS w/ SHA-256 > SHOULD-: RSA w/ SHA-1, DSA w/SHA-1, RSA w/ MD5 > Historic: > =20 > Key Sizes: > RSA and DSA - sign > SHOULD NOT Key size <=3D 1023 > SHOULD 1024 <=3D key size <=3D 2048 > MAY 2048 < key size =20 > =20 > RSA and DSA - Verify > MAY key size <=3D 1023 > MUST 1024 <=3D key size <=3D 2048 > MAY 2048 < key size > =20 > RSA - Certificate Verify > MAY key size <=3D 1023 > MUST 1024 <=3D key size <=3D 4096 > MAY 4096 < key size > =20 > DSA - Certificate Verify > MAY key size <=3D 1023 > MUST 1024 <=3D key size <=3D 3072 > =20 > =20 > =20 > Proposed for S/MIME 3.5 > =20 > MUST: RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519 > MUST-: RSA w/ SHA-256 > SHOULD+: > SHOULD: RSA-PSS w/ SHA-512, ECDSA P-521 w/ SHA-256512, EdDSA448 > SHOULD-: DSA w/ SHA-256 > Historic: RSA w/ SHA-1, DSA w/ SHA-1, RSA w/ MD5, DSA w/ SHA-256 > =20 > Key Sizes: > RSA and DSA - sign > SHOULD NOT Key size <=3D 2048 2047 > SHOULD 2048 <=3D key size <=3D 4096 > MAY 4096 < key size =20 > =20 > RSA and DSA - Verify > Historic MAY key size <=3D 2048 2047 > MUST 2048 <=3D key size <=3D 4096 > MAY 4096 < key size > =20 > RSA - Certificate Verify > Historic MAY key size <=3D 2048 2047 > MUST 2048 <=3D key size <=3D 4096 > MAY 4096 < key size > =20 > DSA - Certificate Verify > Historic MAY key size <=3D 1023 > Historic MUST 1024 <=3D key size <=3D 3072 > =20 > =20 > Questions: > =20 > 1. Should DSA be dropped to historic for messages and just left = as SHOULD- for certificates, I don't know how many DSA certificates = actually exist. >=20 > Take 2 state: I have removed all DSA from the current set of = algorithms for both messages and certificates. This is now historic = only > =20 > 2. I have changed to lower limits on RSA but not DSA for = certificate verification - should it be changed as well? Again I don't = know how many DSA certificates exist. >=20 > Take 2 state: I have removed DSA certificates to historic so the = question is moot. > =20 > 3. I don't think that any statements for ECDSA on key size need = to be made separately from the algorithm support list. Does anybody = disagree? >=20 > Take 2 state: Nobody said anything to the contrary. So no plans to = make a key size section for ECDSA algorithms. > =20 > 4. NEW: SPT suggested that we should not be making any statements = on doing anything with 512 hash values. (Although with tons of standard = snark J). My reasoning for including this was less to do with the fact = that I thought the 512-bit hash functions were more efficient on 64-bit = hardware (a statement that I cannot find support for with a quick web = search for SHA-2) and therefore it made sense from a throughput point of = view. I don=92t think we need the for security and if they are not = more efficient I would be in favor not making them SHOULDs > =20 > 5. NEW: Blake has complained about the number of MUST algorithms = that comes out from this list. There are effectively 4 in the list = above, as opposed to the 1 that is in the current set of documents. We = cannot kill the current MUST so it has to stay. However, all of the new = MUSTs could be downgraded from MUST to SHOULD without out any problems. = The only issue is that one of them needs to be a MUST so that we have a = true MUST not just a MUST- algorithm. Looking at the list my breakdown = would be: > =20 > =B7 RSA-PSS =96 Given that it has been slow on update the only = reason to have it be a MUST is that most people are probably going to = have RSA keys today. There are some arguments that say RSA-PSS is no = better than RSA-v1.5 when doing real-world analysis. I don=92t know = that I agree with this as I have problems with arguments by analogy. = This could easily be a SHOULD instead of a MUST > =B7 ECDSA =96 This is the world of NIST requirements today. I = think this justifies it being a MUST > =B7 EdDSA =96 This is the world of NOT MIST requirements today. = I think this justifies it being a MUST > =20 > Jim > =20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_6AB281F0-C60C-449E-B60C-4F6126149E45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = would like to see ECDSA P-384 w/ SHA-384 on the SHOULD = list.

Russ


On = Aug 7, 2016, at 5:54 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

This message looks = at Signature Algorithms.  Please restrict your discussions to this = set of algorithms, I will be sending out messages on other algorithms = over time.
 
Current = Document for S/MIME 3.1
 
MUST:   RSA w/ SHA-256
SHOULD+:  DSA w/ SHA-256, RSASSA-PSS w/ = SHA-256
SHOULD-:  RSA = w/ SHA-1, DSA w/SHA-1, RSA w/ MD5
Historic:
 
Key = Sizes:
RSA and DSA - = sign
SHOULD = NOT            = Key size <=3D 1023
SHOULD      1024 <=3D key size = <=3D 2048
MAY         &nbs= p;  2048 < key size  
 
RSA = and DSA - Verify
MAY         &nbs= p;      key size <=3D = 1023
MUST      1024 <=3D key size = <=3D 2048
MAY        2048 < key = size
 
RSA - Certificate Verify
MAY         &nbs= p;   key size <=3D 1023
MUST  1024 <=3D key size <=3D = 4096
MAY      4096  < key = size
 
DSA - Certificate Verify
MAY         &nbs= p;   key size <=3D 1023
MUST    1024 <=3D key size <=3D = 3072
 
 
 
Proposed = for S/MIME 3.5
 
MUST: = RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, = EdDSA25519
MUST-: RSA w/ = SHA-256
SHOULD+:
SHOULD:  RSA-PSS w/ SHA-512, ECDSA P-521 w/ = SHA-256512, EdDSA448
SHOULD-: DSA w/ = SHA-256
Historic: RSA w/ = SHA-1, DSA w/ SHA-1, RSA w/ MD5, DSA w/ = SHA-256
 
Key = Sizes:
RSA and DSA - sign
SHOULD = NOT            = Key size <=3D 2048 2047
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: = Calibri, sans-serif;">SHOULD      2048 <=3D = key size <=3D 4096
MAY         &nbs= p;   4096 < key size  
 
RSA and = DSA - = Verify
Historic MAY   &nbs= p;            key = size <=3D 2048 2047
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: = Calibri, sans-serif;">MUST      2048 <=3D = key size <=3D 4096
MAY        4096 < key = size
 
RSA - Certificate Verify
Historic MAY   &nbs= p;         key size <=3D 2048 2047
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: = Calibri, sans-serif;">MUST  2048 <=3D key size <=3D = 4096
MAY      4096  < key = size
 
DSA - Certificate Verify
Historic MAY   &nbs= p;         key size <=3D = 1023
Historic MUST   1024 = <=3D key size <=3D 3072
 
 
Questions:
 
1.      Should DSA be = dropped to historic for messages and just left as SHOULD- for = certificates, I don't know how many DSA certificates actually = exist.

Take 2 state: I have removed all DSA = from the current set of algorithms for both messages and = certificates.  This is now historic only
 
2.      I have = changed to lower limits on RSA but not DSA for certificate verification = - should it be changed as well?  Again I don't know how many DSA = certificates exist.

Take 2 state: I have removed DSA = certificates to historic so the question is moot.
 
3.      I don't think = that any statements for ECDSA on key size need to be made separately = from the algorithm support list.  Does anybody = disagree?

Take 2 state:  Nobody said anything to the = contrary.  So no plans to make a key size section for ECDSA = algorithms.
 
4.      NEW: SPT suggested that we = should not be making any statements on doing anything with 512 hash = values.  (Although with tons of standard snark J).   My reasoning for including this was = less to do with the fact that I thought the 512-bit hash functions were = more efficient on 64-bit hardware (a statement that I cannot find = support for with a quick web search for SHA-2) and therefore it made = sense from a throughput point of view.   I don=92t think we = need the for security and if they are not more efficient I would be in = favor not making them SHOULDs
 
5.      NEW:  Blake has = complained about the number of MUST algorithms that comes out from this = list.  There are effectively 4 in the list above, as opposed to the = 1 that is in the current set of documents.  We cannot kill the = current MUST so it has to stay.  However, all of the new MUSTs = could be downgraded from MUST to SHOULD without out any problems.  = The only issue is that one of them needs to be a MUST so that we have a = true MUST not just a MUST- algorithm.  Looking at the list my = breakdown would be:
 
=B7        RSA-PSS = =96 Given that it has been slow on update the only reason to have it be = a MUST is that most people are probably going to have RSA keys = today.  There are some arguments that say RSA-PSS is no better than = RSA-v1.5 when doing real-world analysis.  I don=92t know that I = agree with this as I have problems with arguments by = analogy.   This could easily be a SHOULD instead of a = MUST
=B7        ECDSA = =96 This is the world of NIST requirements today.  I think this = justifies it being a MUST
=B7        EdDSA = =96 This is the world of NOT MIST requirements today.  I think this = justifies it being a MUST
 
Jim
 
________________________________= _______________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
= --Apple-Mail=_6AB281F0-C60C-449E-B60C-4F6126149E45-- From nobody Mon Aug 8 07:43:56 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737EB12D610 for ; Mon, 8 Aug 2016 07:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 R-7461Intrnn for ; Mon, 8 Aug 2016 07:43:54 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5F71E12D83F for ; Mon, 8 Aug 2016 07:43:54 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D0B603F4004; Mon, 8 Aug 2016 14:43:53 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id B9918423704; Mon, 8 Aug 2016 14:43:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1470667433; bh=iJSR19OBD4NPFsLOzTkP3BQMkYjU6w3LaNmE4BpiGQU=; l=102; h=From:To:CC:Date:References:In-Reply-To:From; b=ZWzE9m2PekOCayI1gzWKVcYrOxp0ws2axlsy5vw3ATx8IWQMXN86fP9oq6eY+wuxZ Pgj0bSqTVJViTLd+9bJYVUsTlnJ7qAm3EAI/gvO0Fdra8MqqnwlGDULyueEUWpkfdx 9lGOhvbe8xl3ir2TKgk5G7/B9D91EFRJ76iWB6eE= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 2A09A1FC8D; Mon, 8 Aug 2016 14:43:53 +0000 (GMT) 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.1178.4; Mon, 8 Aug 2016 07:43:52 -0700 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.1178.000; Mon, 8 Aug 2016 10:43:52 -0400 From: "Salz, Rich" To: Russ Housley , Jim Schaad Thread-Topic: [Spasm] Change of Algorithms: Signature Algorithms Take 2 Thread-Index: AdHw7zjRr7pNe4uWRVmZLKRppVz4XwAtO9EAAAg6VuA= Date: Mon, 8 Aug 2016 14:43:52 +0000 Message-ID: <6afd1be131044583ba0962ea82894df9@usma1ex-dag1mb1.msg.corp.akamai.com> References: <01eb01d1f0f6$383f5230$a8bdf690$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.87] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 14:43:55 -0000 > I would like to see ECDSA P-384 w/ SHA-384 on the SHOULD list. I'd rather see 256 and 512 only. From nobody Mon Aug 8 07:49:23 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5AD12D610 for ; Mon, 8 Aug 2016 07:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 QCH_fU5owGG5 for ; Mon, 8 Aug 2016 07:49:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD3212D618 for ; Mon, 8 Aug 2016 07:49:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 05A7B300538 for ; Mon, 8 Aug 2016 10:49:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hgkZUJoVuK_6 for ; Mon, 8 Aug 2016 10:49:18 -0400 (EDT) Received: from [192.168.1.28] (nc-71-50-129-15.dyn.embarqhsd.net [71.50.129.15]) by mail.smeinc.net (Postfix) with ESMTPSA id ABB433002BA; Mon, 8 Aug 2016 10:49:17 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> Date: Mon, 8 Aug 2016 10:49:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <91486371-D844-4925-9CA9-D712996E597C@vigilsec.com> References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 14:49:23 -0000 I would like to see SHA-384 on the SHOULD list. If we are going to have EdDSA25519 on the MUST list for signatures, then = SHA-512 belongs on the MUST list for digest algorithms. I=92m also fine = with both of these being SHOULD+. Russ On Aug 7, 2016, at 10:34 PM, Jim Schaad wrote: > This message looks at Digest Algorithms. Please restrict your = discussion to > this set of algorithms. I will be sending out messages on other = algorithms > over time. >=20 > Note: Digest Algorithms are used for computing the digest of the = content. > These are not the "same" as the digest algorithms that are used as = part of > signature algorithms. There may be things one wants to try and keep > similar, as we suggest that you use the same digest algorithm, but = they are > not the same things. >=20 >=20 > Current Document for S/MIME 3.1 >=20 > MUST: SHA-256 > SHOULD-: SHA-1, MD5(for backwards compatibility) >=20 >=20 > Proposed for S/MIME 3.5 >=20 > MUST: SHA-256 > Historic: SHA-1, MD5 >=20 > Questions: >=20 > 1. There is only one MUST and no path forward. Is this a problem = that > needs to be dealt with? EdDSA25519 uses SHA-512 under the covers, = does that > mean we should make SHA-512 at least a SHOULD here? >=20 > 2. Is there anybody who wants to standup and argue for adopting in = any of > the SHA-3 algorithms? >=20 > Jim >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Aug 8 08:02:55 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA69C12D0B1 for ; Mon, 8 Aug 2016 08:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 faUYr7_nssrC for ; Mon, 8 Aug 2016 08:02:52 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51E612D858 for ; Mon, 8 Aug 2016 08:02:48 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 8 Aug 2016 08:14:29 -0700 From: Jim Schaad To: "'Salz, Rich'" References: <01d801d1f0ef$18a68030$49f38090$@augustcellars.com> In-Reply-To: Date: Mon, 8 Aug 2016 08:02:20 -0700 Message-ID: <02a601d1f185$de3ab9b0$9ab02d10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 thread-index: AQHpc95ztakHMNv8KmlwHM55196SjwE4Wm7jAnWSlsqf8rRzkA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms - Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 15:02:54 -0000 Why should the rationale be in the document? > -----Original Message----- > From: Salz, Rich [mailto:rsalz@akamai.com] > Sent: Monday, August 08, 2016 6:36 AM > To: Jim Schaad > Cc: SPASM > Subject: RE: [Spasm] Change of Algorithms: Content Encryption Algorithms - > Take 2 > > +1. I assume the rationale will make it into the draft. From nobody Mon Aug 8 09:51:13 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A574D12D1AC for ; Mon, 8 Aug 2016 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 W7OYjAIpwdwu for ; Mon, 8 Aug 2016 09:51:10 -0700 (PDT) Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [62.209.51.94]) (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 058D712D0EA for ; Mon, 8 Aug 2016 09:51:09 -0700 (PDT) Received: from pps.filterd (m0046668.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u78GhovV016662; Mon, 8 Aug 2016 18:51:08 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 24n5c0thty-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 08 Aug 2016 18:51:08 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 7706331; Mon, 8 Aug 2016 16:51:07 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas6.st.com [10.75.90.73]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 2F3FA2B3C; Mon, 8 Aug 2016 16:51:07 +0000 (GMT) Received: from [10.137.2.67] (10.137.2.67) by webmail-eu.st.com (10.75.90.73) with Microsoft SMTP Server id 8.3.444.0; Mon, 8 Aug 2016 18:51:06 +0200 To: References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> From: Gilles Van Assche X-Enigmail-Draft-Status: N1110 Message-ID: <57A8B886.9010600@st.com> Date: Mon, 8 Aug 2016 18:51:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-08_13:, , signatures=0 Archived-At: Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 16:51:12 -0000 Hi, Why not consider SHAKE? It has good performance and has been publicly evaluated. Kind regards, Gilles On 08/08/16 04:34, Jim Schaad wrote: > This message looks at Digest Algorithms. Please restrict your discussion to > this set of algorithms. I will be sending out messages on other algorithms > over time. > > Note: Digest Algorithms are used for computing the digest of the content. > These are not the "same" as the digest algorithms that are used as part of > signature algorithms. There may be things one wants to try and keep > similar, as we suggest that you use the same digest algorithm, but they are > not the same things. > > > Current Document for S/MIME 3.1 > > MUST: SHA-256 > SHOULD-: SHA-1, MD5(for backwards compatibility) > > > Proposed for S/MIME 3.5 > > MUST: SHA-256 > Historic: SHA-1, MD5 > > Questions: > > 1. There is only one MUST and no path forward. Is this a problem that > needs to be dealt with? EdDSA25519 uses SHA-512 under the covers, does that > mean we should make SHA-512 at least a SHOULD here? > > 2. Is there anybody who wants to standup and argue for adopting in any of > the SHA-3 algorithms? > > Jim > > > From nobody Mon Aug 8 19:53:21 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA50612D6B8 for ; Mon, 8 Aug 2016 19:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, 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 LJR_IUvHWTPc for ; Mon, 8 Aug 2016 19:53:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5634212D6B3 for ; Mon, 8 Aug 2016 19:53:18 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 8 Aug 2016 20:04:58 -0700 From: Jim Schaad To: 'Russ Housley' References: <01d801d1f0ef$18a68030$49f38090$@augustcellars.com> In-Reply-To: Date: Mon, 8 Aug 2016 19:52:46 -0700 Message-ID: <004701d1f1e9$1d65f470$5831dd50$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01D1F1AE.710C4C90" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHpc95ztakHMNv8KmlwHM55196SjwH2Hs33oAE5OvA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms - Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 02:53:21 -0000 ------=_NextPart_000_0048_01D1F1AE.710C4C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have no problems with this, however I will channel Blake - what is the reason for having three must algorithms at this point? I can see that the support delta is very small given that both 128 and 256 bit AES primitive is required already. Jim From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley Sent: Monday, August 08, 2016 7:21 AM To: Jim Schaad Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms - Take 2 I would like to see AES-128 GCM on the MUST list as well. Russ On Aug 7, 2016, at 5:03 PM, Jim Schaad > wrote: I have looked at the responses to the original mail and am updating the mail to reflect what I thought I saw as comments. This message looks at Content Encryption Algorithms. Please restrict your discussions to this set of algorithms, I will be sending out messages on other algorithm times over time. Current Document for S/MIME 3.1 MUST: AES-128 CBC SHOULD+: AES-192 CBC and AES-256 CBC SHOULD-: DES EDE3 CBC (tripleDES) Historic: RC2/40 Proposed for S/MIME 3.5 MUST: AES-192 CBC, AES-256 CBC, AES-256 GCM MUST-: AES-128 CBC SHOULD+: ChaCha20/Poly1305 (256-bit) SHOULD-: AES-128 CBC Historic: RC2/40, DES EDE3 CBC (tripleDES) Take 2 State: With this set we now have two MUST algorithms with the same primitive. We are indicating that we think that ChaCha20/Poly1305 will become a MUST in the future so we have stated a potential fail over algorithm if AES or GCM go into the tank for any reason. More comments are welcome. Questions: 1. The jump from MUST to SHOULD- may be too aggressive for AES-128 CBC, we should potentially state this as MUST- but I think being aggressive makes more sense as we want to go to all AEAD algorithms in next version. Take 2 state: Russ said that yes I was. As I suggested on the list I have pushed this back up to a MUST-. 2. No recommendation for: AES-128 GCM or AES-192 GCM, should there be? How do people feel about 128 and 192 bit algorithms? Take 2 state: List appears to say that we should not say anything about 192-bit algorithms. However people did not comment on the -128 vs -256 question so I have left the recommendation of AES-256 GCM alone. 3. Do we want to downgrade all of the CBC algorithms in favor of GCM algorithms? Take 2 state: SPT is the only one who commented on this. I have a tendency to agree with his proposal that we are adding AEAD and we should be pushing that as the preferred algorithm. Making a MUST statement about AES-256 CBC seems to counter act this statement so I have removed it. Jim _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_0048_01D1F1AE.710C4C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have no = problems with this, however I will channel Blake – what is the = reason for having three must algorithms at this point?  I can see = that the support delta is very small given that both 128 and 256 bit AES = primitive is required already.

 

Jim

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Monday, August 08, 2016 7:21 AM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: [Spasm] Change of = Algorithms: Content Encryption Algorithms - Take = 2

 

I would like = to see AES-128 GCM on the MUST list as well.

 

Russ

 

 

On = Aug 7, 2016, at 5:03 PM, Jim Schaad <ietf@augustcellars.com> = wrote:



I have = looked at the responses to the original mail and am updating the mail to = reflect what I thought I saw as = comments.

 

This message = looks at Content Encryption Algorithms.  Please restrict your = discussions to this set of algorithms, I will be sending out messages on = other algorithm times over time.

 

Current = Document for S/MIME 3.1

 

MUST: = AES-128 CBC

SHOULD+: = AES-192 CBC and AES-256 CBC

SHOULD-: DES = EDE3 CBC (tripleDES)

Historic: = RC2/40

 

Proposed for = S/MIME 3.5

 

MUST:  AES-192 CBC, AES-256 = CBC, AES-256 = GCM

MUST-: = AES-128 CBC

SHOULD+: = ChaCha20/Poly1305 (256-bit)

SHOULD-: = AES-128 CBC

Historic: = RC2/40, DES EDE3 CBC (tripleDES)

 

Take 2 = State: With this = set we now have two MUST algorithms with the same primitive.  We = are indicating that we think that ChaCha20/Poly1305 will become a MUST = in the future so we have stated a potential fail over algorithm if AES = or GCM go into the tank for any reason.   More comments are = welcome.

 

Questions:

1.      The jump = from MUST to SHOULD- may be too aggressive for AES-128 CBC, we should = potentially state this as MUST- but I think being aggressive makes more = sense as we want to go to all AEAD algorithms in next = version.

Take 2 state: Russ said that yes I was.  As = I suggested on the list I have pushed this back up to a = MUST-.

 

2.      No = recommendation for: AES-128 GCM or AES-192 GCM, should there be?  = How do people feel about 128 and 192 bit algorithms?

Take 2 = state: List appears to say that we should not say anything about = 192-bit algorithms.  However people did not comment on the -128 vs = -256 question so I have left the recommendation of AES-256 GCM = alone.

 

3.      Do we want = to downgrade all of the CBC algorithms in favor of GCM = algorithms?

Take 2 state:  SPT is the only one who = commented on this.  I have a tendency to agree with his proposal = that we are adding AEAD and we should be pushing that as the preferred = algorithm.  Making a MUST statement about AES-256 CBC seems to = counter act this statement so I have removed = it.

 

Jim

 

 

 

____________= ___________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

 

------=_NextPart_000_0048_01D1F1AE.710C4C90-- From nobody Mon Aug 8 20:00:03 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57AF12D69E for ; Mon, 8 Aug 2016 20:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, 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 rlCAs-rf5R0C for ; Mon, 8 Aug 2016 19:59:59 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE40612B031 for ; Mon, 8 Aug 2016 19:59:58 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 8 Aug 2016 20:12:04 -0700 From: Jim Schaad To: 'Russ Housley' References: <01eb01d1f0f6$383f5230$a8bdf690$@augustcellars.com> In-Reply-To: Date: Mon, 8 Aug 2016 19:59:52 -0700 Message-ID: <005101d1f1ea$1b9de930$52d9bb90$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01D1F1AF.6F4308D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH6Zs1F+AZ+g9clK0MJDseClGlVVAJmgV7vn9vSdzA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 03:00:02 -0000 ------=_NextPart_000_0052_01D1F1AF.6F4308D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It seems to me that the same argument you made on 192 would apply here as well. Jim From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley Sent: Monday, August 08, 2016 7:39 AM To: Jim Schaad Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Signature Algorithms Take 2 I would like to see ECDSA P-384 w/ SHA-384 on the SHOULD list. Russ On Aug 7, 2016, at 5:54 PM, Jim Schaad > wrote: This message looks at Signature Algorithms. Please restrict your discussions to this set of algorithms, I will be sending out messages on other algorithms over time. Current Document for S/MIME 3.1 MUST: RSA w/ SHA-256 SHOULD+: DSA w/ SHA-256, RSASSA-PSS w/ SHA-256 SHOULD-: RSA w/ SHA-1, DSA w/SHA-1, RSA w/ MD5 Historic: Key Sizes: RSA and DSA - sign SHOULD NOT Key size <= 1023 SHOULD 1024 <= key size <= 2048 MAY 2048 < key size RSA and DSA - Verify MAY key size <= 1023 MUST 1024 <= key size <= 2048 MAY 2048 < key size RSA - Certificate Verify MAY key size <= 1023 MUST 1024 <= key size <= 4096 MAY 4096 < key size DSA - Certificate Verify MAY key size <= 1023 MUST 1024 <= key size <= 3072 Proposed for S/MIME 3.5 MUST: RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519 MUST-: RSA w/ SHA-256 SHOULD+: SHOULD: RSA-PSS w/ SHA-512, ECDSA P-521 w/ SHA-256512, EdDSA448 SHOULD-: DSA w/ SHA-256 Historic: RSA w/ SHA-1, DSA w/ SHA-1, RSA w/ MD5, DSA w/ SHA-256 Key Sizes: RSA and DSA - sign SHOULD NOT Key size <= 2048 2047 SHOULD 2048 <= key size <= 4096 MAY 4096 < key size RSA and DSA - Verify Historic MAY key size <= 2048 2047 MUST 2048 <= key size <= 4096 MAY 4096 < key size RSA - Certificate Verify Historic MAY key size <= 2048 2047 MUST 2048 <= key size <= 4096 MAY 4096 < key size DSA - Certificate Verify Historic MAY key size <= 1023 Historic MUST 1024 <= key size <= 3072 Questions: 1. Should DSA be dropped to historic for messages and just left as SHOULD- for certificates, I don't know how many DSA certificates actually exist. Take 2 state: I have removed all DSA from the current set of algorithms for both messages and certificates. This is now historic only 2. I have changed to lower limits on RSA but not DSA for certificate verification - should it be changed as well? Again I don't know how many DSA certificates exist. Take 2 state: I have removed DSA certificates to historic so the question is moot. 3. I don't think that any statements for ECDSA on key size need to be made separately from the algorithm support list. Does anybody disagree? Take 2 state: Nobody said anything to the contrary. So no plans to make a key size section for ECDSA algorithms. 4. NEW: SPT suggested that we should not be making any statements on doing anything with 512 hash values. (Although with tons of standard snark :)). My reasoning for including this was less to do with the fact that I thought the 512-bit hash functions were more efficient on 64-bit hardware (a statement that I cannot find support for with a quick web search for SHA-2) and therefore it made sense from a throughput point of view. I don't think we need the for security and if they are not more efficient I would be in favor not making them SHOULDs 5. NEW: Blake has complained about the number of MUST algorithms that comes out from this list. There are effectively 4 in the list above, as opposed to the 1 that is in the current set of documents. We cannot kill the current MUST so it has to stay. However, all of the new MUSTs could be downgraded from MUST to SHOULD without out any problems. The only issue is that one of them needs to be a MUST so that we have a true MUST not just a MUST- algorithm. Looking at the list my breakdown would be: * RSA-PSS - Given that it has been slow on update the only reason to have it be a MUST is that most people are probably going to have RSA keys today. There are some arguments that say RSA-PSS is no better than RSA-v1.5 when doing real-world analysis. I don't know that I agree with this as I have problems with arguments by analogy. This could easily be a SHOULD instead of a MUST * ECDSA - This is the world of NIST requirements today. I think this justifies it being a MUST * EdDSA - This is the world of NOT MIST requirements today. I think this justifies it being a MUST Jim _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_0052_01D1F1AF.6F4308D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It seems to = me that the same argument you made on 192 would apply here as = well.

 

Jim

 

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Monday, August 08, 2016 7:39 AM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: [Spasm] Change of = Algorithms: Signature Algorithms Take = 2

 

I would like = to see ECDSA P-384 w/ SHA-384 on the SHOULD list.

 

Russ

 

 

On = Aug 7, 2016, at 5:54 PM, Jim Schaad <ietf@augustcellars.com> = wrote:



This message = looks at Signature Algorithms.  Please restrict your discussions to = this set of algorithms, I will be sending out messages on other = algorithms over time.

 

Current = Document for S/MIME 3.1

 

MUST: &n= bsp; RSA w/ SHA-256

SHOULD+: = ; DSA w/ SHA-256, RSASSA-PSS w/ = SHA-256

SHOULD-: = ; RSA w/ SHA-1, DSA w/SHA-1, RSA w/ = MD5

Historic:

 

Key = Sizes:

RSA and DSA = - sign

SHOULD = NOT            = Key size <=3D 1023

SHOULD &= nbsp;    1024 <=3D key size <=3D = 2048

MAY &nbs= p;          2048 < key = size  

 

RSA and DSA = - Verify

MAY &nbs= p;            = ;  key size <=3D 1023

MUST &nb= sp;    1024 <=3D key size <=3D = 2048

MAY &nbs= p;      2048 < key = size

 

RSA - = Certificate Verify

MAY &nbs= p;           key size = <=3D 1023

MUST  = 1024 <=3D key size <=3D 4096

MAY &nbs= p;    4096  < key = size

 

DSA - = Certificate Verify

MAY &nbs= p;           key size = <=3D 1023

MUST &nb= sp;  1024 <=3D key size <=3D = 3072

 

 

 

Proposed for = S/MIME 3.5

 

MUST: = RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, = EdDSA25519

MUST-: RSA = w/ SHA-256

SHOULD+:=

SHOULD: = RSA-PSS w/ SHA-512, ECDSA P-521 w/ SHA-256512, = EdDSA448

SHOULD-: DSA w/ = SHA-256

Historic: = RSA w/ SHA-1, DSA w/ SHA-1, RSA w/ MD5, DSA w/ = SHA-256

 

Key = Sizes:

RSA and DSA - = sign

SHOULD = NOT            = Key size <=3D 2048 2047<= /p>

SHOULD &= nbsp;    2048 <=3D key size <=3D = 4096

MAY &nbs= p;           4096 < = key size  

 

RSA and DSA - = Verify

Historic MAY &nbs= p;            = ;  key size <=3D 2048 2047<= /p>

MUST &nb= sp;    2048 <=3D key size <=3D = 4096

MAY &nbs= p;      4096 < key = size

 

RSA - = Certificate Verify

Historic MAY &nbs= p;           key size = <=3D 2048 2047<= /p>

MUST  = 2048 <=3D key size <=3D 4096

MAY &nbs= p;    4096  < key = size

 

DSA - = Certificate Verify

Historic MAY &nbs= p;           key size = <=3D 1023

Historic MUST &nb= sp; 1024 <=3D key size <=3D = 3072

 

 

Questions:

 

1.      Should DSA = be dropped to historic for messages and just left as SHOULD- for = certificates, I don't know how many DSA certificates actually = exist.

Take 2 state: I have removed all DSA = from the current set of algorithms for both messages and = certificates.  This is now historic = only

 

2.      I have = changed to lower limits on RSA but not DSA for certificate verification = - should it be changed as well?  Again I don't know how many DSA = certificates exist.

Take 2 state: I have removed DSA = certificates to historic so the question is = moot.

 

3.      I don't = think that any statements for ECDSA on key size need to be made = separately from the algorithm support list.  Does anybody = disagree?

Take 2 state:  Nobody said anything to the = contrary.  So no plans to make a key size section for ECDSA = algorithms.

 

4.      NEW: SPT = suggested that we should not be making any statements on doing anything = with 512 hash values.  (Although with tons of standard snark J).  = ; My reasoning for including this was less to do with the fact that I = thought the 512-bit hash functions were more efficient on 64-bit = hardware (a statement that I cannot find support for with a quick web = search for SHA-2) and therefore it made sense from a throughput point of = view.   I don’t think we need the for security and if = they are not more efficient I would be in favor not making them = SHOULDs

 

5.      NEW: =  Blake = has complained about the number of MUST algorithms that comes out from = this list.  There are effectively 4 in the list above, as opposed = to the 1 that is in the current set of documents.  We cannot kill = the current MUST so it has to stay.  However, all of the new MUSTs = could be downgraded from MUST to SHOULD without out any problems.  = The only issue is that one of them needs to be a MUST so that we have a = true MUST not just a MUST- algorithm.  Looking at the list my = breakdown would be:

 

·        RSA-PSS = – Given that it has been slow on update the only reason to have it = be a MUST is that most people are probably going to have RSA keys = today.  There are some arguments that say RSA-PSS is no better than = RSA-v1.5 when doing real-world analysis.  I don’t know that I = agree with this as I have problems with arguments by = analogy.   This could easily be a SHOULD instead of a = MUST

·        ECDSA = – This is the world of NIST requirements today.  I think this = justifies it being a MUST

·        EdDSA = – This is the world of NOT MIST requirements today.  I think = this justifies it being a MUST

 

Jim

 

____________= ___________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

 

------=_NextPart_000_0052_01D1F1AF.6F4308D0-- From nobody Mon Aug 8 20:07:17 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5734A12D69E for ; Mon, 8 Aug 2016 20:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 BZJRKzdU8qUy for ; Mon, 8 Aug 2016 20:07:15 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E808912B031 for ; Mon, 8 Aug 2016 20:07:14 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 8 Aug 2016 20:19:00 -0700 From: Jim Schaad To: 'Gilles Van Assche' , References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> In-Reply-To: <57A8B886.9010600@st.com> Date: Mon, 8 Aug 2016 20:06:48 -0700 Message-ID: <006001d1f1eb$13390e90$39ab2bb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHWFVA45DH236BAKjdHgAKf0jipKAOM5yixoBtC3lA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 03:07:16 -0000 Given that SHAKE is really the same as SHA3, that would be part of the last question that I asked. SHAKE is not considered to be a hash algorithm, but is instead an XOF (Extendable Output Function). These do not have the quite the same security claims as digest algorithms due to the arbitrary sized output. (I will modify the previous statement as saying this is my understanding and may have nothing to do with reality.) SHAKE256(M, d) is almost the same as SHA3-256. (The only difference is the unique algorithm marker). Jim > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Gilles Van Assche > Sent: Monday, August 08, 2016 9:51 AM > To: spasm@ietf.org > Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms > > Hi, > > Why not consider SHAKE? It has good performance and has been publicly > evaluated. > > Kind regards, > Gilles > > > On 08/08/16 04:34, Jim Schaad wrote: > > This message looks at Digest Algorithms. Please restrict your > > discussion to this set of algorithms. I will be sending out messages > > on other algorithms over time. > > > > Note: Digest Algorithms are used for computing the digest of the content. > > These are not the "same" as the digest algorithms that are used as > > part of signature algorithms. There may be things one wants to try > > and keep similar, as we suggest that you use the same digest > > algorithm, but they are not the same things. > > > > > > Current Document for S/MIME 3.1 > > > > MUST: SHA-256 > > SHOULD-: SHA-1, MD5(for backwards compatibility) > > > > > > Proposed for S/MIME 3.5 > > > > MUST: SHA-256 > > Historic: SHA-1, MD5 > > > > Questions: > > > > 1. There is only one MUST and no path forward. Is this a problem > > that needs to be dealt with? EdDSA25519 uses SHA-512 under the > > covers, does that mean we should make SHA-512 at least a SHOULD here? > > > > 2. Is there anybody who wants to standup and argue for adopting in > > any of the SHA-3 algorithms? > > > > Jim > > > > > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Aug 9 05:33:31 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0EC12D68F for ; Tue, 9 Aug 2016 05:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 nrJgyb0te44h for ; Tue, 9 Aug 2016 05:33:28 -0700 (PDT) Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [62.209.51.94]) (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 4BC7212D7E7 for ; Tue, 9 Aug 2016 05:17:17 -0700 (PDT) Received: from pps.filterd (m0046037.ppops.net [127.0.0.1]) by m0046037.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u79CF4kl017260; Tue, 9 Aug 2016 14:16:52 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by m0046037.ppops.net with ESMTP id 24n5nrpka4-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 09 Aug 2016 14:16:52 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 8548E31; Tue, 9 Aug 2016 12:16:51 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas6.st.com [10.75.90.73]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D958224EE; Tue, 9 Aug 2016 12:16:50 +0000 (GMT) Received: from [10.137.2.67] (10.137.2.67) by webmail-eu.st.com (10.75.90.73) with Microsoft SMTP Server id 8.3.444.0; Tue, 9 Aug 2016 14:16:50 +0200 To: Jim Schaad , "spasm@ietf.org" References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> <006001d1f1eb$13390e90$39ab2bb0$@augustcellars.com> From: Gilles Van Assche X-Enigmail-Draft-Status: N1110 Message-ID: <57A9C9BE.4070002@st.com> Date: Tue, 9 Aug 2016 14:17:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <006001d1f1eb$13390e90$39ab2bb0$@augustcellars.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-09_04:, , signatures=0 Archived-At: Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 12:33:30 -0000 On 09/08/16 05:07, Jim Schaad wrote: > Given that SHAKE is really the same as SHA3, that would be part of the > last question that I asked. SHAKE is not considered to be a hash > algorithm, but is instead an XOF (Extendable Output Function). Indeed. However, when restricted to a particular output length, the XOF becomes a traditional hash function. > These do not have the quite the same security claims as digest > algorithms due to the arbitrary sized output. (I will modify the > previous statement as saying this is my understanding and may have > nothing to do with reality.) > > SHAKE256(M, d) is almost the same as SHA3-256. (The only difference is > the unique algorithm marker). The reason I mention SHAKE as opposed to the SHA3-* hash functions is that SHAKE128 and SHAKE256 are faster for a given security strength. I.e., SHAKE128 is faster than SHA3-256 for 128-bit security, and SHAKE256 is faster than SHA3-512 for 256-bit security. Kind regards, Gilles From nobody Tue Aug 9 16:46:09 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645A912D8FB for ; Tue, 9 Aug 2016 16:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 6TponWaJfd16 for ; Tue, 9 Aug 2016 16:46:07 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 86D5F12D1CA for ; Tue, 9 Aug 2016 16:46:07 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9D32A50A84 for ; Tue, 9 Aug 2016 19:46:06 -0400 (EDT) To: spasm@ietf.org References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <3f325b55fd814e6fb45360550c42f74a@usma1ex-dag1mb1.msg.corp.akamai.com> From: Sean Leonard Message-ID: <3b80d361-3134-6328-1a97-ea8dc17260a6@seantek.com> Date: Tue, 9 Aug 2016 16:44:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3f325b55fd814e6fb45360550c42f74a@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 23:46:08 -0000 On 8/8/2016 7:07 AM, Salz, Rich wrote: >> 1. There is only one MUST and no path forward. Is this a problem that needs >> to be dealt with? EdDSA25519 uses SHA-512 under the covers, does that >> mean we should make SHA-512 at least a SHOULD here? >> >> 2. Is there anybody who wants to standup and argue for adopting in any of >> the SHA-3 algorithms? > I'd like to see *something* as a should. I have a slight preference for SHA512, but could live with SHA3 if others feel strongly. I think SHA-3 should be SHOULD-. Sean From nobody Tue Aug 9 18:07:32 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD69B12B012 for ; Tue, 9 Aug 2016 18:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 QCD-oI2qd1dO for ; Tue, 9 Aug 2016 18:07:29 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D5A12D533 for ; Tue, 9 Aug 2016 18:07:28 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 9 Aug 2016 18:19:19 -0700 From: Jim Schaad To: 'Sean Leonard' , References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <3f325b55fd814e6fb45360550c42f74a@usma1ex-dag1mb1.msg.corp.akamai.com> <3b80d361-3134-6328-1a97-ea8dc17260a6@seantek.com> In-Reply-To: <3b80d361-3134-6328-1a97-ea8dc17260a6@seantek.com> Date: Tue, 9 Aug 2016 18:07:03 -0700 Message-ID: <016201d1f2a3$82fc7830$88f56890$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHWFVA45DH236BAKjdHgAKf0jipKAGLcmltAkDHdEigGrpX8A== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 01:07:31 -0000 Why not just make it a MAY in that case or not mention it? SHOULD- This term means the same as SHOULD. However, the authors expect that a requirement marked as SHOULD- will be demoted to a MAY in a future version of this document. Are you really saying it is going to go away in future versions? jim > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard > Sent: Tuesday, August 09, 2016 4:45 PM > To: spasm@ietf.org > Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms > > On 8/8/2016 7:07 AM, Salz, Rich wrote: > >> 1. There is only one MUST and no path forward. Is this a problem > >> that needs to be dealt with? EdDSA25519 uses SHA-512 under the > >> covers, does that mean we should make SHA-512 at least a SHOULD here? > >> > >> 2. Is there anybody who wants to standup and argue for adopting in > >> any of the SHA-3 algorithms? > > I'd like to see *something* as a should. I have a slight preference for > SHA512, but could live with SHA3 if others feel strongly. > > I think SHA-3 should be SHOULD-. > > Sean > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Aug 9 21:17:50 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C128F12D5EC for ; Tue, 9 Aug 2016 21:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 1wOvSng0qZQ7 for ; Tue, 9 Aug 2016 21:17:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 6B60A12D581 for ; Tue, 9 Aug 2016 21:17:47 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 79C56509B5 for ; Wed, 10 Aug 2016 00:17:46 -0400 (EDT) To: spasm@ietf.org References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <3f325b55fd814e6fb45360550c42f74a@usma1ex-dag1mb1.msg.corp.akamai.com> <3b80d361-3134-6328-1a97-ea8dc17260a6@seantek.com> <016201d1f2a3$82fc7830$88f56890$@augustcellars.com> From: Sean Leonard Message-ID: <0a055590-65d1-3d99-5f06-805f38b70f76@seantek.com> Date: Tue, 9 Aug 2016 21:16:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <016201d1f2a3$82fc7830$88f56890$@augustcellars.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 04:17:49 -0000 whoops, my bad. I guess I meant SHOULD- to mean "not really SHOULD right now, but it's going to be SHOULD soon", which I guess would be like a MAY+ or SHOULD↑↑. But there are no MAY+ or SHOULD↑↑ keywords. So, I suppose, just "SHOULD"? Unless you want to propose a new term. Sean On 8/9/2016 6:07 PM, Jim Schaad wrote: > Why not just make it a MAY in that case or not mention it? > > SHOULD- This term means the same as SHOULD. However, the authors expect > that a requirement marked as SHOULD- will be demoted to a MAY in a future > version of this document. > > Are you really saying it is going to go away in future versions? > > jim > >> -----Original Message----- >> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard >> Sent: Tuesday, August 09, 2016 4:45 PM >> To: spasm@ietf.org >> Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms >> >> On 8/8/2016 7:07 AM, Salz, Rich wrote: >>>> 1. There is only one MUST and no path forward. Is this a problem >>>> that needs to be dealt with? EdDSA25519 uses SHA-512 under the >>>> covers, does that mean we should make SHA-512 at least a SHOULD here? >>>> >>>> 2. Is there anybody who wants to standup and argue for adopting in >>>> any of the SHA-3 algorithms? >>> I'd like to see *something* as a should. I have a slight preference > for >> SHA512, but could live with SHA3 if others feel strongly. >> >> I think SHA-3 should be SHOULD-. >> >> Sean >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Aug 10 09:15:00 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C851812D7B4 for ; Wed, 10 Aug 2016 09:14:58 -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 (1024-bit key) header.d=sn3rd.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 p4MjJcb452RM for ; Wed, 10 Aug 2016 09:14:57 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 147B612D739 for ; Wed, 10 Aug 2016 09:14:57 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id t7so48506621qkh.0 for ; Wed, 10 Aug 2016 09:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=a3I5dd2K/LEyIu+b6a48Lw2670HhDR3FYOxz/baRfkU=; b=NQjN112mmbU3VV7Eai4EzO0TuzWrKrX0J8c2PDOmaxM/T+gURPd6DHmKkjkTK17MCb itQok2uEZ9eGpxcNBMnfIq61XB9qjYiELdB3Q6hxnj6xSmAnV78foOb2cPpch1GF+Sdx v6j3cPj9LPEjjeMk/5zaJja3IzMgMfKOnZfxI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=a3I5dd2K/LEyIu+b6a48Lw2670HhDR3FYOxz/baRfkU=; b=RZ7BFSAooOejZHMeo1GwiRxGIdgUhBAJ5I1bXXDf2qfInke2NuWbda8yqWgULmJEPv aGSM4p6XATceiE7fowBPVHYwJmqWYBwZvoCq/J539BgpIJnu3RoaV7S0qewSTvzlQAcH Y0HZbKX3TufOE1okAg3qKSkCE2iHW98alLi4oWoHoyiWJwcayKlEIgB6uXOcWyd+od9i xUGgUgORPsakPrUTmmDPzoX7BiO0vSECHKHpjsC9bzTdXHsaWxCxmz0Lb59564H/Wkku RPicsD4ZHASe6qmgjJ1p3N+SGOR7oDXuNQyk3OyMsYIM3tCRBAGajtt396JzmFCLEU5e dmbA== X-Gm-Message-State: AEkoouuCu6JbWS50gM1Elgqp73LUP5ftEBGfy2d6yTtAeAuUpVMP/Bp8Anpc3jc5e01a5w== X-Received: by 10.233.235.143 with SMTP id b137mr5637149qkg.144.1470845696085; Wed, 10 Aug 2016 09:14:56 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-123-93.washdc.east.verizon.net. [173.73.123.93]) by smtp.gmail.com with ESMTPSA id w185sm23679912qkd.23.2016.08.10.09.14.55 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 09:14:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <57A8B886.9010600@st.com> Date: Wed, 10 Aug 2016 12:14:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <275EA92F-2101-4C33-85F8-FAE12F61D783@sn3rd.com> References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> To: SPASM X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 16:14:59 -0000 I=E2=80=99m half expecting a lmgtfy link, but is SHAKE available in = OpenSSL or on Widows or Macs? Having folks generate code for a new = content type to support AEAD algorithms is one thing and maybe a pretty = big thing at that. Being the first (correct me if I=E2=80=99m wrong = here) IETF protocol to have a SHOULD SHAKE requirement seems like a = requirement that=E2=80=99s going to get ignored. If implementers = don=E2=80=99t respond with a resounding chorus of "oh yeah! we were = going to do that in our next release of product X" then I think that we = should leave driving the SHAKE adoption train to some other more widely = deployed/used protocol for now and S/MIME can piggy back off of it = later. spt > On Aug 08, 2016, at 12:51, Gilles Van Assche = wrote: >=20 > Hi, >=20 > Why not consider SHAKE? It has good performance and has been publicly > evaluated. >=20 > Kind regards, > Gilles >=20 >=20 > On 08/08/16 04:34, Jim Schaad wrote: >> This message looks at Digest Algorithms. Please restrict your = discussion to >> this set of algorithms. I will be sending out messages on other = algorithms >> over time. >>=20 >> Note: Digest Algorithms are used for computing the digest of the = content. >> These are not the "same" as the digest algorithms that are used as = part of >> signature algorithms. There may be things one wants to try and keep >> similar, as we suggest that you use the same digest algorithm, but = they are >> not the same things. >>=20 >>=20 >> Current Document for S/MIME 3.1 >>=20 >> MUST: SHA-256 >> SHOULD-: SHA-1, MD5(for backwards compatibility) >>=20 >>=20 >> Proposed for S/MIME 3.5 >>=20 >> MUST: SHA-256 >> Historic: SHA-1, MD5 >>=20 >> Questions: >>=20 >> 1. There is only one MUST and no path forward. Is this a problem = that >> needs to be dealt with? EdDSA25519 uses SHA-512 under the covers, = does that >> mean we should make SHA-512 at least a SHOULD here? >>=20 >> 2. Is there anybody who wants to standup and argue for adopting in = any of >> the SHA-3 algorithms? >>=20 >> Jim >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Aug 10 10:58:49 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02F712D60E for ; Wed, 10 Aug 2016 10:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EO79hf_wBh7 for ; Wed, 10 Aug 2016 10:58:46 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 55D9912D0F6 for ; Wed, 10 Aug 2016 10:58:46 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id i5so120825027wmg.0 for ; Wed, 10 Aug 2016 10:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pl8BG94wSiLIIqeMp3C/CRQJuR4cf0eQTeGIk0bJwF4=; b=1I50LSg8xhIZZ3s3rUqT9pGB7w24GtlqiOx6lIKIVsAJ+88BLFJNTPJwLDDetIewi+ wpfJjpfQ7z5yoIrHAx+LH3h9CntUA+zthsU5hN6JNSTKPJGtqXxXY5Cp0+rM3078ifSS MpUh5P9DJdOeHwBF4D6FGPu1U0fz6hYDwE/eS2COjXPdVukqxHsnZUgdkb2oTXZiLbqK prhUGbxWNsqWuSWvjhFPLqvv30YkZe5SG6UqtvtZHYrZ+xS87q3q1jnyAoUdUxeuBhGi /DaSpJwUu9BJLgn3RXSquKAmNt+1beF/0tsHVcbZDwFKKl4YlDWGvkmZfbcaDPzo9Iqj CvSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pl8BG94wSiLIIqeMp3C/CRQJuR4cf0eQTeGIk0bJwF4=; b=cLxKjV5kBzw0RkJsD0sfpSo5A3N+u4I7ehNCsL1pP1dXtGZWNqojVTT87QvQemLkBw +D+OyRy9CJG/rYYOFTEmyiAXn98z9rbL0keIYqLvUSOL4mCITStaiGRYs+UgJUMbDdFG n6kG9eRuosA9p0qQCP7DGZnQpT/0R9itSe3rk5bY13LN3Z44cNz2CLkIAj1ARWFDvU/f /dKGUpwRVK7y2Eh7ZLLDj98hbqQ2cA8Mh2MIsfvmpLdMurV+r50tDiJ0fgi/7MJlIFtL 7gWOE8eOtq9BW0DdxPMwry8rUiKYYgW0/mzTJlAuOywBKBaBQKdKBnXmKDxLl2TSdoLZ 4uKw== X-Gm-Message-State: AEkoousDKPqLQzTwN1D/0tPvTDnQS3OnU6/L+zUMb+VyB0ZuM3DXkoeiMyhxwpMiRk8/QQ== X-Received: by 10.194.139.34 with SMTP id qv2mr5294271wjb.50.1470851924734; Wed, 10 Aug 2016 10:58:44 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id v189sm9468274wmv.12.2016.08.10.10.58.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 10:58:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <275EA92F-2101-4C33-85F8-FAE12F61D783@sn3rd.com> Date: Wed, 10 Aug 2016 20:58:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <84916CC1-AE92-4566-B500-A5E8BC8B1468@gmail.com> References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> <275EA92F-2101-4C33-85F8-FAE12F61D783@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 17:58:48 -0000 > On 10 Aug 2016, at 7:14 PM, Sean Turner wrote: >=20 > I=E2=80=99m half expecting a lmgtfy link, but is SHAKE available in = OpenSSL or on Widows or Macs? Having folks generate code for a new = content type to support AEAD algorithms is one thing and maybe a pretty = big thing at that. Being the first (correct me if I=E2=80=99m wrong = here) IETF protocol to have a SHOULD SHAKE requirement seems like a = requirement that=E2=80=99s going to get ignored. If implementers = don=E2=80=99t respond with a resounding chorus of "oh yeah! we were = going to do that in our next release of product X" then I think that we = should leave driving the SHAKE adoption train to some other more widely = deployed/used protocol for now and S/MIME can piggy back off of it = later. Not in OpenSSL. AFAICT not in Windows or Mac library. You can find code = online if you want to, though. Looking at other places in the IETF, nobody=E2=80=99s rushing to write a = =E2=80=9CSHA-3 and its use in xxx=E2=80=9D documents. In fact, there are = none. Compare and contrast with SHA-2 documents when that algorithm was = new or with ChaCha20/Poly1305 or Curve25519 documents more recently.=20 The only document I=E2=80=99ve seen that uses SHA-3 is the EdDSA = document where for Curve448 SHAKE256 is used internally. So in a word, the IETF response to SHA-3 is =E2=80=9Cmeh=E2=80=9D Yoav= From nobody Wed Aug 10 12:11:03 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A703312D0D1 for ; Wed, 10 Aug 2016 12:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 e4LGTpg_ddnz for ; Wed, 10 Aug 2016 12:11:00 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D8512B029 for ; Wed, 10 Aug 2016 12:10:59 -0700 (PDT) Received: from hebrews (50.39.87.30) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 10 Aug 2016 12:23:12 -0700 From: Jim Schaad To: 'Yoav Nir' , 'Sean Turner' References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> <275EA92F-2101-4C33-85F8-FAE12F61D783@sn3rd.com> <84916CC1-AE92-4566-B500-A5E8BC8B1468@gmail.com> In-Reply-To: <84916CC1-AE92-4566-B500-A5E8BC8B1468@gmail.com> Date: Wed, 10 Aug 2016 12:10:51 -0700 Message-ID: <023801d1f33a$ecc23ba0$c646b2e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHWFVA45DH236BAKjdHgAKf0jipKAOM5yixAwUkYkIDO2h1gZ/r30bQ Content-Language: en-us X-Originating-IP: [50.39.87.30] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 19:11:01 -0000 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Yoav Nir > Sent: Wednesday, August 10, 2016 10:59 AM > To: Sean Turner > Cc: SPASM > Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms >=20 >=20 > > On 10 Aug 2016, at 7:14 PM, Sean Turner wrote: > > > > I=E2=80=99m half expecting a lmgtfy link, but is SHAKE available in = OpenSSL or on > Widows or Macs? Having folks generate code for a new content type to = support > AEAD algorithms is one thing and maybe a pretty big thing at that. = Being the > first (correct me if I=E2=80=99m wrong here) IETF protocol to have a = SHOULD SHAKE > requirement seems like a requirement that=E2=80=99s going to get = ignored. If > implementers don=E2=80=99t respond with a resounding chorus of "oh = yeah! we were > going to do that in our next release of product X" then I think that = we should > leave driving the SHAKE adoption train to some other more widely > deployed/used protocol for now and S/MIME can piggy back off of it = later. >=20 > Not in OpenSSL. AFAICT not in Windows or Mac library. You can find = code online > if you want to, though. >=20 > Looking at other places in the IETF, nobody=E2=80=99s rushing to write = a =E2=80=9CSHA-3 and its > use in xxx=E2=80=9D documents. In fact, there are none. Compare and = contrast with SHA- > 2 documents when that algorithm was new or with ChaCha20/Poly1305 or > Curve25519 documents more recently. >=20 > The only document I=E2=80=99ve seen that uses SHA-3 is the EdDSA = document where for > Curve448 SHAKE256 is used internally. This is the only place that I have seen it yet. There is also an issue = of having OIDs created. They exist for the SHA3 algorithms, but the = level of OIDs needed to treat SHAKE as a hash algorithm don't exist the = last time I went on a search. Jim >=20 > So in a word, the IETF response to SHA-3 is =E2=80=9Cmeh=E2=80=9D >=20 > Yoav > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Aug 10 14:32:47 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2BB12D877 for ; Wed, 10 Aug 2016 14:32:45 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 Kr-S4XlvcX_s for ; Wed, 10 Aug 2016 14:32:44 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 1E8C812D873 for ; Wed, 10 Aug 2016 14:32:44 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id j12so33160277ywb.2 for ; Wed, 10 Aug 2016 14:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iTxT2+9EmXJATIGEqYoNvKnm4hKDiWYO8GGzAxpTY5g=; b=PEIx1v8NhE7lyUe+t2Cz2vGQeLdYruVQjGUaMOTTXbP/k+L+FjcCi9W7Z2CgFExbgu RKKE9oxcNjZoUy5wwi7cg7BUVQbwf1EnSLY5s5v6E2CrvXFmgJbvEfVIStKXlCcLuY74 JF1Qpi/G6bze7C94EsN2HQoO6p5Ka7y8k7crY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iTxT2+9EmXJATIGEqYoNvKnm4hKDiWYO8GGzAxpTY5g=; b=Dwe0ptxteWIPWQO9BN6q5ZqN/s0p32LXZauFwAf8YdoLRfW106EQnm+cBPYpy0W8n6 E+6xzh+mfbBKuG08Q4valTB+K8MinJmegeIDEP6psTTXGsQgoEuYxT5xQLpp9dLmJhD5 pppSa54xQ2GPgFGNLAb4N1zIiG1SrhkDmYdfnNRpf5ObR0HQ2YMcAhNOUsXBFw5clBvs n/JYLagduEgx4xz9vfKrqaL9Nv/IhU3bS6+vOaK/Q/ll7qHWhwb/+l+y9wLC0CDXnB8n I2G0Xvb3g94/k9KdYEi+eyVhKgEf8+8kglLKnQsO/pJPqFL6EGTXslov8QFqsnHvn5Nu eIXg== X-Gm-Message-State: AEkooutzJmtqXUGMIgvhUtFScUdqIOwSaFqAsMSTbq4QU8r+9a22kzYtZEry4NCpYxrafA== X-Received: by 10.129.108.194 with SMTP id h185mr4094671ywc.153.1470864763247; Wed, 10 Aug 2016 14:32:43 -0700 (PDT) Received: from [10.84.208.254] ([166.170.33.139]) by smtp.gmail.com with ESMTPSA id y85sm19343640ywy.23.2016.08.10.14.32.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 14:32:42 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6D181A29-5C9D-4E16-9928-F6970031D890 Mime-Version: 1.0 (1.0) From: Sean Turner X-Mailer: iPhone Mail (13G35) In-Reply-To: <023801d1f33a$ecc23ba0$c646b2e0$@augustcellars.com> Date: Wed, 10 Aug 2016 17:32:40 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> <275EA92F-2101-4C33-85F8-FAE12F61D783@sn3rd.com> <84916CC1-AE92-4566-B500-A5E8BC8B1468@gmail.com> <023801d1f33a$ecc23ba0$c646b2e0$@augustcellars.com> To: Jim Schaad Archived-At: Cc: SPASM , Yoav Nir Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 21:32:46 -0000 --Apple-Mail-6D181A29-5C9D-4E16-9928-F6970031D890 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Aug 10, 2016, at 15:10, Jim Schaad wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Yoav Nir >> Sent: Wednesday, August 10, 2016 10:59 AM >> To: Sean Turner >> Cc: SPASM >> Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms >>=20 >>=20 >>> On 10 Aug 2016, at 7:14 PM, Sean Turner wrote: >>>=20 >>> I=E2=80=99m half expecting a lmgtfy link, but is SHAKE available in Open= SSL or on >> Widows or Macs? Having folks generate code for a new content type to sup= port >> AEAD algorithms is one thing and maybe a pretty big thing at that. Being= the >> first (correct me if I=E2=80=99m wrong here) IETF protocol to have a SHOU= LD SHAKE >> requirement seems like a requirement that=E2=80=99s going to get ignored.= If >> implementers don=E2=80=99t respond with a resounding chorus of "oh yeah! w= e were >> going to do that in our next release of product X" then I think that we s= hould >> leave driving the SHAKE adoption train to some other more widely >> deployed/used protocol for now and S/MIME can piggy back off of it later.= >>=20 >> Not in OpenSSL. AFAICT not in Windows or Mac library. You can find code o= nline >> if you want to, though. >>=20 >> Looking at other places in the IETF, nobody=E2=80=99s rushing to write a =E2= =80=9CSHA-3 and its >> use in xxx=E2=80=9D documents. In fact, there are none. Compare and contr= ast with SHA- >> 2 documents when that algorithm was new or with ChaCha20/Poly1305 or >> Curve25519 documents more recently. >>=20 >> The only document I=E2=80=99ve seen that uses SHA-3 is the EdDSA document= where for >> Curve448 SHAKE256 is used internally. >=20 > This is the only place that I have seen it yet. There is also an issue of= having OIDs created. They exist for the SHA3 algorithms, but the level of O= IDs needed to treat SHAKE as a hash algorithm don't exist the last time I we= nt on a search. >=20 > Jim >=20 >>=20 >> So in a word, the IETF response to SHA-3 is =E2=80=9Cmeh=E2=80=9D >>=20 >> Yoav I knew I had seen some oids (if we need them): http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html spt= --Apple-Mail-6D181A29-5C9D-4E16-9928-F6970031D890 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Aug 10, 2016, at 15:= 10, Jim Schaad <ietf@augustcell= ars.com> wrote:

<= br>
-----Original Message---= --
From: Spasm [mailto:spasm-bounces@ietf.org] On B= ehalf Of Yoav Nir
Sen= t: Wednesday, August 10, 2016 10:59 AM
To: Sean Turner <sean= @sn3rd.com>
Cc= : SPASM <spasm@ietf.org><= br>
Subject: Re: [Spasm] Change o= f Algorithms: Digest Algorithms

On 1= 0 Aug 2016, at 7:14 PM, Sean Turner <se= an@sn3rd.com> wrote:

I=E2=80=99m h= alf expecting a lmgtfy link, but is SHAKE available in OpenSSL or on<= br>
Widows or Macs?=  Having folks generate code for a new content type to support
AEAD algorithms is one thing a= nd maybe a pretty big thing at that.  Being the
=
first (correct me if I=E2=80=99m wrong here)= IETF protocol to have a SHOULD SHAKE
requirement seems like a requirement that=E2=80=99s going t= o get ignored.  If
implementers don=E2=80=99t respond with a resounding chorus of "oh yeah! w= e were
going to do th= at in our next release of product X" then I think that we should
<= /blockquote>
leave driving the SHAKE adoption= train to some other more widely
deployed/used protocol for now and S/MIME can piggy back off of i= t later.

<= /blockquote>
Not in OpenSSL. AFAICT not in Wi= ndows or Mac library. You can find code online
if you want to, though.

Looking at other places in the IETF, nobody=E2=80=99s rushing to wr= ite a =E2=80=9CSHA-3 and its
use in xxx=E2=80=9D documents. In fact, there are none. Compare and c= ontrast with SHA-
2 d= ocuments when that algorithm was new or with ChaCha20/Poly1305 or
=
Curve25519 documents more recen= tly.

The only document I=E2=80=99ve seen t= hat uses SHA-3 is the EdDSA document where for
Curve448 SHAKE256 is used internally.

This is the only place that I have seen it= yet.  There is also an issue of having OIDs created.  They exist f= or the SHA3 algorithms, but the level of OIDs needed to treat SHAKE as a has= h algorithm don't exist the last time I went on a search.

Jim


So in a word, the I= ETF response to SHA-3 is =E2=80=9Cmeh=E2=80=9D

= Yoav

I knew I had seen s= ome oids (if we need them):

= spt
= --Apple-Mail-6D181A29-5C9D-4E16-9928-F6970031D890-- From nobody Wed Aug 10 14:48:06 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CA112D868 for ; Wed, 10 Aug 2016 14:48:05 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 3X5TQU8E89F0 for ; Wed, 10 Aug 2016 14:48:04 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47313126579 for ; Wed, 10 Aug 2016 14:48:04 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id x196so18534021ybe.1 for ; Wed, 10 Aug 2016 14:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=78fmdz6iN0nkYUpwKngb6WgDgszrlzKqrheoKgTgV3Q=; b=jouX8e42Jlii+yoBER2DS7MiLH6oN8OKBWP4dfUO6gukqEKe3QHAC58qwGbBWO8SIb rEahTn4lA2RvZPfqBZ/iC43pEGbUsONcKMGimsoKANxrTcSpmzk8CdR0vVfb2tmoCZwA 0sZ/jLpvtGnZkNTWRl74uMUjsdytMBpTVI0OM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=78fmdz6iN0nkYUpwKngb6WgDgszrlzKqrheoKgTgV3Q=; b=DyC58G/fK5kg3QA9bd0OGOdBGxtQK+kKWYEPeyC2U0sp3Od9RdA0rp752uTxXlwHGC 51bYWaA6rVT4egVBGVZYQkDD7CMpRyrk5TwRg2RDc6OZE6IdgL0B+xQ6qrEhjy67L5dP 0mrO3cJy6npU2Bhb+atmm7rztCRBDnCra/P+VAwrDr+DW+fP7zC1P6AP+MBbWKxIDQEs go+1iQOsYSUC6a4WgynFGdmRo1iDY6CL8xNWMU2Ny4YaoFxqDDQtLtE+ph3PwzymMxjN 5pW4eUP3tV2LWscYyef6P+tp7+HB2mT+Zs+fGVL5R5J2tvBmJQ0CjyTjSiwP/8JGFLGk nRfQ== X-Gm-Message-State: AEkoouuO3z/BmTaaFM9zNcUek9nwE3Q/7r6bTViYSvnoH0ypSpZJbCwFN7N1Ki68HCF4qA== X-Received: by 10.37.44.7 with SMTP id s7mr3787503ybs.99.1470865683464; Wed, 10 Aug 2016 14:48:03 -0700 (PDT) Received: from [10.84.208.254] ([166.170.33.139]) by smtp.gmail.com with ESMTPSA id r186sm19344541ywr.38.2016.08.10.14.48.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 14:48:02 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6432A602-E63E-440D-857C-220D9055D955 Mime-Version: 1.0 (1.0) From: Sean Turner X-Mailer: iPhone Mail (13G35) In-Reply-To: <84916CC1-AE92-4566-B500-A5E8BC8B1468@gmail.com> Date: Wed, 10 Aug 2016 17:48:01 -0400 Content-Transfer-Encoding: 7bit Message-Id: <17767718-1822-4C81-9B75-615A1ED389D8@sn3rd.com> References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> <275EA92F-2101-4C33-85F8-FAE12F61D783@sn3rd.com> <84916CC1-AE92-4566-B500-A5E8BC8B1468@gmail.com> To: Yoav Nir Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 21:48:06 -0000 --Apple-Mail-6432A602-E63E-440D-857C-220D9055D955 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Aug 10, 2016, at 13:58, Yoav Nir wrote: >=20 >=20 >> On 10 Aug 2016, at 7:14 PM, Sean Turner wrote: >>=20 >> I=E2=80=99m half expecting a lmgtfy link, but is SHAKE available in OpenS= SL or on Widows or Macs? Having folks generate code for a new content type t= o support AEAD algorithms is one thing and maybe a pretty big thing at that.= Being the first (correct me if I=E2=80=99m wrong here) IETF protocol to ha= ve a SHOULD SHAKE requirement seems like a requirement that=E2=80=99s going t= o get ignored. If implementers don=E2=80=99t respond with a resounding chor= us of "oh yeah! we were going to do that in our next release of product X" t= hen I think that we should leave driving the SHAKE adoption train to some ot= her more widely deployed/used protocol for now and S/MIME can piggy back off= of it later. >=20 > Not in OpenSSL. AFAICT not in Windows or Mac library. You can find code on= line if you want to, though. >=20 > Looking at other places in the IETF, nobody=E2=80=99s rushing to write a =E2= =80=9CSHA-3 and its use in xxx=E2=80=9D documents. In fact, there are none. C= ompare and contrast with SHA-2 documents when that algorithm was new or with= ChaCha20/Poly1305 or Curve25519 documents more recently.=20 >=20 > The only document I=E2=80=99ve seen that uses SHA-3 is the EdDSA document w= here for Curve448 SHAKE256 is used internally. >=20 > So in a word, the IETF response to SHA-3 is =E2=80=9Cmeh=E2=80=9D There's also a handful of validated products too: http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html But, yeah I'm still thinking SHAKE shouldn't be a SHOULD. spt= --Apple-Mail-6432A602-E63E-440D-857C-220D9055D955 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Aug 10, 2016, at 13:= 58, Yoav Nir <ynir.ietf@gmail.com<= /a>> wrote:


On 10 Aug 2016, at 7:14 PM, Sean Turner <sean@sn3rd.com> wrote:

I=E2=80=99m half expecting a lmgtfy link, but is SHAKE ava= ilable in OpenSSL or on Widows or Macs?  Having folks generate code for= a new content type to support AEAD algorithms is one thing and maybe a pret= ty big thing at that.  Being the first (correct me if I=E2=80=99m wrong= here) IETF protocol to have a SHOULD SHAKE requirement seems like a require= ment that=E2=80=99s going to get ignored.  If implementers don=E2=80=99= t respond with a resounding chorus of "oh yeah! we were going to do that in o= ur next release of product X" then I think that we should leave driving the S= HAKE adoption train to some other more widely deployed/used protocol for now= and S/MIME can piggy back off of it later.

Not in OpenSSL. AFAICT not in Windows or Mac library. You can f= ind code online if you want to, though.

Loo= king at other places in the IETF, nobody=E2=80=99s rushing to write a =E2=80= =9CSHA-3 and its use in xxx=E2=80=9D documents. In fact, there are none. Com= pare and contrast with SHA-2 documents when that algorithm was new or with C= haCha20/Poly1305 or Curve25519 documents more recently.

The only document I=E2=80=99ve seen that uses SHA-3 is the EdD= SA document where for Curve448 SHAKE256 is used internally.
=
So in a word, the IETF response to SHA-3 is =E2=80=9Cmeh=E2= =80=9D

There's also a handful of validated p= roducts too:

But, yeah I'm still thinking SHAKE= shouldn't be a SHOULD.

spt
= --Apple-Mail-6432A602-E63E-440D-857C-220D9055D955-- From nobody Wed Aug 10 15:07:54 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F32412D880 for ; Wed, 10 Aug 2016 15:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, 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 v10cpjP7dZ2M for ; Wed, 10 Aug 2016 15:07:52 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BF312D87E for ; Wed, 10 Aug 2016 15:07:51 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 10 Aug 2016 15:20:02 -0700 From: Jim Schaad To: 'Sean Turner' References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> <275EA92F-2101-4C33-85F8-FAE12F61D783@sn3rd.com> <84916CC1-AE92-4566-B500-A5E8BC8B1468@gmail.com> <023801d1f33a$ecc23ba0$c646b2e0$@augustcellars.com> In-Reply-To: Date: Wed, 10 Aug 2016 15:07:46 -0700 Message-ID: <025c01d1f353$a1501430$e3f03c90$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025D_01D1F318.F4F2C2D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHWFVA45DH236BAKjdHgAKf0jipKAOM5yixAwUkYkIDO2h1gQIkrFdoARUtC9Kf0kIHEA== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: 'SPASM' , 'Yoav Nir' Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 22:07:54 -0000 ------=_NextPart_000_025D_01D1F318.F4F2C2D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Turner Sent: Wednesday, August 10, 2016 2:33 PM To: Jim Schaad Cc: SPASM ; Yoav Nir Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms =20 =20 On Aug 10, 2016, at 15:10, Jim Schaad > wrote: -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Wednesday, August 10, 2016 10:59 AM To: Sean Turner > Cc: SPASM > Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms =20 =20 On 10 Aug 2016, at 7:14 PM, Sean Turner > wrote: =20 I=E2=80=99m half expecting a lmgtfy link, but is SHAKE available in = OpenSSL or on Widows or Macs? Having folks generate code for a new content type to = support AEAD algorithms is one thing and maybe a pretty big thing at that. = Being the first (correct me if I=E2=80=99m wrong here) IETF protocol to have a = SHOULD SHAKE requirement seems like a requirement that=E2=80=99s going to get = ignored. If implementers don=E2=80=99t respond with a resounding chorus of "oh yeah! = we were going to do that in our next release of product X" then I think that we = should leave driving the SHAKE adoption train to some other more widely deployed/used protocol for now and S/MIME can piggy back off of it = later. =20 Not in OpenSSL. AFAICT not in Windows or Mac library. You can find code = online if you want to, though. =20 Looking at other places in the IETF, nobody=E2=80=99s rushing to write a = =E2=80=9CSHA-3 and its use in xxx=E2=80=9D documents. In fact, there are none. Compare and = contrast with SHA- 2 documents when that algorithm was new or with ChaCha20/Poly1305 or Curve25519 documents more recently. =20 The only document I=E2=80=99ve seen that uses SHA-3 is the EdDSA = document where for Curve448 SHAKE256 is used internally. This is the only place that I have seen it yet. There is also an issue = of having OIDs created. They exist for the SHA3 algorithms, but the = level of OIDs needed to treat SHAKE as a hash algorithm don't exist the = last time I went on a search. Jim =20 So in a word, the IETF response to SHA-3 is =E2=80=9Cmeh=E2=80=9D =20 Yoav =20 I knew I had seen some oids (if we need them): =20 http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html =20 Yes =E2=80=93 that gives you the OIDs for doing SHA3. But if you are = doing SHAKE, where are you encoding the length of the output? That is = what I meant by the OIDs for SHAKE do not exist. =20 Jim =20 =20 spt ------=_NextPart_000_025D_01D1F318.F4F2C2D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean = Turner
Sent: Wednesday, August 10, 2016 2:33 PM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>; Yoav Nir = <ynir.ietf@gmail.com>
Subject: Re: [Spasm] Change of = Algorithms: Digest Algorithms

 

 

On Aug 10, 2016, at 15:10, Jim Schaad = <ietf@augustcellars.com> = wrote:




-----Original = Message-----

From: Spasm [mailto:spasm-bounces@ietf.org]= On Behalf Of Yoav Nir

Sent: Wednesday, August 10, 2016 10:59 = AM

To: = Sean Turner <sean@sn3rd.com>

Cc: SPASM <spasm@ietf.org>

Subject: Re: [Spasm] Change of Algorithms: Digest = Algorithms

 

 

On = 10 Aug 2016, at 7:14 PM, Sean Turner <sean@sn3rd.com> = wrote:

 

I=E2=80=99m half expecting a lmgtfy link, but is SHAKE = available in OpenSSL or = on

Widows or Macs?  Having folks generate code for a = new content type to support

AEAD = algorithms is one thing and maybe a pretty big thing at that. =  Being the

first (correct me if I=E2=80=99m wrong here) IETF = protocol to have a SHOULD SHAKE

requirement seems like a requirement that=E2=80=99s = going to get ignored.  If

implementers don=E2=80=99t respond with a resounding = chorus of "oh yeah! we were

going to do that in our next release of product = X" then I think that we = should

leave driving the SHAKE adoption train to some other = more widely

deployed/used protocol for now and S/MIME can piggy = back off of it later.

 

Not = in OpenSSL. AFAICT not in Windows or Mac library. You can find code = online

if = you want to, though.

 

Looking at other places in the IETF, nobody=E2=80=99s = rushing to write a =E2=80=9CSHA-3 and = its

use = in xxx=E2=80=9D documents. In fact, there are none. Compare and contrast = with SHA-

2 = documents when that algorithm was new or with ChaCha20/Poly1305 = or

Curve25519 documents more = recently.

 

The = only document I=E2=80=99ve seen that uses SHA-3 is the EdDSA document = where for

Curve448 SHAKE256 is used = internally.


This is = the only place that I have seen it yet.  There is also an issue of = having OIDs created.  They exist for the SHA3 algorithms, but the = level of OIDs needed to treat SHAKE as a hash algorithm don't exist the = last time I went on a = search.

Jim


 

So = in a word, the IETF response to SHA-3 is = =E2=80=9Cmeh=E2=80=9D

 

Yoav

 

I knew = I had seen some oids (if we need them):

 

http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.ht= ml

 

Yes = =E2=80=93 that gives you the OIDs for doing SHA3.=C2=A0 But if you are = doing SHAKE, where are you encoding the length of the output?=C2=A0 That = is what I meant by the OIDs for SHAKE do not = exist.

 

Jim

 

 

spt

------=_NextPart_000_025D_01D1F318.F4F2C2D0-- From nobody Thu Aug 11 03:04:55 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DFF12B014 for ; Thu, 11 Aug 2016 03:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 8YPxQilrb16i for ; Thu, 11 Aug 2016 03:04:52 -0700 (PDT) Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) (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 E90C6126579 for ; Thu, 11 Aug 2016 03:04:51 -0700 (PDT) Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx08-00178001.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u7BA1Knf023255; Thu, 11 Aug 2016 12:04:50 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx08-00178001.pphosted.com with ESMTP id 24n515jbwu-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Aug 2016 12:04:50 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9D48831; Thu, 11 Aug 2016 10:04:49 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas6.st.com [10.75.90.73]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 4542F1579; Thu, 11 Aug 2016 10:04:49 +0000 (GMT) Received: from [10.137.2.67] (10.137.2.67) by webmail-eu.st.com (10.75.90.73) with Microsoft SMTP Server id 8.3.444.0; Thu, 11 Aug 2016 12:04:48 +0200 To: References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> <275EA92F-2101-4C33-85F8-FAE12F61D783@sn3rd.com> <84916CC1-AE92-4566-B500-A5E8BC8B1468@gmail.com> <17767718-1822-4C81-9B75-615A1ED389D8@sn3rd.com> From: Gilles Van Assche X-Enigmail-Draft-Status: N1110 Message-ID: <57AC4DCD.1070306@st.com> Date: Thu, 11 Aug 2016 12:05:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <17767718-1822-4C81-9B75-615A1ED389D8@sn3rd.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-11_06:, , signatures=0 Archived-At: Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 10:04:54 -0000 It still surprises me that people stick to SHA-2, a family of algorithms designed by NSA behind closed doors, while SHA-3 - comes with a design rationale; - received many years of public scrutiny before it became a standard; - has a thicker safety margin; - has software performances similar to SHA-2 (or better performance at a comparable safety margin); - offers much better performance in many cases (e.g., hardware, side-channel protections); - excels at flexibility with simpler and more efficient solutions for mask generating functions, PRF, MAC, PRNG, etc. Kind regards, Gilles On 10/08/16 23:48, Sean Turner wrote: > > On Aug 10, 2016, at 13:58, Yoav Nir > wrote: > >> >>> On 10 Aug 2016, at 7:14 PM, Sean Turner >> > wrote: >>> >>> I’m half expecting a lmgtfy link, but is SHAKE available in OpenSSL >>> or on Widows or Macs? Having folks generate code for a new content >>> type to support AEAD algorithms is one thing and maybe a pretty big >>> thing at that. Being the first (correct me if I’m wrong here) IETF >>> protocol to have a SHOULD SHAKE requirement seems like a requirement >>> that’s going to get ignored. If implementers don’t respond with a >>> resounding chorus of "oh yeah! we were going to do that in our next >>> release of product X" then I think that we should leave driving the >>> SHAKE adoption train to some other more widely deployed/used >>> protocol for now and S/MIME can piggy back off of it later. >> >> Not in OpenSSL. AFAICT not in Windows or Mac library. You can find >> code online if you want to, though. >> >> Looking at other places in the IETF, nobody’s rushing to write a >> “SHA-3 and its use in xxx” documents. In fact, there are none. >> Compare and contrast with SHA-2 documents when that algorithm was new >> or with ChaCha20/Poly1305 or Curve25519 documents more recently. >> >> The only document I’ve seen that uses SHA-3 is the EdDSA document >> where for Curve448 SHAKE256 is used internally. >> >> So in a word, the IETF response to SHA-3 is “meh” > > There's also a handful of validated products too: > http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html > > But, yeah I'm still thinking SHAKE shouldn't be a SHOULD. > > spt From nobody Thu Aug 11 03:24:43 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5D712D0A1 for ; Thu, 11 Aug 2016 03:24:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 aMLtLf2FTi-S for ; Thu, 11 Aug 2016 03:24:38 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0128.outbound.protection.outlook.com [23.103.201.128]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B0B12B069 for ; Thu, 11 Aug 2016 03:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MvxsFI3zHJM9U9qoKtDrstV+iZa5OGFhei+nJf0zuGU=; b=MzSoxk14tyf+Q4IZu5ZqxYcb9l8P86Bp6eg/jmOK6VQZak3ttnWM7d7b5iEczJ5EQ9CZCuyDODUsTdF+rKeAy3RMMq+zyFJnkwbHDm6/KAwofqqsGSg7sNdlAdUOQgC/55XB2FerzNi3U9uEvULcbSA+7x94Gnwa5ojEdQ9z8pE= Received: from MWHPR09MB1390.namprd09.prod.outlook.com (10.172.51.16) by MWHPR09MB1390.namprd09.prod.outlook.com (10.172.51.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 11 Aug 2016 10:24:34 +0000 Received: from MWHPR09MB1390.namprd09.prod.outlook.com ([10.172.51.16]) by MWHPR09MB1390.namprd09.prod.outlook.com ([10.172.51.16]) with mapi id 15.01.0549.025; Thu, 11 Aug 2016 10:24:34 +0000 From: "Dang, Quynh (Fed)" To: Jim Schaad , 'Sean Turner' Thread-Topic: [Spasm] Change of Algorithms: Digest Algorithms Thread-Index: AQHR8ZUU0gvUKfqt3UaAyC8x2q/k8qBCYX2AgAAdAICAABQqgIAAJ58AgAAJzwCAAIrMAA== Date: Thu, 11 Aug 2016 10:24:33 +0000 Message-ID: References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> <275EA92F-2101-4C33-85F8-FAE12F61D783@sn3rd.com> <84916CC1-AE92-4566-B500-A5E8BC8B1468@gmail.com> <023801d1f33a$ecc23ba0$c646b2e0$@augustcellars.com> <025c01d1f353$a1501430$e3f03c90$@augustcellars.com> In-Reply-To: <025c01d1f353$a1501430$e3f03c90$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.220.213] x-ms-office365-filtering-correlation-id: e338b153-84e3-4578-ebdc-08d3c1d1b0b2 x-microsoft-exchange-diagnostics: 1; MWHPR09MB1390; 6:xoANIeuzqaTtNXHLA+Fs0c7HBnDeICIQCYozn4beFciUftbjuydBN+FgWM4xsyotkLrsj7qMIqwFT5XvN3VGR1GHmBeqRJmmJcp/6acwzDbhvRk4Y8I/Jq9OkRy/6JGlzdB0fzOQ5GBzcn6BYEhzuCLt28IUEGt6UMVisRFfob+EU86AFXsPUlWubnS8ld2GfZdGj/kbJBjI1xJ7aTUe5E70KhCgkTZ7d43m4NgfkrKChhENR2TgIu/ThTTWAfVJnOs9Ul2vhfb+OYHsPsmggQPWoTcD53G9jecJ88oXI4oR1zTzAuUK3RNVvhlwVmO3qpULyT72DCr1tbIGKf+L5g==; 5:zmq19XRZ+FlS/iWqn49XnM9DbjPAygpz+sVy/tRgH9SlnJVsuwmnfHA51qXbw5+wUpWAaoLQVQvR42IAds8Vt8qKjTgz1K4CxGS3lOBVeaNhIjTH4TokB+0jM1DKtDo8kZo9bE9g20rbdTllQDBCHA==; 24:xRSQiH049ecCuJPoZ4F+7URZ8fZwvheQnu23ddBuAZcU5e/YDeVo+F90HTIjxvWsxhjCj1uST6KkKfSS8DJLxRYnqmJLZZCtVPbu0mO8KDg=; 7:UnhIVfneH3hr4hCF5xceE+ukV2uudtucdgZ/WUMKxI0QI7urJTfXxgf2IAbYKel3BPQltzgCjNUVexn7be6fq37RFm42EzQlDyZr4EBBOAOhSn/vqo9p7wyhLrxNmGvLdKwGPkKfi0JhX7YtpMBa3DD5Z0FVn6oiaMNutrPn3Xw7O/icxLSgg1g6SSzgH12MSm1uRk9i9ROpcugiBWEkEk0yQwWo25S9iAF9T0vxBxbekGH9SFDUQAWvopyJL4km x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1390; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(209352067349851)(131022147185803)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040171)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:MWHPR09MB1390; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1390; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(51444003)(189002)(377454003)(13464003)(199003)(18543002)(24454002)(101416001)(87936001)(93886004)(10400500002)(19617315012)(5002640100001)(86362001)(19580395003)(19625215002)(36756003)(77096005)(66066001)(76176999)(54356999)(16236675004)(122556002)(50986999)(7906003)(8676002)(2900100001)(2950100001)(105586002)(15975445007)(5001770100001)(3280700002)(99286002)(4326007)(2906002)(92566002)(790700001)(189998001)(586003)(7846002)(7736002)(19580405001)(3846002)(6116002)(4001350100001)(102836003)(3660700001)(68736007)(19300405004)(97736004)(81166006)(106116001)(83506001)(8936002)(106356001)(11100500001)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1390; H:MWHPR09MB1390.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D3D1C5DC2883Eqdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2016 10:24:33.7085 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1390 Archived-At: Cc: 'SPASM' , 'Yoav Nir' Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 10:24:41 -0000 --_000_D3D1C5DC2883Eqdangnistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jim, I can get SHAKE128/256 and SHAKE256/512 (256-bit and 512-bit hash outputs r= espectively) assigned with new OIDs for you and the working group. One of the beauties of the SHAKEs is that one can use a SHAKE (1) to do fu= ll-domain hash RSA signatures or (2) as a MGF very efficiently because the= SHAKEs are one-pass construction. SHAKEs are also very efficient PRFs, MACs and KDFs because they are one-pas= s construction; not like HMAC and other PRFs. One can also have authentica= ted ciphers from the Keccak permuation inside the SHAKES and more. Regards, Quynh. From: Spasm > on beha= lf of Jim Schaad > Date: Wednesday, August 10, 2016 at 6:07 PM To: 'Sean Turner' > Cc: 'SPASM' >, 'Yoav Nir' > Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Turner Sent: Wednesday, August 10, 2016 2:33 PM To: Jim Schaad > Cc: SPASM >; Yoav Nir > Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms On Aug 10, 2016, at 15:10, Jim Schaad > wrote: -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Wednesday, August 10, 2016 10:59 AM To: Sean Turner > Cc: SPASM > Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms On 10 Aug 2016, at 7:14 PM, Sean Turner > wrote: I'm half expecting a lmgtfy link, but is SHAKE available in OpenSSL or on Widows or Macs? Having folks generate code for a new content type to suppo= rt AEAD algorithms is one thing and maybe a pretty big thing at that. Being t= he first (correct me if I'm wrong here) IETF protocol to have a SHOULD SHAKE requirement seems like a requirement that's going to get ignored. If implementers don't respond with a resounding chorus of "oh yeah! we were going to do that in our next release of product X" then I think that we sho= uld leave driving the SHAKE adoption train to some other more widely deployed/used protocol for now and S/MIME can piggy back off of it later. Not in OpenSSL. AFAICT not in Windows or Mac library. You can find code onl= ine if you want to, though. Looking at other places in the IETF, nobody's rushing to write a "SHA-3 and= its use in xxx" documents. In fact, there are none. Compare and contrast with S= HA- 2 documents when that algorithm was new or with ChaCha20/Poly1305 or Curve25519 documents more recently. The only document I've seen that uses SHA-3 is the EdDSA document where for Curve448 SHAKE256 is used internally. This is the only place that I have seen it yet. There is also an issue of = having OIDs created. They exist for the SHA3 algorithms, but the level of = OIDs needed to treat SHAKE as a hash algorithm don't exist the last time I = went on a search. Jim So in a word, the IETF response to SHA-3 is "meh" Yoav I knew I had seen some oids (if we need them): http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html Yes - that gives you the OIDs for doing SHA3. But if you are doing SHAKE, = where are you encoding the length of the output? That is what I meant by t= he OIDs for SHAKE do not exist. Jim spt --_000_D3D1C5DC2883Eqdangnistgov_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <65C136DDAE098F4F8D2CCF64C66EBB41@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Jim,

I can get SHAKE128/256 and SHAKE256/512 (256-bit and 512-bit hash outp= uts respectively) assigned with new OIDs for you and the working group.

One of the beauties of the SHAKEs is that one can use a SHAKE  (1= ) to do full-domain hash RSA signatures or  (2) as a MGF very efficien= tly because the SHAKEs are one-pass construction. 

SHAKEs are also very efficient PRFs, MACs and KDFs because they are on= e-pass construction; not like HMAC and other PRFs.  One can also have = authenticated ciphers from the Keccak permuation inside the SHAKES and more= .

Regards,
Quynh. 

From: Spasm <spasm-bounces@ietf.org> on behalf of Jim Scha= ad <ietf@augustcellars.com= >
Date: Wednesday, August 10, 2016 at= 6:07 PM
To: 'Sean Turner' <sean@sn3rd.com>
Cc: 'SPASM' <spasm@ietf.org>, 'Yoav Nir' <ynir.ietf@gmail.com>
Subject: Re: [Spasm] Change of Algo= rithms: Digest Algorithms

 

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Turner
Sent: Wednesday, August 10, 2016 2:33 PM
To: Jim Schaad <ietf@au= gustcellars.com>
Cc: SPASM <spasm@ietf.org&g= t;; Yoav Nir <ynir.ietf@gmail.com= >
Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms

 

 

On Aug 10, 2016, at 1= 5:10, Jim Schaad <ietf@augustc= ellars.com> wrote:




-----Original Message-----

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Yoav Nir

Sent: Wednesday, August 10, 2016 10:59 AM=

To: Sean Turner <sean@sn3rd.com>

Cc: SPASM <spas= m@ietf.org>

Subject: Re: [Spasm] Change of Algorithms: Digest Al= gorithms

 

 

On 10 Aug 2016, at 7:14 PM, Sean Turner <sean@sn3rd.com> wrote:

 

I’m half expecting a lmgtfy link, but is SHAKE= available in OpenSSL or on

Widows or Macs?  Having folks generate code for= a new content type to support

AEAD algorithms is one thing and maybe a pretty big = thing at that.  Being the

first (correct me if I’m wrong here) IETF prot= ocol to have a SHOULD SHAKE

requirement seems like a requirement that’s go= ing to get ignored.  If

implementers don’t respond with a resounding c= horus of "oh yeah! we were

going to do that in our next release of product X&qu= ot; then I think that we should

leave driving the SHAKE adoption train to some other= more widely

deployed/used protocol for now and S/MIME can piggy = back off of it later.

 

Not in OpenSSL. AFAICT not in Windows or Mac library= . You can find code online

if you want to, though.

 

Looking at other places in the IETF, nobody’s = rushing to write a “SHA-3 and its

use in xxx” documents. In fact, there are none= . Compare and contrast with SHA-

2 documents when that algorithm was new or with ChaC= ha20/Poly1305 or

Curve25519 documents more recently.

 

The only document I’ve seen that uses SHA-3 is= the EdDSA document where for

Curve448 SHAKE256 is used internally.


This is the only place that I have seen it yet.  There is also an issu= e of having OIDs created.  They exist for the SHA3 algorithms, but the= level of OIDs needed to treat SHAKE as a hash algorithm don't exist the la= st time I went on a search.

Jim


 

So in a word, the IETF response to SHA-3 is “m= eh”

 

Yoav

 

I knew I had seen some oids (if we need them):<= /o:p>

 

http://csrc.nist.gov/groups/ST/crypto_apps_in= fra/csor/algorithms.html

 

Yes – that gives you the OIDs for doing SHA3.  Bu= t if you are doing SHAKE, where are you encoding the length of the output?&= nbsp; That is what I meant by the OIDs for SHAKE do not exist.

 

Jim

 

 

spt

 --_000_D3D1C5DC2883Eqdangnistgov_-- From nobody Thu Aug 11 07:14:44 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F25912D608 for ; Thu, 11 Aug 2016 07:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 LDXKgx05JKnu for ; Thu, 11 Aug 2016 07:14:38 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6714E12D727 for ; Thu, 11 Aug 2016 07:10:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5BD8E3002C4 for ; Thu, 11 Aug 2016 10:10:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id B62q5pjDxakN for ; Thu, 11 Aug 2016 10:10:30 -0400 (EDT) Received: from [192.168.1.28] (nc-71-50-129-15.dyn.embarqhsd.net [71.50.129.15]) by mail.smeinc.net (Postfix) with ESMTPSA id CB0E53002BA; Thu, 11 Aug 2016 10:10:29 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <57AC4DCD.1070306@st.com> Date: Thu, 11 Aug 2016 10:10:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <56EE8864-1678-4C32-B243-EAC654F82F7F@vigilsec.com> References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> <275EA92F-2101-4C33-85F8-FAE12F61D783@sn3rd.com> <84916CC1-AE92-4566-B500-A5E8BC8B1468@gmail.com> <17767718-1822-4C81-9B75-615A1ED389D8@sn3rd.com> <57AC4DCD.1070306@st.com> To: Gilles Van Assche X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 14:14:42 -0000 Gilles: I recognize some of the these advantages you point out. last time I = looked, SHA3 is less widely implemented and slower than SHA2. You say = it is faster. Can you point me to the measurements? Russ On Aug 11, 2016, at 6:05 AM, Gilles Van Assche = wrote: > It still surprises me that people stick to SHA-2, a family of = algorithms > designed by NSA behind closed doors, while SHA-3 > - comes with a design rationale; > - received many years of public scrutiny before it became a standard; > - has a thicker safety margin; > - has software performances similar to SHA-2 (or better performance at = a > comparable safety margin); > - offers much better performance in many cases (e.g., hardware, > side-channel protections); > - excels at flexibility with simpler and more efficient solutions for > mask generating functions, PRF, MAC, PRNG, etc. >=20 > Kind regards, > Gilles >=20 >=20 > On 10/08/16 23:48, Sean Turner wrote: >>=20 >> On Aug 10, 2016, at 13:58, Yoav Nir > > wrote: >>=20 >>>=20 >>>> On 10 Aug 2016, at 7:14 PM, Sean Turner >>> > wrote: >>>>=20 >>>> I=92m half expecting a lmgtfy link, but is SHAKE available in = OpenSSL >>>> or on Widows or Macs? Having folks generate code for a new content >>>> type to support AEAD algorithms is one thing and maybe a pretty big >>>> thing at that. Being the first (correct me if I=92m wrong here) = IETF >>>> protocol to have a SHOULD SHAKE requirement seems like a = requirement >>>> that=92s going to get ignored. If implementers don=92t respond = with a >>>> resounding chorus of "oh yeah! we were going to do that in our next >>>> release of product X" then I think that we should leave driving the >>>> SHAKE adoption train to some other more widely deployed/used >>>> protocol for now and S/MIME can piggy back off of it later. >>>=20 >>> Not in OpenSSL. AFAICT not in Windows or Mac library. You can find >>> code online if you want to, though. >>>=20 >>> Looking at other places in the IETF, nobody=92s rushing to write a >>> =93SHA-3 and its use in xxx=94 documents. In fact, there are none. >>> Compare and contrast with SHA-2 documents when that algorithm was = new >>> or with ChaCha20/Poly1305 or Curve25519 documents more recently. >>>=20 >>> The only document I=92ve seen that uses SHA-3 is the EdDSA document >>> where for Curve448 SHAKE256 is used internally. >>>=20 >>> So in a word, the IETF response to SHA-3 is =93meh=94 >>=20 >> There's also a handful of validated products too: >> http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html >>=20 >> But, yeah I'm still thinking SHAKE shouldn't be a SHOULD. >>=20 >> spt >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Aug 11 07:17:26 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515A912D612 for ; Thu, 11 Aug 2016 07:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 vvEO8T0Q1Z8L for ; Thu, 11 Aug 2016 07:17:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F39612D0E4 for ; Thu, 11 Aug 2016 07:13:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4F7543002BA for ; Thu, 11 Aug 2016 10:13:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HKTjkfUBMns7 for ; Thu, 11 Aug 2016 10:13:28 -0400 (EDT) Received: from [192.168.1.28] (nc-71-50-129-15.dyn.embarqhsd.net [71.50.129.15]) by mail.smeinc.net (Postfix) with ESMTPSA id B4EED3005A7; Thu, 11 Aug 2016 10:13:27 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <0a055590-65d1-3d99-5f06-805f38b70f76@seantek.com> Date: Thu, 11 Aug 2016 10:13:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26155D71-EAB2-4D0E-90D2-0DDF37083E02@vigilsec.com> References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <3f325b55fd814e6fb45360550c42f74a@usma1ex-dag1mb1.msg.corp.akamai.com> <3b80d361-3134-6328-1a97-ea8dc17260a6@seantek.com> <016201d1f2a3$82fc7830$88f56890$@augustcellars.com> <0a055590-65d1-3d99-5f06-805f38b70f76@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 14:17:25 -0000 Sean: Please see RFC 7696 for the definitions being used here: SHOULD+ This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted to a MUST in the future. SHOULD- This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD- will be deprecated to a MAY or worse in the future. MUST- This term means the same as MUST. However, it is expected that an algorithm marked as MUST- will be downgraded in the future. Although the status of the algorithm will be determined at a later time, it is reasonable to expect that a the status of a MUST- algorithm will remain at least a SHOULD or a SHOULD-. Russ On Aug 10, 2016, at 12:16 AM, Sean Leonard wrote: > whoops, my bad. I guess I meant SHOULD- to mean "not really SHOULD = right now, but it's going to be SHOULD soon", which I guess would be = like a MAY+ or SHOULD=E2=86=91=E2=86=91. >=20 > But there are no MAY+ or SHOULD=E2=86=91=E2=86=91 keywords. So, I = suppose, just "SHOULD"? Unless you want to propose a new term. >=20 > Sean >=20 > On 8/9/2016 6:07 PM, Jim Schaad wrote: >> Why not just make it a MAY in that case or not mention it? >>=20 >> SHOULD- This term means the same as SHOULD. However, the authors = expect >> that a requirement marked as SHOULD- will be demoted to a MAY in a = future >> version of this document. >>=20 >> Are you really saying it is going to go away in future versions? >>=20 >> jim >>=20 >>> -----Original Message----- >>> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean = Leonard >>> Sent: Tuesday, August 09, 2016 4:45 PM >>> To: spasm@ietf.org >>> Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms >>>=20 >>> On 8/8/2016 7:07 AM, Salz, Rich wrote: >>>>> 1. There is only one MUST and no path forward. Is this a problem >>>>> that needs to be dealt with? EdDSA25519 uses SHA-512 under the >>>>> covers, does that mean we should make SHA-512 at least a SHOULD = here? >>>>>=20 >>>>> 2. Is there anybody who wants to standup and argue for adopting = in >>>>> any of the SHA-3 algorithms? >>>> I'd like to see *something* as a should. I have a slight = preference >> for >>> SHA512, but could live with SHA3 if others feel strongly. >>>=20 >>> I think SHA-3 should be SHOULD-. >>>=20 >>> Sean >>>=20 >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://www.ietf.org/mailman/listinfo/spasm >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Aug 11 07:32:50 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287DF12D791 for ; Thu, 11 Aug 2016 07:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 Du9glu0u5yvR for ; Thu, 11 Aug 2016 07:32:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B596C12D766 for ; Thu, 11 Aug 2016 07:32:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B4E0C2015D; Thu, 11 Aug 2016 10:42:55 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8C592638D1; Thu, 11 Aug 2016 10:32:10 -0400 (EDT) From: Michael Richardson To: Gilles Van Assche In-Reply-To: <57AC4DCD.1070306@st.com> References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> <275EA92F-2101-4C33-85F8-FAE12F61D783@sn3rd.com> <84916CC1-AE92-4566-B500-A5E8BC8B1468@gmail.com> <17767718-1822-4C81-9B75-615A1ED389D8@sn3rd.com> <57AC4DCD.1070306@st.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 14:32:48 -0000 --=-=-= Content-Type: text/plain Gilles Van Assche wrote: > It still surprises me that people stick to SHA-2, a family of > algorithms designed by NSA behind closed doors, while SHA-3 - comes I tend to agree. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV6yMZ4CLcPvd0N1lAQIDkwgAkQZKnoH+VmuDhYSzZLPgEaEhKwDvOd4x 1VzE1z981ij1o2nUy5sh6M1WaZEq8PpKNDh9bs1yvvVjtjeQB6zUye1t+2JHjK8a e5Zpbp+xJG/nSAhgKKJ4ubNhC+F5o0FNYiCL4LMhze+FE0wUpZSY2+ncLoePGkz7 Cpqm18FR2HTS5RtX0sJOsRGjnM7BRAruaeCGRspLVJ3axqmo+OnVhcmRAY19m5hK THHsGNbta90cy3BAikq0vAmJE6gdGgRYnbbo1Xt8G8TuhK46Jrp+lmYuHH14WVOA WthQXJShrS8+/GCvFUYpPuDxP9R5piB4mmNkb+kcSD2rJ8RNEYsonQ== =olSU -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 11 15:44:54 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5F412D746 for ; Thu, 11 Aug 2016 15:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 infVRv4FXA-2 for ; Thu, 11 Aug 2016 15:44:51 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 648D512D16F for ; Thu, 11 Aug 2016 15:44:51 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 68D7F509B6 for ; Thu, 11 Aug 2016 18:44:50 -0400 (EDT) To: spasm@ietf.org References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <3f325b55fd814e6fb45360550c42f74a@usma1ex-dag1mb1.msg.corp.akamai.com> <3b80d361-3134-6328-1a97-ea8dc17260a6@seantek.com> <016201d1f2a3$82fc7830$88f56890$@augustcellars.com> <0a055590-65d1-3d99-5f06-805f38b70f76@seantek.com> <26155D71-EAB2-4D0E-90D2-0DDF37083E02@vigilsec.com> From: Sean Leonard Message-ID: <07fe682e-c8de-6e3c-5943-ac06a73eef9b@seantek.com> Date: Thu, 11 Aug 2016 15:42:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <26155D71-EAB2-4D0E-90D2-0DDF37083E02@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 22:44:53 -0000 Yes. As I pointed out, I was going for "MAY+", which is not actually a term that exists (yet). Not sure if a MAY+ should be added to the definitions, or just leave it alone. My preferences are: #1 MAY+ #2 SHOULD #3 (omit) As Gilles Van Assche mentioned, SHA-3 has a lot of design advantages. Given that SHA-1 is waning, it would be better to get ahead of the curve. But this industry has a tendency to be very reactionary: "don't add new stuff if the old stuff is not obviously broken". It took 11+ years to get SHA-1 just starting to be phased out. Just something to think about. Sean On 8/11/2016 7:13 AM, Russ Housley wrote: > Sean: > > Please see RFC 7696 for the definitions being used here: > > > SHOULD+ This term means the same as SHOULD. However, it is > likely that an algorithm marked as SHOULD+ will be > promoted to a MUST in the future. > > SHOULD- This term means the same as SHOULD. However, it is > likely that an algorithm marked as SHOULD- will be > deprecated to a MAY or worse in the future. > > MUST- This term means the same as MUST. However, it is > expected that an algorithm marked as MUST- will be > downgraded in the future. Although the status of the > algorithm will be determined at a later time, it is > reasonable to expect that a the status of a MUST- > algorithm will remain at least a SHOULD or a SHOULD-. > > Russ > > > On Aug 10, 2016, at 12:16 AM, Sean Leonard wrote: > >> whoops, my bad. I guess I meant SHOULD- to mean "not really SHOULD right now, but it's going to be SHOULD soon", which I guess would be like a MAY+ or SHOULD↑↑. >> >> But there are no MAY+ or SHOULD↑↑ keywords. So, I suppose, just "SHOULD"? Unless you want to propose a new term. >> >> Sean >> From nobody Fri Aug 12 01:06:01 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842EA12D9D9 for ; Fri, 12 Aug 2016 01:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 A0pCE0JozM6X for ; Fri, 12 Aug 2016 01:05:58 -0700 (PDT) Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [62.209.51.94]) (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 58DCA12D9C9 for ; Fri, 12 Aug 2016 01:05:57 -0700 (PDT) Received: from pps.filterd (m0046668.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u7C7vhUO025003; Fri, 12 Aug 2016 10:05:56 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 24ruw8kg95-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Aug 2016 10:05:56 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 2D99831; Fri, 12 Aug 2016 08:05:54 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas6.st.com [10.75.90.73]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9A50313DA; Fri, 12 Aug 2016 08:05:54 +0000 (GMT) Received: from [10.137.2.67] (10.137.2.67) by webmail-eu.st.com (10.75.90.73) with Microsoft SMTP Server id 8.3.444.0; Fri, 12 Aug 2016 10:05:53 +0200 To: Russ Housley References: <020d01d1f11d$731ef7d0$595ce770$@augustcellars.com> <57A8B886.9010600@st.com> <275EA92F-2101-4C33-85F8-FAE12F61D783@sn3rd.com> <84916CC1-AE92-4566-B500-A5E8BC8B1468@gmail.com> <17767718-1822-4C81-9B75-615A1ED389D8@sn3rd.com> <57AC4DCD.1070306@st.com> <56EE8864-1678-4C32-B243-EAC654F82F7F@vigilsec.com> From: Gilles Van Assche X-Enigmail-Draft-Status: N1110 Message-ID: <57AD836E.901@st.com> Date: Fri, 12 Aug 2016 10:06:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56EE8864-1678-4C32-B243-EAC654F82F7F@vigilsec.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-12_02:, , signatures=0 Archived-At: Cc: "spasm@ietf.org" Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 08:06:00 -0000 Hi Russ, For hardware performance, you can have a look at the reports made during the SHA-3 competition (including comparisons with SHA-2), e.g., [1] [2]. For software performance, eBASH contains benchmarks on several machines. You may also want to run "KeccakTests --speed" with the Keccak code package [3], which contains some more recent implementations. (It is on our ever-growing to-do list to submit those to eBASH.) E.g., on Sandy Bridge [4]: SHAKE128 (keccakc256): 8.81 c/b SHAKE256 (keccakc512): 10.87 c/b SHA-512: 10.94 c/b SHA-256: 14.12 c/b E.g., on Skylake [5]: SHA-512: 5.08 c/b SHAKE128: 7.01 c/b SHA-256: 7.62 c/b SHAKE256: 8.64 c/b Kind regards, Gilles [1] http://csrc.nist.gov/groups/ST/hash/sha-3/Round3/March2012/documents/papers/GURKAYNAK_paper.pdf [2] http://eprint.iacr.org/2012/368.pdf [3] https://github.com/gvanas/KeccakCodePackage [4] http://bench.cr.yp.to/results-hash.html#amd64-h6sandy [5] http://bench.cr.yp.to/results-hash.html#amd64-skylake On 11/08/16 16:10, Russ Housley wrote: > Gilles: > > I recognize some of the these advantages you point out. last time I looked, SHA3 is less widely implemented and slower than SHA2. You say it is faster. Can you point me to the measurements? > > Russ > > > On Aug 11, 2016, at 6:05 AM, Gilles Van Assche wrote: > >> It still surprises me that people stick to SHA-2, a family of algorithms >> designed by NSA behind closed doors, while SHA-3 >> - comes with a design rationale; >> - received many years of public scrutiny before it became a standard; >> - has a thicker safety margin; >> - has software performances similar to SHA-2 (or better performance at a >> comparable safety margin); >> - offers much better performance in many cases (e.g., hardware, >> side-channel protections); >> - excels at flexibility with simpler and more efficient solutions for >> mask generating functions, PRF, MAC, PRNG, etc. >> >> Kind regards, >> Gilles >> >> >> On 10/08/16 23:48, Sean Turner wrote: >>> On Aug 10, 2016, at 13:58, Yoav Nir >> > wrote: >>> >>>>> On 10 Aug 2016, at 7:14 PM, Sean Turner >>>> > wrote: >>>>> >>>>> I’m half expecting a lmgtfy link, but is SHAKE available in OpenSSL >>>>> or on Widows or Macs? Having folks generate code for a new content >>>>> type to support AEAD algorithms is one thing and maybe a pretty big >>>>> thing at that. Being the first (correct me if I’m wrong here) IETF >>>>> protocol to have a SHOULD SHAKE requirement seems like a requirement >>>>> that’s going to get ignored. If implementers don’t respond with a >>>>> resounding chorus of "oh yeah! we were going to do that in our next >>>>> release of product X" then I think that we should leave driving the >>>>> SHAKE adoption train to some other more widely deployed/used >>>>> protocol for now and S/MIME can piggy back off of it later. >>>> Not in OpenSSL. AFAICT not in Windows or Mac library. You can find >>>> code online if you want to, though. >>>> >>>> Looking at other places in the IETF, nobody’s rushing to write a >>>> “SHA-3 and its use in xxx” documents. In fact, there are none. >>>> Compare and contrast with SHA-2 documents when that algorithm was new >>>> or with ChaCha20/Poly1305 or Curve25519 documents more recently. >>>> >>>> The only document I’ve seen that uses SHA-3 is the EdDSA document >>>> where for Curve448 SHAKE256 is used internally. >>>> >>>> So in a word, the IETF response to SHA-3 is “meh” >>> There's also a handful of validated products too: >>> http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html >>> >>> But, yeah I'm still thinking SHAKE shouldn't be a SHOULD. >>> >>> spt >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm > From nobody Tue Aug 16 10:23:26 2016 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F2A12D129; Tue, 16 Aug 2016 10:23:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147136820563.22928.2476033573179146793.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 10:23:25 -0700 Archived-At: Cc: spasm@ietf.org, lamps-chairs@ietf.org, housley@vigilsec.com, stephen.farrell@cs.tcd.ie Subject: [Spasm] lamps - New Meeting Session Request for IETF 97 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 17:23:26 -0000 A new meeting session request has just been submitted by Russ Housley, a Chair of the lamps working group. --------------------------------------------------------- Working Group Name: Limited Additional Mechanisms for PKIX and SMIME Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: curdle cose dane ianaplan jose perc saag sidr sipbrandy stir tls rtcweb acme openpgp sidrops its Second Priority: ntp cfrg dprive ecrit oauth quic sacm mile modern Third Priority: mtgvenue Special Requests: --------------------------------------------------------- From nobody Tue Aug 16 11:27:03 2016 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E20012D123; Tue, 16 Aug 2016 11:27:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147137202221.22994.15639644615800214195.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 11:27:02 -0700 Archived-At: Cc: spasm@ietf.org, lamps-chairs@ietf.org, housley@vigilsec.com, stephen.farrell@cs.tcd.ie Subject: [Spasm] lamps - Update to a Meeting Session Request for IETF 97 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 18:27:02 -0000 An update to a meeting session request has just been submitted by Russ Housley, a Chair of the lamps working group. --------------------------------------------------------- Working Group Name: Limited Additional Mechanisms for PKIX and SMIME Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: curdle cose dane ianaplan jose perc saag sidr sipbrandy stir tls rtcweb acme openpgp sidrops its radext Second Priority: ntp cfrg dprive ecrit oauth quic sacm mile modern Third Priority: mtgvenue Special Requests: --------------------------------------------------------- From nobody Tue Aug 16 14:18:16 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34D012D181 for ; Tue, 16 Aug 2016 14:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, 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 DyJ7Mm3WoK4p for ; Tue, 16 Aug 2016 14:18:11 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4783D12B024 for ; Tue, 16 Aug 2016 14:18:10 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 16 Aug 2016 14:29:58 -0700 From: Jim Schaad To: 'SPASM' Date: Tue, 16 Aug 2016 14:17:40 -0700 Message-ID: <05da01d1f803$a0d885f0$e28991d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05DB_01D1F7C8.F47BA9C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdH3/qUvnAntdyxAQhmptO9SjNvC7w== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: [Spasm] Change of Algorithms: Take 3 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 21:18:14 -0000 ------=_NextPart_000_05DB_01D1F7C8.F47BA9C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This message looks at Signature Algorithms. Please restrict your = discussions to this set of algorithms, I will be sending out messages on = other algorithms over time. =20 I have started doing the editing work on this. The pull request can be = found at https://github.com/lamps-wg/smime/pull/21 =20 =20 Current Document for S/MIME 3.1 =20 MUST: RSA w/ SHA-256 SHOULD+: DSA w/ SHA-256, RSASSA-PSS w/ SHA-256 SHOULD-: RSA w/ SHA-1, DSA w/SHA-1, RSA w/ MD5 Historic: =20 Key Sizes: RSA and DSA - sign SHOULD NOT Key size <=3D 1023 SHOULD 1024 <=3D key size <=3D 2048 MAY 2048 < key size =20 =20 RSA and DSA - Verify MAY key size <=3D 1023 MUST 1024 <=3D key size <=3D 2048 MAY 2048 < key size =20 RSA - Certificate Verify MAY key size <=3D 1023 MUST 1024 <=3D key size <=3D 4096 MAY 4096 < key size =20 DSA - Certificate Verify MAY key size <=3D 1023 MUST 1024 <=3D key size <=3D 3072 =20 =20 =20 Proposed for S/MIME 3.5 =20 MUST: RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519 MUST-: RSA w/ SHA-256 SHOULD+: SHOULD: RSA-PSS w/ SHA-512, ECDSA P-521 w/ SHA-512, EdDSA448 SHOULD-:=20 Historic: RSA w/ SHA-1, DSA w/ SHA-1, RSA w/ MD5, DSA w/ SHA-256 =20 Key Sizes: RSA - sign SHOULD NOT Key size <=3D 2047 SHOULD 2048 <=3D key size <=3D 4096 MAY 4096 < key size =20 =20 RSA - Verify Historic MAY key size <=3D 2047 MUST 2048 <=3D key size <=3D 4096 MAY 4096 < key size =20 RSA - Certificate Verify Historic MAY key size <=3D 2047 MUST 2048 <=3D key size <=3D 4096 MAY 4096 < key size =20 DSA - Certificate Verify Historic MAY key size <=3D 1023 Historic MUST 1024 <=3D key size <=3D 3072 =20 =20 Questions: =20 1. Should DSA be dropped to historic for messages and = just left as SHOULD- for certificates, I don't know how many DSA = certificates actually exist. Take 2 state: I have removed all DSA from the current set of algorithms = for both messages and certificates. This is now historic only =20 2. I have changed to lower limits on RSA but not DSA for = certificate verification - should it be changed as well? Again I don't = know how many DSA certificates exist. Take 2 state: I have removed DSA certificates to historic so the = question is moot. =20 3. I don't think that any statements for ECDSA on key = size need to be made separately from the algorithm support list. Does = anybody disagree? Take 2 state: Nobody said anything to the contrary. So no plans to = make a key size section for ECDSA algorithms. =20 4. SPT suggested that we should not be making any = statements on doing anything with 512 hash values. (Although with tons = of standard snark =EF=81=8A). My reasoning for including this was less = to do with the fact that I thought the 512-bit hash functions were more = efficient on 64-bit hardware (a statement that I cannot find support for = with a quick web search for SHA-2) and therefore it made sense from a = throughput point of view. I don=E2=80=99t think we need the for = security and if they are not more efficient I would be in favor not = making them SHOULDs Take 3 state: Since nobody said anything to the contrary, I have removed = all of the SHA-512 hash algorithms. Russ stated that he would like to = add ECDSA P-384 w/SHA-384 but I have seen no support for this position = on the list. =20 5. Blake has complained about the number of MUST = algorithms that comes out from this list. There are effectively 4 in = the list above, as opposed to the 1 that is in the current set of = documents. We cannot kill the current MUST so it has to stay. However, = all of the new MUSTs could be downgraded from MUST to SHOULD without out = any problems. The only issue is that one of them needs to be a MUST so = that we have a true MUST not just a MUST- algorithm. Looking at the = list my breakdown would be: =20 =E2=80=A2 RSA-PSS =E2=80=93 Given that it has been slow = on update the only reason to have it be a MUST is that most people are = probably going to have RSA keys today. There are some arguments that = say RSA-PSS is no better than RSA-v1.5 when doing real-world analysis. = I don=E2=80=99t know that I agree with this as I have problems with = arguments by analogy. This could easily be a SHOULD instead of a MUST =E2=80=A2 ECDSA =E2=80=93 This is the world of NIST = requirements today. I think this justifies it being a MUST =E2=80=A2 EdDSA =E2=80=93 This is the world of NOT MIST = requirements today. I think this justifies it being a MUST Take 3 state: I have modified this to be all on receive and one on send, = but I have not changed any of these to be SHOULD rather than MUST. =20 Jim =20 ------=_NextPart_000_05DB_01D1F7C8.F47BA9C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

This message looks at Signature Algorithms.=C2=A0 = Please restrict your discussions to this set of algorithms, I will be = sending out messages on other algorithms over time.

 

I have = started doing the editing work on this.=C2=A0 The pull request can be = found at https://github.com/lam= ps-wg/smime/pull/21

 

 

Current Document for S/MIME 3.1

 

MUST:=C2=A0=C2=A0 RSA w/ SHA-256

SHOULD+:=C2=A0 DSA w/ SHA-256, RSASSA-PSS w/ = SHA-256

SHOULD-:=C2=A0 RSA w/ = SHA-1, DSA w/SHA-1, RSA w/ MD5

Historic:

 

Key = Sizes:

RSA and DSA - = sign

SHOULD = NOT=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Key size <=3D 1023

SHOULD=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1024 <=3D = key size <=3D 2048

MAY=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 2048 < key size=C2=A0=C2=A0

 

RSA = and DSA - Verify

MAY=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 key size <=3D = 1023

MUST=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1024 <=3D key = size <=3D 2048

MAY=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2048 = < key size

 

RSA - = Certificate Verify

MAY=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 key size <=3D 1023

MUST=C2=A0 1024 <=3D key size <=3D = 4096

MAY=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4096=C2=A0 < = key size

 

DSA - Certificate Verify

MAY=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 key size <=3D 1023

MUST=C2=A0=C2=A0=C2=A0 1024 <=3D key size = <=3D 3072

 

 

 

Proposed for S/MIME 3.5

 

MUST: = RSA-PSS w/ SHA-256, ECDSA P-256 w/ SHA-256, EdDSA25519

MUST-: RSA w/ SHA-256

SHOULD+:

SHOULD:=C2=A0 RSA-PSS w/ SHA-512, ECDSA P-521 w/ = SHA-512, EdDSA448

SHOULD-: =

Historic: RSA w/ SHA-1, DSA w/ = SHA-1, RSA w/ MD5, DSA w/ SHA-256

 

Key = Sizes:

RSA - sign

SHOULD = NOT=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Key size <=3D 2047

SHOULD=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2048 <=3D = key size <=3D 4096

MAY=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 4096 < key size=C2=A0=C2=A0

 

RSA - = Verify

Historic = MAY=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 key size <=3D 2047

MUST=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2048 <=3D key = size <=3D 4096

MAY=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4096 = < key size

 

RSA - = Certificate Verify

Historic = MAY=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= key size <=3D 2047

MUST=C2=A0 = 2048 <=3D key size <=3D 4096

MAY=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4096=C2=A0 < = key size

 

DSA - Certificate Verify

Historic = MAY=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= key size <=3D 1023

Historic = MUST=C2=A0=C2=A0 1024 <=3D key size <=3D 3072

 

 

Questions:

 

1.           = ;     Should DSA be dropped = to historic for messages and just left as SHOULD- for certificates, I = don't know how many DSA certificates actually exist.

Take 2 = state: I have removed all DSA from the current set of algorithms for = both messages and certificates.=C2=A0 This is now historic = only

 

2.           = ;     I have changed to = lower limits on RSA but not DSA for certificate verification - should it = be changed as well?=C2=A0 Again I don't know how many DSA certificates = exist.

Take 2 state: I have removed DSA certificates to = historic so the question is moot.

 

3.           = ;     I don't think that any = statements for ECDSA on key size need to be made separately from the = algorithm support list.=C2=A0 Does anybody disagree?

Take 2 = state: =C2=A0Nobody said anything to the contrary.=C2=A0 So no plans = to make a key size section for ECDSA algorithms.

 

4.           = ;     SPT suggested that we = should not be making any statements on doing anything with 512 hash = values.=C2=A0 (Although with tons of standard snark = =EF=81=8A).=C2=A0=C2=A0 My reasoning for including this was less to do = with the fact that I thought the 512-bit hash functions were more = efficient on 64-bit hardware (a statement that I cannot find support for = with a quick web search for SHA-2) and therefore it made sense from a = throughput point of view.=C2=A0=C2=A0 I don=E2=80=99t think we need the = for security and if they are not more efficient I would be in favor not = making them SHOULDs

Take 3 state: Since nobody said = anything to the contrary, I have removed all of the SHA-512 hash = algorithms.=C2=A0 Russ stated that he would like to add ECDSA P-384 = w/SHA-384 but I have seen no support for this position on the = list.

 

5.           = ;     Blake has complained = about the number of MUST algorithms that comes out from this list.=C2=A0 = There are effectively 4 in the list above, as opposed to the 1 that is = in the current set of documents.=C2=A0 We cannot kill the current MUST = so it has to stay.=C2=A0 However, all of the new MUSTs could be = downgraded from MUST to SHOULD without out any problems.=C2=A0 The only = issue is that one of them needs to be a MUST so that we have a true MUST = not just a MUST- algorithm.=C2=A0 Looking at the list my breakdown would = be:

 

=E2=80=A2           = ;      RSA-PSS = =E2=80=93 Given that it has been slow on update the only reason to have = it be a MUST is that most people are probably going to have RSA keys = today.=C2=A0 There are some arguments that say RSA-PSS is no better than = RSA-v1.5 when doing real-world analysis.=C2=A0 I don=E2=80=99t know that = I agree with this as I have problems with arguments by = analogy.=C2=A0=C2=A0 This could easily be a SHOULD instead of a = MUST

=E2=80=A2           = ;      ECDSA =E2=80=93 = This is the world of NIST requirements today.=C2=A0 I think this = justifies it being a MUST

=E2=80=A2           = ;      EdDSA =E2=80=93 = This is the world of NOT MIST requirements today.=C2=A0 I think this = justifies it being a MUST


Take 3 state: I have modified = this to be all on receive and one on send, but I have not changed any of = these to be SHOULD rather than MUST.

 

Jim

 

------=_NextPart_000_05DB_01D1F7C8.F47BA9C0-- From nobody Tue Aug 16 14:18:45 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC12212D0AB for ; Tue, 16 Aug 2016 14:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, 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 MXjW5MNZPTnQ for ; Tue, 16 Aug 2016 14:18:41 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998BC12B024 for ; Tue, 16 Aug 2016 14:18:40 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 16 Aug 2016 14:30:53 -0700 From: Jim Schaad To: 'Russ Housley' References: <01d801d1f0ef$18a68030$49f38090$@augustcellars.com> <004701d1f1e9$1d65f470$5831dd50$@augustcellars.com> In-Reply-To: <004701d1f1e9$1d65f470$5831dd50$@augustcellars.com> Date: Tue, 16 Aug 2016 14:18:35 -0700 Message-ID: <05df01d1f803$c1805b20$44811160$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05E0_01D1F7C9.15274F80" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHpc95ztakHMNv8KmlwHM55196SjwH2Hs33AmC9pXOf+miwEA== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms - Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 21:18:44 -0000 ------=_NextPart_000_05E0_01D1F7C9.15274F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have merged in my pull request for content encryption algorithms. I did add AES-128 GCM as part of that merge. Jim From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, August 08, 2016 7:53 PM To: 'Russ Housley' Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms - Take 2 I have no problems with this, however I will channel Blake - what is the reason for having three must algorithms at this point? I can see that the support delta is very small given that both 128 and 256 bit AES primitive is required already. Jim From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley Sent: Monday, August 08, 2016 7:21 AM To: Jim Schaad > Cc: SPASM > Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms - Take 2 I would like to see AES-128 GCM on the MUST list as well. Russ On Aug 7, 2016, at 5:03 PM, Jim Schaad > wrote: I have looked at the responses to the original mail and am updating the mail to reflect what I thought I saw as comments. This message looks at Content Encryption Algorithms. Please restrict your discussions to this set of algorithms, I will be sending out messages on other algorithm times over time. Current Document for S/MIME 3.1 MUST: AES-128 CBC SHOULD+: AES-192 CBC and AES-256 CBC SHOULD-: DES EDE3 CBC (tripleDES) Historic: RC2/40 Proposed for S/MIME 3.5 MUST: AES-192 CBC, AES-256 CBC, AES-256 GCM MUST-: AES-128 CBC SHOULD+: ChaCha20/Poly1305 (256-bit) SHOULD-: AES-128 CBC Historic: RC2/40, DES EDE3 CBC (tripleDES) Take 2 State: With this set we now have two MUST algorithms with the same primitive. We are indicating that we think that ChaCha20/Poly1305 will become a MUST in the future so we have stated a potential fail over algorithm if AES or GCM go into the tank for any reason. More comments are welcome. Questions: 1. The jump from MUST to SHOULD- may be too aggressive for AES-128 CBC, we should potentially state this as MUST- but I think being aggressive makes more sense as we want to go to all AEAD algorithms in next version. Take 2 state: Russ said that yes I was. As I suggested on the list I have pushed this back up to a MUST-. 2. No recommendation for: AES-128 GCM or AES-192 GCM, should there be? How do people feel about 128 and 192 bit algorithms? Take 2 state: List appears to say that we should not say anything about 192-bit algorithms. However people did not comment on the -128 vs -256 question so I have left the recommendation of AES-256 GCM alone. 3. Do we want to downgrade all of the CBC algorithms in favor of GCM algorithms? Take 2 state: SPT is the only one who commented on this. I have a tendency to agree with his proposal that we are adding AEAD and we should be pushing that as the preferred algorithm. Making a MUST statement about AES-256 CBC seems to counter act this statement so I have removed it. Jim _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_05E0_01D1F7C9.15274F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have = merged in my pull request for content encryption algorithms.   = I did add AES-128 GCM as part of that merge.

 

Jim

 

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Jim = Schaad
Sent: Monday, August 08, 2016 7:53 PM
To: = 'Russ Housley' <housley@vigilsec.com>
Cc: 'SPASM' = <spasm@ietf.org>
Subject: Re: [Spasm] Change of = Algorithms: Content Encryption Algorithms - Take = 2

 

I have no = problems with this, however I will channel Blake – what is the = reason for having three must algorithms at this point?  I can see = that the support delta is very small given that both 128 and 256 bit AES = primitive is required already.

 

Jim

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org]= On Behalf Of Russ Housley
Sent: Monday, August 08, = 2016 7:21 AM
To: Jim Schaad <ietf@augustcellars.com>
= Cc: SPASM <spasm@ietf.org>
Subject: = Re: [Spasm] Change of Algorithms: Content Encryption Algorithms - Take = 2

 

I would like = to see AES-128 GCM on the MUST list as well.

 

Russ

 

 

On = Aug 7, 2016, at 5:03 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

I have = looked at the responses to the original mail and am updating the mail to = reflect what I thought I saw as = comments.

 

This message = looks at Content Encryption Algorithms.  Please restrict your = discussions to this set of algorithms, I will be sending out messages on = other algorithm times over time.

 

Current = Document for S/MIME 3.1

 

MUST: = AES-128 CBC

SHOULD+: = AES-192 CBC and AES-256 CBC

SHOULD-: DES = EDE3 CBC (tripleDES)

Historic: = RC2/40

 

Proposed for = S/MIME 3.5

 

MUST:  AES-192 CBC, AES-256 = CBC, AES-256 = GCM

MUST-: = AES-128 CBC

SHOULD+: = ChaCha20/Poly1305 (256-bit)

SHOULD-: = AES-128 CBC

Historic: = RC2/40, DES EDE3 CBC (tripleDES)

 

Take 2 = State: With this = set we now have two MUST algorithms with the same primitive.  We = are indicating that we think that ChaCha20/Poly1305 will become a MUST = in the future so we have stated a potential fail over algorithm if AES = or GCM go into the tank for any reason.   More comments are = welcome.

 

Questions:

1.      The jump = from MUST to SHOULD- may be too aggressive for AES-128 CBC, we should = potentially state this as MUST- but I think being aggressive makes more = sense as we want to go to all AEAD algorithms in next = version.

Take 2 state: Russ said that yes I was.  As = I suggested on the list I have pushed this back up to a = MUST-.

 

2.      No = recommendation for: AES-128 GCM or AES-192 GCM, should there be?  = How do people feel about 128 and 192 bit algorithms?

Take 2 = state: List appears to say that we should not say anything about = 192-bit algorithms.  However people did not comment on the -128 vs = -256 question so I have left the recommendation of AES-256 GCM = alone.

 

3.      Do we want = to downgrade all of the CBC algorithms in favor of GCM = algorithms?

Take 2 state:  SPT is the only one who = commented on this.  I have a tendency to agree with his proposal = that we are adding AEAD and we should be pushing that as the preferred = algorithm.  Making a MUST statement about AES-256 CBC seems to = counter act this statement so I have removed = it.

 

Jim

 

 

 

____________= ___________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

 

------=_NextPart_000_05E0_01D1F7C9.15274F80-- From nobody Tue Aug 16 14:46:02 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2F712B024 for ; Tue, 16 Aug 2016 14:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, 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 VAyKlHLtAQR9 for ; Tue, 16 Aug 2016 14:46:00 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDAB212B044 for ; Tue, 16 Aug 2016 14:45:59 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 16 Aug 2016 14:57:52 -0700 From: Jim Schaad To: 'SPASM' Date: Tue, 16 Aug 2016 14:45:34 -0700 Message-ID: <05fb01d1f807$866599c0$9330cd40$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05FC_01D1F7CC.DA090BB0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdH4A+TtdWIliWV6Q1GUZN+XiKINig== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: [Spasm] Change of Algorithms: Digest Algorithms Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 21:46:01 -0000 ------=_NextPart_000_05FC_01D1F7CC.DA090BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This message looks at Digest Algorithms. Please restrict your discussion to this set of algorithms. I will be sending out messages on other algorithms over time. Note: Digest Algorithms are used for computing the digest of the content. These are not the "same" as the digest algorithms that are used as part of signature algorithms. There may be things one wants to try and keep similar, as we suggest that you use the same digest algorithm, but they are not the same things. Current Document for S/MIME 3.1 MUST: SHA-256 SHOULD-: SHA-1, MD5(for backwards compatibility) Proposed for S/MIME 3.5 MUST: SHA-256 SHOULD: SHA-512 Historic: SHA-1, MD5 Questions: 1. There is only one MUST and no path forward. Is this a problem that needs to be dealt with? EdDSA25519 uses SHA-512 under the covers, does that mean we should make SHA-512 at least a SHOULD here? Take 2 status: I have added SHA-512 to the list of SHOULDs because it vaguely matches what is used by EdDSA 25519. It is not really needed as EdDSA 25519 is targeted as the 128-bit level which is what SHA-256 supports but an implementation of EdDSA 25519 is probably going to have it available. 2. Is there anybody who wants to standup and argue for adopting in any of the SHA-3 algorithms? Take 2 status: There have been a couple of pro SHAKE people, a couple of anti SHA-3 people and a larger segment that seems to say 'Meh'. My take at this time is that there does not seem to be support to adding this right now. Jim ------=_NextPart_000_05FC_01D1F7CC.DA090BB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This message looks at Digest Algorithms.  = Please restrict your discussion to this set of algorithms.  I will = be sending out messages on other algorithms over time.

 

Note:  Digest Algorithms are used for = computing the digest of the content.

These are not the "same" as the digest = algorithms that are used as part of signature algorithms.  There = may be things one wants to try and keep similar, as we suggest that you = use the same digest algorithm, but they are not the same = things.

 

 

Current Document for S/MIME 3.1

 

MUST: = SHA-256

SHOULD-: SHA-1, MD5(for = backwards compatibility)

 

 

Proposed for S/MIME 3.5

 

MUST: = SHA-256

SHOULD: = SHA-512

Historic: SHA-1, = MD5

 

Questions:

 

1.      = There is only one MUST and no path = forward.  Is this a problem that needs to be dealt with?  = EdDSA25519 uses SHA-512 under the covers, does that mean we should make = SHA-512 at least a SHOULD here?

Take 2 status:  I = have added SHA-512 to the list of SHOULDs because it vaguely matches = what is used by EdDSA 25519.  It is not really needed as EdDSA = 25519 is targeted as the 128-bit level which is what SHA-256 supports = but an implementation of EdDSA 25519 is probably going to have it = available.

 

2.      = Is there anybody who wants to standup and argue = for adopting in any of the SHA-3 algorithms?

Take 2 = status:  There have been a couple of pro SHAKE people, a couple = of anti SHA-3 people and a larger segment that seems to say = ‘Meh’.  My take at this time is that there does not = seem to be support to adding this right now.

 

Jim

 

 

------=_NextPart_000_05FC_01D1F7CC.DA090BB0-- From nobody Tue Aug 16 14:46:48 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1086412D763 for ; Tue, 16 Aug 2016 14:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 if6CjnjoCJjn for ; Tue, 16 Aug 2016 14:46:45 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB7112B044 for ; Tue, 16 Aug 2016 14:46:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C755A3005AB for ; Tue, 16 Aug 2016 17:46:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BdP9D0R5NHaq for ; Tue, 16 Aug 2016 17:46:41 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 1524C300293; Tue, 16 Aug 2016 17:46:41 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_07D25C0E-8526-4978-9538-08A8B04EA9E0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <05da01d1f803$a0d885f0$e28991d0$@augustcellars.com> Date: Tue, 16 Aug 2016 17:46:50 -0400 Message-Id: <8849812E-0338-4A33-A6F9-E2627AAF3AB4@vigilsec.com> References: <05da01d1f803$a0d885f0$e28991d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Take 3 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 21:46:47 -0000 --Apple-Mail=_07D25C0E-8526-4978-9538-08A8B04EA9E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jim: > Questions: > =20 > 1. Should DSA be dropped to historic for messages and = just left as SHOULD- for certificates, I don't know how many DSA = certificates actually exist. >=20 > Take 2 state: I have removed all DSA from the current set of = algorithms for both messages and certificates. This is now historic = only The only DSA certificates that I know about used 1024-bit keys. Those = should be historic. Can=E2=80=99t we just say historic for all key = sizes? =20 > 2. I have changed to lower limits on RSA but not DSA = for certificate verification - should it be changed as well? Again I = don't know how many DSA certificates exist. >=20 > Take 2 state: I have removed DSA certificates to historic so the = question is moot. Okay. > 3. I don't think that any statements for ECDSA on key = size need to be made separately from the algorithm support list. Does = anybody disagree? >=20 > Take 2 state: Nobody said anything to the contrary. So no plans to = make a key size section for ECDSA algorithms. I think that we should only support named curves, and each one of those = comes with an implied key size. =20 > 4. SPT suggested that we should not be making any = statements on doing anything with 512 hash values. (Although with tons = of standard snark =EF=81=8A). My reasoning for including this was less = to do with the fact that I thought the 512-bit hash functions were more = efficient on 64-bit hardware (a statement that I cannot find support for = with a quick web search for SHA-2) and therefore it made sense from a = throughput point of view. I don=E2=80=99t think we need the for = security and if they are not more efficient I would be in favor not = making them SHOULDs >=20 > Take 3 state: Since nobody said anything to the contrary, I have = removed all of the SHA-512 hash algorithms. Russ stated that he would = like to add ECDSA P-384 w/SHA-384 but I have seen no support for this = position on the list. I would still like to see ECDSA P-384 w/SHA-384 as a SHOULD algorithm. > 5. Blake has complained about the number of MUST = algorithms that comes out from this list. There are effectively 4 in = the list above, as opposed to the 1 that is in the current set of = documents. We cannot kill the current MUST so it has to stay. However, = all of the new MUSTs could be downgraded from MUST to SHOULD without out = any problems. The only issue is that one of them needs to be a MUST so = that we have a true MUST not just a MUST- algorithm. Looking at the = list my breakdown would be: > =20 > =E2=80=A2 RSA-PSS =E2=80=93 Given that it has been = slow on update the only reason to have it be a MUST is that most people = are probably going to have RSA keys today. There are some arguments = that say RSA-PSS is no better than RSA-v1.5 when doing real-world = analysis. I don=E2=80=99t know that I agree with this as I have = problems with arguments by analogy. This could easily be a SHOULD = instead of a MUST > =E2=80=A2 ECDSA =E2=80=93 This is the world of NIST = requirements today. I think this justifies it being a MUST > =E2=80=A2 EdDSA =E2=80=93 This is the world of NOT = MIST requirements today. I think this justifies it being a MUST >=20 > Take 3 state: I have modified this to be all on receive and one on = send, but I have not changed any of these to be SHOULD rather than MUST. I agree with Blake. I suggest: MUST: ECDSA P-256 w/ SHA-256 MUST-: RSA w/ SHA-256 SHOULD+: RSA-PSS w/ SHA-256, EdDSA25519 SHOULD: ECDSA P-384 w/SHA-384 Russ --Apple-Mail=_07D25C0E-8526-4978-9538-08A8B04EA9E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Jim:

Questions:
 
1.           = ;     Should DSA be = dropped to historic for messages and just left as SHOULD- for = certificates, I don't know how many DSA certificates actually = exist.

Take 2 state: I have removed all DSA from = the current set of algorithms for both messages and certificates.  = This is now historic = only

The only DSA = certificates that I know about used 1024-bit keys.  Those should be = historic.  Can=E2=80=99t we just say historic for all key = sizes?
 
2.           = ;     I have = changed to lower limits on RSA but not DSA for certificate verification = - should it be changed as well?  Again I don't know how many DSA = certificates exist.

Take 2 state: I have removed DSA = certificates to historic so the question is = moot.

Okay.

3.           = ;     I don't think = that any statements for ECDSA on key size need to be made separately = from the algorithm support list.  Does anybody = disagree?

Take 2 state:  Nobody said = anything to the contrary.  So no plans to make a key size section = for ECDSA algorithms.

I = think that we should only support named curves, and each one of those = comes with an implied key size.
 
4.           = ;     SPT suggested = that we should not be making any statements on doing anything with 512 = hash values.  (Although with tons of standard snark = =EF=81=8A).   My reasoning for including this was less to do = with the fact that I thought the 512-bit hash functions were more = efficient on 64-bit hardware (a statement that I cannot find support for = with a quick web search for SHA-2) and therefore it made sense from a = throughput point of view.   I don=E2=80=99t think we need the = for security and if they are not more efficient I would be in favor not = making them SHOULDs

Take 3 state: Since nobody said = anything to the contrary, I have removed all of the SHA-512 hash = algorithms.  Russ stated that he would like to add ECDSA P-384 = w/SHA-384 but I have seen no support for this position on the = list.

I would still = like to see ECDSA P-384 w/SHA-384 as a SHOULD = algorithm.

5.           = ;     Blake has = complained about the number of MUST algorithms that comes out from this = list.  There are effectively 4 in the list above, as opposed to the = 1 that is in the current set of documents.  We cannot kill the = current MUST so it has to stay.  However, all of the new MUSTs = could be downgraded from MUST to SHOULD without out any problems.  = The only issue is that one of them needs to be a MUST so that we have a = true MUST not just a MUST- algorithm.  Looking at the list my = breakdown would be:
 
=E2=80=A2           = ;      RSA-PSS =E2=80=93= Given that it has been slow on update the only reason to have it be a = MUST is that most people are probably going to have RSA keys = today.  There are some arguments that say RSA-PSS is no better than = RSA-v1.5 when doing real-world analysis.  I don=E2=80=99t know that = I agree with this as I have problems with arguments by = analogy.   This could easily be a SHOULD instead of a = MUST
=E2=80=A2           = ;      ECDSA =E2=80=93= This is the world of NIST requirements today.  I think this = justifies it being a MUST
=E2=80=A2           = ;      EdDSA =E2=80=93= This is the world of NOT MIST requirements today.  I think this = justifies it being a MUST

Take 3 state: I have modified this to = be all on receive and one on send, but I have not changed any of these = to be SHOULD rather than = MUST.

I agree = with Blake.  I suggest:

MUST: ECDSA = P-256 w/ SHA-256
MUST-: RSA w/ SHA-256
SHOULD+: = RSA-PSS w/ SHA-256, EdDSA25519
SHOULD: ECDSA P-384 = w/SHA-384

Russ

= --Apple-Mail=_07D25C0E-8526-4978-9538-08A8B04EA9E0-- From nobody Tue Aug 16 14:50:54 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CD912D829 for ; Tue, 16 Aug 2016 14:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 mdXwaxti1f1w for ; Tue, 16 Aug 2016 14:50:51 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F7B12D828 for ; Tue, 16 Aug 2016 14:50:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8B7643005B4 for ; Tue, 16 Aug 2016 17:50:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Wr3XES1C8EYd for ; Tue, 16 Aug 2016 17:50:47 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 5F167300289; Tue, 16 Aug 2016 17:50:47 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_55874271-8C11-47F0-A608-AF898D5F2AFB" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <05fb01d1f807$866599c0$9330cd40$@augustcellars.com> Date: Tue, 16 Aug 2016 17:50:56 -0400 Message-Id: <9841C267-6CFF-4029-A47E-EE1D9DEECACE@vigilsec.com> References: <05fb01d1f807$866599c0$9330cd40$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 21:50:53 -0000 --Apple-Mail=_55874271-8C11-47F0-A608-AF898D5F2AFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jim: Just responding to the first question. > 1. There is only one MUST and no path forward. Is this a problem = that needs to be dealt with? EdDSA25519 uses SHA-512 under the covers, = does that mean we should make SHA-512 at least a SHOULD here? >=20 > Take 2 status: I have added SHA-512 to the list of SHOULDs because it = vaguely matches what is used by EdDSA 25519. It is not really needed as = EdDSA 25519 is targeted as the 128-bit level which is what SHA-256 = supports but an implementation of EdDSA 25519 is probably going to have = it available. I think that EdDSA25519 and SHA-512 should both be SHOULD algorithms. = Your other message has EdDSA25519 at the MUST level, and I suggested = moving it to the SHOULD level to make these match. Russ --Apple-Mail=_55874271-8C11-47F0-A608-AF898D5F2AFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Jim:

Just responding to the first = question.

1.      There is only = one MUST and no path forward.  Is this a problem that needs to be = dealt with?  EdDSA25519 uses SHA-512 under the covers, does that = mean we should make SHA-512 at least a SHOULD here?

Take 2 = status:  I have added SHA-512 to the list of SHOULDs because it = vaguely matches what is used by EdDSA 25519.  It is not really = needed as EdDSA 25519 is targeted as the 128-bit level which is what = SHA-256 supports but an implementation of EdDSA 25519 is probably going = to have it available.

I = think that EdDSA25519 and SHA-512 should both be SHOULD algorithms. =  Your other message has EdDSA25519 at the MUST level, and I = suggested moving it to the SHOULD level to make these = match.

Russ

= --Apple-Mail=_55874271-8C11-47F0-A608-AF898D5F2AFB-- From nobody Tue Aug 16 14:56:23 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DF312D828 for ; Tue, 16 Aug 2016 14:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, 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 Hlo9zSXM-u5J for ; Tue, 16 Aug 2016 14:56:18 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DD312D511 for ; Tue, 16 Aug 2016 14:56:18 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 16 Aug 2016 15:08:09 -0700 From: Jim Schaad To: 'Russ Housley' References: <05fb01d1f807$866599c0$9330cd40$@augustcellars.com> <9841C267-6CFF-4029-A47E-EE1D9DEECACE@vigilsec.com> In-Reply-To: <9841C267-6CFF-4029-A47E-EE1D9DEECACE@vigilsec.com> Date: Tue, 16 Aug 2016 14:55:52 -0700 Message-ID: <060f01d1f808$f694d1b0$e3be7510$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0610_01D1F7CE.4A38DFE0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLx1VyogwVYktLYzIqd8gnhoT47wQHbb9jrnf2K/eA= Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 21:56:23 -0000 ------=_NextPart_000_0610_01D1F7CE.4A38DFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, August 16, 2016 2:51 PM To: Jim Schaad Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms Take 2 Jim: Just responding to the first question. 1. There is only one MUST and no path forward. Is this a problem that needs to be dealt with? EdDSA25519 uses SHA-512 under the covers, does that mean we should make SHA-512 at least a SHOULD here? Take 2 status: I have added SHA-512 to the list of SHOULDs because it vaguely matches what is used by EdDSA 25519. It is not really needed as EdDSA 25519 is targeted as the 128-bit level which is what SHA-256 supports but an implementation of EdDSA 25519 is probably going to have it available. I think that EdDSA25519 and SHA-512 should both be SHOULD algorithms. Your other message has EdDSA25519 at the MUST level, and I suggested moving it to the SHOULD level to make these match. [JLS] It is not clear to me that there is an advantage from a security impedance matching to say that one needs to use SHA-512 with EdDSA25519. As I said above, SHA-256 matches up just fine with EdDSA25519. The story would be different if we had required support for EdDSA448. Do you have a different understanding? Is there a reasoning to making these two items match? Jim Russ ------=_NextPart_000_0610_01D1F7CE.4A38DFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Tuesday, August 16, 2016 2:51 PM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: [Spasm] Change of = Algorithms: Digest Algorithms Take 2

 

Jim:

 

Just responding to the first = question.



1.      There is = only one MUST and no path forward.  Is this a problem that needs to = be dealt with?  EdDSA25519 uses SHA-512 under the covers, does that = mean we should make SHA-512 at least a SHOULD here?

Take 2 = status:  I have added SHA-512 to the list of SHOULDs because it = vaguely matches what is used by EdDSA 25519.  It is not really = needed as EdDSA 25519 is targeted as the 128-bit level which is what = SHA-256 supports but an implementation of EdDSA 25519 is probably going = to have it = available.

 

I = think that EdDSA25519 and SHA-512 should both be SHOULD algorithms. =  Your other message has EdDSA25519 at the MUST level, and I = suggested moving it to the SHOULD level to make these = match.

 

[JLS] It is = not clear to me that there is an advantage from a security impedance = matching to say that one needs to use SHA-512 with = EdDSA25519.   As I said above, SHA-256 matches up just fine = with EdDSA25519.  The story would be different if we had required = support for EdDSA448.   Do you have a different = understanding?  Is there a reasoning to making these two items = match?

Jim

 

 

Russ

 

------=_NextPart_000_0610_01D1F7CE.4A38DFE0-- From nobody Tue Aug 16 17:39:34 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37A412D5F7 for ; Tue, 16 Aug 2016 17:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, 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 k3TKVFEXJFlk for ; Tue, 16 Aug 2016 17:39:29 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D6312D783 for ; Tue, 16 Aug 2016 17:39:28 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 16 Aug 2016 17:51:14 -0700 From: Jim Schaad To: 'Russ Housley' References: <05da01d1f803$a0d885f0$e28991d0$@augustcellars.com> <8849812E-0338-4A33-A6F9-E2627AAF3AB4@vigilsec.com> In-Reply-To: <8849812E-0338-4A33-A6F9-E2627AAF3AB4@vigilsec.com> Date: Tue, 16 Aug 2016 17:38:56 -0700 Message-ID: <062901d1f81f$be5e70f0$3b1b52d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_062A_01D1F7E5.12047AF0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFqf6LeWjM2uSNf0fCQLOEbNhx7IgIgVBhCoQozciA= Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Take 3 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 00:39:32 -0000 ------=_NextPart_000_062A_01D1F7E5.12047AF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, August 16, 2016 2:47 PM To: Jim Schaad Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Take 3 =20 Jim: Questions: =20 1. Should DSA be dropped to historic for messages and = just left as SHOULD- for certificates, I don't know how many DSA = certificates actually exist. Take 2 state: I have removed all DSA from the current set of algorithms = for both messages and certificates. This is now historic only =20 The only DSA certificates that I know about used 1024-bit keys. Those = should be historic. Can=E2=80=99t we just say historic for all key = sizes? =20 [JLS] This is what I did. I saw no reason to keep DSA around as it does = not seem to be a) used or b) any more quantum resistant than ECDSA is. =20 2. I have changed to lower limits on RSA but not DSA for = certificate verification - should it be changed as well? Again I don't = know how many DSA certificates exist. Take 2 state: I have removed DSA certificates to historic so the = question is moot. =20 Okay. 3. I don't think that any statements for ECDSA on key = size need to be made separately from the algorithm support list. Does = anybody disagree? Take 2 state: Nobody said anything to the contrary. So no plans to = make a key size section for ECDSA algorithms. =20 I think that we should only support named curves, and each one of those = comes with an implied key size. =20 4. SPT suggested that we should not be making any = statements on doing anything with 512 hash values. (Although with tons = of standard snark J). My reasoning for including this was less to do = with the fact that I thought the 512-bit hash functions were more = efficient on 64-bit hardware (a statement that I cannot find support for = with a quick web search for SHA-2) and therefore it made sense from a = throughput point of view. I don=E2=80=99t think we need the for = security and if they are not more efficient I would be in favor not = making them SHOULDs Take 3 state: Since nobody said anything to the contrary, I have removed = all of the SHA-512 hash algorithms. Russ stated that he would like to = add ECDSA P-384 w/SHA-384 but I have seen no support for this position = on the list. =20 I would still like to see ECDSA P-384 w/SHA-384 as a SHOULD algorithm. 5. Blake has complained about the number of MUST = algorithms that comes out from this list. There are effectively 4 in = the list above, as opposed to the 1 that is in the current set of = documents. We cannot kill the current MUST so it has to stay. However, = all of the new MUSTs could be downgraded from MUST to SHOULD without out = any problems. The only issue is that one of them needs to be a MUST so = that we have a true MUST not just a MUST- algorithm. Looking at the = list my breakdown would be: =20 =E2=80=A2 RSA-PSS =E2=80=93 Given that it has been slow = on update the only reason to have it be a MUST is that most people are = probably going to have RSA keys today. There are some arguments that = say RSA-PSS is no better than RSA-v1.5 when doing real-world analysis. = I don=E2=80=99t know that I agree with this as I have problems with = arguments by analogy. This could easily be a SHOULD instead of a MUST =E2=80=A2 ECDSA =E2=80=93 This is the world of NIST = requirements today. I think this justifies it being a MUST =E2=80=A2 EdDSA =E2=80=93 This is the world of NOT MIST = requirements today. I think this justifies it being a MUST Take 3 state: I have modified this to be all on receive and one on send, = but I have not changed any of these to be SHOULD rather than MUST. =20 I agree with Blake. I suggest: =20 MUST: ECDSA P-256 w/ SHA-256 MUST-: RSA w/ SHA-256 SHOULD+: RSA-PSS w/ SHA-256, EdDSA25519 SHOULD: ECDSA P-384 w/SHA-384 =20 [JLS] Privileging ECDSA over EdDSA is almost surely going to lead to = some pushback among some communities as they see the NIST curves as = being anathema since they do not have the desired property of = transparency. What would be the argument that you would put forward to = calm the waters over this? =20 [JLS] Do we really see RSA-PSS as being pushed to a MUST at that point? = The world seems to be rushing headlong into the world of EC and leaving = RSA behind. I don=E2=80=99t see a good reason to keep it at SHOULD+ = unless we think this would become the standard going forward. It makes = more sense to me for it to be either MUST, because we think that it will = be used a lot, or SHOULD, because RSA is now somewhat in the slow lane. = The only reason that I know to support RSA is quantum support. Today = it is believed that RSA is more resistant to quantum cryptography = breakages. =20 Jim =20 =20 Russ =20 ------=_NextPart_000_062A_01D1F7E5.12047AF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Tuesday, August 16, 2016 2:47 PM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: [Spasm] Change of = Algorithms: Take 3

 

Jim:



Questions:

 

1.        = ;        Should DSA = be dropped to historic for messages and just left as SHOULD- for = certificates, I don't know how many DSA certificates actually = exist.

Take 2 state: I have removed all DSA from = the current set of algorithms for both messages and certificates.  = This is now historic = only

 

The = only DSA certificates that I know about used 1024-bit keys.  Those = should be historic.  Can=E2=80=99t we just say historic for all key = sizes?

 

[JLS] This = is what I did.=C2=A0 I saw no reason to keep DSA around as it does not = seem to be a) used or b) any more quantum resistant than ECDSA = is.

 =

2.        = ;        I have = changed to lower limits on RSA but not DSA for certificate verification = - should it be changed as well?  Again I don't know how many DSA = certificates exist.

Take 2 state: I have removed DSA = certificates to historic so the question is = moot.

 

Okay.



3.        = ;        I don't = think that any statements for ECDSA on key size need to be made = separately from the algorithm support list.  Does anybody = disagree?

Take 2 state:  Nobody said = anything to the contrary.  So no plans to make a key size section = for ECDSA = algorithms.

 

I = think that we should only support named curves, and each one of those = comes with an implied key size.

 =

4.        = ;        SPT = suggested that we should not be making any statements on doing anything = with 512 hash values.  (Although with tons of standard snark = J).  = ; My reasoning for including this was less to do with the fact that I = thought the 512-bit hash functions were more efficient on 64-bit = hardware (a statement that I cannot find support for with a quick web = search for SHA-2) and therefore it made sense from a throughput point of = view.   I don=E2=80=99t think we need the for security and if = they are not more efficient I would be in favor not making them = SHOULDs

Take 3 state: Since nobody said = anything to the contrary, I have removed all of the SHA-512 hash = algorithms.  Russ stated that he would like to add ECDSA P-384 = w/SHA-384 but I have seen no support for this position on the = list.

 

I = would still like to see ECDSA P-384 w/SHA-384 as a SHOULD = algorithm.



5.        = ;        Blake has = complained about the number of MUST algorithms that comes out from this = list.  There are effectively 4 in the list above, as opposed to the = 1 that is in the current set of documents.  We cannot kill the = current MUST so it has to stay.  However, all of the new MUSTs = could be downgraded from MUST to SHOULD without out any problems.  = The only issue is that one of them needs to be a MUST so that we have a = true MUST not just a MUST- algorithm.  Looking at the list my = breakdown would be:

 

=E2=80=A2        = ;         RSA-PSS = =E2=80=93 Given that it has been slow on update the only reason to have = it be a MUST is that most people are probably going to have RSA keys = today.  There are some arguments that say RSA-PSS is no better than = RSA-v1.5 when doing real-world analysis.  I don=E2=80=99t know that = I agree with this as I have problems with arguments by = analogy.   This could easily be a SHOULD instead of a = MUST

=E2=80=A2        = ;         ECDSA = =E2=80=93 This is the world of NIST requirements today.  I think = this justifies it being a MUST

=E2=80=A2        = ;         EdDSA = =E2=80=93 This is the world of NOT MIST requirements today.  I = think this justifies it being a MUST


Take = 3 state: I have = modified this to be all on receive and one on send, but I have not = changed any of these to be SHOULD rather than = MUST.

 

I = agree with Blake.  I suggest:

 

MUST: ECDSA P-256 w/ = SHA-256

MUST-: RSA w/ = SHA-256

SHOULD+: RSA-PSS = w/ SHA-256, EdDSA25519

SHOULD: ECDSA P-384 w/SHA-384

 

[JLS] = Privileging ECDSA over EdDSA is almost surely going to lead to some = pushback among some communities as they see the NIST curves as being = anathema since they do not have the desired property of = transparency.=C2=A0 What would be the argument that you would put = forward to calm the waters over this?

 

[JLS] Do we = really see RSA-PSS as being pushed to a MUST at that point?=C2=A0 The = world seems to be rushing headlong into the world of EC and leaving RSA = behind.=C2=A0 I don=E2=80=99t see a good reason to keep it at SHOULD+ = unless we think this would become the standard going forward.=C2=A0 It = makes more sense to me for it to be either MUST, because we think that = it will be used a lot, or SHOULD, because RSA is now somewhat in the = slow lane.=C2=A0=C2=A0 The only reason that I know to support RSA is = quantum support.=C2=A0 Today it is believed that RSA is more resistant = to quantum cryptography breakages.

 

Jim

 

 

Russ

 

------=_NextPart_000_062A_01D1F7E5.12047AF0-- From nobody Wed Aug 17 12:59:35 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD39612D155 for ; Wed, 17 Aug 2016 12:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 GEpZXONfyWLO for ; Wed, 17 Aug 2016 12:59:32 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3356312B076 for ; Wed, 17 Aug 2016 12:59:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1C70030050D for ; Wed, 17 Aug 2016 15:59:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DTKUo3Niop78 for ; Wed, 17 Aug 2016 15:59:28 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id CC400300086; Wed, 17 Aug 2016 15:59:28 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E54BA142-FC28-48B0-8A70-9ED92BBE5B71" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <060f01d1f808$f694d1b0$e3be7510$@augustcellars.com> Date: Wed, 17 Aug 2016 15:59:38 -0400 Message-Id: <867D20C0-402F-4F63-AC50-1E97AA717633@vigilsec.com> References: <05fb01d1f807$866599c0$9330cd40$@augustcellars.com> <9841C267-6CFF-4029-A47E-EE1D9DEECACE@vigilsec.com> <060f01d1f808$f694d1b0$e3be7510$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Digest Algorithms Take 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 19:59:34 -0000 --Apple-Mail=_E54BA142-FC28-48B0-8A70-9ED92BBE5B71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jim: > Just responding to the first question. >=20 >=20 > 1. There is only one MUST and no path forward. Is this a problem = that needs to be dealt with? EdDSA25519 uses SHA-512 under the covers, = does that mean we should make SHA-512 at least a SHOULD here? >=20 > Take 2 status: I have added SHA-512 to the list of SHOULDs because it = vaguely matches what is used by EdDSA 25519. It is not really needed as = EdDSA 25519 is targeted as the 128-bit level which is what SHA-256 = supports but an implementation of EdDSA 25519 is probably going to have = it available. > =20 > I think that EdDSA25519 and SHA-512 should both be SHOULD algorithms. = Your other message has EdDSA25519 at the MUST level, and I suggested = moving it to the SHOULD level to make these match. > =20 > [JLS] It is not clear to me that there is an advantage from a security = impedance matching to say that one needs to use SHA-512 with EdDSA25519. = As I said above, SHA-256 matches up just fine with EdDSA25519. The = story would be different if we had required support for EdDSA448. Do = you have a different understanding? Is there a reasoning to making = these two items match? My reading of section 5.1 of draft-irtf-cfrg-eddsa-06 is that SHA-512 is = mandated. It is fully baked into the algorithm description. For this = reason, not the security impedance match, I think that both EdDSA25519 = and SHA-512 ought to be SHOULD algorithms (or they could both be MUST = algorithms). Your recent proposal had one as a SHOULD and the other as = a MUST. Russ --Apple-Mail=_E54BA142-FC28-48B0-8A70-9ED92BBE5B71 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Jim:

Just responding to the first = question.


1.      There is = only one MUST and no path forward.  Is this a problem that needs to = be dealt with?  EdDSA25519 uses SHA-512 under the covers, does that = mean we should make SHA-512 at least a SHOULD here?

Take 2 = status:  I have added SHA-512 to the list of SHOULDs because it = vaguely matches what is used by EdDSA 25519.  It is not really = needed as EdDSA 25519 is targeted as the 128-bit level which is what = SHA-256 supports but an implementation of EdDSA 25519 is probably going = to have it available.
 
I = think that EdDSA25519 and SHA-512 should both be SHOULD algorithms. =  Your other message has EdDSA25519 at the MUST level, and I = suggested moving it to the SHOULD level to make these = match.
 
[JLS] It is = not clear to me that there is an advantage from a security impedance = matching to say that one needs to use SHA-512 with = EdDSA25519.   As I said above, SHA-256 matches up just fine = with EdDSA25519.  The story would be different if we had required = support for EdDSA448.   Do you have a different = understanding?  Is there a reasoning to making these two items = match?

My reading of = section 5.1 of draft-irtf-cfrg-eddsa-06 is that SHA-512 is mandated. =  It is fully baked into the algorithm description.  For this = reason, not the security impedance match, I think that both EdDSA25519 = and SHA-512 ought to be SHOULD algorithms (or they could both be MUST = algorithms).  Your recent proposal had one as a SHOULD and the = other as a = MUST.

Russ

= --Apple-Mail=_E54BA142-FC28-48B0-8A70-9ED92BBE5B71-- From nobody Wed Aug 17 13:10:38 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E854412D5A2 for ; Wed, 17 Aug 2016 13:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 V3_bfKMTzO2W for ; Wed, 17 Aug 2016 13:10:35 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7EF112D594 for ; Wed, 17 Aug 2016 13:10:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BD8573005AE for ; Wed, 17 Aug 2016 16:10:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LV-ZVkE_YPD1 for ; Wed, 17 Aug 2016 16:10:32 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 625FF3004CA; Wed, 17 Aug 2016 16:10:32 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CB494400-ACD4-4473-8D2A-6FAB9E074FA2" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <062901d1f81f$be5e70f0$3b1b52d0$@augustcellars.com> Date: Wed, 17 Aug 2016 16:10:45 -0400 Message-Id: References: <05da01d1f803$a0d885f0$e28991d0$@augustcellars.com> <8849812E-0338-4A33-A6F9-E2627AAF3AB4@vigilsec.com> <062901d1f81f$be5e70f0$3b1b52d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Take 3 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 20:10:37 -0000 --Apple-Mail=_CB494400-ACD4-4473-8D2A-6FAB9E074FA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Jim: > MUST: ECDSA P-256 w/ SHA-256 > MUST-: RSA w/ SHA-256 > SHOULD+: RSA-PSS w/ SHA-256, EdDSA25519 > SHOULD: ECDSA P-384 w/SHA-384 > =20 > [JLS] Privileging ECDSA over EdDSA is almost surely going to lead to = some pushback among some communities as they see the NIST curves as = being anathema since they do not have the desired property of = transparency. What would be the argument that you would put forward to = calm the waters over this? I would like to see RSA-PSS w/ SHA-256 and EdDSA25519 at the MUST level, = but I do not see enough implementation to support either of them at that = level. Frankly, RSA w/ SHA-256 enjoys much greater deployment than all = of the rest. However, it is time to signal that we need to move to the = others. Right now, ECDSA P-256 w/ SHA-256 enjoys greater deployment = than either RSA-PSS w/ SHA-256 or EdDSA25519. I expect TL 1.3 = deployment to improve the deployment situation for all of these, but we = are not seeing those impacts yet. > [JLS] Do we really see RSA-PSS as being pushed to a MUST at that = point? The world seems to be rushing headlong into the world of EC and = leaving RSA behind. I don=92t see a good reason to keep it at SHOULD+ = unless we think this would become the standard going forward. It makes = more sense to me for it to be either MUST, because we think that it will = be used a lot, or SHOULD, because RSA is now somewhat in the slow lane. = The only reason that I know to support RSA is quantum support. Today = it is believed that RSA is more resistant to quantum cryptography = breakages. TLS 1.3 is going to require RSA-PSS for the signature on the Finished = message. So, as I said above, I expect TL 1.3 deployment to improve the = deployment situation for RSA-PSS. Further, as you know, most existing = RSA certificates can be used with RSA-PSS. Russ --Apple-Mail=_CB494400-ACD4-4473-8D2A-6FAB9E074FA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Jim:

MUST: ECDSA P-256 w/ = SHA-256
MUST-: RSA w/ = SHA-256
SHOULD+: RSA-PSS w/ SHA-256, = EdDSA25519
SHOULD: ECDSA P-384 w/SHA-384
 
[JLS] = Privileging ECDSA over EdDSA is almost surely going to lead to some = pushback among some communities as they see the NIST curves as being = anathema since they do not have the desired property of = transparency.  What would be the argument that you would put = forward to calm the waters over = this?

I would = like to see RSA-PSS w/ SHA-256 and EdDSA25519 at the MUST level, = but I do not see enough implementation to support either of them at that = level.  Frankly, RSA w/ SHA-256 enjoys much greater deployment than = all of the rest.  However, it is time to signal that we need to = move to the others.  Right now, ECDSA P-256 w/ SHA-256 enjoys = greater deployment than either RSA-PSS w/ SHA-256 or EdDSA25519.  I = expect TL 1.3 deployment to improve the deployment situation for all of = these, but we are not seeing those impacts yet.

[JLS] Do we really see RSA-PSS as being pushed to a MUST at that = point?  The world seems to be rushing headlong into the world of EC = and leaving RSA behind.  I don=92t see a good reason to keep it at = SHOULD+ unless we think this would become the standard going = forward.  It makes more sense to me for it to be either MUST, = because we think that it will be used a lot, or SHOULD, because RSA is = now somewhat in the slow lane.   The only reason that I know = to support RSA is quantum support.  Today it is believed that RSA = is more resistant to quantum cryptography = breakages.

TLS 1.3 is = going to require RSA-PSS for the signature on the Finished message. =  So, as I said above, I expect TL 1.3 deployment to improve the = deployment situation for RSA-PSS.  Further, as you know, most = existing RSA certificates can be used with = RSA-PSS.

Russ

= --Apple-Mail=_CB494400-ACD4-4473-8D2A-6FAB9E074FA2-- From nobody Mon Aug 22 21:31:59 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4761F12D0B6 for ; Mon, 22 Aug 2016 21:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 p8ZLSuoQCWIK for ; Mon, 22 Aug 2016 21:31:56 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65D612D7E3 for ; Mon, 22 Aug 2016 21:31:55 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 22 Aug 2016 21:44:09 -0700 From: Jim Schaad To: 'SPASM' Date: Mon, 22 Aug 2016 21:31:51 -0700 Message-ID: <01c401d1fcf7$4633da20$d29b8e60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdH89JrIj2HC7PffQ2uezOBS2H7zcA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Spasm] Change of Algorithms: Key Management Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 04:31:57 -0000 This message looks at Key Management Algorithms. Please restrict your discussions to this set of algorithms, I will be sending out messages on other algorithms over time. Current Document for S/MIME 3.1 MUST: RSA Encryption MUST: AES-128 Key Wrap SHOULD+: RSAES-OAEP SHOULD-: ECDH-ES w/ DH Key Sizes: RSA and DH - Encrypt SHOULD NOT key <= 1023 SHOULD 1024 <= key <= 2048 MAY 2048 < size RSA and DH - Decryption MAY key <= 1023 MUST 1024 <= key < 2048 MAY 2048 < key Proposed for S/MIME 3.5 MUST: ECDH-ES w/ P-256, ECDH-ES w/ X25519 MUST: AES-128 KW, AES-256 KW (Language - must match key size of CEK algorithm and KW algorithm) MUST-: RSA Encryption SHOULD+: RSAES-OAEP Historic: ECDH-ES w/ DH Sizes: RSA - Encrypt and Decrypt Historic key size < 2048 MUST 2048 <= key size <= 4096 ( if RSA supported) MAY 4098 < key size Reasoning: Assuming that the world is currently headed in the ECDH world rather than RSA-OAEP. Assume that there is enough not NIST sediment that both key types are needed. Questions: At this time, I have no specific questions. Jim From nobody Tue Aug 23 08:19:03 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258FF12D193 for ; Tue, 23 Aug 2016 08:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 nCyj_8u4QY_m for ; Tue, 23 Aug 2016 08:18:57 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50ED12DBDC for ; Tue, 23 Aug 2016 07:51:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6A2A23005CA for ; Tue, 23 Aug 2016 10:51:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1fnvU7erZjV6 for ; Tue, 23 Aug 2016 10:51:38 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 155A930050E; Tue, 23 Aug 2016 10:51:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <01c401d1fcf7$4633da20$d29b8e60$@augustcellars.com> Date: Tue, 23 Aug 2016 10:51:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01c401d1fcf7$4633da20$d29b8e60$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Key Management Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:19:02 -0000 Jim: > This message looks at Key Management Algorithms. Please restrict your > discussions to this set of algorithms, I will be sending out messages = on > other algorithms over time. I appreciate the desire to divide and conquer. However, I think the new = CFRG curves should appear at the same level across all of the = algorithms. So, if X25519 is a MUST for key management, then EdDSA with the same = curve should also be a MUST. On the other hand, if X25519 is a SHOULD+ for key management, then EdDSA = with the same curve should also be a SHOULD+. Russ= From nobody Tue Aug 23 08:51:09 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C85512B03F for ; Tue, 23 Aug 2016 08:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 mkUtrhF_tvEZ for ; Tue, 23 Aug 2016 08:51:06 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CA712D0F7 for ; Tue, 23 Aug 2016 08:51:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C664A3005AC for ; Tue, 23 Aug 2016 11:51:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IiU_EBFQJcUi for ; Tue, 23 Aug 2016 11:51:02 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id B1FA73002C2 for ; Tue, 23 Aug 2016 11:51:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <00a701d1e42c$89112070$9b336150$@augustcellars.com> Date: Tue, 23 Aug 2016 11:48:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <47CCE396-2613-4152-A8AF-9C577FB2D914@vigilsec.com> References: <20160722134707.12260.17545.idtracker@ietfa.amsl.com> <00a701d1e42c$89112070$9b336150$@augustcellars.com> To: SPASM X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Spasm] New Version Notification for draft-schaad-lamps-rfc5750-bis-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:51:08 -0000 Several people have spoken for adoption, and no one has spoken against = adoption. Jim, please post draft-ietf-lamps-rfc5750-bis-00 when th next = version is ready to go. Russ On Jul 22, 2016, at 11:20 AM, Jim Schaad wrote: > Since Russ is going to be a stickler for details, here is a candidate = draft for updating RFC 5750. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, July 22, 2016 3:47 PM >> To: Blake Ramsdell ; Sean Turner ; >> Blake C. Ramsdell ; Jim Schaad = >> Subject: New Version Notification for = draft-schaad-lamps-rfc5750-bis-00.txt >>=20 >>=20 >> A new version of I-D, draft-schaad-lamps-rfc5750-bis-00.txt >> has been successfully submitted by Jim Schaad and posted to the IETF >> repository. >>=20 >> Name: draft-schaad-lamps-rfc5750-bis >> Revision: 00 >> Title: Secure/Multipurpose Internet Mail Extensions (S/ = MIME) >> Version 3.2 Certificate Handling >> Document date: 2016-07-22 >> Group: Individual Submission >> Pages: 21 >> URL: = https://www.ietf.org/internet-drafts/draft-schaad-lamps-rfc5750- >> bis-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-schaad-lamps-rfc5750-bis/ >> Htmlized: = https://tools.ietf.org/html/draft-schaad-lamps-rfc5750-bis-00 >>=20 >>=20 >> Abstract: >> This document specifies conventions for X.509 certificate usage by >> Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. >> S/MIME provides a method to send and receive secure MIME messages, >> and certificates are an integral part of S/MIME agent processing. >> S/MIME agents validate certificates as described in RFC 5280, the >> Internet X.509 Public Key Infrastructure Certificate and CRL = Profile. >> S/MIME agents must meet the certificate processing requirements in >> this document as well as those in RFC 5280. This document = obsoletes >> RFC 3850. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Aug 23 17:47:24 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B5012D5A4 for ; Tue, 23 Aug 2016 17:47:23 -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 (1024-bit key) header.d=sn3rd.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 Racc4zvSv4mH for ; Tue, 23 Aug 2016 17:47:22 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650B412D12E for ; Tue, 23 Aug 2016 17:47:22 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id t7so1414461qkh.1 for ; Tue, 23 Aug 2016 17:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fDt/QU8jVkYcMWcXn87j+7eXL9Jr06g2rWxhgnf6uF8=; b=lOV0yw1jjYGC6EgX8Spaj8MuRsb4O+iPevrR8HfUkeTnuhucDaq1ufL4GkQ2lfWrIR wfq1fuM7aA51YfNnDgrGItTyL+f+v7EHP+gWWb8xEfdk7+EDmo1P9f0kpUwLgQSm8HFb 9veOBXpO3he/nI5ECoInRQdo/5pskFsPXinlI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fDt/QU8jVkYcMWcXn87j+7eXL9Jr06g2rWxhgnf6uF8=; b=Cdw6Y7+AXqPhUByKUR67jQ3tF5vsVcE0Sqlmi/ME3YX9ATelBzJuaFXcEZira6GU79 9mS2z+Mey1iV3ifual0kWJf4MFIprA55RFpOR8EDvMv82MK4zqv+0/7lOQleJ6k2MPg4 VSEUk/AFuEIvh2X/EAZ5RRcADmp0zV75c9iQEIF7EdunUff70NjZpuMpKd4rdjx+GvPU U8eiRI7to26O7YiRbNzQ+gvElaFPjTczAaFx7A8F7k886FNRFCyl9BQEWStc+ogwj5eI hxA7zlqiW8CkcIFaOEl0HE97vKyLYjBKj1ryRAfm2Jvky1nQuW9uLgUA2hZJUyTt7oOg hffw== X-Gm-Message-State: AE9vXwN6c5TeaELoTs9XCXEXBc5UZDOdZzM3CzxvSH8OYdsI13fJWOkzBy412EAIeBx3HA== X-Received: by 10.55.165.138 with SMTP id o132mr313530qke.90.1471999641576; Tue, 23 Aug 2016 17:47:21 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-120-170.washdc.east.verizon.net. [173.73.120.170]) by smtp.gmail.com with ESMTPSA id r10sm3267403qtc.5.2016.08.23.17.47.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Aug 2016 17:47:20 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Tue, 23 Aug 2016 20:47:18 -0400 Content-Transfer-Encoding: 7bit Message-Id: <8DD7493C-7E2F-45B5-81D4-400261A3770E@sn3rd.com> References: <05da01d1f803$a0d885f0$e28991d0$@augustcellars.com> <8849812E-0338-4A33-A6F9-E2627AAF3AB4@vigilsec.com> <062901d1f81f$be5e70f0$3b1b52d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Take 3 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 00:47:23 -0000 > On Aug 17, 2016, at 16:10, Russ Housley wrote: > >> MUST: ECDSA P-256 w/ SHA-256 >> MUST-: RSA w/ SHA-256 >> SHOULD+: RSA-PSS w/ SHA-256, EdDSA25519 >> SHOULD: ECDSA P-384 w/SHA-384 I can live with this. spt From nobody Tue Aug 23 18:02:15 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE3312D635 for ; Tue, 23 Aug 2016 18:02:13 -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 (1024-bit key) header.d=sn3rd.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 3-tbEjShiCN3 for ; Tue, 23 Aug 2016 18:02:12 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485A212D5A4 for ; Tue, 23 Aug 2016 18:02:12 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id v123so1625970qkh.2 for ; Tue, 23 Aug 2016 18:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m7Cs9Q4kMiX8mDd94XaK2Vf2F+IOWu3QN2HlXLbRf8A=; b=mOwQtcYwh1LxEHMeAJyX9TPhs9eU5MnhdgQhzdUkDhEvQWcus0RAgxgmbF36CLaRGX 4r2MKHCpafAVrl3GMwkbKLcKw26QYcYKwKOafJL3g1zxWr2t/CVwV+2AQjOoUChkgRf1 TCJwRKzmuLL7MLs8bSFpvbyfJDOppDWisRWtY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m7Cs9Q4kMiX8mDd94XaK2Vf2F+IOWu3QN2HlXLbRf8A=; b=GtMqSwpnItP6z/ppkWrJaex64lKz5F9r1bAELIfcoghdxFuwEQ/u1BgsEfZYS/R0Aw Il0Z0fywvp5S1cRpJGVM5Gvf1qx9AUNbDVWz+ARH7b8NP7kA0NN/HYg1dqQkqbbE97xr bsZZ1SzP3YqeEi5wXwKG3IwnfjeR3wokGCatBmpfgNyKPZj0c4jQt2ICcUuQmbKIBR96 3ItzS16R39/CJUw3Ka9SUB2KNx3YF68dKZ2wCfOpPJeAIyHkXkgS+tPzfK838PIM4iVB Z6cnWV2elX8dJy93zBdmNh/HvlQa1/x309UU3oe6ch+jx0xTVUqsdO/RRunQJnngrTSu npoQ== X-Gm-Message-State: AE9vXwPUdP6KBa2t5NJvuso/2fjstc+BwE/duVsTdrYj2hncfiPG2ebF8oj3su/FPegTuw== X-Received: by 10.55.148.193 with SMTP id w184mr300869qkd.181.1472000531437; Tue, 23 Aug 2016 18:02:11 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-120-170.washdc.east.verizon.net. [173.73.120.170]) by smtp.gmail.com with ESMTPSA id o5sm3294008qko.12.2016.08.23.18.02.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Aug 2016 18:02:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <01c401d1fcf7$4633da20$d29b8e60$@augustcellars.com> Date: Tue, 23 Aug 2016 21:02:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <74445045-9C3B-4E13-A767-B1E04CF0646A@sn3rd.com> References: <01c401d1fcf7$4633da20$d29b8e60$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Key Management Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 01:02:13 -0000 > On Aug 23, 2016, at 00:31, Jim Schaad wrote: >=20 > SHOULD+: RSAES-OAEP >=20 > Reasoning: > Assuming that the world is currently headed in the ECDH world rather = than > RSA-OAEP. If we=E2=80=99re thinking folks are moving towards ECDH-ES (w/ either = X25519 or P-256) shouldn=E2=80=99t we be making RSAES-OAEP a SHOULD-? I = mean are really thinking that it=E2=80=99ll be =E2=80=9Cpromoted=E2=80=9D = to a MUST? spt From nobody Tue Aug 23 19:59:25 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DC012D5FB for ; Tue, 23 Aug 2016 19:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 X6vBW34V6rmd for ; Tue, 23 Aug 2016 19:59:24 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0CF12D10C for ; Tue, 23 Aug 2016 19:59:24 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 23 Aug 2016 20:11:09 -0700 From: Jim Schaad To: 'Russ Housley' References: <01c401d1fcf7$4633da20$d29b8e60$@augustcellars.com> In-Reply-To: Date: Tue, 23 Aug 2016 19:58:51 -0700 Message-ID: <030b01d1fdb3$734eea60$59ecbf20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI/fsd1GEnfLFMO3Eor1tj2EL8RVAH2j+Ymn2y0niA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Key Management Algorithms X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 02:59:25 -0000 This corresponds to what is currently in my document for signature algorithms - MUST support EdDSA 25519. Jim > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Tuesday, August 23, 2016 7:52 AM > To: Jim Schaad > Cc: SPASM > Subject: Re: [Spasm] Change of Algorithms: Key Management Algorithms > > Jim: > > > This message looks at Key Management Algorithms. Please restrict your > > discussions to this set of algorithms, I will be sending out messages > > on other algorithms over time. > > I appreciate the desire to divide and conquer. However, I think the new CFRG > curves should appear at the same level across all of the algorithms. > > So, if X25519 is a MUST for key management, then EdDSA with the same curve > should also be a MUST. > > On the other hand, if X25519 is a SHOULD+ for key management, then EdDSA > with the same curve should also be a SHOULD+. > > Russ= From nobody Thu Aug 25 15:23:44 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A85212D647 for ; Thu, 25 Aug 2016 15:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 Bd4RsPHTQd8g for ; Thu, 25 Aug 2016 15:23:41 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D83012D13B for ; Thu, 25 Aug 2016 15:23:40 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 25 Aug 2016 15:35:32 -0700 From: Jim Schaad To: 'Russ Housley' References: <05da01d1f803$a0d885f0$e28991d0$@augustcellars.com> <8849812E-0338-4A33-A6F9-E2627AAF3AB4@vigilsec.com> <062901d1f81f$be5e70f0$3b1b52d0$@augustcellars.com> In-Reply-To: Date: Thu, 25 Aug 2016 15:23:14 -0700 Message-ID: <079a01d1ff1f$473b4230$d5b1c690$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_079B_01D1FEE4.9ADF9E80" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFqf6LeWjM2uSNf0fCQLOEbNhx7IgIgVBhCA44bSe4B463hJaDrSErQ Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Take 3 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 22:23:43 -0000 ------=_NextPart_000_079B_01D1FEE4.9ADF9E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Russ, I agree with you that the most common of the signing algorithms that we are looking at is RSA w/SHA-256. Sometimes I wished that I could just have a full domain hash of RSA and go forward from there. The amount of pushback that I get from efforts to remove RSA v1.5 is tiring. There are times when I feel MUST statements need to be aspirational as well as practical. For this reason, I am willing to look at what I would feel is the paths going forward as well as what is currently done. I believe that there is a great deal of support that is either currently in existence or will shortly be in existence for EdDSA25519. Today EdDSA25519 is in BouncyCastle and X25519 is in the next release of OpenSSL and I expect that EdDSA25519 will in included as well (they are in need of the curdle draft). I am sure that it is going into the crypto libraries for Mozilla and Google due to its inclusion in the TLS 1.3 specifications. I would be surprised if they are not setup to use it today in testing. I have also found it in one embedded cryptographic package that I am working with. I am not sure how fast Microsoft and Apple are going to pick these up, but I would not be surprised if Google tries to get and pushes EdDSA in all of its websites pushing this for quicker adoption. The slow point is going to be getting CAs to accept it as an algorithm, but I believe that having pressure from Firefox and Chrome is going to make this something relatively quickly accepted. On the other half of this is the question of how fast people are going to update and roll out any updates to S/MIME. I would expect this to be on the order of a couple of years before a reasonable amount of roll out is done. By then the world will not look the same as it is today. One of the ways that I can think of to make sure that one segment of people decide that they do not want to move from PGP to S/MIME is to stay with the NIST algorithms as the core EC curves. I do not believe that there are any problems with them, but there is a not insignificant group of people who are more than willing to make the claim that there might be. Putting both curves on a par means both that people are going to use the EC algorithms and that they will be able to use the one of their choice. I think this would be good news for Microsoft. There is also the question of how long do you think it is going to take for NIST to bless EdDSA25519 and X25519. Since these are generally thought of as being both faster and less likely to have timing leaks (maybe true, maybe not) there will be people who perceive them as being better even if they do not believe that the current NIST curves are tainted. Given politics, I believe that 25519 is going to win long term over P-256. I don't want to go through this process again in 3-5 years to deal with that. Making both EC curves musts means that we don't need to. The only reason that I see RSA-PSS winning is if we have a quantum computing problem. If it was not for that I would make this a SHOULD algorithm and promptly forget about it. People who use RSA are most likely to stay with 1.5 because it is what they currently have and until we do another update at some future point not going to go away. Again, I am not sure that an update is a likely event given the question of market support. Based on the above, I am strongly in favor of keeping EdDSA25519 as a must along with P256. Jim From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley Sent: Wednesday, August 17, 2016 1:11 PM To: Jim Schaad Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Take 3 Jim: MUST: ECDSA P-256 w/ SHA-256 MUST-: RSA w/ SHA-256 SHOULD+: RSA-PSS w/ SHA-256, EdDSA25519 SHOULD: ECDSA P-384 w/SHA-384 [JLS] Privileging ECDSA over EdDSA is almost surely going to lead to some pushback among some communities as they see the NIST curves as being anathema since they do not have the desired property of transparency. What would be the argument that you would put forward to calm the waters over this? I would like to see RSA-PSS w/ SHA-256 and EdDSA25519 at the MUST level, but I do not see enough implementation to support either of them at that level. Frankly, RSA w/ SHA-256 enjoys much greater deployment than all of the rest. However, it is time to signal that we need to move to the others. Right now, ECDSA P-256 w/ SHA-256 enjoys greater deployment than either RSA-PSS w/ SHA-256 or EdDSA25519. I expect TL 1.3 deployment to improve the deployment situation for all of these, but we are not seeing those impacts yet. [JLS] Do we really see RSA-PSS as being pushed to a MUST at that point? The world seems to be rushing headlong into the world of EC and leaving RSA behind. I don't see a good reason to keep it at SHOULD+ unless we think this would become the standard going forward. It makes more sense to me for it to be either MUST, because we think that it will be used a lot, or SHOULD, because RSA is now somewhat in the slow lane. The only reason that I know to support RSA is quantum support. Today it is believed that RSA is more resistant to quantum cryptography breakages. TLS 1.3 is going to require RSA-PSS for the signature on the Finished message. So, as I said above, I expect TL 1.3 deployment to improve the deployment situation for RSA-PSS. Further, as you know, most existing RSA certificates can be used with RSA-PSS. Russ ------=_NextPart_000_079B_01D1FEE4.9ADF9E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Russ,

 

I agree with = you that the most common of the signing algorithms that we are looking = at is RSA w/SHA-256.  Sometimes I wished that I could just have a = full domain hash of RSA and go forward from there.  The amount of = pushback that I get from efforts to remove RSA v1.5 is = tiring.

 

There are = times when I feel MUST statements need to be aspirational as well as = practical.  For this reason, I am willing to look at what I would = feel is the paths going forward as well as what is currently done.  = I believe that there is a great deal of support that is either currently = in existence or will shortly be in existence for EdDSA25519.  Today = EdDSA25519 is in BouncyCastle and X25519 is in the next release of = OpenSSL and I expect that EdDSA25519 will in included as well (they are = in need of the curdle draft).  I am sure that it is going into the = crypto libraries for Mozilla and Google due to its inclusion in the TLS = 1.3 specifications.  I would be surprised if they are not setup to = use it today in testing.  I have also found it in one embedded = cryptographic package that I am working with.  I am not sure how = fast Microsoft and Apple are going to pick these up, but I would not be = surprised if Google tries to get and pushes EdDSA in all of its websites = pushing this for quicker adoption.

 

The slow = point is going to be getting CAs to accept it as an algorithm, but I = believe that having pressure from Firefox and Chrome is going to make = this something relatively quickly accepted.  On the other half of = this is the question of how fast people are going to update and roll out = any updates to S/MIME.  I would expect this to be on the order of a = couple of years before a reasonable amount of roll out is done.  By = then the world will not look the same as it is = today.

 

One of the = ways that I can think of to make sure that one segment of people decide = that they do not want to move from PGP to S/MIME is to stay with the = NIST algorithms as the core EC curves.  I do not believe that there = are any problems with them, but there is a not insignificant group of = people who are more than willing to make the claim that there might = be.  Putting both curves on a par means both that people are going = to use the EC algorithms and that they will be able to use the one of = their choice.   I think this would be good news for = Microsoft.  There is also the question of how long do you think it = is going to take for NIST to bless EdDSA25519 and X25519.  Since = these are generally thought of as being both faster and less likely to = have timing leaks (maybe true, maybe not) there will be people who = perceive them as being better even if they do not believe that the = current NIST curves are tainted.

 

Given = politics, I believe that 25519 is going to win long term over = P-256.  I don’t want to go through this process again in 3-5 = years to deal with that.  Making both EC curves musts means that we = don’t need to.

 

The only = reason that I see RSA-PSS winning is if we have a quantum computing = problem.  If it was not for that I would make this a SHOULD = algorithm and promptly forget about it.  People who use RSA are = most likely to stay with 1.5 because it is what they currently have and = until we do another update at some future point not going to go = away.  Again, I am not sure that an update is a likely event given = the question of market support.

 

Based on the = above, I am strongly in favor of keeping EdDSA25519 as a must along with = P256.

 

Jim

 

 

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Wednesday, August 17, 2016 1:11 PM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: [Spasm] Change of = Algorithms: Take 3

 

Jim:



MUST: ECDSA P-256 w/ = SHA-256

MUST-: RSA w/ = SHA-256

SHOULD+: RSA-PSS w/ SHA-256, = EdDSA25519

SHOULD: ECDSA P-384 = w/SHA-384

 =

[JLS] = Privileging ECDSA over EdDSA is almost surely going to lead to some = pushback among some communities as they see the NIST curves as being = anathema since they do not have the desired property of = transparency.  What would be the argument that you would put = forward to calm the waters over = this?

 

I = would like to see RSA-PSS w/ SHA-256 and EdDSA25519 at the MUST = level, but I do not see enough implementation to support either of them = at that level.  Frankly, RSA w/ SHA-256 enjoys much greater = deployment than all of the rest.  However, it is time to signal = that we need to move to the others.  Right now, ECDSA P-256 w/ = SHA-256 enjoys greater deployment than either RSA-PSS w/ SHA-256 or = EdDSA25519.  I expect TL 1.3 deployment to improve the deployment = situation for all of these, but we are not seeing those impacts = yet.



[JLS] Do we = really see RSA-PSS as being pushed to a MUST at that point?  The = world seems to be rushing headlong into the world of EC and leaving RSA = behind.  I don’t see a good reason to keep it at SHOULD+ = unless we think this would become the standard going forward.  It = makes more sense to me for it to be either MUST, because we think that = it will be used a lot, or SHOULD, because RSA is now somewhat in the = slow lane.   The only reason that I know to support RSA is = quantum support.  Today it is believed that RSA is more resistant = to quantum cryptography = breakages.

 

TLS 1.3 = is going to require RSA-PSS for the signature on the Finished message. =  So, as I said above, I expect TL 1.3 deployment to improve the = deployment situation for RSA-PSS.  Further, as you know, most = existing RSA certificates can be used with = RSA-PSS.

 

Russ

 

------=_NextPart_000_079B_01D1FEE4.9ADF9E80-- From nobody Thu Aug 25 17:16:56 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD16612D578 for ; Thu, 25 Aug 2016 17:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 IwjsuL_qqa8J for ; Thu, 25 Aug 2016 17:16:53 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DCB612D529 for ; Thu, 25 Aug 2016 17:16:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 421263005B6 for ; Thu, 25 Aug 2016 20:16:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hq2nEiYG2oO0 for ; Thu, 25 Aug 2016 20:16:50 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 65024300451; Thu, 25 Aug 2016 20:16:50 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3DE135F8-95AD-40B3-B7E0-BFD4F5E1B6E9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <079a01d1ff1f$473b4230$d5b1c690$@augustcellars.com> Date: Thu, 25 Aug 2016 20:16:55 -0400 Message-Id: <81175F43-9D2B-413F-AD3D-D107792360B9@vigilsec.com> References: <05da01d1f803$a0d885f0$e28991d0$@augustcellars.com> <8849812E-0338-4A33-A6F9-E2627AAF3AB4@vigilsec.com> <062901d1f81f$be5e70f0$3b1b52d0$@augustcellars.com> <079a01d1ff1f$473b4230$d5b1c690$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Take 3 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 00:16:55 -0000 --Apple-Mail=_3DE135F8-95AD-40B3-B7E0-BFD4F5E1B6E9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Jim: I think your last message is saying: MUST: ECDSA P-256 w/ SHA-256, EdDSA25519 MUST-: RSA w/ SHA-256 SHOULD: RSA-PSS w/ SHA-256, ECDSA P-384 w/SHA-384 Did I follow you logic correctly? Russ --Apple-Mail=_3DE135F8-95AD-40B3-B7E0-BFD4F5E1B6E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Jim:

I think your last message is = saying:

MUST: = ECDSA P-256 w/ SHA-256, EdDSA25519
MUST-: RSA w/ SHA-256
SHOULD: RSA-PSS w/ SHA-256, ECDSA P-384 = w/SHA-384

Did I follow you = logic correctly?

Russ
= --Apple-Mail=_3DE135F8-95AD-40B3-B7E0-BFD4F5E1B6E9-- From nobody Thu Aug 25 17:35:32 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54D912D144 for ; Thu, 25 Aug 2016 17:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 sbhaogzQY_mY for ; Thu, 25 Aug 2016 17:35:28 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6BD12B016 for ; Thu, 25 Aug 2016 17:35:27 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 25 Aug 2016 17:47:19 -0700 From: Jim Schaad To: 'Russ Housley' References: <05da01d1f803$a0d885f0$e28991d0$@augustcellars.com> <8849812E-0338-4A33-A6F9-E2627AAF3AB4@vigilsec.com> <062901d1f81f$be5e70f0$3b1b52d0$@augustcellars.com> <079a01d1ff1f$473b4230$d5b1c690$@augustcellars.com> <81175F43-9D2B-413F-AD3D-D107792360B9@vigilsec.com> In-Reply-To: <81175F43-9D2B-413F-AD3D-D107792360B9@vigilsec.com> Date: Thu, 25 Aug 2016 17:35:02 -0700 Message-ID: <07c201d1ff31$b08f5980$11ae0c80$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C3_01D1FEF7.04327D50" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFqf6LeWjM2uSNf0fCQLOEbNhx7IgIgVBhCA44bSe4B463hJQH/XMI2AlyeB8mgyfNEwA== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Change of Algorithms: Take 3 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 00:35:30 -0000 ------=_NextPart_000_07C3_01D1FEF7.04327D50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit With the proviso that I am not sure on P-384, yes. Jim From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley Sent: Thursday, August 25, 2016 5:17 PM To: Jim Schaad Cc: SPASM Subject: Re: [Spasm] Change of Algorithms: Take 3 Jim: I think your last message is saying: MUST: ECDSA P-256 w/ SHA-256, EdDSA25519 MUST-: RSA w/ SHA-256 SHOULD: RSA-PSS w/ SHA-256, ECDSA P-384 w/SHA-384 Did I follow you logic correctly? Russ ------=_NextPart_000_07C3_01D1FEF7.04327D50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

With the = proviso that I am not sure on P-384, yes.

 

Jim

 

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Thursday, August 25, 2016 5:17 PM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: [Spasm] Change of = Algorithms: Take 3

 

Jim:

 

I = think your last message is saying:

 

MUST: ECDSA P-256 w/ SHA-256, = EdDSA25519

MUST-: RSA w/ = SHA-256

SHOULD: = RSA-PSS w/ SHA-256, ECDSA P-384 = w/SHA-384

 

Did I follow you logic = correctly?

 

Russ

------=_NextPart_000_07C3_01D1FEF7.04327D50-- From nobody Mon Aug 29 21:04:57 2016 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4A312D0FF; Mon, 29 Aug 2016 21:04:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147252989540.19045.14451060202052338375.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2016 21:04:55 -0700 Archived-At: Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 04:04:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.5 Message Specification Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5751-bis-01.txt Pages : 53 Date : 2016-08-29 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.5. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 29 21:29:23 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1CB12B026 for ; Mon, 29 Aug 2016 21:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 reZIqiC0YpOP for ; Mon, 29 Aug 2016 21:29:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767DC127A90 for ; Mon, 29 Aug 2016 21:29:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 450AE3004C3 for ; Tue, 30 Aug 2016 00:29:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yQfOvQknuVEz for ; Tue, 30 Aug 2016 00:29:18 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 74ACD3002B1 for ; Tue, 30 Aug 2016 00:29:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <147252989540.19045.14451060202052338375.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2016 00:29:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147252989540.19045.14451060202052338375.idtracker@ietfa.amsl.com> To: SPASM X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 04:29:22 -0000 I did a very quick skim of the -01 version. Thanks. I expected Section 2.3 to include ECDH and X25519. If they are added, = some related guidance will be needed in Sections 4.4 and 4.5. Section 4 offers guidance about RSA, RSASSA-PSS, RSAES-OAEP, and DH = algorithms. It used to contain some guidance about DSA. Is there any = reason to remove DSA guidance from 4.2 and 4.3? I think we need to add = guidance in Sections 4.2 and 4.3 for ECDSA and EdDSA. Russ From nobody Mon Aug 29 21:29:44 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDF012D0B3 for ; Mon, 29 Aug 2016 21:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 Dma_lJWWcTLh for ; Mon, 29 Aug 2016 21:29:40 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB18B12B026 for ; Mon, 29 Aug 2016 21:29:39 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 29 Aug 2016 21:41:26 -0700 From: Jim Schaad To: 'SPASM' References: <147252989540.19045.14451060202052338375.idtracker@ietfa.amsl.com> In-Reply-To: <147252989540.19045.14451060202052338375.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2016 21:29:09 -0700 Message-ID: <034101d20277$0f4130a0$2dc391e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF7yRrIX3D59W/UrgspUBkr1mAzQ6ENWu0w Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Spasm] FW: I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 04:29:42 -0000 This update has the algorithm updates with the following exceptions: 1. The key management changes have not been done yet. 2. The signature algorithms doesn't have P-384 listed in them. The first is just a timing issue. The second is because at this time the only person that I have seen arguing for this is Russ. I would like to see some additional support or some additional reasoning to add this. I am not sure that this does not fall into the same category as the arguments about doing 192 bit AES, would people really use 384 or just jump to 448 and 521? The update to the certs draft has also been submitted with the same set of changes and should be coming out shortly. Jim > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, August 29, 2016 9:05 PM > To: i-d-announce@ietf.org > Cc: spasm@ietf.org > Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Limited Additional Mechanisms for PKIX and > SMIME of the IETF. > > Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version > 3.5 Message Specification > Authors : Jim Schaad > Blake Ramsdell > Sean Turner > Filename : draft-ietf-lamps-rfc5751-bis-01.txt > Pages : 53 > Date : 2016-08-29 > > Abstract: > This document defines Secure/Multipurpose Internet Mail Extensions > (S/MIME) version 3.5. S/MIME provides a consistent way to send and > receive secure MIME data. Digital signatures provide authentication, > message integrity, and non-repudiation with proof of origin. > Encryption provides data confidentiality. Compression can be used to > reduce data size. This document obsoletes RFC 5751. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Aug 29 21:29:59 2016 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 363D0127A90; Mon, 29 Aug 2016 21:29:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147253139718.19081.4964460077559707435.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2016 21:29:57 -0700 Archived-At: Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5750-bis-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 04:29:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 3.2 Certificate Handling Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5750-bis-00.txt Pages : 23 Date : 2016-08-29 Abstract: This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5750-bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 29 21:32:56 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D17812D0A1 for ; Mon, 29 Aug 2016 21:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 4gfpEwdotwaR for ; Mon, 29 Aug 2016 21:32:54 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A39127A90 for ; Mon, 29 Aug 2016 21:32:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3343630051F for ; Tue, 30 Aug 2016 00:32:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YpRvPlS7EmB6 for ; Tue, 30 Aug 2016 00:32:51 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 4B5A23002B1; Tue, 30 Aug 2016 00:32:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <034101d20277$0f4130a0$2dc391e0$@augustcellars.com> Date: Tue, 30 Aug 2016 00:32:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <86411335-B429-468D-9ABB-6740E922FFF6@vigilsec.com> References: <147252989540.19045.14451060202052338375.idtracker@ietfa.amsl.com> <034101d20277$0f4130a0$2dc391e0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] FW: I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 04:32:55 -0000 Jim: Thanks for the updated draft. > This update has the algorithm updates with the following exceptions: >=20 > 1. The key management changes have not been done yet. > 2. The signature algorithms doesn't have P-384 listed in them. >=20 > The first is just a timing issue. > The second is because at this time the only person that I have seen = arguing > for this is Russ. I would like to see some additional support or some > additional reasoning to add this. I am not sure that this does not = fall > into the same category as the arguments about doing 192 bit AES, would > people really use 384 or just jump to 448 and 521? I will point out that the Suite B community will use P-384. I do not = know if there are others. Russ From nobody Tue Aug 30 11:20:26 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114F912D7BD for ; Tue, 30 Aug 2016 11:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 yAdWihlIbQ0p for ; Tue, 30 Aug 2016 11:20:16 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CD912D7B6 for ; Tue, 30 Aug 2016 11:20:14 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 30 Aug 2016 11:32:30 -0700 From: Jim Schaad To: 'Russ Housley' , 'SPASM' References: <147252989540.19045.14451060202052338375.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 30 Aug 2016 11:20:00 -0700 Message-ID: <03fe01d202eb$205c84b0$61158e10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF7yRrIX3D59W/UrgspUBkr1mAzQwJwpiDuoPqwUXA= Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 18:20:22 -0000 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Monday, August 29, 2016 9:29 PM > To: SPASM > Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt > > I did a very quick skim of the -01 version. Thanks. > > I expected Section 2.3 to include ECDH and X25519. If they are added, some > related guidance will be needed in Sections 4.4 and 4.5. Our messages much have crossed where I said that this wasn't done for timing issues. I am not sure what type of guidance needs to be added to section 4.4. and 4.5 though, there is no concept of having different sized keys as the MUST requirements in section 2.3 are going to require a specific key size. > > Section 4 offers guidance about RSA, RSASSA-PSS, RSAES-OAEP, and DH > algorithms. It used to contain some guidance about DSA. Is there any reason to > remove DSA guidance from 4.2 and 4.3? I think we need to add guidance in > Sections 4.2 and 4.3 for ECDSA and EdDSA. I am in the process of trying to remove all DSA guidance to section B.2 for clarity. It is just going to take a while to go through section 4.1 and clean that one up. As above since they section 4.2-4.5 are all dealing with key sizes, what guidance do you think needs to be in there given that we are dealing with fixed sized keys for ECDSA and EdDSA in requirements. It would make more sense to list specific curves as may in section 2.x Jim > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Aug 30 12:48:21 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD98912D7AA for ; Tue, 30 Aug 2016 12:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 bZeIPtJFeALA for ; Tue, 30 Aug 2016 12:48:18 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36FC12B03D for ; Tue, 30 Aug 2016 12:48:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 96A603005B4 for ; Tue, 30 Aug 2016 15:48:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GAPbAOMq7nV8 for ; Tue, 30 Aug 2016 15:48:14 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id A1C9A300411; Tue, 30 Aug 2016 15:48:14 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <03fe01d202eb$205c84b0$61158e10$@augustcellars.com> Date: Tue, 30 Aug 2016 15:48:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147252989540.19045.14451060202052338375.idtracker@ietfa.amsl.com> <03fe01d202eb$205c84b0$61158e10$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 19:48:20 -0000 Jim: >> I did a very quick skim of the -01 version. Thanks. >>=20 >> I expected Section 2.3 to include ECDH and X25519. If they are = added,some >> related guidance will be needed in Sections 4.4 and 4.5. >=20 > Our messages much have crossed where I said that this wasn't done for = timing > issues. Yes, I think so. > I am not sure what type of guidance needs to be added to section 4.4. = and > 4.5 though, there is no concept of having different sized keys as the = MUST > requirements in section 2.3 are going to require a specific key size. For Section 4.4, I was thinking about something like =85 An S/MIME agent when establishing keys for content encryption using = the ECDH MUST support P-256, and MAY support other curves as well. For there CFRG curves, maybe we only say that X25519 MUST be supported that X448 MAY be supported. Russ From nobody Tue Aug 30 14:49:57 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFBD12D817 for ; Tue, 30 Aug 2016 14:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 CM21XE2YBMar for ; Tue, 30 Aug 2016 14:49:53 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC0D12D80F for ; Tue, 30 Aug 2016 14:49:53 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 30 Aug 2016 15:02:30 -0700 From: Jim Schaad To: 'Russ Housley' References: <147252989540.19045.14451060202052338375.idtracker@ietfa.amsl.com> <03fe01d202eb$205c84b0$61158e10$@augustcellars.com> In-Reply-To: Date: Tue, 30 Aug 2016 14:49:46 -0700 Message-ID: <045a01d20308$6e4568f0$4ad03ad0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF7yRrIX3D59W/UrgspUBkr1mAzQwJwpiDuAizUfTIBU3v4X6De9pxQ Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 21:49:55 -0000 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Tuesday, August 30, 2016 12:48 PM > To: Jim Schaad > Cc: SPASM > Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt > > Jim: > > >> I did a very quick skim of the -01 version. Thanks. > >> > >> I expected Section 2.3 to include ECDH and X25519. If they are > >> added,some related guidance will be needed in Sections 4.4 and 4.5. > > > > Our messages much have crossed where I said that this wasn't done for > > timing issues. > > Yes, I think so. > > > I am not sure what type of guidance needs to be added to section 4.4. > > and > > 4.5 though, there is no concept of having different sized keys as the > > MUST requirements in section 2.3 are going to require a specific key size. > > For Section 4.4, I was thinking about something like . > > An S/MIME agent when establishing keys for content encryption using the > ECDH MUST support P-256, and MAY support other curves as well. > > For there CFRG curves, maybe we only say that X25519 MUST be supported that > X448 MAY be supported. But why would that not be in section 2.X instead? It is not like X25519 supports different key sizes which is what is currently documented in section 4. Jim > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Aug 30 14:56:45 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6A112B044 for ; Tue, 30 Aug 2016 14:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 NYlFTbF_CQaP for ; Tue, 30 Aug 2016 14:56:42 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F97612B043 for ; Tue, 30 Aug 2016 14:56:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3AC033004B7 for ; Tue, 30 Aug 2016 17:56:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Jbf_-91xusKS for ; Tue, 30 Aug 2016 17:56:39 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 2D2D1300411; Tue, 30 Aug 2016 17:56:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <045a01d20308$6e4568f0$4ad03ad0$@augustcellars.com> Date: Tue, 30 Aug 2016 17:55:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <52D1D1F9-F672-4232-A19C-EA8A5675A4B0@vigilsec.com> References: <147252989540.19045.14451060202052338375.idtracker@ietfa.amsl.com> <03fe01d202eb$205c84b0$61158e10$@augustcellars.com> <045a01d20308$6e4568f0$4ad03ad0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 21:56:44 -0000 Jim: >>=20 >>>> I did a very quick skim of the -01 version. Thanks. >>>>=20 >>>> I expected Section 2.3 to include ECDH and X25519. If they are >>>> added,some related guidance will be needed in Sections 4.4 and 4.5. >>>=20 >>> Our messages much have crossed where I said that this wasn't done = for >>> timing issues. >>=20 >> Yes, I think so. >>=20 >>> I am not sure what type of guidance needs to be added to section = 4.4. >>> and >>> 4.5 though, there is no concept of having different sized keys as = the >>> MUST requirements in section 2.3 are going to require a specific key > size. >>=20 >> For Section 4.4, I was thinking about something like . >>=20 >> An S/MIME agent when establishing keys for content encryption using = the >> ECDH MUST support P-256, and MAY support other curves as well. >>=20 >> For there CFRG curves, maybe we only say that X25519 MUST be = supported > that >> X448 MAY be supported. >=20 > But why would that not be in section 2.X instead? It is not like = X25519 > supports different key sizes which is what is currently documented in > section 4. This seems to be the place that the document says you MAY do stronger = things too. Russ