From _n{vesil|@H122.P484.IIJ4U.OR.JP Fri Feb 1 01:26:39 2008 Return-Path: <_n{vesil|@H122.P484.IIJ4U.OR.JP> X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6DC3A68B5 for ; Fri, 1 Feb 2008 01:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 103.906 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=103.906 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FB_PENIS=1.66, FRT_PENIS1=3.592, HELO_EQ_DE=0.35, HTML_MESSAGE=1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, MANGLED_DICK=2.3, MANGLED_PENIS=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_OBFU_PENIS_SUB=3.333, SUBJECT_FUZZY_PENIS=3.096, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.3 HELO_EQ_DE HELO_EQ_DE * 3.1 SUBJECT_FUZZY_PENIS Attempt to obfuscate words in Subject: * 3.3 SARE_OBFU_PENIS_SUB subject has obfuscated spammer topic * 2.3 MANGLED_PENIS BODY: mangled - Penis * 0.6 J_CHICKENPOX_12 BODY: 1alpha-pock-2alpha * 2.3 MANGLED_DICK BODY: mangled dick * 3.6 FRT_PENIS1 BODY: ReplaceTags: Penis * 1.7 FB_PENIS BODY: FB_PENIS * 0.6 J_CHICKENPOX_13 BODY: 1alpha-pock-3alpha * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: wordiel.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: wordiel.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: wordiel.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: wordiel.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: wordiel.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: wordiel.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: wordiel.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [91.18.143.223 listed in dnsbl.sorbs.net] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [91.18.143.223 listed in zen.spamhaus.org] * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDCdIxXfavrK for ; Fri, 1 Feb 2008 01:26:38 -0800 (PST) Received: from p5B129996.dip0.t-ipconnect.de (p5B128FDF.dip0.t-ipconnect.de [91.18.143.223]) by core3.amsl.com (Postfix) with ESMTP id E0C803A686F for ; Fri, 1 Feb 2008 01:26:35 -0800 (PST) Message-ID: <000e01c864b4$c097bdc0$9699125b@vuolpxld1vu8mz> From: "Kourosh Kryska" <_n{vesil|@H122.P484.IIJ4U.OR.JP> To: openpgp-archive@ietf.org Subject: ***SPAM*** 103.906 (5) Want a brand new large P3Nis? It's easy, simply click HERE Date: Fri, 1 Feb 2008 10:28:06 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000A_01C864BD.225C25C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000A_01C864BD.225C25C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do not make the mistake of being content with your d1ck ----------=_NextPart_000_000A_01C864BD.225C25C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do not make the mistake of being = content with=20 your d1ck ----------=_NextPart_000_000A_01C864BD.225C25C0-- From _svaelja@MONTE.K12.MN.US Fri Feb 1 03:26:44 2008 Return-Path: <_svaelja@MONTE.K12.MN.US> X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3363A690B for ; Fri, 1 Feb 2008 03:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 52.123 X-Spam-Level: **************************************************** X-Spam-Status: Yes, score=52.123 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 1.1 HELO_EQ_DSL HELO_EQ_DSL * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 4.3 HELO_DYNAMIC_HCC Relay HELO'd using suspicious hostname (HCC) * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.3 HOST_EQ_BR HOST_EQ_BR * 1.0 HELO_EQ_BR HELO_EQ_BR * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 82] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 65] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 82] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: ookbast.com] * 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is a abuseable web server * [189.30.225.187 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [189.30.225.187 listed in zen.spamhaus.org] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye1zT1rqBrSJ for ; Fri, 1 Feb 2008 03:26:43 -0800 (PST) Received: from 189-30-225-187.paemt701.dsl.brasiltelecom.net.br (189-30-225-187.paemt701.dsl.brasiltelecom.net.br [189.30.225.187]) by core3.amsl.com (Postfix) with ESMTP id 277EC3A6869 for ; Fri, 1 Feb 2008 03:26:40 -0800 (PST) Message-ID: <000e01c864c5$3816c390$bbe11ebd@eduardo> From: "Dalton Hartlin" <_svaelja@MONTE.K12.MN.US> To: openpgp-archive@ietf.org Subject: ***SPAM*** 52.123 (5) Chicks will be AMAZED by your legendary PROWESS. Date: Fri, 1 Feb 2008 09:25:59 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000A_01C864B4.748C6CF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000A_01C864B4.748C6CF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Assure your masculinity with your new huge rod. ----------=_NextPart_000_000A_01C864B4.748C6CF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Assure your masculinity with your = new huge=20 rod. ----------=_NextPart_000_000A_01C864B4.748C6CF0-- From gleasonspongioblastoma8552461@yahoo.com Fri Feb 1 03:57:22 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238A93A697B; Fri, 1 Feb 2008 03:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 247.397 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=247.397 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_FAKE_RCVD_LINE=10.357, FH_RELAY_NODNS=1.451, GB_H_REPLICA=50, GB_REPLICA=50, GB_WATCH_1=50, HELO_MISMATCH_COM=0.553, INVALID_MSGID=1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_DOUBLE_IP_SPAM=3.798, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_IP_FROMIP1=1.666, SARE_SPEC_REPL_OBFU1=1.666, SARE_SUB_PERFECT=0.725, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.7 SARE_SUB_PERFECT subject has likely spammer phrase or word * 50 GB_H_REPLICA Misspelled Replica Watch Seller * 10 FH_FAKE_RCVD_LINE RCVD line looks faked (A) * 1.7 SARE_RECV_IP_FROMIP1 Received line is IP address from IP address * 1.7 SARE_SPEC_REPL_OBFU1 BODY: SARE_SPEC_REPL_OBFU1 * 0.6 J_CHICKENPOX_42 BODY: 4alpha-pock-2alpha * 0.6 J_CHICKENPOX_15 BODY: 1alpha-pock-5alpha * 50 GB_REPLICA BODY: Misspelled Replica Watch Seller * 50 GB_WATCH_1 BODY: Misspelled Watch Watch Seller * 3.0 BAYES_95 BODY: Bayesian spam probability is 95 to 99% * [score: 0.9638] * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: pofdiekk.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: pofdiekk.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: pofdiekk.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: pofdiekk.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: pofdiekk.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: pofdiekk.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [71.91.8.206 listed in zen.spamhaus.org] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 1.9 INVALID_MSGID Message-Id is not valid, according to RFC 2822 * 3.8 RCVD_DOUBLE_IP_SPAM Bulk email fingerprint (double IP) found * 0.6 HELO_MISMATCH_COM HELO_MISMATCH_COM Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osJNcTpOIThy; Fri, 1 Feb 2008 03:57:21 -0800 (PST) Received: from unknown.al.charter.com (unknown [71.91.8.206]) by core3.amsl.com (Postfix) with SMTP id A90593A693B; Fri, 1 Feb 2008 03:57:00 -0800 (PST) Received: from 32.224.60.206 by 71.91.8.206; Fri, 01 Feb 2008 04:54:35 -0700 Message-ID: From: "Lila Cunningham" Reply-To: "Lila Cunningham" To: off-path-bof@ietf.org Subject: ***SPAM*** 247.397 (5) Repl1ca watch is a perfect gift! Date: Fri, 01 Feb 2008 06:58:35 -0500 MIME-Version: 1.0 Winter is hitting and New Year is coming. Do you need perfect gift? 0rder high qual1ty repl1ca of w4tches, purses & bags from 2008! http://www.pofdiekk.com/ From seizzit@afhosting.com Fri Feb 1 09:45:23 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614563A67F2 for ; Fri, 1 Feb 2008 09:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 85.915 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=85.915 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.2 HOST_EQ_IT HOST_EQ_IT * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 0.6 HELO_EQ_IT HELO_EQ_IT * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: lefoursm.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: lefoursm.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: lefoursm.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: lefoursm.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: lefoursm.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [90.133.77.120 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy7L5Oqt0SAp for ; Fri, 1 Feb 2008 09:45:22 -0800 (PST) Received: from d90-133-77-120.cust.tele2.it (d90-133-77-120.cust.tele2.it [90.133.77.120]) by core3.amsl.com (Postfix) with ESMTP id 6F58B3A6858 for ; Fri, 1 Feb 2008 09:43:42 -0800 (PST) Message-ID: <000a01c864fa$36797430$784d855a@utented2e89f51> From: "Decio cartier" To: openpgp-archive@ietf.org Subject: ***SPAM*** 85.915 (5) Non-stop action every night - do you have what it takes? Date: Fri, 1 Feb 2008 18:45:19 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0006_01C86502.9831F550" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0006_01C86502.9831F550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chicks will be AMAZED by your legendary PROWESS. ----------=_NextPart_000_0006_01C86502.9831F550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chicks will be AMAZED by your = legendary=20 PROWESS. ----------=_NextPart_000_0006_01C86502.9831F550-- From email.caa@irish-coffee.biz Tue Feb 5 10:37:26 2008 Return-Path: X-Original-To: openpgp-archive@lists.ietf.org Delivered-To: ietfarch-openpgp-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D333F3A7CFA; Tue, 5 Feb 2008 10:53:02 -0800 (PST) Received: from irish-coffee.biz (unknown [121.43.145.92]) by mail.ietf.org (Postfix) with SMTP id 73C1C3A8F1B for ; Tue, 5 Feb 2008 00:31:02 -0800 (PST) Received: from [63.38.143.167] by mail.webhostings4u.com with NNFMP; Tue, 05 Feb 2008 10:27:48 +0100 Message-ID: Date: Tue, 05 Feb 2008 10:15:54 +0100 Reply-To: "Felix" From: "Felix" User-Agent: Mozilla 4.79 [en]C-CCK-MCD {SillyDog} (Win98; U) MIME-Version: 1.0 To: "Achim" Subject: Eine Empfehlung von Felix Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hallo Achim! Ich habe eine super Seite entdeckt, wo man ganz einfach einen Seitensprung Partner finden kann. Ich habe mir gerade mein Passwort angefordert und kann die Seite nur weiterempfehlen. Echt eine super Sache! Schau einfach auch mal vorbei: http://www.onlineseitensprung3.tk/ Viele Grüße Felix ------------------------------------------------------------------------ Diese ePost wurde versendet von: Felix (email.caa@irish-coffee.biz) From dfno88@yahoo.cn Tue Feb 5 10:42:57 2008 Return-Path: X-Original-To: openpgp-archive@lists.ietf.org Delivered-To: ietfarch-openpgp-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 95D3F3A6A7D; Tue, 5 Feb 2008 10:53:06 -0800 (PST) Received: from yahoo.cn (unknown [58.61.168.82]) by mail.ietf.org (Postfix) with ESMTP id 4989028D14B for ; Tue, 5 Feb 2008 07:46:46 -0800 (PST) Received: from WWW-140D654E44F[169.254.30.83] by tom.com with SMTP id 4B66FFEF; Tue, 5 Feb 2008 23:48:12 +0800 From: =?GB2312?B?u+G8xtauyfk=?= Subject: =?GB2312?B?vdo=?= / =?GB2312?B?y7Ago6ixo8H0sbjTw6Op?= To: "openpgp-archive" Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Reply-To: dongwoo88@163.com Date: Tue, 5 Feb 2008 23:48:35 +0800 X-Mailer: Foxmail 5.0 beta2 Message-Id: <20080205154647.4989028D14B@mail.ietf.org> li
     
     
     
From Shandon-lost@WALSHJESUIT.ORG Tue Feb 5 10:43:58 2008 Return-Path: X-Original-To: openpgp-archive@ietf.org Delivered-To: ietfarch-openpgp-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id C47D33A821E; Tue, 5 Feb 2008 10:53:06 -0800 (PST) Received: from kelinat218.keli.cz (kelinat218.keli.cz [193.85.243.218]) by mail.ietf.org (Postfix) with ESMTP id 4D6C53A8D4A for ; Mon, 4 Feb 2008 23:46:52 -0800 (PST) Message-ID: <001101c867cb$7e5809a0$daf355c1@Reicheltovi> From: "Shandon Fitzner" To: openpgp-archive@ietf.org Subject: Be the Ladies' choice with your brand new big d-!ck. Date: Tue, 5 Feb 2008 08:48:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000D_01C867D3.E01C71A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000D_01C867D3.E01C71A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Never hear a single complaint about your small weener ever again. ----------=_NextPart_000_000D_01C867D3.E01C71A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Never hear a single complaint about = your=20 small weener ever again. ----------=_NextPart_000_000D_01C867D3.E01C71A0-- From kongj6@tom.com Tue Feb 5 10:44:26 2008 Return-Path: X-Original-To: openpgp-archive@ietf.org Delivered-To: ietfarch-openpgp-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 3BFA03A782F; Tue, 5 Feb 2008 10:57:45 -0800 (PST) Received: from tom.com (unknown [58.61.168.82]) by mail.ietf.org (Postfix) with ESMTP id 6A64C3AA002 for ; Tue, 5 Feb 2008 04:29:42 -0800 (PST) Received: from WWW-140D654E44F[169.254.30.83] by yahoo.cn with SMTP id 76DF42D0; Tue, 5 Feb 2008 20:31:05 +0800 From: =?GB2312?B?u+G8xtauyfk=?= Subject: =?GB2312?B?vdo=?= / =?GB2312?B?y7Ago6ixo8H0sbjTw6Op?= To: "openpgp-archive" Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Reply-To: dongwoo88@163.com Date: Tue, 5 Feb 2008 20:31:31 +0800 X-Mailer: Foxmail 5.0 beta2 Message-Id: <20080205122943.6A64C3AA002@mail.ietf.org> li
     
     
     
From dfno88@yahoo.cn Tue Feb 5 10:46:02 2008 Return-Path: X-Original-To: openpgp-archive@lists.ietf.org Delivered-To: ietfarch-openpgp-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 44AA63A74E8; Tue, 5 Feb 2008 10:43:09 -0800 (PST) Received: from yahoo.cn (unknown [58.61.168.82]) by mail.ietf.org (Postfix) with ESMTP id 51D5F3A9FFE for ; Tue, 5 Feb 2008 04:29:40 -0800 (PST) Received: from WWW-140D654E44F[169.254.30.83] by yahoo.cn with SMTP id 7403FBFE; Tue, 5 Feb 2008 20:31:05 +0800 From: =?GB2312?B?u+G8xtauyfk=?= Subject: =?GB2312?B?vdo=?= / =?GB2312?B?y7Ago6ixo8H0sbjTw6Op?= To: "openpgp-archive" Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Reply-To: dongwoo88@163.com Date: Tue, 5 Feb 2008 20:31:27 +0800 X-Mailer: Foxmail 5.0 beta2 Message-Id: <20080205122940.51D5F3A9FFE@mail.ietf.org> li
     
     
     
From drhrou8@tom.com Tue Feb 5 10:57:03 2008 Return-Path: X-Original-To: openpgp-archive@megatron.ietf.org Delivered-To: ietfarch-openpgp-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 355243A7F81; Tue, 5 Feb 2008 10:52:56 -0800 (PST) Received: from tom.com (unknown [58.61.168.82]) by mail.ietf.org (Postfix) with ESMTP id 3474A28D150 for ; Tue, 5 Feb 2008 07:46:56 -0800 (PST) Received: from WWW-140D654E44F[169.254.30.83] by tom.com with SMTP id 2786ED73; Tue, 5 Feb 2008 23:48:12 +0800 From: =?GB2312?B?u+G8xtauyfk=?= Subject: =?GB2312?B?vdo=?= / =?GB2312?B?y7Ago6ixo8H0sbjTw6Op?= To: "openpgp-archive" Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Reply-To: dongwoo88@163.com Date: Tue, 5 Feb 2008 23:48:45 +0800 X-Mailer: Foxmail 5.0 beta2 Message-Id: <20080205154657.3474A28D150@mail.ietf.org> li
     
     
     
From _segrenao@UCP.COM.HK Tue Feb 5 11:00:23 2008 Return-Path: <_segrenao@UCP.COM.HK> X-Original-To: openpgp-archive@ietf.org Delivered-To: ietfarch-openpgp-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id C64EA3A6CA3; Tue, 5 Feb 2008 10:37:53 -0800 (PST) Received: from host-62-10-83-201.cust-adsl.tiscali.it (host-62-10-79-58.cust-adsl.tiscali.it [62.10.79.58]) by mail.ietf.org (Postfix) with ESMTP id 34E6528CC28 for ; Tue, 5 Feb 2008 06:24:24 -0800 (PST) Message-ID: <001201c86803$06bb54f0$c9530a3e@TRINACRIA> From: "genine mel" <_segrenao@UCP.COM.HK> To: openpgp-archive@ietf.org Subject: Increase your pen1s size naturally with enlargement pills made from 100% herbal ingredients Date: Tue, 5 Feb 2008 15:25:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000E_01C8680B.687FBCF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000E_01C8680B.687FBCF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You're right to be ashamed if your d1ck is tiny, but know this - YOU CAN = CHANGE THAT ----------=_NextPart_000_000E_01C8680B.687FBCF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You're right to be ashamed if your = d1ck is=20 tiny, but know this - YOU CAN CHANGE THAT ----------=_NextPart_000_000E_01C8680B.687FBCF0-- From sgding6@163.com Tue Feb 5 11:01:31 2008 Return-Path: X-Original-To: openpgp-archive@megatron.ietf.org Delivered-To: ietfarch-openpgp-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id F06193A6B6E; Tue, 5 Feb 2008 10:37:59 -0800 (PST) Received: from 163.com (unknown [58.61.168.82]) by mail.ietf.org (Postfix) with ESMTP id AC6963A9FFF for ; Tue, 5 Feb 2008 04:29:40 -0800 (PST) Received: from WWW-140D654E44F[169.254.30.83] by 163.com with SMTP id 2DFFA9FD; Tue, 5 Feb 2008 20:31:05 +0800 From: =?GB2312?B?u+G8xtauyfk=?= Subject: =?GB2312?B?vdo=?= / =?GB2312?B?y7Ago6ixo8H0sbjTw6Op?= To: "openpgp-archive" Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Reply-To: dongwoo88@163.com Date: Tue, 5 Feb 2008 20:31:28 +0800 X-Mailer: Foxmail 4.2 [cn] Message-Id: <20080205122940.AC6963A9FFF@mail.ietf.org> li
     
     
     
From sgding6@163.com Tue Feb 5 11:01:48 2008 Return-Path: X-Original-To: openpgp-archive@ietf.org Delivered-To: ietfarch-openpgp-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 3CA8B3A70D1; Tue, 5 Feb 2008 10:52:49 -0800 (PST) Received: from 163.com (unknown [58.61.168.82]) by mail.ietf.org (Postfix) with ESMTP id BEE4428D14E for ; Tue, 5 Feb 2008 07:46:49 -0800 (PST) Received: from WWW-140D654E44F[169.254.30.83] by yahoo.cn with SMTP id 283DBF27; Tue, 5 Feb 2008 23:48:12 +0800 From: =?GB2312?B?u+G8xtauyfk=?= Subject: =?GB2312?B?vdo=?= / =?GB2312?B?y7Ago6ixo8H0sbjTw6Op?= To: "openpgp-archive" Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Reply-To: dongwoo88@163.com Date: Tue, 5 Feb 2008 23:48:37 +0800 X-Mailer: Foxmail 4.2 [cn] Message-Id: <20080205154649.BEE4428D14E@mail.ietf.org> li
     
     
     
From email.uaayf@cavtel.net Tue Feb 5 11:03:52 2008 Return-Path: X-Original-To: openpgp-archive@ietf.org Delivered-To: ietfarch-openpgp-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 50FB73A8130; Tue, 5 Feb 2008 10:37:55 -0800 (PST) Received: from cavtel.net (static-76-160-232-250.dsl.cavtel.net [76.160.232.250]) by mail.ietf.org (Postfix) with SMTP id EF1083A90A9 for ; Tue, 5 Feb 2008 01:10:04 -0800 (PST) Received: from mx.reskind.net ([165.190.73.215]) by mail.webhostings4u.com with QMQP; Tue, 05 Feb 2008 00:59:49 -0900 Received: from unknown (98.236.27.57) by smtp-server1.cfdenselr.com with SMTP; Tue, 05 Feb 2008 00:57:22 -0900 Message-ID: Reply-To: "Felix" From: "Felix" To: "Siegfried" Subject: Eine Empfehlung von Felix Date: Tue, 05 Feb 2008 00:36:53 -0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V9.0.2416 Hallo Siegfried! Ich habe eine super Seite entdeckt, wo man ganz einfach einen Seitensprung Partner finden kann. Ich habe mir gerade mein Passwort angefordert und kann die Seite nur weiterempfehlen. Echt eine super Sache! Schau einfach auch mal vorbei: http://www.onlineseitensprung3.tk/ Viele Grüße Felix ------------------------------------------------------------------------ Diese ePost wurde versendet von: Felix (email.uaayf@cavtel.net) From owner-ietf-openpgp@mail.imc.org Mon Feb 18 20:19:17 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74C63A6C9F for ; Mon, 18 Feb 2008 20:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eflMYQV8OCb for ; Mon, 18 Feb 2008 20:19:17 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id F04163A6C95 for ; Mon, 18 Feb 2008 20:19:16 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1J40Isb093535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 21:00:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1J40IZB093534; Mon, 18 Feb 2008 21:00:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1J40GCu093525 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 18 Feb 2008 21:00:17 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m1J4XGo5001896 for ; Mon, 18 Feb 2008 23:33:17 -0500 Message-ID: <47BA544E.8020608@brainhub.org> Date: Mon, 18 Feb 2008 20:00:14 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: ECC in OpenPGP proposal Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello OpenPGP list, as Hal Finney had mentioned earlier, here is the draft: http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt Unless you read this on a text terminal, here is the document in alternative formats that offer cross-references as navigation links: http://brainhub.googlepages.com/pgp This submissions considers comments of the group to earlier Elliptic curve Cryptography (ECC) draft submissions. A couple of issues that were raised then are the justification for ECC in OpenPGP and how the larger set of ECC parameters can be managed. Why do we need ECC? The main reason is better alignment with the strength of symmetric key. Given that US government has chosen ECC in favor of modp for larger key sizes, this proposal is carefully written to comply with NSA Suite-B. Informally, this is a proposal for these who are concerned that the use of SHA2-512 and AES-256 will need something stronger that RSA 1024. By optimistic estimates users should use at least RSA 4096 with AES 256, while it is a common assumption that RSA 8192 is more appropriate. In practice, many sites today are not able to use RSA keys of sizes greater than 4096. ECC offers alternatives to larger modp key sizes. Another advantage of ECC is an opportunity to expand the set of hardware on which OpenPGP can be implemented. The security of AES-128 with corresponding ECC public key may be more attractive for "weak" devices, as opposed to RSA public keys, especially because the ECC curves introduced by this standard are already supported by TLS, IKE, PKIX, and SSH. Any system that communicates over slow medium will benefit from smaller keys and ESKs as well. This paragraph describes the direction chosen by the proposal in reference to the issue of magnitude of ECC parameters and options. One possible approach an ECC standard can take is to define all possible formats in one RFC, a "toolbox" approach. One can argue that smartcard devices may prefer ECC in binary fields, while software implementations would like to work in generalized Mersenne prime fields. Another group of OpenPGP applications may wish to generate its own random curves as part of a protocol, and so on. While it may be possible to create such a broad standard that will make each concerned implementer happy, it creates more interoperability issues. This puts burden on an implementation that wants to support every type of ECC key. The performance and security issues associated with generation and verification of random ECC curves creates new order of complexity. It seems to me that in the short run there are two likely outcomes resulting from implementing a "toolbox" approach. In the first one, there will be no interoperability between different OpenPGP implementations. The second possibility is that there will be a core set of parameters that will be implemented by everybody who claims ECC support. This second possibility is probably wishful thinking. Consider the fact that in OpenPGP there is no method to advertise public key support, yet alone, a method to advertise a nuance of public key support. For example, what an application should use for a top key, so that self-signatures and certifications by this key are broadly understood? It is rare to see SHA2-512 used for these signatures. I think the following approach will help speed up adoption of the standard: we define core set of ECC parameters and make them MUST. This will be lowest common denominator of all possible ECC configurations (within the acceptable security strength). This will not be the optimal field for every application, yet, it will be good compromise to achieve faster adoption. Future advances in computing will drive the upgrade of the core set, but by then there will be a path by which ECC-capable applications can transition to other formats. The draft doesn't preclude the existence of companion proposals that define ECC in other fields, moreover, the draft provides a framework for these extensions. Finally, only patent-free techniques were chosen for this proposal. The requirement to be in unencumbered field further reduced the acceptable ECC methods. To summarize, this document offers narrow core set of functionality and focuses on matching AES strength and on Suite-B support. There are lots of MUSTs, very few SHOULDs in the interest of interoperability and patent clarity. I would appreciate if the group reviews the document. Thank you. From owner-ietf-openpgp@mail.imc.org Wed Feb 20 02:48:39 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D15A28C129 for ; Wed, 20 Feb 2008 02:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piEd5IZP0CwE for ; Wed, 20 Feb 2008 02:48:38 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0B2C53A6E4F for ; Wed, 20 Feb 2008 02:47:43 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KACiq8080463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 03:12:44 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1KAChAI080462; Wed, 20 Feb 2008 03:12:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KACeQI080453 for ; Wed, 20 Feb 2008 03:12:42 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id C12C15D23; Wed, 20 Feb 2008 10:12:20 +0000 (GMT/BST) Message-ID: <47BBFCFC.6070508@systemics.com> Date: Wed, 20 Feb 2008 11:12:12 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Andrey Jivsov Cc: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal References: <47BA544E.8020608@brainhub.org> In-Reply-To: <47BA544E.8020608@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi all, Some comments. Caveat: I wouldn't know an EC if someone hit me over the head with it... Big comment: far too much variability, for little gain. Andrey Jivsov wrote: > > Hello OpenPGP list, > > as Hal Finney had mentioned earlier, here is the draft: > http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt > > Unless you read this on a text terminal, here is the document in > alternative formats that offer cross-references as navigation links: > http://brainhub.googlepages.com/pgp > Why do we need ECC? The main reason is better alignment with the > strength of symmetric key. Given that US government has chosen ECC in > favor of modp for larger key sizes, this proposal is carefully written > to comply with NSA Suite-B. I think it is sufficient to state that you want a Suite-B compatible profile. 4. ... "SHOULD support ECDH" what is the point of not supporting ECDH? I recommend MUST. ===== 6. ... "the KDF hash function MAY be any hash function defined in [FIPS 180-2] or its successor, except that SHA-1 MUST NOT be used." What is the point in permitting alternatives? If there is a good reason, I would prefer to see them enumerated for better understanding and for certainty. I especially don't like "or its successor." I ask ... without expecting to understanding the answer ... why it is that it is useful or necessary to permit any variability in the KDF? ===== 11.2 I don't think it makes sense for OpenPGP WG to suggest that it knows what "Secret" and "Top Secret" means, nor that it can "achieve" this. The normative place for that is NSA. If some guidance of intentions is useful, it should be in the sense of a comment. "This profile is intended to be compatible with Suite B." If the NSA can be convinced to make a statement as to what works for them, include that too. ==== 11.2 I don't see any point in providing both Secret and Top Secret? This seems like a way to create comaptibility problems for zero payoff. I suggest the full Top Secret as the only profile, and that's it. ==== 11. Indeed, what is the point in allowing people to fiddle around with different curves, KDFs, and hashes? Nobody has ever cracked any of them, or nobody that we care about (which excludes the NSA, perversely). Set one and leave it as that. This "profile" proposes 2 different public key algorithms, 3 different curves (plus future ones), 3 different hashes (plus future ones), 3 different AES strengths, MDC on or off, It/Salt as a SHOULD. I suggest you would half the entire workload by reducing all above choices to 1 MUST, and reduce the compatibility problems to about a tenth. It would then have a good chance of being a really useful profile. To business folks who don't care for the tea-room discussion about key lengths and rights to be compatible but uncommunicative... ===== 12. "MDC SHOULD be used when symmetrical encryption key is protected by ECDH." Is there any good reason to permit it to be dropped? Remove a compatibility complaint, make it a MUST? Iterated and Salted S2K ... Ditto. ===== From owner-ietf-openpgp@mail.imc.org Thu Feb 21 00:29:02 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D1428C9C9 for ; Thu, 21 Feb 2008 00:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_47=0.6, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N4FmB+qovse for ; Thu, 21 Feb 2008 00:29:00 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 132D428C9E3 for ; Thu, 21 Feb 2008 00:28:59 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1L88p5B004955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 01:08:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1L88pFk004954; Thu, 21 Feb 2008 01:08:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1L88n07004947 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 21 Feb 2008 01:08:50 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [192.168.1.81] (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m1L8gVo5015437; Thu, 21 Feb 2008 03:42:32 -0500 Message-ID: <47BD318F.5010509@brainhub.org> Date: Thu, 21 Feb 2008 00:08:47 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Ian G Subject: Re: ECC in OpenPGP proposal References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> In-Reply-To: <47BBFCFC.6070508@systemics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Ian, thank you for your comments. Ian G wrote: > > Hi all, > > > Some comments. Caveat: I wouldn't know an EC if someone hit me over > the head with it... > > Big comment: far too much variability, for little gain. > > > > > > > Andrey Jivsov wrote: >> >> Hello OpenPGP list, >> >> as Hal Finney had mentioned earlier, here is the draft: >> http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt >> >> Unless you read this on a text terminal, here is the document in >> alternative formats that offer cross-references as navigation links: >> http://brainhub.googlepages.com/pgp > >> Why do we need ECC? The main reason is better alignment with the >> strength of symmetric key. Given that US government has chosen ECC in >> favor of modp for larger key sizes, this proposal is carefully >> written to comply with NSA Suite-B. > > I think it is sufficient to state that you want a Suite-B compatible > profile. Suite-B offers fewer choices than this spec does. Some of restrictions imposed by Suite-B are debatable. The purpose of this draft is to match the strength of AES-128, AES-192 and AES-256. See section 12 for corresponding sizes for hashes and curves (which are "double width" of AES key sizes). http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.html#toc15 Suite-B only lists AES-128 and AES-256, EC P256 and P384, SHA-256 and SHA-384. This creates a shift in relative strength. To illustrate this using the table in section 12, NSA dropped the row with AES-256 and replaced AES-192 with AES-256 in the second raw, resulting in weaker top public key algorithm. Suite-B allows some patented techniques that were excluded. This leaves us with two curves for Suite-B, but since we must have two, why not add next strongest one as SHOULD for better symmetry? Without EC P521 addition applications will be left with 15K RSA/ElGamal key or weaker EC P384 to match AES-256. > ... "SHOULD support ECDH" > > what is the point of not supporting ECDH? I recommend MUST. > I can support this. However, please note that the signature has more weight by being a tool of certifications, i.e. self-signatures depends on it. Without support for ECDSA we cannot have functional EC keys, while we can have sign-only keys without ECDH. It is possible to have sign+encrypt keys with ECDSA top key and modp ElGamal DH. Also note that ECDH brings with it the need to implement KDF and key wrapping methods, because there is no ElGamal alternative in ECC field. ECDSA should be easier to implement than ECDH. > ===== > > 6. ... "the KDF hash function MAY be any hash function defined in > [FIPS 180-2] or its successor, except that SHA-1 MUST NOT be used." > > What is the point in permitting alternatives? If there is a good > reason, I would prefer to see them enumerated for better understanding > and for certainty. This is to continue good tradition of algorithm agility in OpenPGP. I am sure TLS designers would like to get rid of MD5, hardwired into their analog of KDF. Implementors are advised to follow the recommendations set in the table of section 12, which will mean that there are 3 ways to set up KDFs, parameterized by different hash algorithms, for each of 3 sizes of symmetric keys. The hash algorithms have already been implemented in vast majority of OpenPGP applications. The code to use KDF should be written using generic hash API, so that there will be no difference which hash algorithm is passed to initialize this API. Overall, I think the benefits overweight the slightly more complex format. > > I especially don't like "or its successor." I can drop this clause. I attempted to write a spec that doesn't need to be updated after NIST introduces new hashes. I wanted to make external the definition of what the right hashes for AES-128, AES-192, and AES-256 are. > I ask ... without expecting to understanding the answer ... why it is > that it is useful or necessary to permit any variability in the KDF? In summary, this follows from the need to support every AES key size. No other variability is allowed in section 6. > > ===== > > > > 11.2 I don't think it makes sense for OpenPGP WG to suggest that it > knows what "Secret" and "Top Secret" means, nor that it can "achieve" > this. The normative place for that is NSA. If some guidance of > intentions is useful, it should be in the sense of a comment. "This > profile is intended to be compatible with Suite B." If the NSA can be > convinced to make a statement as to what works for them, include that too. These Secret/Top Secret classifications are from Suite-B page. I can add your suggestion and the phrase "[SUITE-B] is the normative source of the definition" to section 11.2. We need a way to say what an OpenPGP application shall do to comply with each level of Suite-B security. http://www.nsa.gov/ia/industry/crypto_suite_b.cfm > ==== > > 11.2 I don't see any point in providing both Secret and Top Secret? > This seems like a way to create comaptibility problems for zero > payoff. I suggest the full Top Secret as the only profile, and that's > it. I think that the incremental cost to achieve Secret level of Suite-B is insignificant, given that an application has implemented Top Secret level. In addition, because I've dropped some of patented methods allowed by Suite-B, in my mind the scale is tipped to offer more choices. Also, Top Secret has less symmetry in the sense of relative security than Secret, as mentioned above. > ==== > > 11. Indeed, what is the point in allowing people to fiddle around > with different curves, KDFs, and hashes? Nobody has ever cracked any > of them, or nobody that we care about (which excludes the NSA, > perversely). Set one and leave it as that. > > This "profile" proposes 2 different public key algorithms, 3 different > curves (plus future ones), 3 different hashes (plus future ones), 3 > different AES strengths, MDC on or off, It/Salt as a SHOULD. My goal was to limit as much as I can. Let me explain how I arrived at the present set. I will leave MDC and S2K out of this section. Here is what have now: We want to support 3 sizes of AES algorithms. AES algorithms pair with 3 hashes and 3 curves in the sense of relative security. We need encryption and signing, and this is achieved with two new public key algorithms. Let's put this into perspective and sketch what it could have been. In addition to above: Point compression format. Curves in binary field, using polynomial or normal basis representations Curves in prime field that allow the choice of the prime; there is no limit to customization, up to the random curves over random underlying fields ECDH with cofactor; ECMQV (both patented) Multiple KDF or key wrapping method in conjunction with ECDH Another way to look at how flexible or constrained current proposal is is by comparing its flexibility with, for example, current modp ElGamal encryption in OpenPGP. An OpenPGP application today generates its own prime and is not constrained by the allowed size of such a prime (usually in a range of 1024-4096 bits). In this ECC proposal we essentially folding infinite number of primes into 3 predefined primes. This proposal offers the least choice of ECC parameters of any IETF standard. > I suggest you would half the entire workload by reducing all above > choices to 1 MUST, and reduce the compatibility problems to about a > tenth. > > It would then have a good chance of being a really useful profile. To > business folks who don't care for the tea-room discussion about key > lengths and rights to be compatible but uncommunicative... At present the only MUST for OpenPGP are curves ID 1 and 2. It also says that SHA-256 and SHA-384 are MUST. All this is in section 11.1. These are the curves/hashed approved by Suite-B. I can accepts that we reduce the OpenPGP profile to ID 1 and SHA-256. This will match Suite-B "Secret" level and drop "Top Secret". The section 11.2 is for Suite-B compatibility. The MUSTs there are for applications implementing Suite-B profile. I should put a sentence into 11.2 that makes this clear. I wasn't trying to tell an applications which Suite-B profile to use (for this there is section 12). > ===== > > 12. "MDC SHOULD be used when symmetrical encryption key is protected > by ECDH." > > Is there any good reason to permit it to be dropped? Remove a > compatibility complaint, make it a MUST? Hal Finney had a reservation that MDC and S2K are orthogonal to ECC, so I changed the key word to SHOULD. The proponents of MUST would take an opportunity to tighten the security, because only recently updated applications can understand the ECC key. I will go with the consensus, and if there is none, I am happy to remove these references. > Iterated and Salted S2K ... Ditto. I looks forward to see other responses. I am flexible on many of these issues in the interest of the consensus. From owner-ietf-openpgp@mail.imc.org Thu Feb 21 04:09:27 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1E528C4BA for ; Thu, 21 Feb 2008 04:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOco9fj3Y+7p for ; Thu, 21 Feb 2008 04:09:22 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 3893728C4E3 for ; Thu, 21 Feb 2008 04:09:22 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LBjYkg030461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 04:45:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LBjYoK030460; Thu, 21 Feb 2008 04:45:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LBjWPw030378 for ; Thu, 21 Feb 2008 04:45:33 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 4C48A57C01; Thu, 21 Feb 2008 12:45:01 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywHZV1cwR9Az; Thu, 21 Feb 2008 12:45:01 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id BD26957B96; Thu, 21 Feb 2008 12:45:00 +0100 (CET) Message-ID: <47BD643C.8090000@systemics.com> Date: Thu, 21 Feb 2008 12:45:00 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Andrey Jivsov CC: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> In-Reply-To: <47BD318F.5010509@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrey Jivsov wrote: > Hello Ian, thank you for your comments. Thanks for response. I have not responded in detail to all your responses, we might be better off both seeing how the rest of the group chimes in. Instead I've just amplified my points where there was some divergence. On background, when it comes to agility, I am a little bit of a nazi. To me, choice is bad, nasty, evil. This is because the choice does no good for the user, and lots and lots of bad. http://iang.org/ssl/h1_the_one_true_cipher_suite.html A few points below: >> ... "SHOULD support ECDH" >> >> what is the point of not supporting ECDH? I recommend MUST. >> > > I can support this. > > However, please note that the signature has more weight by being a tool > of certifications, i.e. self-signatures depends on it. Without support > for ECDSA we cannot have functional EC keys, while we can have sign-only > keys without ECDH. It is possible to have sign+encrypt keys with ECDSA > top key and modp ElGamal DH. Is your argument here that it is possible to do signature-only applications with just ECDSA? So this opens a window for a simplified implementation? I would not be in favour of such an optimisation for the simple reason that signature-only applications are not common nor popular (nor well built IMHO). We are here to do encryption. Signature-only concepts are something that people talked about and failed to make good on the talk. So I see this as a throw-back to the 1990s and DoJ ideas about everyone having a digital signature and the world being a better place and many other blind alleys. Didn't happen, not useful. > Also note that ECDH brings with it the need to implement KDF and key > wrapping methods, because there is no ElGamal alternative in ECC field. > ECDSA should be easier to implement than ECDH. OK, so there is more work if it is a MUST. To summarise, we are here for the encryption. Digsigs are the option, not the other way around. Therefore I recommend it as a MUST. >> ===== >> >> 6. ... "the KDF hash function MAY be any hash function defined in >> [FIPS 180-2] or its successor, except that SHA-1 MUST NOT be used." >> >> What is the point in permitting alternatives? If there is a good >> reason, I would prefer to see them enumerated for better understanding >> and for certainty. > > This is to continue good tradition of algorithm agility in OpenPGP. Ouch :) That tradition was born of a bunch of hackers and a bunch of cryptographers who sat around and hacked and drank wine and promised the world that it would be better. I know, I was one of them. OpenPGP these days is more a business area. People implement OpenPGP not because it is sexy and they like wine but because it solves problems for users and can help to sell product. In business we do not want "agility". What we want to give our users is a product that boots up and runs, securely, out of the box. There is only one mode, and it is secure. There is no place for agility in the world of business. Agility never solved anything, I posit (a debate over wine, ever there was one), and it sure created a lot of problems. If there was a chance to to do it all again, I would (and do) propose this as a rule: one true cipher suite, and that's it. > http://www.nsa.gov/ia/industry/crypto_suite_b.cfm OK, read that, thanks. I suggest only one profile is needed: "Top Secret". (I would do it as your ID 3.) >> 11.2 I don't see any point in providing both Secret and Top Secret? >> This seems like a way to create comaptibility problems for zero >> payoff. I suggest the full Top Secret as the only profile, and that's >> it. > > I think that the incremental cost to achieve Secret level of Suite-B is > insignificant, given that an application has implemented Top Secret > level. The incremental cost of "Top Secret" instead of "Secret" is truly insignificant, yes, and the same in reverse. My point is that the cost of two profiles over one profile is huge. And I'm not talking about the implementors but the users. Implement one "Top Secret" profile and be done with it. Say that OpenPGP Suite-B is rated for all traffic, and save the users a headache, for every message they must send, for all time. > This proposal offers the least choice of ECC parameters of any IETF > standard. I like it better for that :) The IETF has not been particularly successful at crypto, so I don't mind drifting a long way from their views... > At present the only MUST for OpenPGP are curves ID 1 and 2. It also says > that SHA-256 and SHA-384 are MUST. All this is in section 11.1. These > are the curves/hashed approved by Suite-B. I can accepts that we reduce > the OpenPGP profile to ID 1 and SHA-256. This will match Suite-B > "Secret" level and drop "Top Secret". No, I'd suggest the reverse: "Top Secret" and drop or downgrade "Secret". If you must implement multiple profiles, then "Top Secret" should be the MUST, and the lower one MAY. No point in encouraging people to add agility, although there is a potential market for the mobile phone people to implement a lower profile. iang From owner-ietf-openpgp@mail.imc.org Fri Feb 22 22:30:33 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519CE3A68A9 for ; Fri, 22 Feb 2008 22:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.238 X-Spam-Level: X-Spam-Status: No, score=-0.238 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYZOqx0a8AqJ for ; Fri, 22 Feb 2008 22:30:32 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8DF9F3A6873 for ; Fri, 22 Feb 2008 22:30:32 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1N6CqIu067830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 23:12:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1N6Cqqt067829; Fri, 22 Feb 2008 23:12:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1N6CoPJ067819 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 22 Feb 2008 23:12:51 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m1N6l8o5026927; Sat, 23 Feb 2008 01:47:09 -0500 Message-ID: <47BFB960.8040009@brainhub.org> Date: Fri, 22 Feb 2008 22:12:48 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Ian G Subject: Re: ECC in OpenPGP proposal References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> <47BD643C.8090000@systemics.com> In-Reply-To: <47BD643C.8090000@systemics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Ian, I appreciate your pragmatism regarding algorithm agility. There are two practical issues we need to worry about: steady increase in processing power and the difference in processing power on various hardware. A proposal with single ciphersuite cannot remain adequate indefinitely. We need ability to roll forward the strength of public key crypto as yesterday's strength declines over time. We have impressive breadth of hardware that supports ECC today: from servers to smartcards. These devices demand some breadth of choices for ECC curves: servers might want the ultimate crypto strength, while smartcards are usually trying to meet set manufacturing cost at OK performance. The document we discuss has three "ciphersuites" with two of them as MUST. As I said, I am OK with making only one MUST. I am inclined toward weaker one, since it has to be the lowest common denominator. From owner-ietf-openpgp@mail.imc.org Mon Feb 25 13:59:46 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1680128C65D for ; Mon, 25 Feb 2008 13:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUuHK7sHbTTV for ; Mon, 25 Feb 2008 13:59:45 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 63F2428C9C4 for ; Mon, 25 Feb 2008 13:54:37 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1PLXeDH067587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Feb 2008 14:33:40 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1PLXe2x067586; Mon, 25 Feb 2008 14:33:40 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1PLXbTv067578 for ; Mon, 25 Feb 2008 14:33:39 -0700 (MST) (envelope-from n.mavrogiannopoulos@gmail.com) Received: by fg-out-1718.google.com with SMTP id 22so1343256fge.26 for ; Mon, 25 Feb 2008 13:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding:sender; bh=5UGkHb8K+be9MtkrnJdmbVyzFwSiOhzAmlwy5fZdw9c=; b=P6P0vofaU0KaHT4y1IsZYDSCSGLxqHXW63NCC5tsVTRHitQA+qIWjmf/sr+yzmMQhdZXFKExZQ6+oz/OdfnRUO1ViQ7s6YGb01SFxZY1XDCcUU+fKd093OheAEl9AWJYeIGU8FYY/G6O2ShVcGoUMl1VQYgwME4JxveoB7Eob+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding:sender; b=kaHTEtip9C6nzODLeuaP+vfwzE6gyhOhbKBDc6Vcl3jXews66gcs3SBF9Ecy6W/VA4/HgXSR1MrCVEbBC0zcG6oKtLD3dwi+x2J1DMrQx7INLSyKFa6I3NhWkWgQtV55nrkAAvPLmYKrBj5dgKG0K6NRedFk9s+VbvzuimjOVm0= Received: by 10.86.68.20 with SMTP id q20mr3546122fga.59.1203975216690; Mon, 25 Feb 2008 13:33:36 -0800 (PST) Received: from ?10.100.1.196? ( [77.49.222.159]) by mx.google.com with ESMTPS id 4sm5497235fge.3.2008.02.25.13.33.34 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Feb 2008 13:33:35 -0800 (PST) Message-ID: <47C3342D.20403@gnutls.org> Date: Mon, 25 Feb 2008 23:33:33 +0200 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: tls@ietf.org CC: ietf-openpgp@imc.org Subject: updated TLS-Openpgp protocol Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've updated the experimental protocol for openpgp keys. The updated version can be found at: http://www.ietf.org/internet-drafts/draft-mavrogiannopoulos-rfc5081bis-00.txt The main addition is that it adds support for using subkeys instead of the main key of the openpgp certificate. For this reason i'd like to revive this protocol as a TLS WG item. For this to be possible there must be interest on this protocol, so if there are there people in this list supporting this protocol please express it. Of course comments are always welcome. regards, Nikos PS. Currently there is a module for the apache web server implementing the openpgp-tls protocol, available at: http://www.outoforder.cc/projects/apache/mod_gnutls/ From owner-ietf-openpgp@mail.imc.org Tue Feb 26 13:29:08 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E94A3A6C6D for ; Tue, 26 Feb 2008 13:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe3Zk4hEYfTw for ; Tue, 26 Feb 2008 13:29:07 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5B37F28C5A2 for ; Tue, 26 Feb 2008 13:29:04 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1QKxhCS097235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2008 13:59:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1QKxhV7097234; Tue, 26 Feb 2008 13:59:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1QKxfrO097227 for ; Tue, 26 Feb 2008 13:59:42 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 32371D00FFF for ; Tue, 26 Feb 2008 12:59:41 -0800 (PST) Received: from [192.168.111.151] ([66.236.113.201]) by keys.merrymeet.com (PGP Universal service); Tue, 26 Feb 2008 12:59:41 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 26 Feb 2008 12:59:41 -0800 Message-Id: <533AF4A7-B591-4775-A34F-C44E7B33B5D6@callas.org> From: Jon Callas To: OpenPGP In-Reply-To: <47BD643C.8090000@systemics.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ECC in OpenPGP proposal Date: Tue, 26 Feb 2008 12:59:39 -0800 References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> <47BD643C.8090000@systemics.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 21, 2008, at 3:45 AM, Ian G wrote: > > Andrey Jivsov wrote: >> Hello Ian, thank you for your comments. > > > Thanks for response. I have not responded in detail to all your > responses, we might be better off both seeing how the rest of the > group chimes in. Instead I've just amplified my points where there > was some divergence. > > On background, when it comes to agility, I am a little bit of a > nazi. To me, choice is bad, nasty, evil. This is because the > choice does no good for the user, and lots and lots of bad. > > http://iang.org/ssl/h1_the_one_true_cipher_suite.html Ian, I agree that there is virtue in limiting choice. However, there are a lot of people who want ECC, particularly in the context of Suite B. In the not-to-distant future, this will be a requirement. There are also other changes we will need to do on the horizon. For example, someday there will be an AHS hash algorithm set from NIST. Do we not to that, either? The argument you give is to have no choices. For the people who want more, is to use S/MIME? If so, and if that's the decision of the working group -- well, I disagree, but rough consensus is rough consensus. My company does both OpenPGP and S/MIME. If the answer to people who want Suite B is that we support it with S/ MIME, that's fine. It is also a huge disappointment, because I would like to satisfy people's ECC and Suite B needs with OpenPGP, but we can always migrate people to S/MIME who need that. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHxH29sTedWZOD3gYRAkc5AJ9LruANnjQGcXVKLMoxWHrcLqgE7wCg/Uax OQ03J48GnMLG78wcI2bpgwI= =IHhn -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Feb 27 03:12:58 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248FE3A689C for ; Wed, 27 Feb 2008 03:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uN7HYYYiOEW3 for ; Wed, 27 Feb 2008 03:12:57 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0BFB43A68BB for ; Wed, 27 Feb 2008 03:12:56 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RApL9H064216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 03:51:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1RApL7K064215; Wed, 27 Feb 2008 03:51:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RApJZp064186 for ; Wed, 27 Feb 2008 03:51:20 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 3E87357C07; Wed, 27 Feb 2008 11:50:47 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPzMJzAioKOd; Wed, 27 Feb 2008 11:50:47 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 83A9157BFC; Wed, 27 Feb 2008 11:50:46 +0100 (CET) Message-ID: <47C54085.8000009@systemics.com> Date: Wed, 27 Feb 2008 11:50:45 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Callas CC: OpenPGP Subject: Re: ECC in OpenPGP proposal References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> <47BD643C.8090000@systemics.com> <533AF4A7-B591-4775-A34F-C44E7B33B5D6@callas.org> In-Reply-To: <533AF4A7-B591-4775-A34F-C44E7B33B5D6@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Jon, Jon Callas wrote: >> http://iang.org/ssl/h1_the_one_true_cipher_suite.html > > Ian, > > I agree that there is virtue in limiting choice. However, there are a > lot of people who want ECC, particularly in the context of Suite B. In > the not-to-distant future, this will be a requirement. For the record, I agree there should be a Suite B ! It is an economic reality, a real-world requirement. When NIST/NSA speaks, that's it. The short summary of my argument is that there should one and only one MUST profile for Suite B, and that it should be the strong one / Top Secret. Other lesser profiles could be MAY, or if you let the agility nazis have their way, absent, as they have no economic use and lots and lots of costs to users. (The reason I say that 'Secret' could be a MAY is that there are complicated blah blahs in the government/security world that sometimes force suppliers to provide several modes, against good security practice.) (I'm aware of the "mobile" argument that was raised in the previous post. I would say that the mobile boys propose a "mobile" profile. That's because mobile has other aspects that aren't necessarily considered in Suite B.) > There are also other changes we will need to do on the horizon. For > example, someday there will be an AHS hash algorithm set from NIST. Do > we not to that, either? The argument you give is to have no choices. Yes. AHS is years away, if AES was any guide. AHS won't improve overall security markedly over SHA256-512 family. NIST/NSA will also have to update Suite B when AHS comes out. When all that dust settles, then is the time to reconsider it. I would plan on Suite B (one profile) now and know that in 5 or 7 years we will need to do a Suite B-bis. > For the people who want more, is to use S/MIME? If so, and if that's > the decision of the working group -- well, I disagree, but rough > consensus is rough consensus. My company does both OpenPGP and S/MIME. > If the answer to people who want Suite B is that we support it with S/ > MIME, that's fine. It is also a huge disappointment, because I would > like to satisfy people's ECC and Suite B needs with OpenPGP, but we > can always migrate people to S/MIME who need that. I think there should be a Suite B, in OpenPGP. And, to forestall the outrage, I fully expect to not get consensus on my plea to reduce agility :) We waited for 10 years to get the current OpenPGP draft, so we can wait another 10 years to find out why it took 10 years... iang From owner-ietf-openpgp@mail.imc.org Wed Feb 27 08:23:23 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2173A698E for ; Wed, 27 Feb 2008 08:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylu4EMMeCsfz for ; Wed, 27 Feb 2008 08:23:22 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0CE8D28C796 for ; Wed, 27 Feb 2008 08:22:31 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RFuc7G098883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 08:56:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1RFuc6N098882; Wed, 27 Feb 2008 08:56:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RFuTiG098862 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 27 Feb 2008 08:56:37 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1JUOm4-0006Bm-9R for ; Wed, 27 Feb 2008 17:04:52 +0100 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1JUOZS-0005rb-Cz for ; Wed, 27 Feb 2008 16:51:50 +0100 From: Werner Koch To: ietf-openpgp@imc.org Subject: ECC curve ID Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Wed, 27 Feb 2008 16:51:50 +0100 Message-ID: <87lk564ctl.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110007 (No Gnus v0.7) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, altough I am aware of the discussion about limiting the number of algorithms/profiles in a future ECC option, I am not happy with section 10 of the draft: 10. ECC curve ID The parameter ECC curve ID is an integer that defines the named curve. ID Curve description Curve name 0 Reserved 1 NIST Curve P-256 [FIPS 186-2] "NIST P256" 2 NIST Curve P-384 [FIPS 186-2] "NIST P384" 3 NIST Curve P-521 [FIPS 186-2] "NIST P521" 100-110 Private/Experimental curves 255 Reserved for future expansion Although this uses the same scheme we use all over OpenPGP, we should make future life easier for all by not using registered IDs but use other identifiers here. For registering IDs we need to informal agree on a new identifier, implement that one and then wait a couple of months/years until it gets really assigned. The private/experimental IDs are not really useful for this because they can't be used after the algorithm has been offically registered. Thus, I propose to use ASN.1 object identifiers for the curves; i.e.: 1.2.840.10045.3.1.7 NIST P-256 (Not sure about this OID) 1.3.132.0.34 NIST P-384 1.3.132.0.35 NIST P-521 and declare some of them as MUST be implemented if ECC is implemented. Having object identifiers allows us to add other curves. Well, you will now say, we should limit that to the NIST defined curves. May I now remind you that there other national standard bodies which require the use of other curves. In Europe we have a tendency to prefer our own algorithms and sometimes it is a hard requirement not rely on foreign crypto standard (cf. the use of RIPE-MD160). I know that interoperability will be limited but as long as other curves are declared optional this is not a major issue. S/MIME users will suffer from the same problem. I have not yet looked at the preference system and how to integrate curve names into it. I doubt that it is really required because we don't have preference for key length eithers. Shalom-Salam, Werner p.s. I don't think that the notion of "Top Secret" And "Secret" belongs into an RFC. I could also ask to add "VS/NfD", which is a secrecy level used in Germany. -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From owner-ietf-openpgp@mail.imc.org Wed Feb 27 11:26:55 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01F63A6C6B for ; Wed, 27 Feb 2008 11:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.243 X-Spam-Level: X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLz1krF3gWbB for ; Wed, 27 Feb 2008 11:26:52 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E60633A6E1D for ; Wed, 27 Feb 2008 11:26:51 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RIw8Gf021017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 11:58:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1RIw85T021016; Wed, 27 Feb 2008 11:58:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.infoseccorp.com (h-66-166-172-3.chcgilgm.covad.net [66.166.172.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RIw7UM021010 for ; Wed, 27 Feb 2008 11:58:08 -0700 (MST) (envelope-from markowitz@infoseccorp.com) Message-Id: <200802271858.m1RIw7UM021010@balder-227.proper.com> X-AuthUser: mjm@infoseccorp.com Received: from mjmdt.infoseccorp.com ([127.0.0.1]:54885) by infoseccorp.com with [XMail 1.21 ESMTP Server] id for from ; Wed, 27 Feb 2008 12:43:45 -0600 Received: from 192.168.0.65 ([192.168.0.65] helo=mjmdt.infoseccorp.com) by ASSP-nospam; 27 Feb 2008 12:43:45 -0600 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Feb 2008 12:54:39 -0600 To: Werner Koch From: Mike Markowitz Subject: Re: ECC curve ID Cc: ietf-openpgp@imc.org In-Reply-To: <87lk564ctl.fsf@wheatstone.g10code.de> References: <87lk564ctl.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-2AF82ACA Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 09:51 AM 2/27/2008, Werner Koch wrote: > 1.2.840.10045.3.1.7 NIST P-256 (Not sure about this OID) Werner: We think that this is correct -- at least it's what we've been using for quite some time and have received no complaints to date (and have witnessed no conflicts between our code and everything we've been able to access for compatibility testing). Microsoft agrees (and our P-256 ECC certs are accepted by Vista IE): "XCN_OID_ECC_CURVE_P256 (1.2.840.10045.3.1.7) " http://msdn2.microsoft.com/en-us/library/aa379070(VS.85).aspx Also, if you need an official NIST reference, SP 800-78-1 lists this OID on page 9 (table 3-6): http://csrc.nist.gov/publications/nistpubs/800-78-1/SP-800-78-1_final2.pdf In hex, it's "0x2A8648CE3D030107." Cheers, Michael ========== Michael J. Markowitz, Ph.D. Email: markowitz@infoseccorp.com Vice President R&D Voice: 708-445-1704 (Oak Park) Information Security Corporation 847-405-0500 (Deerfield) 1011 Lake Street, Suite 425 Fax: 708-445-9705 Oak Park, IL 60301 WWW: http://www.infoseccorp.com From owner-ietf-openpgp@mail.imc.org Wed Feb 27 15:06:27 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B613A6AF5 for ; Wed, 27 Feb 2008 15:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.823 X-Spam-Level: X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfeK502Rwbsg for ; Wed, 27 Feb 2008 15:06:21 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D14C93A6CD6 for ; Wed, 27 Feb 2008 15:06:07 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RMZuM0037365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 15:35:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1RMZuDD037364; Wed, 27 Feb 2008 15:35:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RMZtOd037357 for ; Wed, 27 Feb 2008 15:35:55 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id C91A4D0A79B for ; Wed, 27 Feb 2008 14:35:54 -0800 (PST) Received: from titania.pgp.com ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Wed, 27 Feb 2008 14:35:54 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 27 Feb 2008 14:35:54 -0800 Cc: OpenPGP Message-Id: From: Jon Callas To: Ian G In-Reply-To: <47C54085.8000009@systemics.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ECC in OpenPGP proposal Date: Wed, 27 Feb 2008 14:35:53 -0800 References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> <47BD643C.8090000@systemics.com> <533AF4A7-B591-4775-A34F-C44E7B33B5D6@callas.org> <47C54085.8000009@systemics.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > For the record, I agree there should be a Suite B ! It is an > economic reality, a real-world requirement. When NIST/NSA speaks, > that's it. > > The short summary of my argument is that there should one and only > one MUST profile for Suite B, and that it should be the strong one / > Top Secret. > > Other lesser profiles could be MAY, or if you let the agility nazis > have their way, absent, as they have no economic use and lots and > lots of costs to users. > > (The reason I say that 'Secret' could be a MAY is that there are > complicated blah blahs in the government/security world that > sometimes force suppliers to provide several modes, against good > security practice.) > > (I'm aware of the "mobile" argument that was raised in the previous > post. I would say that the mobile boys propose a "mobile" profile. > That's because mobile has other aspects that aren't necessarily > considered in Suite B.) Excellent. For a number of reasons, ECC/Suite B is going to be a MAY. You will be permitted to make an OpenPGP application that doesn't do it. (Presently, our MUST algorithms are DSA, Elgamal, 3DES, and SHA1. Changing MUSTs is a can of worms and I don't think any IETF standard is handling it well.) Like many things coming out of NIST, they come in three flavors, 128- bit security, 192-bit, and 256-bit. I have no objection myself to canning the 192-bit ones. I'm of the opinion that if you need more than 128, you should go to 256. In many cases, there isn't even a performance win on the 192-bit system. However, there are very good arguments for doing 192-bit as well, and one of those arguments is that it may be easier to do the 192-bit versions than to explain why you didn't. I don't see how we can simplify past dropping 192. > > > >> There are also other changes we will need to do on the horizon. >> For example, someday there will be an AHS hash algorithm set from >> NIST. Do we not to that, either? The argument you give is to have >> no choices. > > > Yes. AHS is years away, if AES was any guide. AHS won't improve > overall security markedly over SHA256-512 family. NIST/NSA will also > have to update Suite B when AHS comes out. > > When all that dust settles, then is the time to reconsider it. I > would plan on Suite B (one profile) now and know that in 5 or 7 > years we will need to do a Suite B-bis. The NIST schedule has a decision made in 2012. The submissions must be made this August. > > > >> For the people who want more, is to use S/MIME? If so, and if >> that's the decision of the working group -- well, I disagree, but >> rough consensus is rough consensus. My company does both OpenPGP >> and S/MIME. If the answer to people who want Suite B is that we >> support it with S/ MIME, that's fine. It is also a huge >> disappointment, because I would like to satisfy people's ECC and >> Suite B needs with OpenPGP, but we can always migrate people to S/ >> MIME who need that. > > > I think there should be a Suite B, in OpenPGP. > > And, to forestall the outrage, I fully expect to not get consensus > on my plea to reduce agility :) We waited for 10 years to get the > current OpenPGP draft, so we can wait another 10 years to find out > why it took 10 years... Cool. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHxeXKsTedWZOD3gYRAnhSAJ92jiokj+2HJdnY03yFT2t9O5PYIwCgiJBo 0pREjuhus2l54lTJL14DeIU= =Zlos -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Feb 27 15:46:55 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7586B3A6C60 for ; Wed, 27 Feb 2008 15:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v95oIrlBYM6N for ; Wed, 27 Feb 2008 15:46:54 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 65CC83A6B67 for ; Wed, 27 Feb 2008 15:46:54 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RNVKA6042938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 16:31:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1RNVKka042937; Wed, 27 Feb 2008 16:31:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RNVIhG042931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Feb 2008 16:31:19 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m1RNVDDo007507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 15:31:14 -0800 Message-ID: <47C5F2BD.6030003@brainhub.org> Date: Wed, 27 Feb 2008 15:31:09 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Werner Koch Subject: Re: ECC curve ID References: <87lk564ctl.fsf@wheatstone.g10code.de> In-Reply-To: <87lk564ctl.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Werner, thank you for your comments. Werner Koch wrote: > Hi, > > altough I am aware of the discussion about limiting the number of > algorithms/profiles in a future ECC option, I am not happy with section > 10 of the draft: > > 10. ECC curve ID > > The parameter ECC curve ID is an integer that defines the named > curve. > > ID Curve description Curve name > 0 Reserved > 1 NIST Curve P-256 [FIPS 186-2] "NIST P256" > 2 NIST Curve P-384 [FIPS 186-2] "NIST P384" > 3 NIST Curve P-521 [FIPS 186-2] "NIST P521" > 100-110 Private/Experimental curves > 255 Reserved for future expansion > > > Although this uses the same scheme we use all over OpenPGP, we should > make future life easier for all by not using registered IDs but use > other identifiers here. For registering IDs we need to informal agree > on a new identifier, implement that one and then wait a couple of > months/years until it gets really assigned. The private/experimental > IDs are not really useful for this because they can't be used after the > algorithm has been offically registered. > > Thus, I propose to use ASN.1 object identifiers for the curves; i.e.: > > 1.2.840.10045.3.1.7 NIST P-256 (Not sure about this OID) > 1.3.132.0.34 NIST P-384 > 1.3.132.0.35 NIST P-521 > > and declare some of them as MUST be implemented if ECC is implemented. > > Having object identifiers allows us to add other curves. I think that support for arbitrary curves has some merits. On the other hand, these benefits must be compared against possibility of ever getting the ECC support in OpenPGP applications. OpenPGP application is not required to understand ASN.1 / DER. Essentially, this proposal means that we are replacing one-byte ID by multi-byte ID. Would it be good to agree on new curve anyway and how it fits relative strength, what are legal issues, what are implementation issues, which MAY/SHOULD keyword it will be carrying, and so on? If we cannot agree on this on the list, it is unlikely that applications will be able to interoperate using curves we disagree on. The freedom will be detrimental to interoperability. (Conversely, the small subset will allow greater speed optimizations.) While I think we need to start from "core" version of the standard and cut options, perhaps in the future we need to allow named curves in companion proposal or in the next version of the document. For example, ID 254 might mean that there is an ASN.1 structure referencing the curve, inserted somewhere into the sequence of currently defined fields. (If you find it worthwhile, I can be more specific in the draft about the extension path for future curves.) Besides, I thought that once the group agrees on an ID, the IETF process shouldn't take longer than a quarter. > Well, you will > now say, we should limit that to the NIST defined curves. May I now > remind you that there other national standard bodies which require the > use of other curves. In Europe we have a tendency to prefer our own > algorithms and sometimes it is a hard requirement not rely on foreign > crypto standard (cf. the use of RIPE-MD160). > Please note that proposed curves are a part of major international standards: ANSI X9.62 (multiple updates) and industry standard SECG, among others. It is a part of any ECC-related IETF standard. They come with Windows Vista, Linux (openssl), etc. Which ECC standard *excludes* the curves specified in the proposal? I claim that the proposed subset of curves is the most widely supported subset of any standard. I suggest that in the interest of adoption we start from core set and once we deployed the applications that interoperate, we start adding marginal improvements. > I know that interoperability will be limited but as long as other curves > are declared optional this is not a major issue. S/MIME users will > suffer from the same problem. > I note that this seems exactly opposite to what Ian wants, so I propose the idea of core set + extensions as a compromise... > I have not yet looked at the preference system and how to integrate > curve names into it. I doubt that it is really required because we > don't have preference for key length eithers. > This is where freedom will make interoperability problematic. It is hard to come up with preferences that control the structure of self-signatures, because preferences themselves are stored in self-signatures. The only solution to this chicken-and-egg problem is to establish small core set of curves, the two ones I proposed in the draft, and focus on supporting these curves first. > Shalom-Salam, > > Werner > > > > p.s. > I don't think that the notion of "Top Secret" And "Secret" belongs into > an RFC. I could also ask to add "VS/NfD", which is a secrecy level used > in Germany This seems reasonable. If any of 3 curves in the proposal satisfy another standard that the group thinks worth mentioning, such a standard can be noted in the spec. (These references to non-OpenPGP profiles are informative, BTW) From owner-ietf-openpgp@mail.imc.org Thu Feb 28 02:30:25 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F095C3A6BE7 for ; Thu, 28 Feb 2008 02:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1UPunEDmI3f for ; Thu, 28 Feb 2008 02:30:25 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2E8AB3A6B95 for ; Thu, 28 Feb 2008 02:30:25 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SA54PY097403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 03:05:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1SA54jL097402; Thu, 28 Feb 2008 03:05:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SA4uxI097361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Feb 2008 03:05:02 -0700 (MST) (envelope-from simon@josefsson.org) Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1SA4ZFw004140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 11:04:36 +0100 From: Simon Josefsson To: Andrey Jivsov Cc: ietf-openpgp@imc.org, Werner Koch Subject: Re: ECC curve ID References: <87lk564ctl.fsf@wheatstone.g10code.de> <47C5F2BD.6030003@brainhub.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:080228:wk@gnupg.org::ZTyy7bQTQevUZce3:1HMT X-Hashcash: 1:22:080228:openpgp@brainhub.org::2nWE8ieGVJsd6nn3:ANDr X-Hashcash: 1:22:080228:ietf-openpgp@imc.org::naXsen0B4ShoQns7:jUxc Date: Thu, 28 Feb 2008 11:04:35 +0100 In-Reply-To: <47C5F2BD.6030003@brainhub.org> (Andrey Jivsov's message of "Wed, 27 Feb 2008 15:31:09 -0800") Message-ID: <87ejax2y8c.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrey Jivsov writes: > OpenPGP application is not required to understand ASN.1 / > DER. You don't need to support ASN.1 or DER to support OIDs as identities for curves. Just use memcpy or memcmp with a fixed string. > > Besides, I thought that once the group agrees on an ID, the IETF > process shouldn't take longer than a quarter. I think that is quite optimistic. Further, the problem with the process is that you don't get the actual ID number until after that process has finished. This seriously delay deployment and early testing. If IANA could reserve numbers early for experiments, this wouldn't have been such a big problem. Finally, I'd like to +1 Werner's suggestion to use OID's. /Simon From owner-ietf-openpgp@mail.imc.org Thu Feb 28 07:03:58 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E453728C69E for ; Thu, 28 Feb 2008 07:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0jMQP8RSHjO for ; Thu, 28 Feb 2008 07:03:52 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 3C12128C679 for ; Thu, 28 Feb 2008 07:03:46 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SEca1r026806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 07:38:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1SEcatI026805; Thu, 28 Feb 2008 07:38:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SEcYdf026787 for ; Thu, 28 Feb 2008 07:38:35 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id C160857B17; Thu, 28 Feb 2008 15:38:20 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfpIOj5Y+WmO; Thu, 28 Feb 2008 15:38:20 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 772EF57B0F; Thu, 28 Feb 2008 15:38:20 +0100 (CET) Message-ID: <47C6C75C.3040307@systemics.com> Date: Thu, 28 Feb 2008 15:38:20 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Callas CC: OpenPGP Subject: Re: ECC in OpenPGP proposal References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> <47BD643C.8090000@systemics.com> <533AF4A7-B591-4775-A34F-C44E7B33B5D6@callas.org> <47C54085.8000009@systemics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > -----BEGIN PGP SIGNED MESSAGE----- >> The short summary of my argument is that there should one and only >> one MUST profile for Suite B, and that it should be the strong one / >> Top Secret. > For a number of reasons, ECC/Suite B is going to be a MAY. You will be > permitted to make an OpenPGP application that doesn't do it. Hmmm... you raise an interesting point. I had thought that this was going to be a new document, and as it is not referred to in the existing core RFC, then ECC/Suite B was going to be a MAY by definition. Within that new (MAY) document, there would be several choices for MUST, SHOULD, MAY, etc. Or so I thought ... but I'm not fully aware of how these things interact. > Like many things coming out of NIST, they come in three flavors, 128- > bit security, 192-bit, and 256-bit. I have no objection myself to > canning the 192-bit ones. I'm of the opinion that if you need more > than 128, you should go to 256. In many cases, there isn't even a > performance win on the 192-bit system. > > However, there are very good arguments for doing 192-bit as well, and > one of those arguments is that it may be easier to do the 192-bit > versions than to explain why you didn't. In the sense that it exists, and people think it has to exist, yes. "why go against the flow, it's only security after all..." Yes, I agree. In that market, that is the pressure you will get. > I don't see how we can simplify past dropping 192. OK, if you are happy to carry on this discussion ... what are the reasons for including the 128-bit profile? (I know I'm exceeding my noise quota here .. but I hate the thought that we are happily reducing overall security by providing users too many options for them to achieve compatibility with each other.) iang From owner-ietf-openpgp@mail.imc.org Thu Feb 28 11:29:33 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E914C3A6F2D for ; Thu, 28 Feb 2008 11:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id talMHqHG4BFB for ; Thu, 28 Feb 2008 11:29:28 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0CF683A67F2 for ; Thu, 28 Feb 2008 11:29:27 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SJ2KHx055134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 12:02:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1SJ2KYQ055133; Thu, 28 Feb 2008 12:02:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SJ2J3K055127 for ; Thu, 28 Feb 2008 12:02:19 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so2984872wff.28 for ; Thu, 28 Feb 2008 11:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=tNrRcOricLqBSfJ0hhRKhKSW6twoLdFazL/yL/CZLsY=; b=CwlLsb17t7NYAcKdmzVBFQdrYyDDUwqc1EzAlZPLC+b4bFSCj4CrVPH1KMtZngthYV+/zhcjrzUbPdTnWaubz+LzHE6vCipTuUyNRYU1rl+2PFU/TZNB9sFW8tFE0ZFWBsHhqSIYHF/G87Yx3L5qKJJYl+RAhIZs/ifojqnNJJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=n9WGCiqPuMioT7Twmz7xmHAbBu+kDbEMSzZrHMsNq1teEr7wfMAZCpvSn3tuunydlpnZdVysXJ9AeSmQp6SjzAiglDi3DLYx+VlL2Rf1lma8wgho18gBikCTYW0UbtwNiB5T/ebCJOUfh1GmffefWh0HYJZ4VgzBkVumcuoaPLY= Received: by 10.142.212.19 with SMTP id k19mr1622241wfg.86.1204225339016; Thu, 28 Feb 2008 11:02:19 -0800 (PST) Received: by 10.143.172.3 with HTTP; Thu, 28 Feb 2008 11:02:18 -0800 (PST) Message-ID: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> Date: Thu, 28 Feb 2008 19:02:18 +0000 From: "David Crick" To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian wrote: > Hmmm... you raise an interesting point. I had thought that this > was going to be a new document, and as it is not referred to in > the existing core RFC, then ECC/Suite B was going to be a MAY by > definition. > > Within that new (MAY) document, there would be several choices > for MUST, SHOULD, MAY, etc. > > Or so I thought ... but I'm not fully aware of how these things interact. and further: > > I don't see how we can simplify past dropping 192. > > > OK, if you are happy to carry on this discussion ... what are the > reasons for including the 128-bit profile? assuming the may -> whatever chain above holds, what about: MAY implement ECC o MUST implement AES256-SHA384-384ECC o SHOULD implement AES128-SHA256-256ECC o MAY implement AES256-SHA512-521ECC [and/or any other combinations, but these might be "unbalanced"] we currently *have* 3072 RSA/DSA strength (or 4096 RSA/ElG for those wanting a bit of extra headroom); higher size DSA isn't in any [e.g. NIST] standard, and >=4K RSA/ElG public key ops begin to take a noticeable time even on my desktop (so while 7K RSA keys are a simple source-change in GnuPG, ECC would definitely make sense to achieve a balanced crypto system at this strength). Now, for "embedded"/constrained systems there may only be the chance to do AES128-SHA256-256ECC, which would conflict with my "SHOULD" suggestion above. So there would probably be scope for the AES128 set to be a SHOULD as well, or even the MUST instead. To be honest I think having AES256-SHA384-384ECC *and* AES128-SHA256-256ECC in *some* form of MUST/SHOULD *is* desirable: it covers both the two "Suite B" available balanced set of algorithms, which may be important to some people (and is certainly more "marketable" anyway). I wouldn't personally "protest" if AES256-SHA512-521ECC were also included, but I think anything more than these three balanced sets is "silly." From owner-ietf-openpgp@mail.imc.org Thu Feb 28 15:35:27 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDF728C29B for ; Thu, 28 Feb 2008 15:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLGJq-ArVv54 for ; Thu, 28 Feb 2008 15:35:22 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id F145D28C6C8 for ; Thu, 28 Feb 2008 15:35:21 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SNEE2B078692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 16:14:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1SNEEaa078691; Thu, 28 Feb 2008 16:14:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SNEC4R078685 for ; Thu, 28 Feb 2008 16:14:13 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 980FCD126D9 for ; Thu, 28 Feb 2008 15:14:12 -0800 (PST) Received: from titania.pgp.com ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Thu, 28 Feb 2008 15:14:12 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 28 Feb 2008 15:14:12 -0800 Cc: OpenPGP Message-Id: <04C6B64C-70D9-4C8B-A37C-2D353A6E2E0D@callas.org> From: Jon Callas To: Ian G In-Reply-To: <47C6C75C.3040307@systemics.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ECC in OpenPGP proposal Date: Thu, 28 Feb 2008 15:14:10 -0800 References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> <47BD643C.8090000@systemics.com> <533AF4A7-B591-4775-A34F-C44E7B33B5D6@callas.org> <47C54085.8000009@systemics.com> <47C6C75C.3040307@systemics.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Hmmm... you raise an interesting point. I had thought that this was > going to be a new document, and as it is not referred to in the > existing core RFC, then ECC/Suite B was going to be a MAY by > definition. > > Within that new (MAY) document, there would be several choices for > MUST, SHOULD, MAY, etc. > > Or so I thought ... but I'm not fully aware of how these things > interact. > At least in theory, we could make ECC be the MUST. But as I said before, there really isn't a good process to change those things in the IETF. > OK, if you are happy to carry on this discussion ... what are the > reasons for including the 128-bit profile? There's nothing wrong 128-bit security. It's also faster. It competes against 3Kbit integer keys. If you're doing smart cards, HSMs, mobile phones, etc. they will likely need 128-bit security for speed reasons. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHx0BEsTedWZOD3gYRAkmmAJ9eDHz2s6TiLS2rbb4kvwSAFEVDGgCgta1a cc+w9w+IP3KwoAfp7hBfP7c= =txKh -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Feb 29 01:32:21 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9172628C930 for ; Fri, 29 Feb 2008 01:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVgqqFPMyk8b for ; Fri, 29 Feb 2008 01:32:16 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 1E8DA28C681 for ; Fri, 29 Feb 2008 01:32:16 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1T98ZtW022374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 02:08:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1T98Z20022373; Fri, 29 Feb 2008 02:08:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1T98Waa022364 for ; Fri, 29 Feb 2008 02:08:35 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 3FFBED15EAD for ; Fri, 29 Feb 2008 01:08:32 -0800 (PST) Received: from titania.merrymeet.com ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Fri, 29 Feb 2008 01:08:32 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 29 Feb 2008 01:08:32 -0800 Cc: ietf-openpgp@imc.org Message-Id: From: Jon Callas To: David Crick In-Reply-To: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ECC in OpenPGP proposal Date: Fri, 29 Feb 2008 01:08:31 -0800 References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 28, 2008, at 11:02 AM, David Crick wrote: > > Ian wrote: > >> Hmmm... you raise an interesting point. I had thought that this >> was going to be a new document, and as it is not referred to in >> the existing core RFC, then ECC/Suite B was going to be a MAY by >> definition. >> >> Within that new (MAY) document, there would be several choices >> for MUST, SHOULD, MAY, etc. >> >> Or so I thought ... but I'm not fully aware of how these things >> interact. > > and further: > >>> I don't see how we can simplify past dropping 192. >> >> >> OK, if you are happy to carry on this discussion ... what are the >> reasons for including the 128-bit profile? > > assuming the may -> whatever chain above holds, what about: > > MAY implement ECC > o MUST implement AES256-SHA384-384ECC > o SHOULD implement AES128-SHA256-256ECC > o MAY implement AES256-SHA512-521ECC > [and/or any other combinations, but these might be "unbalanced"] I think you have the polarity wrong. AES256-SHA512-521ECC is desirable because it's the most secure. AES128-SHA256-256ECC is desirable because it's fast, and it's what is most likely to be in constrained environments. AES256-SHA384-384ECC (which I think should actually be AES192- SHA384-384ECC), is slow and not as secure. It's neither fish nor fowl. However, for completeness, eliminating it is likely not wise. As much as I sneer at NIST's fondness for 192-bit security (especially when it runs at the same speed as 256-bit security), it's foolish to eliminate it from the spec. That's the sort of thing that might bite us in the ass years from now. The probability that I'll get a cogent, enlightening explanation of why 192-bit security is a Good Thing is directly proportional to the probability of our excluding it. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHx8uQsTedWZOD3gYRAjcgAKCHpO1SjUt+hb8JPV7asxSyJ2uLNgCglqr5 ngJIWmCOG4fzItYg6AnMylQ= =Kun2 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Feb 29 05:08:20 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF6F28C0F6 for ; Fri, 29 Feb 2008 05:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYccePqlK6PY for ; Fri, 29 Feb 2008 05:08:16 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2755D3A6C0C for ; Fri, 29 Feb 2008 05:08:16 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TChP6v042456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 05:43:26 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1TChPe1042455; Fri, 29 Feb 2008 05:43:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TChN9r042446 for ; Fri, 29 Feb 2008 05:43:25 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id E6CAF57B0B; Fri, 29 Feb 2008 13:43:22 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCoKhbZsLqY5; Fri, 29 Feb 2008 13:43:22 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 8CAB657AF8; Fri, 29 Feb 2008 13:43:22 +0100 (CET) Message-ID: <47C7FDEA.5070103@systemics.com> Date: Fri, 29 Feb 2008 13:43:22 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Jon Callas , David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > -----BEGIN PGP SIGNED MESSAGE----- >>> OK, if you are happy to carry on this discussion ... what are the >>> reasons for including the 128-bit profile? >> assuming the may -> whatever chain above holds, what about: >> >> MAY implement ECC >> o MUST implement AES256-SHA384-384ECC >> o SHOULD implement AES128-SHA256-256ECC >> o MAY implement AES256-SHA512-521ECC >> [and/or any other combinations, but these might be "unbalanced"] > > I think you have the polarity wrong. > > AES256-SHA512-521ECC is desirable because it's the most secure. > > AES128-SHA256-256ECC is desirable because it's fast, and it's what is > most likely to be in constrained environments. > > AES256-SHA384-384ECC (which I think should actually be AES192- > SHA384-384ECC), is slow and not as secure. It's neither fish nor fowl. > > However, for completeness, eliminating it is likely not wise. As much > as I sneer at NIST's fondness for 192-bit security (especially when it > runs at the same speed as 256-bit security), it's foolish to eliminate > it from the spec. That's the sort of thing that might bite us in the > ass years from now. The probability that I'll get a cogent, > enlightening explanation of why 192-bit security is a Good Thing is > directly proportional to the probability of our excluding it. OK, so Jon argues that the market forces will push a full set of profiles, regardless of the damage done to security. OK, I accept that, it's a devil's choice. Do we work with the "best practices" mafia or do we try and meet the needs of the real users who just want the darned stuff to boot up and work? If there are going to be 2 profiles, then there may as well be all 3. There is no real saving between 2 and 3. So the remaining question would be, what are the recommendations? If we are including the "mobile" profile of 128, then it makes no sense to me to say that any other profile is a MUST ... because then the mobile guys will have to implement the stronger ones to get the gold star. Which they won't use or want because it's too slow. Which would mean that only the mobile profile is a MUST and the other two are lesser? So I see: MAY implement ECC o MUST implement AES128-SHA256-256ECC (mobile) o SHOULD implement AES256-SHA512-521ECC (strong) o MAY implement AES256-SHA384-384ECC (pretty) iang PS: mobile above includes smartcards and HSMs, it's just a label for those who want "fast" not pareto-complete. From owner-ietf-openpgp@mail.imc.org Fri Feb 29 07:53:23 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3552028C1C5 for ; Fri, 29 Feb 2008 07:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koX9K0FzMsiz for ; Fri, 29 Feb 2008 07:53:22 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id AC8803A6950 for ; Fri, 29 Feb 2008 07:52:25 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TFVWcV059826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 08:31:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1TFVWd3059825; Fri, 29 Feb 2008 08:31:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TFVUaP059817 for ; Fri, 29 Feb 2008 08:31:31 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id C776457B0F; Fri, 29 Feb 2008 16:31:22 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJZuB2t6MCQG; Fri, 29 Feb 2008 16:31:22 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 7E5B357B0B; Fri, 29 Feb 2008 16:31:22 +0100 (CET) Message-ID: <47C82549.8080703@systemics.com> Date: Fri, 29 Feb 2008 16:31:21 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: David Crick CC: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> In-Reply-To: <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: > How hard-coded do we want/need to make the[se] cipher-hash-curve > combinations? For Suite B compatibility/marketability we need > them "fixed" (especially in light of pointing out the higher > relative MAY cipher size) and the hash fixed as SHA2 (as opposed > to, say, a hypothetical Whirlpool; SHA3 could be added later). Me: hardcoded. Nobody ever showed that SHA wasn't good enough for the job * and NIST/NSA is happy with it, until 2012. (I don't expect everyone to agree though :) I noticed that there is this discussion to use Suite B for other purposes (variously, ECC is cool, speed, Euro-profiles, mobile, smart cards, HSMs, ... etc). That is bad, to my mind. This is a profile proposed for Suite B and that's what it should do: Suite B. If the Europeans want to propose a EuroSuite, let them. Let's not jump on the bandwagon and make the profile all-things-for-all-humanity. iang * to a 99% confidence level. SHA0 was the 1%. The rest is crypto-academic stuff which shouldn't impact actual use. From owner-ietf-openpgp@mail.imc.org Fri Feb 29 08:40:10 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5C628C349 for ; Fri, 29 Feb 2008 08:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWeWzwd4Vtq1 for ; Fri, 29 Feb 2008 08:40:04 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B7AAF3A6926 for ; Fri, 29 Feb 2008 08:40:04 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TGKd2A065193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 09:20:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1TGKdRX065190; Fri, 29 Feb 2008 09:20:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TGKc7k065176 for ; Fri, 29 Feb 2008 09:20:38 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so3661782wff.28 for ; Fri, 29 Feb 2008 08:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=DeCEPKVRZlzLjpEDGwuRhga3d5GrKFpZ1Si/hbc9Qvc=; b=EfHQxSw39M1VrVJZWBeZgpgRk+Vo5K5MbHYO3VlQFydNpZoT8tpxKHm5wYsmd10uW+slQ/RS6UKEtMPeebHMNWi6xXyQGC05j8jPHFYDWor7LHQpyxlF+UZaE6st688ho1PJ+76UcSJ6OfYsCjKThqKQqFuHnsHHTvUnOR2pHYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ns0S7UnPoOFbAx07+/yvcVfHP5R74QwfhqhYtVnn4J4t0r5BpeIGRrIOpKLTw2tqlaTVTIqNSoGhpw77xGUSKHszHtdnyshSsAF81rceP+lEOlvYRWZjcbrBa94EBWQZAuEk4WFQ8lapaLAu3ek5ugwkozNtNXbW/VrLjJh01Hw= Received: by 10.143.37.20 with SMTP id p20mr7161555wfj.236.1204302038122; Fri, 29 Feb 2008 08:20:38 -0800 (PST) Received: by 10.143.172.3 with HTTP; Fri, 29 Feb 2008 08:20:38 -0800 (PST) Message-ID: <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> Date: Fri, 29 Feb 2008 16:20:38 +0000 From: "David Crick" To: "Ian G" Subject: Re: ECC in OpenPGP proposal Cc: ietf-openpgp@imc.org In-Reply-To: <47C82549.8080703@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2/29/08, Ian G wrote: > David Crick wrote: > > > How hard-coded do we want/need to make the[se] cipher-hash-curve > > combinations? For Suite B compatibility/marketability we need > > them "fixed" (especially in light of pointing out the higher > > relative MAY cipher size) and the hash fixed as SHA2 (as opposed > > to, say, a hypothetical Whirlpool; SHA3 could be added later). > > Me: hardcoded. Nobody ever showed that SHA wasn't good > enough for the job and NIST/NSA is happy with it, until 2012. ... > If the Europeans want to propose a EuroSuite, let them. > Let's not jump on the bandwagon and make the profile > all-things-for-all-humanity. I'm 1000% happy with fixing the curve-hash sizes *and* only SHA2. *I* would also be 100% happy fixing the cipher sizes with only AES. *However*, are we ( ) willing to insist that for OpenPGP ECC you *absolutely* MUST use AES *and* at these specific sizes for the corresponding algorithm sets below? MAY implement ECC o MUST implement AES128-SHA256-256ECC o SHOULD implement AES256-SHA512-521ECC o MAY implement AES256-SHA384-384ECC Aside from the side-effect of 4880 (and predecessor's) 3DES MUST, this would be the first time that we are mandating specific cipher usage. We're not saying "SHOULD" (and WARN the user if they do otherwise), we're saying MUST. (A watered-down compromise would be to say "for Suite B compliance, AES MUST be used," just as we've said for DSS compliance SHA must be used [and at certain sizes]). From owner-ietf-openpgp@mail.imc.org Fri Feb 29 13:40:53 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D7228C87F for ; Fri, 29 Feb 2008 13:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3W7FMtj8XMM for ; Fri, 29 Feb 2008 13:40:47 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 9B5B93A6E45 for ; Fri, 29 Feb 2008 13:40:47 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TLMIgO098397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 14:22:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1TLMIA2098396; Fri, 29 Feb 2008 14:22:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TLMGJv098388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Feb 2008 14:22:17 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m1TLMDe7008292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 13:22:13 -0800 Message-ID: <47C8777F.2020702@brainhub.org> Date: Fri, 29 Feb 2008 13:22:07 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick , Ian G Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> In-Reply-To: <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think that the scope of ECC document is not to define the perfect combination of symmetric algorithm/hash/public key algorithm. The issue of relative strength applies equally well to RFC 4880. We should discuss the relative strength issue and how the ECC fits into this and we can recommend certain combinations, but should avoid mandating exact permutations. These combinations are not permanent and subject to opinions, mostly because of public key component. Balanced today AES128/SHA256/EC P-256 may need to be AES128/SHA256/EC P-384 in the future. Let's also not forget about the issue of encoding to multiple recipients. Remember that the message gets encoded to a single symmetric key. "Walking up" from this algorithm, which may be other than AES (in fact, the 3DES is the fallback default), we may legitimately end up with pairs of symmetric/public tupples that don't match the "perfect" profile. In other words, if we have two recipient keys: ECDH public key symm. alg -------------------------------------------- P-256 AES-128, CAST5 P-521 AES-256, AES-128 RFC 4880 mandates that we use AES-128/P-521 for the second recipient. In some cases we cannot "insist" on using a particular algorithm. I think the best way to add longevity to this document is to pick up a few core permutations and then make its *components* MUST. In particular, there seem to be consensus on Curve ID 1 as MUST. I also have curve ID 2 as MUST for OpenPGP, which gives some room to shuffle the tupple. I also put SHA256 and SHA384 as MUST. I am OK with relaxing this to Curve ID 2 and SHA384 as SHOULD for OpenPGP profile. It is SHOULD and not MAY because of multiple recipient issue (if it is MAY to generate P-384, it is effectively MUST to be able to encode to it). David Crick wrote: > On 2/29/08, Ian G wrote: > >> David Crick wrote: >> >> > How hard-coded do we want/need to make the[se] cipher-hash-curve >> > combinations? For Suite B compatibility/marketability we need >> > them "fixed" (especially in light of pointing out the higher >> > relative MAY cipher size) and the hash fixed as SHA2 (as opposed >> > to, say, a hypothetical Whirlpool; SHA3 could be added later). >> >> Me: hardcoded. Nobody ever showed that SHA wasn't good >> enough for the job and NIST/NSA is happy with it, until 2012. >> > ... > >> If the Europeans want to propose a EuroSuite, let them. >> Let's not jump on the bandwagon and make the profile >> all-things-for-all-humanity. >> > > I'm 1000% happy with fixing the curve-hash sizes *and* only SHA2. > > *I* would also be 100% happy fixing the cipher sizes with only AES. > > *However*, are we ( ) willing to > insist that for OpenPGP ECC you *absolutely* MUST use AES *and* > at these specific sizes for the corresponding algorithm sets below? > > MAY implement ECC > o MUST implement AES128-SHA256-256ECC > o SHOULD implement AES256-SHA512-521ECC > o MAY implement AES256-SHA384-384ECC > > > Aside from the side-effect of 4880 (and predecessor's) 3DES MUST, > this would be the first time that we are mandating specific cipher > usage. We're not saying "SHOULD" (and WARN the user if they do > otherwise), we're saying MUST. (A watered-down compromise would > be to say "for Suite B compliance, AES MUST be used," just as we've > said for DSS compliance SHA must be used [and at certain sizes]). > From owner-ietf-openpgp@mail.imc.org Fri Feb 29 14:58:35 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB63D3A6D8E for ; Fri, 29 Feb 2008 14:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSjmTpdXi5Z3 for ; Fri, 29 Feb 2008 14:58:34 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id BC3D728C7EC for ; Fri, 29 Feb 2008 14:58:34 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TMbJZB004354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 15:37:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1TMbJTN004353; Fri, 29 Feb 2008 15:37:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TMbIOs004346 for ; Fri, 29 Feb 2008 15:37:18 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id CB4AAD1B240 for ; Fri, 29 Feb 2008 14:37:17 -0800 (PST) Received: from titania.pgp.com ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Fri, 29 Feb 2008 14:37:17 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 29 Feb 2008 14:37:17 -0800 Cc: ietf-openpgp@imc.org, David Crick Message-Id: From: Jon Callas To: Ian G In-Reply-To: <47C7FDEA.5070103@systemics.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ECC in OpenPGP proposal Date: Fri, 29 Feb 2008 14:37:15 -0800 References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > OK, so Jon argues that the market forces will push a full set of > profiles, regardless of the damage done to security. That's not at all what I argue, and I'm miffed at characterizing it that way. If I am arguing anything it is that choices have consequences. I have *observed* that if we don't do ECC at all, then people who want ECC have to use some other protocol. We seem to be in rough consensus that that is a bad thing. I have *observed* that if we do only the strong profile, then we cut out smart cards and bounded devices. I have *observed* that if we don't do the middle profile (which I have no personal love for), then we expose ourselves to missing out on something because of good reasons that we do not understand. The consequence of these three observations is that if we push to minimalism, we run the risk of missing the needs of the end users. That could mean that we've wasted our time. I have also *observed* that any labeling this as MAY, SHOULD, or MUST is mostly an illusion. ECC is an option. Options within options is really not possible. I support minimalism, as well as guidance, but there are also consequences. It would be bad for OpenPGP to have a standard that could not be implemented on light bulbs (I used to say cell phones, but they're now 400MHz devices), forcing the light bulb people to use something else. It would be bad for OpenPGP to lose another potential market because we took out something we're not happy with. (I am not happy with 192- bit security systems, as I've said. I'm also a realist.) I worry a lot about what I call architectural arrogance. That arrogance comes from presuming that because we're smart people, we are therefore the smartest people, and to disagree is to be wrong. I agree with you that all things being equal, 256-bit security is better than 128-bit security. I think that all things being equal, that's the way to go. However, engineering is all about tradeoffs in the real world, and in the real world all things are seldom equal. A statement that says, "well, you can do P-256, but only if you do P-521, too" (which is an expression in English of P-512=MUST, P-256=MAY) is awfully close to architectural arrogance. In symmetric crypto, we've slid to 256-bit security because it has a relatively minimal incremental cost. We need to understand that that cost-benefit win does not imply that AES-128 is "damaged" in its security. In the absence of a real world, I think taking a hard stand (256-bit or bust) is virtuous. In the presence of the real world I live in, a concession about 128-bit crypto is necessary. I don't like the fact that in the real world people whom I want to use OpenPGP live in, a concession about 192-bit is necessary. One of my co-workers has a statement that she sometimes says. She says, "Do you want to be right, or do you want to be effective?" At the end of the day, I want to be effective. So therefore, what I am arguing is that the *consequences* of purity that I agree with is an outcome that would be ineffective. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHyIkdsTedWZOD3gYRAi3PAKC/LaDXxIhsG7j6Ps5XlO0otZaXYACgp9Ty IMVCcWhCf7tFQRJlarqD7Pk= =ZLnE -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Feb 29 16:38:44 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C766A28C7D8 for ; Fri, 29 Feb 2008 16:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwJvbYGPqsPs for ; Fri, 29 Feb 2008 16:38:43 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C185B28C8EB for ; Fri, 29 Feb 2008 16:38:22 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m210MJMD013458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 17:22:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m210MJAb013457; Fri, 29 Feb 2008 17:22:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m210MHBK013449 for ; Fri, 29 Feb 2008 17:22:18 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so3960854wff.28 for ; Fri, 29 Feb 2008 16:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=BTAD70krPeAIHbuekgFmCP1LrHRgcAVY+6Axp6xwtK4=; b=TnHwMrX274BD+CVjaE4/D+1QSas1p0tKrmBuEALRTFC2HUMkx1HmkMt/sEdHI8DjIVVm7ZYufESrUA0ROfpLP4nDiu2/P7aJUvv9B+9BuEzQFns15Ijst516PusEq4M6e1wPNoiiYAfFk4tJ7tt6JazecJeUO0lJuurYLsVYATo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ST6kNR58RW8XorfYU/gVNWuW0ey2jo1MxgzQ63qUcHNIEwhWyKz1uh9syayQwQhJlgrMN/wg+161ffUqvLRpnnu4b8jlS856hHD6dQiP3ExUTOocpQllJUT6uVlvTGYUHAr977pd99m+pUnHiEqh6VOjaPVyV7jbgPXRGuxaBug= Received: by 10.143.33.19 with SMTP id l19mr7415902wfj.18.1204330937575; Fri, 29 Feb 2008 16:22:17 -0800 (PST) Received: by 10.143.172.3 with HTTP; Fri, 29 Feb 2008 16:22:17 -0800 (PST) Message-ID: <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> Date: Sat, 1 Mar 2008 00:22:17 +0000 From: "David Crick" To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal Cc: "Andrey Jivsov" , "Ian G" In-Reply-To: <47C8777F.2020702@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2/29/08, Andrey Jivsov wrote: > I think that the scope of ECC document is not to define the perfect > combination of symmetric algorithm/hash/public key algorithm. The issue > of relative strength applies equally well to RFC 4880. We should discuss > the relative strength issue and how the ECC fits into this and we can > recommend certain combinations, but should avoid mandating exact > permutations. These combinations are not permanent and subject to > opinions, mostly because of public key component. Balanced today > AES128/SHA256/EC P-256 may need to be AES128/SHA256/EC P-384 in the future. We have guidelines from NIST and NSA on current balanced strengths. Suite B in particular is very specific (selective). (Yes, it has its higher cipher size oddity, but thems the rules.) > Let's also not forget about the issue of encoding to multiple > recipients. Remember that the message gets encoded to a single symmetric > key. "Walking up" from this algorithm, which may be other than AES (in > fact, the 3DES is the fallback default), we may legitimately end up with > pairs of symmetric/public tupples that don't match the "perfect" > profile. In other words, if we have two recipient keys: > > ECDH public key symm. alg > -------------------------------------------- > P-256 AES-128, CAST5 > P-521 AES-256, AES-128 > > RFC 4880 mandates that we use AES-128/P-521 for the second recipient. In > some cases we cannot "insist" on using a particular algorithm. > > I think the best way to add longevity to this document is to pick up a > few core permutations and then make its *components* MUST. In > particular, there seem to be consensus on Curve ID 1 as MUST. I also > have curve ID 2 as MUST for OpenPGP, which gives some room to shuffle > the tupple. I also put SHA256 and SHA384 as MUST. I am OK with relaxing > this to Curve ID 2 and SHA384 as SHOULD for OpenPGP profile. It is > SHOULD and not MAY because of multiple recipient issue (if it is MAY to > generate P-384, it is effectively MUST to be able to encode to it). So far we have erred towards [128-]256-256 as a MUST because of low spec devices. However, someone on here (I think it was) was complaining that they couldn't even use AES-128 on a small Nokia (and so were using RC4) - so there's already examples of OpenPGP being, um, "adapted" to fit needs. With DSA in OpenPGP we're making public key and corresponding hash size restrictions (at least for DSS compliance), so why not for the cipher with ECC? (which Suite B does). The ecc-pre-6.txt's section 2 pretty much says "this is how to do ECC with AES," and we've said that this proposal is a "MAY." In a sense this is therefore some kind of a fork (sub-superset?) of 4880, so we're not concerned with 3DES (or CAST), and - as with DSA - we can make specific restrictions in order to meet compliance. Dependant on the "low spec" argument/evidence, we could just make one of the larger curve-hash pairs as the MUST, and make AES256 as the must cipher. Then if we need to encrypt to one of the two bigger curves *and* a smaller curve then we just "up" the cipher to AES256 for the small curve recipient. As has probably been apparent, I'd like to see "OpenPGP-SuiteB"; just two curves, hash sizes, ciphers and public key algorithms, with AES256 used in the event of both small curve and big curve recipients. (Maybe if we're also communicating with a non-ECC key person then we "force" one of the AESes over 3DES. Or just say we can't communicate if they don't have an AES preference.) Heck, I'd be all for making this into a "V5 key" thing and getting rid of SHA1 and 3DES completely and all the other things we've talked about. Suite B really is the closest to Ian's "one cipher system" (albeit with two of everything!). My initial suggestion was to make the AES256-SHA384-ECC384 as the MUST, since that's the stronger (and since we already have AES128-SHA256-DSA2_RSA_ElG3K strength in OpenPGP). If some people can't use AES128 on small systems *right now* then this doesn't change anything for them. > David Crick wrote: > > On 2/29/08, Ian G wrote: > > > >> David Crick wrote: > >> > >> > How hard-coded do we want/need to make the[se] cipher-hash-curve > >> > combinations? For Suite B compatibility/marketability we need > >> > them "fixed" (especially in light of pointing out the higher > >> > relative MAY cipher size) and the hash fixed as SHA2 (as opposed > >> > to, say, a hypothetical Whirlpool; SHA3 could be added later). > >> > >> Me: hardcoded. Nobody ever showed that SHA wasn't good > >> enough for the job and NIST/NSA is happy with it, until 2012. > >> > > ... > > > >> If the Europeans want to propose a EuroSuite, let them. > >> Let's not jump on the bandwagon and make the profile > >> all-things-for-all-humanity. > >> > > > > I'm 1000% happy with fixing the curve-hash sizes *and* only SHA2. > > > > *I* would also be 100% happy fixing the cipher sizes with only AES. > > > > *However*, are we ( ) willing to > > insist that for OpenPGP ECC you *absolutely* MUST use AES *and* > > at these specific sizes for the corresponding algorithm sets below? > > > > MAY implement ECC > > o MUST implement AES128-SHA256-256ECC > > o SHOULD implement AES256-SHA512-521ECC > > o MAY implement AES256-SHA384-384ECC > > > > > > Aside from the side-effect of 4880 (and predecessor's) 3DES MUST, > > this would be the first time that we are mandating specific cipher > > usage. We're not saying "SHOULD" (and WARN the user if they do > > otherwise), we're saying MUST. (A watered-down compromise would > > be to say "for Suite B compliance, AES MUST be used," just as we've > > said for DSS compliance SHA must be used [and at certain sizes]). From owner-ietf-openpgp@mail.imc.org Fri Feb 29 21:53:34 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A5A3A6A52 for ; Fri, 29 Feb 2008 21:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fky08jKw5cXb for ; Fri, 29 Feb 2008 21:53:33 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 7D3BE3A682A for ; Fri, 29 Feb 2008 21:53:33 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m215cgDs036107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 22:38:42 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m215cg3B036106; Fri, 29 Feb 2008 22:38:42 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m215cHB1036042 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 29 Feb 2008 22:38:26 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m215bGo5020229; Sat, 1 Mar 2008 00:38:08 -0500 Message-ID: <47C8EB4B.9010909@brainhub.org> Date: Fri, 29 Feb 2008 21:36:11 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> In-Reply-To: <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: ... > > The ecc-pre-6.txt's section 2 pretty much says "this is how to > do ECC with AES," and we've said that this proposal is a "MAY." > In a sense this is therefore some kind of a fork (sub-superset?) > of 4880, so we're not concerned with 3DES (or CAST), and - as > with DSA - we can make specific restrictions in order to meet > compliance. I think we need to be careful here. Let's examine a use case. I am a user of some RFC 4880 OpenPGP application. All algorithms are available to me, e.g. I am not a government employee. * I use the application to encrypt mail to 5 recipients, my friends. They use RSA/DSA/ElGamal keys. * I upgraded the application to the next version that happened to implement "ECC in OpenPGP". I assume that we agree that if I encrypt to exactly the same 5 people with new version, as far as algorithm selection is concerned, the result is identical to the previous version. * I added 6th recipient to the list, which uses ECDH key. I hope we will agree that it must be possible to send single e-mail to 6 recipients. RFC 4880 specifies that the default encryption algorithm is 3DES, thus, there is always a match. Why shouldn't single e-mail be sent to 6 recipients with 3DES symmetric key? If the application is operating in Suite-B mode, or FIPS more, etc, then the situation is different. > > Dependant on the "low spec" argument/evidence, we could just > make one of the larger curve-hash pairs as the MUST, and make > AES256 as the must cipher. Then if we need to encrypt to one > of the two bigger curves *and* a smaller curve then we just > "up" the cipher to AES256 for the small curve recipient. RFC 4880 currently grants to a user of embedded device a method to say "don't do AES-256 to me" by using cipher preferences that exclude AES 256. We should respect this. We cannot change the fact that there are hardware platforms that don't implement or don't like AES 256. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m215cgDs036107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 22:38:42 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m215cg3B036106; Fri, 29 Feb 2008 22:38:42 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m215cHB1036042 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 29 Feb 2008 22:38:26 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m215bGo5020229; Sat, 1 Mar 2008 00:38:08 -0500 Message-ID: <47C8EB4B.9010909@brainhub.org> Date: Fri, 29 Feb 2008 21:36:11 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> In-Reply-To: <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: ... > > The ecc-pre-6.txt's section 2 pretty much says "this is how to > do ECC with AES," and we've said that this proposal is a "MAY." > In a sense this is therefore some kind of a fork (sub-superset?) > of 4880, so we're not concerned with 3DES (or CAST), and - as > with DSA - we can make specific restrictions in order to meet > compliance. I think we need to be careful here. Let's examine a use case. I am a user of some RFC 4880 OpenPGP application. All algorithms are available to me, e.g. I am not a government employee. * I use the application to encrypt mail to 5 recipients, my friends. They use RSA/DSA/ElGamal keys. * I upgraded the application to the next version that happened to implement "ECC in OpenPGP". I assume that we agree that if I encrypt to exactly the same 5 people with new version, as far as algorithm selection is concerned, the result is identical to the previous version. * I added 6th recipient to the list, which uses ECDH key. I hope we will agree that it must be possible to send single e-mail to 6 recipients. RFC 4880 specifies that the default encryption algorithm is 3DES, thus, there is always a match. Why shouldn't single e-mail be sent to 6 recipients with 3DES symmetric key? If the application is operating in Suite-B mode, or FIPS more, etc, then the situation is different. > > Dependant on the "low spec" argument/evidence, we could just > make one of the larger curve-hash pairs as the MUST, and make > AES256 as the must cipher. Then if we need to encrypt to one > of the two bigger curves *and* a smaller curve then we just > "up" the cipher to AES256 for the small curve recipient. RFC 4880 currently grants to a user of embedded device a method to say "don't do AES-256 to me" by using cipher preferences that exclude AES 256. We should respect this. We cannot change the fact that there are hardware platforms that don't implement or don't like AES 256. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m210MJMD013458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 17:22:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m210MJAb013457; Fri, 29 Feb 2008 17:22:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m210MHBK013449 for ; Fri, 29 Feb 2008 17:22:18 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so3960854wff.28 for ; Fri, 29 Feb 2008 16:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=BTAD70krPeAIHbuekgFmCP1LrHRgcAVY+6Axp6xwtK4=; b=TnHwMrX274BD+CVjaE4/D+1QSas1p0tKrmBuEALRTFC2HUMkx1HmkMt/sEdHI8DjIVVm7ZYufESrUA0ROfpLP4nDiu2/P7aJUvv9B+9BuEzQFns15Ijst516PusEq4M6e1wPNoiiYAfFk4tJ7tt6JazecJeUO0lJuurYLsVYATo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ST6kNR58RW8XorfYU/gVNWuW0ey2jo1MxgzQ63qUcHNIEwhWyKz1uh9syayQwQhJlgrMN/wg+161ffUqvLRpnnu4b8jlS856hHD6dQiP3ExUTOocpQllJUT6uVlvTGYUHAr977pd99m+pUnHiEqh6VOjaPVyV7jbgPXRGuxaBug= Received: by 10.143.33.19 with SMTP id l19mr7415902wfj.18.1204330937575; Fri, 29 Feb 2008 16:22:17 -0800 (PST) Received: by 10.143.172.3 with HTTP; Fri, 29 Feb 2008 16:22:17 -0800 (PST) Message-ID: <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> Date: Sat, 1 Mar 2008 00:22:17 +0000 From: "David Crick" To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal Cc: "Andrey Jivsov" , "Ian G" In-Reply-To: <47C8777F.2020702@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2/29/08, Andrey Jivsov wrote: > I think that the scope of ECC document is not to define the perfect > combination of symmetric algorithm/hash/public key algorithm. The issue > of relative strength applies equally well to RFC 4880. We should discuss > the relative strength issue and how the ECC fits into this and we can > recommend certain combinations, but should avoid mandating exact > permutations. These combinations are not permanent and subject to > opinions, mostly because of public key component. Balanced today > AES128/SHA256/EC P-256 may need to be AES128/SHA256/EC P-384 in the future. We have guidelines from NIST and NSA on current balanced strengths. Suite B in particular is very specific (selective). (Yes, it has its higher cipher size oddity, but thems the rules.) > Let's also not forget about the issue of encoding to multiple > recipients. Remember that the message gets encoded to a single symmetric > key. "Walking up" from this algorithm, which may be other than AES (in > fact, the 3DES is the fallback default), we may legitimately end up with > pairs of symmetric/public tupples that don't match the "perfect" > profile. In other words, if we have two recipient keys: > > ECDH public key symm. alg > -------------------------------------------- > P-256 AES-128, CAST5 > P-521 AES-256, AES-128 > > RFC 4880 mandates that we use AES-128/P-521 for the second recipient. In > some cases we cannot "insist" on using a particular algorithm. > > I think the best way to add longevity to this document is to pick up a > few core permutations and then make its *components* MUST. In > particular, there seem to be consensus on Curve ID 1 as MUST. I also > have curve ID 2 as MUST for OpenPGP, which gives some room to shuffle > the tupple. I also put SHA256 and SHA384 as MUST. I am OK with relaxing > this to Curve ID 2 and SHA384 as SHOULD for OpenPGP profile. It is > SHOULD and not MAY because of multiple recipient issue (if it is MAY to > generate P-384, it is effectively MUST to be able to encode to it). So far we have erred towards [128-]256-256 as a MUST because of low spec devices. However, someone on here (I think it was) was complaining that they couldn't even use AES-128 on a small Nokia (and so were using RC4) - so there's already examples of OpenPGP being, um, "adapted" to fit needs. With DSA in OpenPGP we're making public key and corresponding hash size restrictions (at least for DSS compliance), so why not for the cipher with ECC? (which Suite B does). The ecc-pre-6.txt's section 2 pretty much says "this is how to do ECC with AES," and we've said that this proposal is a "MAY." In a sense this is therefore some kind of a fork (sub-superset?) of 4880, so we're not concerned with 3DES (or CAST), and - as with DSA - we can make specific restrictions in order to meet compliance. Dependant on the "low spec" argument/evidence, we could just make one of the larger curve-hash pairs as the MUST, and make AES256 as the must cipher. Then if we need to encrypt to one of the two bigger curves *and* a smaller curve then we just "up" the cipher to AES256 for the small curve recipient. As has probably been apparent, I'd like to see "OpenPGP-SuiteB"; just two curves, hash sizes, ciphers and public key algorithms, with AES256 used in the event of both small curve and big curve recipients. (Maybe if we're also communicating with a non-ECC key person then we "force" one of the AESes over 3DES. Or just say we can't communicate if they don't have an AES preference.) Heck, I'd be all for making this into a "V5 key" thing and getting rid of SHA1 and 3DES completely and all the other things we've talked about. Suite B really is the closest to Ian's "one cipher system" (albeit with two of everything!). My initial suggestion was to make the AES256-SHA384-ECC384 as the MUST, since that's the stronger (and since we already have AES128-SHA256-DSA2_RSA_ElG3K strength in OpenPGP). If some people can't use AES128 on small systems *right now* then this doesn't change anything for them. > David Crick wrote: > > On 2/29/08, Ian G wrote: > > > >> David Crick wrote: > >> > >> > How hard-coded do we want/need to make the[se] cipher-hash-curve > >> > combinations? For Suite B compatibility/marketability we need > >> > them "fixed" (especially in light of pointing out the higher > >> > relative MAY cipher size) and the hash fixed as SHA2 (as opposed > >> > to, say, a hypothetical Whirlpool; SHA3 could be added later). > >> > >> Me: hardcoded. Nobody ever showed that SHA wasn't good > >> enough for the job and NIST/NSA is happy with it, until 2012. > >> > > ... > > > >> If the Europeans want to propose a EuroSuite, let them. > >> Let's not jump on the bandwagon and make the profile > >> all-things-for-all-humanity. > >> > > > > I'm 1000% happy with fixing the curve-hash sizes *and* only SHA2. > > > > *I* would also be 100% happy fixing the cipher sizes with only AES. > > > > *However*, are we ( ) willing to > > insist that for OpenPGP ECC you *absolutely* MUST use AES *and* > > at these specific sizes for the corresponding algorithm sets below? > > > > MAY implement ECC > > o MUST implement AES128-SHA256-256ECC > > o SHOULD implement AES256-SHA512-521ECC > > o MAY implement AES256-SHA384-384ECC > > > > > > Aside from the side-effect of 4880 (and predecessor's) 3DES MUST, > > this would be the first time that we are mandating specific cipher > > usage. We're not saying "SHOULD" (and WARN the user if they do > > otherwise), we're saying MUST. (A watered-down compromise would > > be to say "for Suite B compliance, AES MUST be used," just as we've > > said for DSS compliance SHA must be used [and at certain sizes]). Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TMbJZB004354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 15:37:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1TMbJTN004353; Fri, 29 Feb 2008 15:37:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TMbIOs004346 for ; Fri, 29 Feb 2008 15:37:18 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id CB4AAD1B240 for ; Fri, 29 Feb 2008 14:37:17 -0800 (PST) Received: from titania.pgp.com ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Fri, 29 Feb 2008 14:37:17 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 29 Feb 2008 14:37:17 -0800 Cc: ietf-openpgp@imc.org, David Crick Message-Id: From: Jon Callas To: Ian G In-Reply-To: <47C7FDEA.5070103@systemics.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ECC in OpenPGP proposal Date: Fri, 29 Feb 2008 14:37:15 -0800 References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > OK, so Jon argues that the market forces will push a full set of > profiles, regardless of the damage done to security. That's not at all what I argue, and I'm miffed at characterizing it that way. If I am arguing anything it is that choices have consequences. I have *observed* that if we don't do ECC at all, then people who want ECC have to use some other protocol. We seem to be in rough consensus that that is a bad thing. I have *observed* that if we do only the strong profile, then we cut out smart cards and bounded devices. I have *observed* that if we don't do the middle profile (which I have no personal love for), then we expose ourselves to missing out on something because of good reasons that we do not understand. The consequence of these three observations is that if we push to minimalism, we run the risk of missing the needs of the end users. That could mean that we've wasted our time. I have also *observed* that any labeling this as MAY, SHOULD, or MUST is mostly an illusion. ECC is an option. Options within options is really not possible. I support minimalism, as well as guidance, but there are also consequences. It would be bad for OpenPGP to have a standard that could not be implemented on light bulbs (I used to say cell phones, but they're now 400MHz devices), forcing the light bulb people to use something else. It would be bad for OpenPGP to lose another potential market because we took out something we're not happy with. (I am not happy with 192- bit security systems, as I've said. I'm also a realist.) I worry a lot about what I call architectural arrogance. That arrogance comes from presuming that because we're smart people, we are therefore the smartest people, and to disagree is to be wrong. I agree with you that all things being equal, 256-bit security is better than 128-bit security. I think that all things being equal, that's the way to go. However, engineering is all about tradeoffs in the real world, and in the real world all things are seldom equal. A statement that says, "well, you can do P-256, but only if you do P-521, too" (which is an expression in English of P-512=MUST, P-256=MAY) is awfully close to architectural arrogance. In symmetric crypto, we've slid to 256-bit security because it has a relatively minimal incremental cost. We need to understand that that cost-benefit win does not imply that AES-128 is "damaged" in its security. In the absence of a real world, I think taking a hard stand (256-bit or bust) is virtuous. In the presence of the real world I live in, a concession about 128-bit crypto is necessary. I don't like the fact that in the real world people whom I want to use OpenPGP live in, a concession about 192-bit is necessary. One of my co-workers has a statement that she sometimes says. She says, "Do you want to be right, or do you want to be effective?" At the end of the day, I want to be effective. So therefore, what I am arguing is that the *consequences* of purity that I agree with is an outcome that would be ineffective. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHyIkdsTedWZOD3gYRAi3PAKC/LaDXxIhsG7j6Ps5XlO0otZaXYACgp9Ty IMVCcWhCf7tFQRJlarqD7Pk= =ZLnE -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TLMIgO098397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 14:22:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1TLMIA2098396; Fri, 29 Feb 2008 14:22:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TLMGJv098388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Feb 2008 14:22:17 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m1TLMDe7008292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 13:22:13 -0800 Message-ID: <47C8777F.2020702@brainhub.org> Date: Fri, 29 Feb 2008 13:22:07 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick , Ian G Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> In-Reply-To: <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think that the scope of ECC document is not to define the perfect combination of symmetric algorithm/hash/public key algorithm. The issue of relative strength applies equally well to RFC 4880. We should discuss the relative strength issue and how the ECC fits into this and we can recommend certain combinations, but should avoid mandating exact permutations. These combinations are not permanent and subject to opinions, mostly because of public key component. Balanced today AES128/SHA256/EC P-256 may need to be AES128/SHA256/EC P-384 in the future. Let's also not forget about the issue of encoding to multiple recipients. Remember that the message gets encoded to a single symmetric key. "Walking up" from this algorithm, which may be other than AES (in fact, the 3DES is the fallback default), we may legitimately end up with pairs of symmetric/public tupples that don't match the "perfect" profile. In other words, if we have two recipient keys: ECDH public key symm. alg -------------------------------------------- P-256 AES-128, CAST5 P-521 AES-256, AES-128 RFC 4880 mandates that we use AES-128/P-521 for the second recipient. In some cases we cannot "insist" on using a particular algorithm. I think the best way to add longevity to this document is to pick up a few core permutations and then make its *components* MUST. In particular, there seem to be consensus on Curve ID 1 as MUST. I also have curve ID 2 as MUST for OpenPGP, which gives some room to shuffle the tupple. I also put SHA256 and SHA384 as MUST. I am OK with relaxing this to Curve ID 2 and SHA384 as SHOULD for OpenPGP profile. It is SHOULD and not MAY because of multiple recipient issue (if it is MAY to generate P-384, it is effectively MUST to be able to encode to it). David Crick wrote: > On 2/29/08, Ian G wrote: > >> David Crick wrote: >> >> > How hard-coded do we want/need to make the[se] cipher-hash-curve >> > combinations? For Suite B compatibility/marketability we need >> > them "fixed" (especially in light of pointing out the higher >> > relative MAY cipher size) and the hash fixed as SHA2 (as opposed >> > to, say, a hypothetical Whirlpool; SHA3 could be added later). >> >> Me: hardcoded. Nobody ever showed that SHA wasn't good >> enough for the job and NIST/NSA is happy with it, until 2012. >> > ... > >> If the Europeans want to propose a EuroSuite, let them. >> Let's not jump on the bandwagon and make the profile >> all-things-for-all-humanity. >> > > I'm 1000% happy with fixing the curve-hash sizes *and* only SHA2. > > *I* would also be 100% happy fixing the cipher sizes with only AES. > > *However*, are we ( ) willing to > insist that for OpenPGP ECC you *absolutely* MUST use AES *and* > at these specific sizes for the corresponding algorithm sets below? > > MAY implement ECC > o MUST implement AES128-SHA256-256ECC > o SHOULD implement AES256-SHA512-521ECC > o MAY implement AES256-SHA384-384ECC > > > Aside from the side-effect of 4880 (and predecessor's) 3DES MUST, > this would be the first time that we are mandating specific cipher > usage. We're not saying "SHOULD" (and WARN the user if they do > otherwise), we're saying MUST. (A watered-down compromise would > be to say "for Suite B compliance, AES MUST be used," just as we've > said for DSS compliance SHA must be used [and at certain sizes]). > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TGKd2A065193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 09:20:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1TGKdRX065190; Fri, 29 Feb 2008 09:20:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TGKc7k065176 for ; Fri, 29 Feb 2008 09:20:38 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so3661782wff.28 for ; Fri, 29 Feb 2008 08:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=DeCEPKVRZlzLjpEDGwuRhga3d5GrKFpZ1Si/hbc9Qvc=; b=EfHQxSw39M1VrVJZWBeZgpgRk+Vo5K5MbHYO3VlQFydNpZoT8tpxKHm5wYsmd10uW+slQ/RS6UKEtMPeebHMNWi6xXyQGC05j8jPHFYDWor7LHQpyxlF+UZaE6st688ho1PJ+76UcSJ6OfYsCjKThqKQqFuHnsHHTvUnOR2pHYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ns0S7UnPoOFbAx07+/yvcVfHP5R74QwfhqhYtVnn4J4t0r5BpeIGRrIOpKLTw2tqlaTVTIqNSoGhpw77xGUSKHszHtdnyshSsAF81rceP+lEOlvYRWZjcbrBa94EBWQZAuEk4WFQ8lapaLAu3ek5ugwkozNtNXbW/VrLjJh01Hw= Received: by 10.143.37.20 with SMTP id p20mr7161555wfj.236.1204302038122; Fri, 29 Feb 2008 08:20:38 -0800 (PST) Received: by 10.143.172.3 with HTTP; Fri, 29 Feb 2008 08:20:38 -0800 (PST) Message-ID: <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> Date: Fri, 29 Feb 2008 16:20:38 +0000 From: "David Crick" To: "Ian G" Subject: Re: ECC in OpenPGP proposal Cc: ietf-openpgp@imc.org In-Reply-To: <47C82549.8080703@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2/29/08, Ian G wrote: > David Crick wrote: > > > How hard-coded do we want/need to make the[se] cipher-hash-curve > > combinations? For Suite B compatibility/marketability we need > > them "fixed" (especially in light of pointing out the higher > > relative MAY cipher size) and the hash fixed as SHA2 (as opposed > > to, say, a hypothetical Whirlpool; SHA3 could be added later). > > Me: hardcoded. Nobody ever showed that SHA wasn't good > enough for the job and NIST/NSA is happy with it, until 2012. ... > If the Europeans want to propose a EuroSuite, let them. > Let's not jump on the bandwagon and make the profile > all-things-for-all-humanity. I'm 1000% happy with fixing the curve-hash sizes *and* only SHA2. *I* would also be 100% happy fixing the cipher sizes with only AES. *However*, are we ( ) willing to insist that for OpenPGP ECC you *absolutely* MUST use AES *and* at these specific sizes for the corresponding algorithm sets below? MAY implement ECC o MUST implement AES128-SHA256-256ECC o SHOULD implement AES256-SHA512-521ECC o MAY implement AES256-SHA384-384ECC Aside from the side-effect of 4880 (and predecessor's) 3DES MUST, this would be the first time that we are mandating specific cipher usage. We're not saying "SHOULD" (and WARN the user if they do otherwise), we're saying MUST. (A watered-down compromise would be to say "for Suite B compliance, AES MUST be used," just as we've said for DSS compliance SHA must be used [and at certain sizes]). Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TFVWcV059826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 08:31:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1TFVWd3059825; Fri, 29 Feb 2008 08:31:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TFVUaP059817 for ; Fri, 29 Feb 2008 08:31:31 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id C776457B0F; Fri, 29 Feb 2008 16:31:22 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJZuB2t6MCQG; Fri, 29 Feb 2008 16:31:22 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 7E5B357B0B; Fri, 29 Feb 2008 16:31:22 +0100 (CET) Message-ID: <47C82549.8080703@systemics.com> Date: Fri, 29 Feb 2008 16:31:21 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: David Crick CC: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> In-Reply-To: <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: > How hard-coded do we want/need to make the[se] cipher-hash-curve > combinations? For Suite B compatibility/marketability we need > them "fixed" (especially in light of pointing out the higher > relative MAY cipher size) and the hash fixed as SHA2 (as opposed > to, say, a hypothetical Whirlpool; SHA3 could be added later). Me: hardcoded. Nobody ever showed that SHA wasn't good enough for the job * and NIST/NSA is happy with it, until 2012. (I don't expect everyone to agree though :) I noticed that there is this discussion to use Suite B for other purposes (variously, ECC is cool, speed, Euro-profiles, mobile, smart cards, HSMs, ... etc). That is bad, to my mind. This is a profile proposed for Suite B and that's what it should do: Suite B. If the Europeans want to propose a EuroSuite, let them. Let's not jump on the bandwagon and make the profile all-things-for-all-humanity. iang * to a 99% confidence level. SHA0 was the 1%. The rest is crypto-academic stuff which shouldn't impact actual use. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TChP6v042456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 05:43:26 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1TChPe1042455; Fri, 29 Feb 2008 05:43:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TChN9r042446 for ; Fri, 29 Feb 2008 05:43:25 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id E6CAF57B0B; Fri, 29 Feb 2008 13:43:22 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCoKhbZsLqY5; Fri, 29 Feb 2008 13:43:22 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 8CAB657AF8; Fri, 29 Feb 2008 13:43:22 +0100 (CET) Message-ID: <47C7FDEA.5070103@systemics.com> Date: Fri, 29 Feb 2008 13:43:22 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Jon Callas , David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > -----BEGIN PGP SIGNED MESSAGE----- >>> OK, if you are happy to carry on this discussion ... what are the >>> reasons for including the 128-bit profile? >> assuming the may -> whatever chain above holds, what about: >> >> MAY implement ECC >> o MUST implement AES256-SHA384-384ECC >> o SHOULD implement AES128-SHA256-256ECC >> o MAY implement AES256-SHA512-521ECC >> [and/or any other combinations, but these might be "unbalanced"] > > I think you have the polarity wrong. > > AES256-SHA512-521ECC is desirable because it's the most secure. > > AES128-SHA256-256ECC is desirable because it's fast, and it's what is > most likely to be in constrained environments. > > AES256-SHA384-384ECC (which I think should actually be AES192- > SHA384-384ECC), is slow and not as secure. It's neither fish nor fowl. > > However, for completeness, eliminating it is likely not wise. As much > as I sneer at NIST's fondness for 192-bit security (especially when it > runs at the same speed as 256-bit security), it's foolish to eliminate > it from the spec. That's the sort of thing that might bite us in the > ass years from now. The probability that I'll get a cogent, > enlightening explanation of why 192-bit security is a Good Thing is > directly proportional to the probability of our excluding it. OK, so Jon argues that the market forces will push a full set of profiles, regardless of the damage done to security. OK, I accept that, it's a devil's choice. Do we work with the "best practices" mafia or do we try and meet the needs of the real users who just want the darned stuff to boot up and work? If there are going to be 2 profiles, then there may as well be all 3. There is no real saving between 2 and 3. So the remaining question would be, what are the recommendations? If we are including the "mobile" profile of 128, then it makes no sense to me to say that any other profile is a MUST ... because then the mobile guys will have to implement the stronger ones to get the gold star. Which they won't use or want because it's too slow. Which would mean that only the mobile profile is a MUST and the other two are lesser? So I see: MAY implement ECC o MUST implement AES128-SHA256-256ECC (mobile) o SHOULD implement AES256-SHA512-521ECC (strong) o MAY implement AES256-SHA384-384ECC (pretty) iang PS: mobile above includes smartcards and HSMs, it's just a label for those who want "fast" not pareto-complete. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1T98ZtW022374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 02:08:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1T98Z20022373; Fri, 29 Feb 2008 02:08:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1T98Waa022364 for ; Fri, 29 Feb 2008 02:08:35 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 3FFBED15EAD for ; Fri, 29 Feb 2008 01:08:32 -0800 (PST) Received: from titania.merrymeet.com ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Fri, 29 Feb 2008 01:08:32 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 29 Feb 2008 01:08:32 -0800 Cc: ietf-openpgp@imc.org Message-Id: From: Jon Callas To: David Crick In-Reply-To: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ECC in OpenPGP proposal Date: Fri, 29 Feb 2008 01:08:31 -0800 References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 28, 2008, at 11:02 AM, David Crick wrote: > > Ian wrote: > >> Hmmm... you raise an interesting point. I had thought that this >> was going to be a new document, and as it is not referred to in >> the existing core RFC, then ECC/Suite B was going to be a MAY by >> definition. >> >> Within that new (MAY) document, there would be several choices >> for MUST, SHOULD, MAY, etc. >> >> Or so I thought ... but I'm not fully aware of how these things >> interact. > > and further: > >>> I don't see how we can simplify past dropping 192. >> >> >> OK, if you are happy to carry on this discussion ... what are the >> reasons for including the 128-bit profile? > > assuming the may -> whatever chain above holds, what about: > > MAY implement ECC > o MUST implement AES256-SHA384-384ECC > o SHOULD implement AES128-SHA256-256ECC > o MAY implement AES256-SHA512-521ECC > [and/or any other combinations, but these might be "unbalanced"] I think you have the polarity wrong. AES256-SHA512-521ECC is desirable because it's the most secure. AES128-SHA256-256ECC is desirable because it's fast, and it's what is most likely to be in constrained environments. AES256-SHA384-384ECC (which I think should actually be AES192- SHA384-384ECC), is slow and not as secure. It's neither fish nor fowl. However, for completeness, eliminating it is likely not wise. As much as I sneer at NIST's fondness for 192-bit security (especially when it runs at the same speed as 256-bit security), it's foolish to eliminate it from the spec. That's the sort of thing that might bite us in the ass years from now. The probability that I'll get a cogent, enlightening explanation of why 192-bit security is a Good Thing is directly proportional to the probability of our excluding it. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHx8uQsTedWZOD3gYRAjcgAKCHpO1SjUt+hb8JPV7asxSyJ2uLNgCglqr5 ngJIWmCOG4fzItYg6AnMylQ= =Kun2 -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SNEE2B078692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 16:14:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1SNEEaa078691; Thu, 28 Feb 2008 16:14:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SNEC4R078685 for ; Thu, 28 Feb 2008 16:14:13 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 980FCD126D9 for ; Thu, 28 Feb 2008 15:14:12 -0800 (PST) Received: from titania.pgp.com ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Thu, 28 Feb 2008 15:14:12 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 28 Feb 2008 15:14:12 -0800 Cc: OpenPGP Message-Id: <04C6B64C-70D9-4C8B-A37C-2D353A6E2E0D@callas.org> From: Jon Callas To: Ian G In-Reply-To: <47C6C75C.3040307@systemics.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ECC in OpenPGP proposal Date: Thu, 28 Feb 2008 15:14:10 -0800 References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> <47BD643C.8090000@systemics.com> <533AF4A7-B591-4775-A34F-C44E7B33B5D6@callas.org> <47C54085.8000009@systemics.com> <47C6C75C.3040307@systemics.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Hmmm... you raise an interesting point. I had thought that this was > going to be a new document, and as it is not referred to in the > existing core RFC, then ECC/Suite B was going to be a MAY by > definition. > > Within that new (MAY) document, there would be several choices for > MUST, SHOULD, MAY, etc. > > Or so I thought ... but I'm not fully aware of how these things > interact. > At least in theory, we could make ECC be the MUST. But as I said before, there really isn't a good process to change those things in the IETF. > OK, if you are happy to carry on this discussion ... what are the > reasons for including the 128-bit profile? There's nothing wrong 128-bit security. It's also faster. It competes against 3Kbit integer keys. If you're doing smart cards, HSMs, mobile phones, etc. they will likely need 128-bit security for speed reasons. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHx0BEsTedWZOD3gYRAkmmAJ9eDHz2s6TiLS2rbb4kvwSAFEVDGgCgta1a cc+w9w+IP3KwoAfp7hBfP7c= =txKh -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SJ2KHx055134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 12:02:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1SJ2KYQ055133; Thu, 28 Feb 2008 12:02:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SJ2J3K055127 for ; Thu, 28 Feb 2008 12:02:19 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so2984872wff.28 for ; Thu, 28 Feb 2008 11:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=tNrRcOricLqBSfJ0hhRKhKSW6twoLdFazL/yL/CZLsY=; b=CwlLsb17t7NYAcKdmzVBFQdrYyDDUwqc1EzAlZPLC+b4bFSCj4CrVPH1KMtZngthYV+/zhcjrzUbPdTnWaubz+LzHE6vCipTuUyNRYU1rl+2PFU/TZNB9sFW8tFE0ZFWBsHhqSIYHF/G87Yx3L5qKJJYl+RAhIZs/ifojqnNJJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=n9WGCiqPuMioT7Twmz7xmHAbBu+kDbEMSzZrHMsNq1teEr7wfMAZCpvSn3tuunydlpnZdVysXJ9AeSmQp6SjzAiglDi3DLYx+VlL2Rf1lma8wgho18gBikCTYW0UbtwNiB5T/ebCJOUfh1GmffefWh0HYJZ4VgzBkVumcuoaPLY= Received: by 10.142.212.19 with SMTP id k19mr1622241wfg.86.1204225339016; Thu, 28 Feb 2008 11:02:19 -0800 (PST) Received: by 10.143.172.3 with HTTP; Thu, 28 Feb 2008 11:02:18 -0800 (PST) Message-ID: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> Date: Thu, 28 Feb 2008 19:02:18 +0000 From: "David Crick" To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian wrote: > Hmmm... you raise an interesting point. I had thought that this > was going to be a new document, and as it is not referred to in > the existing core RFC, then ECC/Suite B was going to be a MAY by > definition. > > Within that new (MAY) document, there would be several choices > for MUST, SHOULD, MAY, etc. > > Or so I thought ... but I'm not fully aware of how these things interact. and further: > > I don't see how we can simplify past dropping 192. > > > OK, if you are happy to carry on this discussion ... what are the > reasons for including the 128-bit profile? assuming the may -> whatever chain above holds, what about: MAY implement ECC o MUST implement AES256-SHA384-384ECC o SHOULD implement AES128-SHA256-256ECC o MAY implement AES256-SHA512-521ECC [and/or any other combinations, but these might be "unbalanced"] we currently *have* 3072 RSA/DSA strength (or 4096 RSA/ElG for those wanting a bit of extra headroom); higher size DSA isn't in any [e.g. NIST] standard, and >=4K RSA/ElG public key ops begin to take a noticeable time even on my desktop (so while 7K RSA keys are a simple source-change in GnuPG, ECC would definitely make sense to achieve a balanced crypto system at this strength). Now, for "embedded"/constrained systems there may only be the chance to do AES128-SHA256-256ECC, which would conflict with my "SHOULD" suggestion above. So there would probably be scope for the AES128 set to be a SHOULD as well, or even the MUST instead. To be honest I think having AES256-SHA384-384ECC *and* AES128-SHA256-256ECC in *some* form of MUST/SHOULD *is* desirable: it covers both the two "Suite B" available balanced set of algorithms, which may be important to some people (and is certainly more "marketable" anyway). I wouldn't personally "protest" if AES256-SHA512-521ECC were also included, but I think anything more than these three balanced sets is "silly." Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SEca1r026806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 07:38:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1SEcatI026805; Thu, 28 Feb 2008 07:38:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SEcYdf026787 for ; Thu, 28 Feb 2008 07:38:35 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id C160857B17; Thu, 28 Feb 2008 15:38:20 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfpIOj5Y+WmO; Thu, 28 Feb 2008 15:38:20 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 772EF57B0F; Thu, 28 Feb 2008 15:38:20 +0100 (CET) Message-ID: <47C6C75C.3040307@systemics.com> Date: Thu, 28 Feb 2008 15:38:20 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Callas CC: OpenPGP Subject: Re: ECC in OpenPGP proposal References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> <47BD643C.8090000@systemics.com> <533AF4A7-B591-4775-A34F-C44E7B33B5D6@callas.org> <47C54085.8000009@systemics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > -----BEGIN PGP SIGNED MESSAGE----- >> The short summary of my argument is that there should one and only >> one MUST profile for Suite B, and that it should be the strong one / >> Top Secret. > For a number of reasons, ECC/Suite B is going to be a MAY. You will be > permitted to make an OpenPGP application that doesn't do it. Hmmm... you raise an interesting point. I had thought that this was going to be a new document, and as it is not referred to in the existing core RFC, then ECC/Suite B was going to be a MAY by definition. Within that new (MAY) document, there would be several choices for MUST, SHOULD, MAY, etc. Or so I thought ... but I'm not fully aware of how these things interact. > Like many things coming out of NIST, they come in three flavors, 128- > bit security, 192-bit, and 256-bit. I have no objection myself to > canning the 192-bit ones. I'm of the opinion that if you need more > than 128, you should go to 256. In many cases, there isn't even a > performance win on the 192-bit system. > > However, there are very good arguments for doing 192-bit as well, and > one of those arguments is that it may be easier to do the 192-bit > versions than to explain why you didn't. In the sense that it exists, and people think it has to exist, yes. "why go against the flow, it's only security after all..." Yes, I agree. In that market, that is the pressure you will get. > I don't see how we can simplify past dropping 192. OK, if you are happy to carry on this discussion ... what are the reasons for including the 128-bit profile? (I know I'm exceeding my noise quota here .. but I hate the thought that we are happily reducing overall security by providing users too many options for them to achieve compatibility with each other.) iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SA54PY097403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 03:05:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1SA54jL097402; Thu, 28 Feb 2008 03:05:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SA4uxI097361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Feb 2008 03:05:02 -0700 (MST) (envelope-from simon@josefsson.org) Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1SA4ZFw004140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 11:04:36 +0100 From: Simon Josefsson To: Andrey Jivsov Cc: ietf-openpgp@imc.org, Werner Koch Subject: Re: ECC curve ID References: <87lk564ctl.fsf@wheatstone.g10code.de> <47C5F2BD.6030003@brainhub.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:080228:wk@gnupg.org::ZTyy7bQTQevUZce3:1HMT X-Hashcash: 1:22:080228:openpgp@brainhub.org::2nWE8ieGVJsd6nn3:ANDr X-Hashcash: 1:22:080228:ietf-openpgp@imc.org::naXsen0B4ShoQns7:jUxc Date: Thu, 28 Feb 2008 11:04:35 +0100 In-Reply-To: <47C5F2BD.6030003@brainhub.org> (Andrey Jivsov's message of "Wed, 27 Feb 2008 15:31:09 -0800") Message-ID: <87ejax2y8c.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrey Jivsov writes: > OpenPGP application is not required to understand ASN.1 / > DER. You don't need to support ASN.1 or DER to support OIDs as identities for curves. Just use memcpy or memcmp with a fixed string. > > Besides, I thought that once the group agrees on an ID, the IETF > process shouldn't take longer than a quarter. I think that is quite optimistic. Further, the problem with the process is that you don't get the actual ID number until after that process has finished. This seriously delay deployment and early testing. If IANA could reserve numbers early for experiments, this wouldn't have been such a big problem. Finally, I'd like to +1 Werner's suggestion to use OID's. /Simon Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RNVKA6042938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 16:31:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1RNVKka042937; Wed, 27 Feb 2008 16:31:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RNVIhG042931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Feb 2008 16:31:19 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m1RNVDDo007507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 15:31:14 -0800 Message-ID: <47C5F2BD.6030003@brainhub.org> Date: Wed, 27 Feb 2008 15:31:09 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Werner Koch Subject: Re: ECC curve ID References: <87lk564ctl.fsf@wheatstone.g10code.de> In-Reply-To: <87lk564ctl.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Werner, thank you for your comments. Werner Koch wrote: > Hi, > > altough I am aware of the discussion about limiting the number of > algorithms/profiles in a future ECC option, I am not happy with section > 10 of the draft: > > 10. ECC curve ID > > The parameter ECC curve ID is an integer that defines the named > curve. > > ID Curve description Curve name > 0 Reserved > 1 NIST Curve P-256 [FIPS 186-2] "NIST P256" > 2 NIST Curve P-384 [FIPS 186-2] "NIST P384" > 3 NIST Curve P-521 [FIPS 186-2] "NIST P521" > 100-110 Private/Experimental curves > 255 Reserved for future expansion > > > Although this uses the same scheme we use all over OpenPGP, we should > make future life easier for all by not using registered IDs but use > other identifiers here. For registering IDs we need to informal agree > on a new identifier, implement that one and then wait a couple of > months/years until it gets really assigned. The private/experimental > IDs are not really useful for this because they can't be used after the > algorithm has been offically registered. > > Thus, I propose to use ASN.1 object identifiers for the curves; i.e.: > > 1.2.840.10045.3.1.7 NIST P-256 (Not sure about this OID) > 1.3.132.0.34 NIST P-384 > 1.3.132.0.35 NIST P-521 > > and declare some of them as MUST be implemented if ECC is implemented. > > Having object identifiers allows us to add other curves. I think that support for arbitrary curves has some merits. On the other hand, these benefits must be compared against possibility of ever getting the ECC support in OpenPGP applications. OpenPGP application is not required to understand ASN.1 / DER. Essentially, this proposal means that we are replacing one-byte ID by multi-byte ID. Would it be good to agree on new curve anyway and how it fits relative strength, what are legal issues, what are implementation issues, which MAY/SHOULD keyword it will be carrying, and so on? If we cannot agree on this on the list, it is unlikely that applications will be able to interoperate using curves we disagree on. The freedom will be detrimental to interoperability. (Conversely, the small subset will allow greater speed optimizations.) While I think we need to start from "core" version of the standard and cut options, perhaps in the future we need to allow named curves in companion proposal or in the next version of the document. For example, ID 254 might mean that there is an ASN.1 structure referencing the curve, inserted somewhere into the sequence of currently defined fields. (If you find it worthwhile, I can be more specific in the draft about the extension path for future curves.) Besides, I thought that once the group agrees on an ID, the IETF process shouldn't take longer than a quarter. > Well, you will > now say, we should limit that to the NIST defined curves. May I now > remind you that there other national standard bodies which require the > use of other curves. In Europe we have a tendency to prefer our own > algorithms and sometimes it is a hard requirement not rely on foreign > crypto standard (cf. the use of RIPE-MD160). > Please note that proposed curves are a part of major international standards: ANSI X9.62 (multiple updates) and industry standard SECG, among others. It is a part of any ECC-related IETF standard. They come with Windows Vista, Linux (openssl), etc. Which ECC standard *excludes* the curves specified in the proposal? I claim that the proposed subset of curves is the most widely supported subset of any standard. I suggest that in the interest of adoption we start from core set and once we deployed the applications that interoperate, we start adding marginal improvements. > I know that interoperability will be limited but as long as other curves > are declared optional this is not a major issue. S/MIME users will > suffer from the same problem. > I note that this seems exactly opposite to what Ian wants, so I propose the idea of core set + extensions as a compromise... > I have not yet looked at the preference system and how to integrate > curve names into it. I doubt that it is really required because we > don't have preference for key length eithers. > This is where freedom will make interoperability problematic. It is hard to come up with preferences that control the structure of self-signatures, because preferences themselves are stored in self-signatures. The only solution to this chicken-and-egg problem is to establish small core set of curves, the two ones I proposed in the draft, and focus on supporting these curves first. > Shalom-Salam, > > Werner > > > > p.s. > I don't think that the notion of "Top Secret" And "Secret" belongs into > an RFC. I could also ask to add "VS/NfD", which is a secrecy level used > in Germany This seems reasonable. If any of 3 curves in the proposal satisfy another standard that the group thinks worth mentioning, such a standard can be noted in the spec. (These references to non-OpenPGP profiles are informative, BTW) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RMZuM0037365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 15:35:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1RMZuDD037364; Wed, 27 Feb 2008 15:35:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RMZtOd037357 for ; Wed, 27 Feb 2008 15:35:55 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id C91A4D0A79B for ; Wed, 27 Feb 2008 14:35:54 -0800 (PST) Received: from titania.pgp.com ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Wed, 27 Feb 2008 14:35:54 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 27 Feb 2008 14:35:54 -0800 Cc: OpenPGP Message-Id: From: Jon Callas To: Ian G In-Reply-To: <47C54085.8000009@systemics.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ECC in OpenPGP proposal Date: Wed, 27 Feb 2008 14:35:53 -0800 References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> <47BD643C.8090000@systemics.com> <533AF4A7-B591-4775-A34F-C44E7B33B5D6@callas.org> <47C54085.8000009@systemics.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > For the record, I agree there should be a Suite B ! It is an > economic reality, a real-world requirement. When NIST/NSA speaks, > that's it. > > The short summary of my argument is that there should one and only > one MUST profile for Suite B, and that it should be the strong one / > Top Secret. > > Other lesser profiles could be MAY, or if you let the agility nazis > have their way, absent, as they have no economic use and lots and > lots of costs to users. > > (The reason I say that 'Secret' could be a MAY is that there are > complicated blah blahs in the government/security world that > sometimes force suppliers to provide several modes, against good > security practice.) > > (I'm aware of the "mobile" argument that was raised in the previous > post. I would say that the mobile boys propose a "mobile" profile. > That's because mobile has other aspects that aren't necessarily > considered in Suite B.) Excellent. For a number of reasons, ECC/Suite B is going to be a MAY. You will be permitted to make an OpenPGP application that doesn't do it. (Presently, our MUST algorithms are DSA, Elgamal, 3DES, and SHA1. Changing MUSTs is a can of worms and I don't think any IETF standard is handling it well.) Like many things coming out of NIST, they come in three flavors, 128- bit security, 192-bit, and 256-bit. I have no objection myself to canning the 192-bit ones. I'm of the opinion that if you need more than 128, you should go to 256. In many cases, there isn't even a performance win on the 192-bit system. However, there are very good arguments for doing 192-bit as well, and one of those arguments is that it may be easier to do the 192-bit versions than to explain why you didn't. I don't see how we can simplify past dropping 192. > > > >> There are also other changes we will need to do on the horizon. >> For example, someday there will be an AHS hash algorithm set from >> NIST. Do we not to that, either? The argument you give is to have >> no choices. > > > Yes. AHS is years away, if AES was any guide. AHS won't improve > overall security markedly over SHA256-512 family. NIST/NSA will also > have to update Suite B when AHS comes out. > > When all that dust settles, then is the time to reconsider it. I > would plan on Suite B (one profile) now and know that in 5 or 7 > years we will need to do a Suite B-bis. The NIST schedule has a decision made in 2012. The submissions must be made this August. > > > >> For the people who want more, is to use S/MIME? If so, and if >> that's the decision of the working group -- well, I disagree, but >> rough consensus is rough consensus. My company does both OpenPGP >> and S/MIME. If the answer to people who want Suite B is that we >> support it with S/ MIME, that's fine. It is also a huge >> disappointment, because I would like to satisfy people's ECC and >> Suite B needs with OpenPGP, but we can always migrate people to S/ >> MIME who need that. > > > I think there should be a Suite B, in OpenPGP. > > And, to forestall the outrage, I fully expect to not get consensus > on my plea to reduce agility :) We waited for 10 years to get the > current OpenPGP draft, so we can wait another 10 years to find out > why it took 10 years... Cool. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHxeXKsTedWZOD3gYRAnhSAJ92jiokj+2HJdnY03yFT2t9O5PYIwCgiJBo 0pREjuhus2l54lTJL14DeIU= =Zlos -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RIw8Gf021017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 11:58:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1RIw85T021016; Wed, 27 Feb 2008 11:58:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.infoseccorp.com (h-66-166-172-3.chcgilgm.covad.net [66.166.172.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RIw7UM021010 for ; Wed, 27 Feb 2008 11:58:08 -0700 (MST) (envelope-from markowitz@infoseccorp.com) Message-Id: <200802271858.m1RIw7UM021010@balder-227.proper.com> X-AuthUser: mjm@infoseccorp.com Received: from mjmdt.infoseccorp.com ([127.0.0.1]:54885) by infoseccorp.com with [XMail 1.21 ESMTP Server] id for from ; Wed, 27 Feb 2008 12:43:45 -0600 Received: from 192.168.0.65 ([192.168.0.65] helo=mjmdt.infoseccorp.com) by ASSP-nospam; 27 Feb 2008 12:43:45 -0600 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Feb 2008 12:54:39 -0600 To: Werner Koch From: Mike Markowitz Subject: Re: ECC curve ID Cc: ietf-openpgp@imc.org In-Reply-To: <87lk564ctl.fsf@wheatstone.g10code.de> References: <87lk564ctl.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-2AF82ACA Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 09:51 AM 2/27/2008, Werner Koch wrote: > 1.2.840.10045.3.1.7 NIST P-256 (Not sure about this OID) Werner: We think that this is correct -- at least it's what we've been using for quite some time and have received no complaints to date (and have witnessed no conflicts between our code and everything we've been able to access for compatibility testing). Microsoft agrees (and our P-256 ECC certs are accepted by Vista IE): "XCN_OID_ECC_CURVE_P256 (1.2.840.10045.3.1.7) " http://msdn2.microsoft.com/en-us/library/aa379070(VS.85).aspx Also, if you need an official NIST reference, SP 800-78-1 lists this OID on page 9 (table 3-6): http://csrc.nist.gov/publications/nistpubs/800-78-1/SP-800-78-1_final2.pdf In hex, it's "0x2A8648CE3D030107." Cheers, Michael ========== Michael J. Markowitz, Ph.D. Email: markowitz@infoseccorp.com Vice President R&D Voice: 708-445-1704 (Oak Park) Information Security Corporation 847-405-0500 (Deerfield) 1011 Lake Street, Suite 425 Fax: 708-445-9705 Oak Park, IL 60301 WWW: http://www.infoseccorp.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RFuc7G098883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 08:56:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1RFuc6N098882; Wed, 27 Feb 2008 08:56:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RFuTiG098862 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 27 Feb 2008 08:56:37 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1JUOm4-0006Bm-9R for ; Wed, 27 Feb 2008 17:04:52 +0100 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1JUOZS-0005rb-Cz for ; Wed, 27 Feb 2008 16:51:50 +0100 From: Werner Koch To: ietf-openpgp@imc.org Subject: ECC curve ID Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Wed, 27 Feb 2008 16:51:50 +0100 Message-ID: <87lk564ctl.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110007 (No Gnus v0.7) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, altough I am aware of the discussion about limiting the number of algorithms/profiles in a future ECC option, I am not happy with section 10 of the draft: 10. ECC curve ID The parameter ECC curve ID is an integer that defines the named curve. ID Curve description Curve name 0 Reserved 1 NIST Curve P-256 [FIPS 186-2] "NIST P256" 2 NIST Curve P-384 [FIPS 186-2] "NIST P384" 3 NIST Curve P-521 [FIPS 186-2] "NIST P521" 100-110 Private/Experimental curves 255 Reserved for future expansion Although this uses the same scheme we use all over OpenPGP, we should make future life easier for all by not using registered IDs but use other identifiers here. For registering IDs we need to informal agree on a new identifier, implement that one and then wait a couple of months/years until it gets really assigned. The private/experimental IDs are not really useful for this because they can't be used after the algorithm has been offically registered. Thus, I propose to use ASN.1 object identifiers for the curves; i.e.: 1.2.840.10045.3.1.7 NIST P-256 (Not sure about this OID) 1.3.132.0.34 NIST P-384 1.3.132.0.35 NIST P-521 and declare some of them as MUST be implemented if ECC is implemented. Having object identifiers allows us to add other curves. Well, you will now say, we should limit that to the NIST defined curves. May I now remind you that there other national standard bodies which require the use of other curves. In Europe we have a tendency to prefer our own algorithms and sometimes it is a hard requirement not rely on foreign crypto standard (cf. the use of RIPE-MD160). I know that interoperability will be limited but as long as other curves are declared optional this is not a major issue. S/MIME users will suffer from the same problem. I have not yet looked at the preference system and how to integrate curve names into it. I doubt that it is really required because we don't have preference for key length eithers. Shalom-Salam, Werner p.s. I don't think that the notion of "Top Secret" And "Secret" belongs into an RFC. I could also ask to add "VS/NfD", which is a secrecy level used in Germany. -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RApL9H064216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 03:51:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1RApL7K064215; Wed, 27 Feb 2008 03:51:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1RApJZp064186 for ; Wed, 27 Feb 2008 03:51:20 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 3E87357C07; Wed, 27 Feb 2008 11:50:47 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPzMJzAioKOd; Wed, 27 Feb 2008 11:50:47 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 83A9157BFC; Wed, 27 Feb 2008 11:50:46 +0100 (CET) Message-ID: <47C54085.8000009@systemics.com> Date: Wed, 27 Feb 2008 11:50:45 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Callas CC: OpenPGP Subject: Re: ECC in OpenPGP proposal References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> <47BD643C.8090000@systemics.com> <533AF4A7-B591-4775-A34F-C44E7B33B5D6@callas.org> In-Reply-To: <533AF4A7-B591-4775-A34F-C44E7B33B5D6@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Jon, Jon Callas wrote: >> http://iang.org/ssl/h1_the_one_true_cipher_suite.html > > Ian, > > I agree that there is virtue in limiting choice. However, there are a > lot of people who want ECC, particularly in the context of Suite B. In > the not-to-distant future, this will be a requirement. For the record, I agree there should be a Suite B ! It is an economic reality, a real-world requirement. When NIST/NSA speaks, that's it. The short summary of my argument is that there should one and only one MUST profile for Suite B, and that it should be the strong one / Top Secret. Other lesser profiles could be MAY, or if you let the agility nazis have their way, absent, as they have no economic use and lots and lots of costs to users. (The reason I say that 'Secret' could be a MAY is that there are complicated blah blahs in the government/security world that sometimes force suppliers to provide several modes, against good security practice.) (I'm aware of the "mobile" argument that was raised in the previous post. I would say that the mobile boys propose a "mobile" profile. That's because mobile has other aspects that aren't necessarily considered in Suite B.) > There are also other changes we will need to do on the horizon. For > example, someday there will be an AHS hash algorithm set from NIST. Do > we not to that, either? The argument you give is to have no choices. Yes. AHS is years away, if AES was any guide. AHS won't improve overall security markedly over SHA256-512 family. NIST/NSA will also have to update Suite B when AHS comes out. When all that dust settles, then is the time to reconsider it. I would plan on Suite B (one profile) now and know that in 5 or 7 years we will need to do a Suite B-bis. > For the people who want more, is to use S/MIME? If so, and if that's > the decision of the working group -- well, I disagree, but rough > consensus is rough consensus. My company does both OpenPGP and S/MIME. > If the answer to people who want Suite B is that we support it with S/ > MIME, that's fine. It is also a huge disappointment, because I would > like to satisfy people's ECC and Suite B needs with OpenPGP, but we > can always migrate people to S/MIME who need that. I think there should be a Suite B, in OpenPGP. And, to forestall the outrage, I fully expect to not get consensus on my plea to reduce agility :) We waited for 10 years to get the current OpenPGP draft, so we can wait another 10 years to find out why it took 10 years... iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1QKxhCS097235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2008 13:59:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1QKxhV7097234; Tue, 26 Feb 2008 13:59:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1QKxfrO097227 for ; Tue, 26 Feb 2008 13:59:42 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 32371D00FFF for ; Tue, 26 Feb 2008 12:59:41 -0800 (PST) Received: from [192.168.111.151] ([66.236.113.201]) by keys.merrymeet.com (PGP Universal service); Tue, 26 Feb 2008 12:59:41 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 26 Feb 2008 12:59:41 -0800 Message-Id: <533AF4A7-B591-4775-A34F-C44E7B33B5D6@callas.org> From: Jon Callas To: OpenPGP In-Reply-To: <47BD643C.8090000@systemics.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ECC in OpenPGP proposal Date: Tue, 26 Feb 2008 12:59:39 -0800 References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> <47BD643C.8090000@systemics.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 21, 2008, at 3:45 AM, Ian G wrote: > > Andrey Jivsov wrote: >> Hello Ian, thank you for your comments. > > > Thanks for response. I have not responded in detail to all your > responses, we might be better off both seeing how the rest of the > group chimes in. Instead I've just amplified my points where there > was some divergence. > > On background, when it comes to agility, I am a little bit of a > nazi. To me, choice is bad, nasty, evil. This is because the > choice does no good for the user, and lots and lots of bad. > > http://iang.org/ssl/h1_the_one_true_cipher_suite.html Ian, I agree that there is virtue in limiting choice. However, there are a lot of people who want ECC, particularly in the context of Suite B. In the not-to-distant future, this will be a requirement. There are also other changes we will need to do on the horizon. For example, someday there will be an AHS hash algorithm set from NIST. Do we not to that, either? The argument you give is to have no choices. For the people who want more, is to use S/MIME? If so, and if that's the decision of the working group -- well, I disagree, but rough consensus is rough consensus. My company does both OpenPGP and S/MIME. If the answer to people who want Suite B is that we support it with S/ MIME, that's fine. It is also a huge disappointment, because I would like to satisfy people's ECC and Suite B needs with OpenPGP, but we can always migrate people to S/MIME who need that. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHxH29sTedWZOD3gYRAkc5AJ9LruANnjQGcXVKLMoxWHrcLqgE7wCg/Uax OQ03J48GnMLG78wcI2bpgwI= =IHhn -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1PLXeDH067587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Feb 2008 14:33:40 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1PLXe2x067586; Mon, 25 Feb 2008 14:33:40 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1PLXbTv067578 for ; Mon, 25 Feb 2008 14:33:39 -0700 (MST) (envelope-from n.mavrogiannopoulos@gmail.com) Received: by fg-out-1718.google.com with SMTP id 22so1343256fge.26 for ; Mon, 25 Feb 2008 13:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding:sender; bh=5UGkHb8K+be9MtkrnJdmbVyzFwSiOhzAmlwy5fZdw9c=; b=P6P0vofaU0KaHT4y1IsZYDSCSGLxqHXW63NCC5tsVTRHitQA+qIWjmf/sr+yzmMQhdZXFKExZQ6+oz/OdfnRUO1ViQ7s6YGb01SFxZY1XDCcUU+fKd093OheAEl9AWJYeIGU8FYY/G6O2ShVcGoUMl1VQYgwME4JxveoB7Eob+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding:sender; b=kaHTEtip9C6nzODLeuaP+vfwzE6gyhOhbKBDc6Vcl3jXews66gcs3SBF9Ecy6W/VA4/HgXSR1MrCVEbBC0zcG6oKtLD3dwi+x2J1DMrQx7INLSyKFa6I3NhWkWgQtV55nrkAAvPLmYKrBj5dgKG0K6NRedFk9s+VbvzuimjOVm0= Received: by 10.86.68.20 with SMTP id q20mr3546122fga.59.1203975216690; Mon, 25 Feb 2008 13:33:36 -0800 (PST) Received: from ?10.100.1.196? ( [77.49.222.159]) by mx.google.com with ESMTPS id 4sm5497235fge.3.2008.02.25.13.33.34 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Feb 2008 13:33:35 -0800 (PST) Message-ID: <47C3342D.20403@gnutls.org> Date: Mon, 25 Feb 2008 23:33:33 +0200 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: tls@ietf.org CC: ietf-openpgp@imc.org Subject: updated TLS-Openpgp protocol Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've updated the experimental protocol for openpgp keys. The updated version can be found at: http://www.ietf.org/internet-drafts/draft-mavrogiannopoulos-rfc5081bis-00.txt The main addition is that it adds support for using subkeys instead of the main key of the openpgp certificate. For this reason i'd like to revive this protocol as a TLS WG item. For this to be possible there must be interest on this protocol, so if there are there people in this list supporting this protocol please express it. Of course comments are always welcome. regards, Nikos PS. Currently there is a module for the apache web server implementing the openpgp-tls protocol, available at: http://www.outoforder.cc/projects/apache/mod_gnutls/ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1N6CqIu067830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 23:12:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1N6Cqqt067829; Fri, 22 Feb 2008 23:12:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1N6CoPJ067819 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 22 Feb 2008 23:12:51 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m1N6l8o5026927; Sat, 23 Feb 2008 01:47:09 -0500 Message-ID: <47BFB960.8040009@brainhub.org> Date: Fri, 22 Feb 2008 22:12:48 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Ian G Subject: Re: ECC in OpenPGP proposal References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> <47BD643C.8090000@systemics.com> In-Reply-To: <47BD643C.8090000@systemics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Ian, I appreciate your pragmatism regarding algorithm agility. There are two practical issues we need to worry about: steady increase in processing power and the difference in processing power on various hardware. A proposal with single ciphersuite cannot remain adequate indefinitely. We need ability to roll forward the strength of public key crypto as yesterday's strength declines over time. We have impressive breadth of hardware that supports ECC today: from servers to smartcards. These devices demand some breadth of choices for ECC curves: servers might want the ultimate crypto strength, while smartcards are usually trying to meet set manufacturing cost at OK performance. The document we discuss has three "ciphersuites" with two of them as MUST. As I said, I am OK with making only one MUST. I am inclined toward weaker one, since it has to be the lowest common denominator. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LBjYkg030461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 04:45:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LBjYoK030460; Thu, 21 Feb 2008 04:45:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LBjWPw030378 for ; Thu, 21 Feb 2008 04:45:33 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 4C48A57C01; Thu, 21 Feb 2008 12:45:01 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywHZV1cwR9Az; Thu, 21 Feb 2008 12:45:01 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id BD26957B96; Thu, 21 Feb 2008 12:45:00 +0100 (CET) Message-ID: <47BD643C.8090000@systemics.com> Date: Thu, 21 Feb 2008 12:45:00 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Andrey Jivsov CC: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> <47BD318F.5010509@brainhub.org> In-Reply-To: <47BD318F.5010509@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrey Jivsov wrote: > Hello Ian, thank you for your comments. Thanks for response. I have not responded in detail to all your responses, we might be better off both seeing how the rest of the group chimes in. Instead I've just amplified my points where there was some divergence. On background, when it comes to agility, I am a little bit of a nazi. To me, choice is bad, nasty, evil. This is because the choice does no good for the user, and lots and lots of bad. http://iang.org/ssl/h1_the_one_true_cipher_suite.html A few points below: >> ... "SHOULD support ECDH" >> >> what is the point of not supporting ECDH? I recommend MUST. >> > > I can support this. > > However, please note that the signature has more weight by being a tool > of certifications, i.e. self-signatures depends on it. Without support > for ECDSA we cannot have functional EC keys, while we can have sign-only > keys without ECDH. It is possible to have sign+encrypt keys with ECDSA > top key and modp ElGamal DH. Is your argument here that it is possible to do signature-only applications with just ECDSA? So this opens a window for a simplified implementation? I would not be in favour of such an optimisation for the simple reason that signature-only applications are not common nor popular (nor well built IMHO). We are here to do encryption. Signature-only concepts are something that people talked about and failed to make good on the talk. So I see this as a throw-back to the 1990s and DoJ ideas about everyone having a digital signature and the world being a better place and many other blind alleys. Didn't happen, not useful. > Also note that ECDH brings with it the need to implement KDF and key > wrapping methods, because there is no ElGamal alternative in ECC field. > ECDSA should be easier to implement than ECDH. OK, so there is more work if it is a MUST. To summarise, we are here for the encryption. Digsigs are the option, not the other way around. Therefore I recommend it as a MUST. >> ===== >> >> 6. ... "the KDF hash function MAY be any hash function defined in >> [FIPS 180-2] or its successor, except that SHA-1 MUST NOT be used." >> >> What is the point in permitting alternatives? If there is a good >> reason, I would prefer to see them enumerated for better understanding >> and for certainty. > > This is to continue good tradition of algorithm agility in OpenPGP. Ouch :) That tradition was born of a bunch of hackers and a bunch of cryptographers who sat around and hacked and drank wine and promised the world that it would be better. I know, I was one of them. OpenPGP these days is more a business area. People implement OpenPGP not because it is sexy and they like wine but because it solves problems for users and can help to sell product. In business we do not want "agility". What we want to give our users is a product that boots up and runs, securely, out of the box. There is only one mode, and it is secure. There is no place for agility in the world of business. Agility never solved anything, I posit (a debate over wine, ever there was one), and it sure created a lot of problems. If there was a chance to to do it all again, I would (and do) propose this as a rule: one true cipher suite, and that's it. > http://www.nsa.gov/ia/industry/crypto_suite_b.cfm OK, read that, thanks. I suggest only one profile is needed: "Top Secret". (I would do it as your ID 3.) >> 11.2 I don't see any point in providing both Secret and Top Secret? >> This seems like a way to create comaptibility problems for zero >> payoff. I suggest the full Top Secret as the only profile, and that's >> it. > > I think that the incremental cost to achieve Secret level of Suite-B is > insignificant, given that an application has implemented Top Secret > level. The incremental cost of "Top Secret" instead of "Secret" is truly insignificant, yes, and the same in reverse. My point is that the cost of two profiles over one profile is huge. And I'm not talking about the implementors but the users. Implement one "Top Secret" profile and be done with it. Say that OpenPGP Suite-B is rated for all traffic, and save the users a headache, for every message they must send, for all time. > This proposal offers the least choice of ECC parameters of any IETF > standard. I like it better for that :) The IETF has not been particularly successful at crypto, so I don't mind drifting a long way from their views... > At present the only MUST for OpenPGP are curves ID 1 and 2. It also says > that SHA-256 and SHA-384 are MUST. All this is in section 11.1. These > are the curves/hashed approved by Suite-B. I can accepts that we reduce > the OpenPGP profile to ID 1 and SHA-256. This will match Suite-B > "Secret" level and drop "Top Secret". No, I'd suggest the reverse: "Top Secret" and drop or downgrade "Secret". If you must implement multiple profiles, then "Top Secret" should be the MUST, and the lower one MAY. No point in encouraging people to add agility, although there is a potential market for the mobile phone people to implement a lower profile. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1L88p5B004955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 01:08:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1L88pFk004954; Thu, 21 Feb 2008 01:08:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1L88n07004947 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 21 Feb 2008 01:08:50 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [192.168.1.81] (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m1L8gVo5015437; Thu, 21 Feb 2008 03:42:32 -0500 Message-ID: <47BD318F.5010509@brainhub.org> Date: Thu, 21 Feb 2008 00:08:47 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Ian G Subject: Re: ECC in OpenPGP proposal References: <47BA544E.8020608@brainhub.org> <47BBFCFC.6070508@systemics.com> In-Reply-To: <47BBFCFC.6070508@systemics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Ian, thank you for your comments. Ian G wrote: > > Hi all, > > > Some comments. Caveat: I wouldn't know an EC if someone hit me over > the head with it... > > Big comment: far too much variability, for little gain. > > > > > > > Andrey Jivsov wrote: >> >> Hello OpenPGP list, >> >> as Hal Finney had mentioned earlier, here is the draft: >> http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt >> >> Unless you read this on a text terminal, here is the document in >> alternative formats that offer cross-references as navigation links: >> http://brainhub.googlepages.com/pgp > >> Why do we need ECC? The main reason is better alignment with the >> strength of symmetric key. Given that US government has chosen ECC in >> favor of modp for larger key sizes, this proposal is carefully >> written to comply with NSA Suite-B. > > I think it is sufficient to state that you want a Suite-B compatible > profile. Suite-B offers fewer choices than this spec does. Some of restrictions imposed by Suite-B are debatable. The purpose of this draft is to match the strength of AES-128, AES-192 and AES-256. See section 12 for corresponding sizes for hashes and curves (which are "double width" of AES key sizes). http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.html#toc15 Suite-B only lists AES-128 and AES-256, EC P256 and P384, SHA-256 and SHA-384. This creates a shift in relative strength. To illustrate this using the table in section 12, NSA dropped the row with AES-256 and replaced AES-192 with AES-256 in the second raw, resulting in weaker top public key algorithm. Suite-B allows some patented techniques that were excluded. This leaves us with two curves for Suite-B, but since we must have two, why not add next strongest one as SHOULD for better symmetry? Without EC P521 addition applications will be left with 15K RSA/ElGamal key or weaker EC P384 to match AES-256. > ... "SHOULD support ECDH" > > what is the point of not supporting ECDH? I recommend MUST. > I can support this. However, please note that the signature has more weight by being a tool of certifications, i.e. self-signatures depends on it. Without support for ECDSA we cannot have functional EC keys, while we can have sign-only keys without ECDH. It is possible to have sign+encrypt keys with ECDSA top key and modp ElGamal DH. Also note that ECDH brings with it the need to implement KDF and key wrapping methods, because there is no ElGamal alternative in ECC field. ECDSA should be easier to implement than ECDH. > ===== > > 6. ... "the KDF hash function MAY be any hash function defined in > [FIPS 180-2] or its successor, except that SHA-1 MUST NOT be used." > > What is the point in permitting alternatives? If there is a good > reason, I would prefer to see them enumerated for better understanding > and for certainty. This is to continue good tradition of algorithm agility in OpenPGP. I am sure TLS designers would like to get rid of MD5, hardwired into their analog of KDF. Implementors are advised to follow the recommendations set in the table of section 12, which will mean that there are 3 ways to set up KDFs, parameterized by different hash algorithms, for each of 3 sizes of symmetric keys. The hash algorithms have already been implemented in vast majority of OpenPGP applications. The code to use KDF should be written using generic hash API, so that there will be no difference which hash algorithm is passed to initialize this API. Overall, I think the benefits overweight the slightly more complex format. > > I especially don't like "or its successor." I can drop this clause. I attempted to write a spec that doesn't need to be updated after NIST introduces new hashes. I wanted to make external the definition of what the right hashes for AES-128, AES-192, and AES-256 are. > I ask ... without expecting to understanding the answer ... why it is > that it is useful or necessary to permit any variability in the KDF? In summary, this follows from the need to support every AES key size. No other variability is allowed in section 6. > > ===== > > > > 11.2 I don't think it makes sense for OpenPGP WG to suggest that it > knows what "Secret" and "Top Secret" means, nor that it can "achieve" > this. The normative place for that is NSA. If some guidance of > intentions is useful, it should be in the sense of a comment. "This > profile is intended to be compatible with Suite B." If the NSA can be > convinced to make a statement as to what works for them, include that too. These Secret/Top Secret classifications are from Suite-B page. I can add your suggestion and the phrase "[SUITE-B] is the normative source of the definition" to section 11.2. We need a way to say what an OpenPGP application shall do to comply with each level of Suite-B security. http://www.nsa.gov/ia/industry/crypto_suite_b.cfm > ==== > > 11.2 I don't see any point in providing both Secret and Top Secret? > This seems like a way to create comaptibility problems for zero > payoff. I suggest the full Top Secret as the only profile, and that's > it. I think that the incremental cost to achieve Secret level of Suite-B is insignificant, given that an application has implemented Top Secret level. In addition, because I've dropped some of patented methods allowed by Suite-B, in my mind the scale is tipped to offer more choices. Also, Top Secret has less symmetry in the sense of relative security than Secret, as mentioned above. > ==== > > 11. Indeed, what is the point in allowing people to fiddle around > with different curves, KDFs, and hashes? Nobody has ever cracked any > of them, or nobody that we care about (which excludes the NSA, > perversely). Set one and leave it as that. > > This "profile" proposes 2 different public key algorithms, 3 different > curves (plus future ones), 3 different hashes (plus future ones), 3 > different AES strengths, MDC on or off, It/Salt as a SHOULD. My goal was to limit as much as I can. Let me explain how I arrived at the present set. I will leave MDC and S2K out of this section. Here is what have now: We want to support 3 sizes of AES algorithms. AES algorithms pair with 3 hashes and 3 curves in the sense of relative security. We need encryption and signing, and this is achieved with two new public key algorithms. Let's put this into perspective and sketch what it could have been. In addition to above: Point compression format. Curves in binary field, using polynomial or normal basis representations Curves in prime field that allow the choice of the prime; there is no limit to customization, up to the random curves over random underlying fields ECDH with cofactor; ECMQV (both patented) Multiple KDF or key wrapping method in conjunction with ECDH Another way to look at how flexible or constrained current proposal is is by comparing its flexibility with, for example, current modp ElGamal encryption in OpenPGP. An OpenPGP application today generates its own prime and is not constrained by the allowed size of such a prime (usually in a range of 1024-4096 bits). In this ECC proposal we essentially folding infinite number of primes into 3 predefined primes. This proposal offers the least choice of ECC parameters of any IETF standard. > I suggest you would half the entire workload by reducing all above > choices to 1 MUST, and reduce the compatibility problems to about a > tenth. > > It would then have a good chance of being a really useful profile. To > business folks who don't care for the tea-room discussion about key > lengths and rights to be compatible but uncommunicative... At present the only MUST for OpenPGP are curves ID 1 and 2. It also says that SHA-256 and SHA-384 are MUST. All this is in section 11.1. These are the curves/hashed approved by Suite-B. I can accepts that we reduce the OpenPGP profile to ID 1 and SHA-256. This will match Suite-B "Secret" level and drop "Top Secret". The section 11.2 is for Suite-B compatibility. The MUSTs there are for applications implementing Suite-B profile. I should put a sentence into 11.2 that makes this clear. I wasn't trying to tell an applications which Suite-B profile to use (for this there is section 12). > ===== > > 12. "MDC SHOULD be used when symmetrical encryption key is protected > by ECDH." > > Is there any good reason to permit it to be dropped? Remove a > compatibility complaint, make it a MUST? Hal Finney had a reservation that MDC and S2K are orthogonal to ECC, so I changed the key word to SHOULD. The proponents of MUST would take an opportunity to tighten the security, because only recently updated applications can understand the ECC key. I will go with the consensus, and if there is none, I am happy to remove these references. > Iterated and Salted S2K ... Ditto. I looks forward to see other responses. I am flexible on many of these issues in the interest of the consensus. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KACiq8080463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 03:12:44 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1KAChAI080462; Wed, 20 Feb 2008 03:12:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KACeQI080453 for ; Wed, 20 Feb 2008 03:12:42 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id C12C15D23; Wed, 20 Feb 2008 10:12:20 +0000 (GMT/BST) Message-ID: <47BBFCFC.6070508@systemics.com> Date: Wed, 20 Feb 2008 11:12:12 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Andrey Jivsov Cc: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal References: <47BA544E.8020608@brainhub.org> In-Reply-To: <47BA544E.8020608@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi all, Some comments. Caveat: I wouldn't know an EC if someone hit me over the head with it... Big comment: far too much variability, for little gain. Andrey Jivsov wrote: > > Hello OpenPGP list, > > as Hal Finney had mentioned earlier, here is the draft: > http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt > > Unless you read this on a text terminal, here is the document in > alternative formats that offer cross-references as navigation links: > http://brainhub.googlepages.com/pgp > Why do we need ECC? The main reason is better alignment with the > strength of symmetric key. Given that US government has chosen ECC in > favor of modp for larger key sizes, this proposal is carefully written > to comply with NSA Suite-B. I think it is sufficient to state that you want a Suite-B compatible profile. 4. ... "SHOULD support ECDH" what is the point of not supporting ECDH? I recommend MUST. ===== 6. ... "the KDF hash function MAY be any hash function defined in [FIPS 180-2] or its successor, except that SHA-1 MUST NOT be used." What is the point in permitting alternatives? If there is a good reason, I would prefer to see them enumerated for better understanding and for certainty. I especially don't like "or its successor." I ask ... without expecting to understanding the answer ... why it is that it is useful or necessary to permit any variability in the KDF? ===== 11.2 I don't think it makes sense for OpenPGP WG to suggest that it knows what "Secret" and "Top Secret" means, nor that it can "achieve" this. The normative place for that is NSA. If some guidance of intentions is useful, it should be in the sense of a comment. "This profile is intended to be compatible with Suite B." If the NSA can be convinced to make a statement as to what works for them, include that too. ==== 11.2 I don't see any point in providing both Secret and Top Secret? This seems like a way to create comaptibility problems for zero payoff. I suggest the full Top Secret as the only profile, and that's it. ==== 11. Indeed, what is the point in allowing people to fiddle around with different curves, KDFs, and hashes? Nobody has ever cracked any of them, or nobody that we care about (which excludes the NSA, perversely). Set one and leave it as that. This "profile" proposes 2 different public key algorithms, 3 different curves (plus future ones), 3 different hashes (plus future ones), 3 different AES strengths, MDC on or off, It/Salt as a SHOULD. I suggest you would half the entire workload by reducing all above choices to 1 MUST, and reduce the compatibility problems to about a tenth. It would then have a good chance of being a really useful profile. To business folks who don't care for the tea-room discussion about key lengths and rights to be compatible but uncommunicative... ===== 12. "MDC SHOULD be used when symmetrical encryption key is protected by ECDH." Is there any good reason to permit it to be dropped? Remove a compatibility complaint, make it a MUST? Iterated and Salted S2K ... Ditto. ===== Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1J40Isb093535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 21:00:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1J40IZB093534; Mon, 18 Feb 2008 21:00:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1J40GCu093525 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 18 Feb 2008 21:00:17 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m1J4XGo5001896 for ; Mon, 18 Feb 2008 23:33:17 -0500 Message-ID: <47BA544E.8020608@brainhub.org> Date: Mon, 18 Feb 2008 20:00:14 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: ECC in OpenPGP proposal Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello OpenPGP list, as Hal Finney had mentioned earlier, here is the draft: http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt Unless you read this on a text terminal, here is the document in alternative formats that offer cross-references as navigation links: http://brainhub.googlepages.com/pgp This submissions considers comments of the group to earlier Elliptic curve Cryptography (ECC) draft submissions. A couple of issues that were raised then are the justification for ECC in OpenPGP and how the larger set of ECC parameters can be managed. Why do we need ECC? The main reason is better alignment with the strength of symmetric key. Given that US government has chosen ECC in favor of modp for larger key sizes, this proposal is carefully written to comply with NSA Suite-B. Informally, this is a proposal for these who are concerned that the use of SHA2-512 and AES-256 will need something stronger that RSA 1024. By optimistic estimates users should use at least RSA 4096 with AES 256, while it is a common assumption that RSA 8192 is more appropriate. In practice, many sites today are not able to use RSA keys of sizes greater than 4096. ECC offers alternatives to larger modp key sizes. Another advantage of ECC is an opportunity to expand the set of hardware on which OpenPGP can be implemented. The security of AES-128 with corresponding ECC public key may be more attractive for "weak" devices, as opposed to RSA public keys, especially because the ECC curves introduced by this standard are already supported by TLS, IKE, PKIX, and SSH. Any system that communicates over slow medium will benefit from smaller keys and ESKs as well. This paragraph describes the direction chosen by the proposal in reference to the issue of magnitude of ECC parameters and options. One possible approach an ECC standard can take is to define all possible formats in one RFC, a "toolbox" approach. One can argue that smartcard devices may prefer ECC in binary fields, while software implementations would like to work in generalized Mersenne prime fields. Another group of OpenPGP applications may wish to generate its own random curves as part of a protocol, and so on. While it may be possible to create such a broad standard that will make each concerned implementer happy, it creates more interoperability issues. This puts burden on an implementation that wants to support every type of ECC key. The performance and security issues associated with generation and verification of random ECC curves creates new order of complexity. It seems to me that in the short run there are two likely outcomes resulting from implementing a "toolbox" approach. In the first one, there will be no interoperability between different OpenPGP implementations. The second possibility is that there will be a core set of parameters that will be implemented by everybody who claims ECC support. This second possibility is probably wishful thinking. Consider the fact that in OpenPGP there is no method to advertise public key support, yet alone, a method to advertise a nuance of public key support. For example, what an application should use for a top key, so that self-signatures and certifications by this key are broadly understood? It is rare to see SHA2-512 used for these signatures. I think the following approach will help speed up adoption of the standard: we define core set of ECC parameters and make them MUST. This will be lowest common denominator of all possible ECC configurations (within the acceptable security strength). This will not be the optimal field for every application, yet, it will be good compromise to achieve faster adoption. Future advances in computing will drive the upgrade of the core set, but by then there will be a path by which ECC-capable applications can transition to other formats. The draft doesn't preclude the existence of companion proposals that define ECC in other fields, moreover, the draft provides a framework for these extensions. Finally, only patent-free techniques were chosen for this proposal. The requirement to be in unencumbered field further reduced the acceptable ECC methods. To summarize, this document offers narrow core set of functionality and focuses on matching AES strength and on Suite-B support. There are lots of MUSTs, very few SHOULDs in the interest of interoperability and patent clarity. I would appreciate if the group reviews the document. Thank you.