From nobody Wed Mar 1 05:12:21 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889821295A0 for ; Wed, 1 Mar 2017 05:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySFSJ29HEzm1 for ; Wed, 1 Mar 2017 05:12:15 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649351295B2 for ; Wed, 1 Mar 2017 05:12:15 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id v186so109820595wmd.0 for ; Wed, 01 Mar 2017 05:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=ERclPtGHmQwDI8Z6ZImSOHsFXc8Da3GmMTzMfqyVZj0=; b=NCvNVkEqCKF4QZLJbU6ieqtM6mxktTrBHYMVJGUgr9D4fT/km9TdyCa/YTC9P21NN4 yuo4aC2n+n6ANGE2Vlp8UqNhjffdljBAJ6c+34GsvDE5sg67mMOyhCEA5iJYXevViqE+ xzDZxAdpi5Z3TIfpja2Ytpov4KFLLsdWUdkkY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=ERclPtGHmQwDI8Z6ZImSOHsFXc8Da3GmMTzMfqyVZj0=; b=IhKkZkqdY5rFx3GvDBdMMhpeWbTscG4Yyp85LXWN5EYtZiHL2Rdz/N6aYNxwfRwoba WbOVuYZg2P9hJNxUKQIV9+vNEbaWpX+AKVNyov5nIfUQFe7Go20QRnsp2vLDxNToFK2o qLgyetARl9WzIrqYoE4ppvxORl0T5qC2CyvemdMk6gxCwCBmRDGp3I9gvv+967S4HxaI a9kao/CdWnvCVPAeM+PLz7PMIEvnysb+AXzQxANTlRS98S9qZ9JHIf/f5RY513hscHhV sb/96V3GSsgd9i2l7RLfQ+TZEEoMfaZe1c7exag4gnj+FFMRFAAhoMFaO4PQFbJjrNtO yAsA== X-Gm-Message-State: AMke39k59R4BBTZ95nXtg34qmy8wh6iVo7dWvgSn84zuv2TaXqPKeWsnahOpv/l4aWSwGA== X-Received: by 10.28.203.204 with SMTP id b195mr3425506wmg.51.1488373933775; Wed, 01 Mar 2017 05:12:13 -0800 (PST) Received: from [192.168.1.121] ([41.143.43.27]) by smtp.gmail.com with ESMTPSA id m201sm6951872wmd.19.2017.03.01.05.12.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Mar 2017 05:12:13 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_730454EA-7C14-4F96-9548-200CE3398D6F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Aaron Zauner In-Reply-To: Date: Wed, 1 Mar 2017 13:11:25 +0000 Message-Id: <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> To: "Dang, Quynh (Fed)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IRTF CFRG , "" , Sean Turner Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 13:12:17 -0000 --Apple-Mail=_730454EA-7C14-4F96-9548-200CE3398D6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) = wrote: >=20 > Hi Sean, Joe, Eric and all, >=20 > I would like to address my thoughts/suggestions on 2 issues in option = a. >=20 > 1) The data limit should be addressed in term of blocks, not records. = When the record size is not the full size, some user might not know what = to do. When the record size is 1 block, the limit of 2^24.5 blocks = (records) is way too low unnecessarily for the margin of 2^-60. In that = case, 2^34.5 1-block records is the limit which still achieves the = margin of 2^-60. I respectfully disagree. TLS deals in records not in blocks, so in the = end any semantic change here will just confuse implementors, which isn't = a good idea in my opinion. Aaron --Apple-Mail=_730454EA-7C14-4F96-9548-200CE3398D6F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYtsh+AAoJEOTbZJL9ubXVPU0QAN5yFc9KMjMLylANnEW+Bj/1 h1+Uz1PDNU4mNrPFZkr5gCkmk7O5nJOUv1GqZ1Js3ixMaKfcl6JJxOlFLp5e7044 aiEiPGvCNz0uuuFczPklSMBWhkoeoLCEX/m1arm3VgpIz7Xbpa5LbyhtXWc5qzzF 7hLdYUzeAZLDk/dhRViM8y2n/5aE37+GE0cP4JVlmO4kxHFslJykbsLmSBEsPTmn 1NNuETkpOP3RLHcH5a3VExKYJEDfCFWMSeSuoje125/2nUd6+upPgP7EFrrG1I9U 31n03E1mkf1HMNtMz+Jp758+Cp2UzKvcj9YRvNtr+tq9AC9H+jyAr6EoDbbEDC26 b/Ll9gPYyXqyf3GiNCnkA7W6urgjefZfASAknAIT8wc1lfLdrXVQ9Fmj0OQqrbE+ d2QWpMELbsxf96x6zGoXxE3h5wnMlIRRSjF4KvCetvWktPZFq+/48fFJSARmNkhY AjSPAe4K3GapkYHmN4Snt2+a7GerUq3yYkb1nA+3r0sauZus9znfaZNyBjPx3gyl 77n5seCUF54Q+PBODltX6zMnQCzxtSHcf+/KySoTskNqf3scbrYNfw+rR/MEPnB0 BK/wja1Jo7tHfDEPvJOBvOc7QzOv/aS6ytvc2hMxBt0yl18eVnYBfgq8P0sHbsMM UFnX0PgkdO8rcaEU29x1 =KMxk -----END PGP SIGNATURE----- --Apple-Mail=_730454EA-7C14-4F96-9548-200CE3398D6F-- From nobody Wed Mar 1 05:18:59 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6581295D9 for ; Wed, 1 Mar 2017 05:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5IVY2ZFyxfo for ; Wed, 1 Mar 2017 05:18:56 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0122.outbound.protection.outlook.com [23.103.200.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA5E1295D0 for ; Wed, 1 Mar 2017 05:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KGV9SLW6OObsRsNCkK0ACHi3o5nFnrbiAvaVNZSoLMk=; b=iIERUT6FyaSpT9eX84U8CqpRFeTrtOQK+3JlaT4e83uEnXUzkxos6Ng2xMC3w86/DdNbn9drULC14/YQqW8ScPKbBInQWe4G80X1gBLKrsgCfBtGQgBrXOeGwCQpP8t9Gq5T0hvEFZ7jo8rckCSS/eqDblwZVEFlVq/w0c/CVQE= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Wed, 1 Mar 2017 13:18:55 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0933.016; Wed, 1 Mar 2017 13:18:55 +0000 From: "Dang, Quynh (Fed)" To: Aaron Zauner Thread-Topic: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). Thread-Index: AQHSj3N1z8IXvDyfJEuMUkRo/k0w1KF/+8GA//+uQQA= Date: Wed, 1 Mar 2017 13:18:54 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> In-Reply-To: <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: azet.org; dkim=none (message not signed) header.d=none;azet.org; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: a679fd2b-c3d1-401e-2f66-08d460a58306 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:X4o1ZDyGmSxfgOObWJ/OQDihiQIroHoBXJJHj2mR9nfcen+VZgZ9uRO660He8vvn57ZZ6W1/V0sNMOeqBELIRjUbDrO5foxcNO/CMRa6pmgzscaux5CRHSbYUT4PbHCA+iQek4AuApaB8BiTImucvf46YU0jNLRsuLIgxwXQm541K9HOxdwNh+l4MnBkQ5pfKqENhscpvv7KfzoocKRRxFNOCGEy0R4WK0fYW+wvG/ZRDdnvrBwsNuBFKjtAjKKSg6/K6UDjwKlDPIeeM6uRjIYcm4w0tO6KrElazJafp0jWs3DOmbgP+f6Wkes1DD7yJOQQoMO9YbqJemA73AY1Pg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39410400002)(39840400002)(39860400002)(39450400003)(24454002)(377454003)(7736002)(6246003)(86362001)(54356999)(76176999)(6486002)(50986999)(53936002)(2950100002)(6916009)(4326008)(5660300001)(189998001)(38730400002)(106116001)(53546006)(110136004)(3660700001)(102836003)(77096006)(83506001)(2906002)(66066001)(2900100001)(6436002)(6506006)(122556002)(229853002)(8676002)(36756003)(8936002)(92566002)(3846002)(236005)(99286003)(6116002)(6512007)(54896002)(54906002)(81166006)(25786008)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4DC341D311E1qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 13:18:54.8422 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461 Archived-At: Cc: IRTF CFRG , "" , Sean Turner Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 13:18:58 -0000 --_000_D4DC341D311E1qdangnistgov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Aaron Zauner > Date: Wednesday, March 1, 2017 at 8:11 AM To: 'Quynh' > Cc: Sean Turner >, ">" >, IRTF CFRG > Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769= ). On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) > wrote: Hi Sean, Joe, Eric and all, I would like to address my thoughts/suggestions on 2 issues in option a. 1) The data limit should be addressed in term of blocks, not records. When = the record size is not the full size, some user might not know what to do. = When the record size is 1 block, the limit of 2^24.5 blocks (records) is wa= y too low unnecessarily for the margin of 2^-60. In that case, 2^34.5 1-bl= ock records is the limit which still achieves the margin of 2^-60. I respectfully disagree. TLS deals in records not in blocks, so in the end = any semantic change here will just confuse implementors, which isn't a good= idea in my opinion. Over the discussion of the PRs, the preference was blocks. Quynh. Aaron --_000_D4DC341D311E1qdangnistgov_ Content-Type: text/html; charset="us-ascii" Content-ID: <595E4712A92CFB47929993E3FDF9ED5B@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable


From: Aaron Zauner <azet@azet.org>
Date: Wednesday, March 1, 2017 at 8= :11 AM
To: 'Quynh' <Quynh.Dang@nist.gov>
Cc: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tl= s@ietf.org>, IRTF CFRG <cfrg@irt= f.org>
Subject: Re: [Cfrg] Closing out tls= 1.3 "Limits on key usage" PRs (#765/#769).


On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
Hi Sean, Joe, Eric and all,
I would like to address my thoughts/suggestions on 2 issues in option = a.
1) The data limit should be addressed in term of blocks, not records. = When the record size is not the full size, some user might not know what to= do. When the record size is 1 block, the limit of 2^24.5 blocks (records) = is way too low unnecessarily for the margin of 2^-60.  In that case, 2^34.5 1-block records is th= e limit which still achieves the margin of 2^-60.

I respectfully disagree. TLS deals in records not in blocks, so in the= end any semantic change here will just confuse implementors, which isn't a= good idea in my opinion.

Over the discussion of the PRs, the preference was blocks. 

Quynh. 



Aaron

 --_000_D4DC341D311E1qdangnistgov_-- From nobody Wed Mar 1 06:24:52 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70AF12955A for ; Wed, 1 Mar 2017 06:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Hl6_Y9SBkvH for ; Wed, 1 Mar 2017 06:24:46 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537FB12940C for ; Wed, 1 Mar 2017 06:24:44 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id u108so31326209wrb.3 for ; Wed, 01 Mar 2017 06:24:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=E+6wN7j5giQLnctTPVLqaSdM4DtM05NXOsMfxaOqxQE=; b=cRD12fUtjEaJyBUaUsKAl/tgbD6IDOnlI8tFe0RQt0pR4GFUI3MG1VzvvuVLiyxUFj cDrObwXra3icL8l4/Ja/ZlhbKVyOCkSU5y9O6WPAaNKw36TljIbfeuAzvWftPUsCjLGJ O8e2rqxIaGUMeD+KNWSNzFz++W78Isx28KjDk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=E+6wN7j5giQLnctTPVLqaSdM4DtM05NXOsMfxaOqxQE=; b=dXOYQwQ/Q/mf5Op8DzhC8p1u0vvGqw/ueYkra20JeJ7X1pWhh0yeVNrSWDeFkmoykH xtTMNj9U/4F14KuNR/lHO29asBi/PRgHrvGppcN3l1p9IFFJ4EqfGBx5OwIq+Yds+NL6 n1wk/EzU6JssJEO8BwtlEJzfJobp3MRYQGhRFBUEEQGk+oSdSDSq8zYU2GKv7XCWrwYN lWM6QEmoMMnoQlYOlV7IOqXvAwLy2uvH2dfU+v/2MGVDFavJWeVgj/jTPeAyF5kiqad+ uOMK9rEjMBhAfyfEfuom6RSQhsAZE0/Ieu/Mz/2Equ0OFj7MYEAvoe8mveBI/BMko/s9 pwdQ== X-Gm-Message-State: AMke39nf0oUJBg9KEgChEVRN7dWKA8PvchvJpbnJupHlcgqF6oVRd8kMH7BR5b06FLGSSQ== X-Received: by 10.223.175.196 with SMTP id y4mr7417080wrd.77.1488378282826; Wed, 01 Mar 2017 06:24:42 -0800 (PST) Received: from [192.168.1.121] ([160.178.204.57]) by smtp.gmail.com with ESMTPSA id p93sm6780589wrc.67.2017.03.01.06.24.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Mar 2017 06:24:42 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7A411B51-E70C-45CA-9662-6BFD89ADE5E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Aaron Zauner In-Reply-To: Date: Wed, 1 Mar 2017 14:24:37 +0000 Message-Id: <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> To: "Dang, Quynh (Fed)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IRTF CFRG , "" , Sean Turner Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 14:24:47 -0000 --Apple-Mail=_7A411B51-E70C-45CA-9662-6BFD89ADE5E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) = wrote: >=20 >=20 >=20 > From: Aaron Zauner > Date: Wednesday, March 1, 2017 at 8:11 AM > To: 'Quynh' > Cc: Sean Turner , "" , = IRTF CFRG > Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs = (#765/#769). >=20 >>=20 >>> On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) = wrote: >>> Hi Sean, Joe, Eric and all, >>> I would like to address my thoughts/suggestions on 2 issues in = option a. >>> 1) The data limit should be addressed in term of blocks, not = records. When the record size is not the full size, some user might not = know what to do. When the record size is 1 block, the limit of 2^24.5 = blocks (records) is way too low unnecessarily for the margin of 2^-60. = In that case, 2^34.5 1-block records is the limit which still achieves = the margin of 2^-60. >>=20 >> I respectfully disagree. TLS deals in records not in blocks, so in = the end any semantic change here will just confuse implementors, which = isn't a good idea in my opinion. >=20 > Over the discussion of the PRs, the preference was blocks. I don't see a clear preference. I see Brian Smith suggested switching to = blocks to be more precise in a PR. But in general it seems to me that = "Option A" was preferred in this thread anyhow - so these PRs aren't = relevant? I'm not sure that text on key-usage limits in blocks in a spec = that fundamentally deals in records is less confusing, quite the = opposite (at least to me). As I pointed out earlier: I strongly = recommend that any changes to the spec are as clear als possible to = engineers (non-crypto/math people) -- e.g. why the spec is suddenly = dealing in blocks instead of records et cetera. Again; I really don't = see any reason to change text here - to me all suggested changes are = even more confusing. Aaron --Apple-Mail=_7A411B51-E70C-45CA-9662-6BFD89ADE5E9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYttmmAAoJEOTbZJL9ubXVLj8P/1uOMf2t1u+IcxFcv+UnoXYg yAt1hVlI+oGsaNHTTZgnyByvoqgivwx43r/MYV6vBTwm1ZkC2eSYeYIotqh4YJSB QE8Cr+rJu+LqbBnBnpVJxJzx9Szc9jkYlMvwemfaz7hFs/Jw9t6U80WtDIrxSdSn XUrw7u9idGRvhIHhRRZcI9/9GaaXOu4Z1HBq5CpMrfPZ2yP1Y9FmpTxIjtI13VsC 6pHtqgqO7rbqZM6Kb12SUmUwcOsu7oeHToWzAJN5X+55yabBGX4lfdERe/Yyp2M1 f32xE+6unw7jj9hoZV9IPvYvNqKI6Tyd/YlzOwwgbv6GMWawJ4uO4xPjwVc71BvD 3626kXB9LIs6EhTHPay4wX3/3E2LDoqaXA4bE6edoLBLc+BnYJDYdL72v1Go5Ffv KsdpNsqqnCmQ7RYbZFEKy6430NIRLGGOuC1pcz1XxH7FtSPcWHa5a87VGZAq2ZjP QL3DU71M6p+TL2AGLNvCVgOyB0vu9g8eIBjPPip/SrD9rCIQBdJcJPySnpgkScjq tIGTuJRQWb59OIuQ9tFFZ18POX4HS8s3Xbp4Hr3fGeaCY227Et+wZh9Vh5rti4Bv Yih1X1T/cajvkX5jhdqoBC6KBAEv94JtOXpHbz3Wf2PFUWD91jizWdpm+1EqqNlC l+pFOdGqFpB6kxrRbn6T =05qZ -----END PGP SIGNATURE----- --Apple-Mail=_7A411B51-E70C-45CA-9662-6BFD89ADE5E9-- From nobody Wed Mar 1 06:31:40 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A951012940C for ; Wed, 1 Mar 2017 06:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bfreq7w10WzH for ; Wed, 1 Mar 2017 06:31:33 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0108.outbound.protection.outlook.com [23.103.201.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295ED12954C for ; Wed, 1 Mar 2017 06:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=M2g1eztAId+QHNq5+KMh9itnFJFl574ik456g/jR1tI=; b=NUKcLiHSL8XgSJ2oI/LrdfNH6vew64bmAu143dNrI15fb9q6UeY9nbS7Vyvxi0sG0jL1l8aVhYR9vFrrJ0lS2stzY9JQ+O0fsUiOuZcjnSfsk1ueaNOQ3xvRxvxIA5RtVHf5PFA37XfdgtYEHDFRJeojHRG2GWq43iGjWKwvEY0= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Wed, 1 Mar 2017 14:31:31 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0933.016; Wed, 1 Mar 2017 14:31:30 +0000 From: "Dang, Quynh (Fed)" To: Aaron Zauner , "Dang, Quynh (Fed)" Thread-Topic: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). Thread-Index: AQHSj3N1z8IXvDyfJEuMUkRo/k0w1KF/+8GA//+uQQCAAGYzgP//rheA Date: Wed, 1 Mar 2017 14:31:30 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> In-Reply-To: <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: azet.org; dkim=none (message not signed) header.d=none;azet.org; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:LlIukQqq6F7mxgo0E8/8lKsyrcbaT3WQYyLDe9SpStnV1mIOZGGRwlQCt9S5gQ+nwH2+4ncBCXxd9USsAaet/GmqohO+QJReDdwBqSBvr2tTogtA+o6cqud+gI7aawRj8mjPRHOy1g1woWY1QebkkKo16/lzvTUoA1kts4JeDKFhA0qabzeWwz0nfRXO7Sp6K2LZ3xzhNN2oJ2BxxCZIU5ce7k9YyhWgyqxn1haxY0hYMEMdKuaX+ZeXcaBmTRvzwZvGqQ5nKp+H6NQXK9ddqwva0Mq34N6ziGUmLA5Kc9JgL66LCKGsQaL20Rc+Kw0+kCCasWv+7l7Dw78HJ1z6gQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39840400002)(39450400003)(39410400002)(39850400002)(24454002)(377454003)(6506006)(6436002)(122556002)(66066001)(2900100001)(229853002)(2906002)(83506001)(102836003)(77096006)(81166006)(54906002)(54896002)(6512007)(3280700002)(25786008)(8936002)(92566002)(8676002)(36756003)(6116002)(99286003)(3846002)(236005)(54356999)(6486002)(76176999)(50986999)(93886004)(6246003)(7736002)(86362001)(106116001)(53546006)(189998001)(38730400002)(3660700001)(53936002)(2950100002)(5660300001)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: a4c94d87-d5ce-4d9c-986e-08d460afa711 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; x-forefront-prvs: 0233768B38 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4DC4473311F2qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 14:31:30.1271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461 Archived-At: Cc: IRTF CFRG , "" , Sean Turner Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 14:31:35 -0000 --_000_D4DC4473311F2qdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Aaron Zauner > Date: Wednesday, March 1, 2017 at 9:24 AM To: 'Quynh' > Cc: Sean Turner >, ">" >, IRTF CFRG > Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769= ). On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) > wrote: From: Aaron Zauner > Date: Wednesday, March 1, 2017 at 8:11 AM To: 'Quynh' > Cc: Sean Turner >, ">" >, IRTF CFRG > Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769= ). On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) > wrote: Hi Sean, Joe, Eric and all, I would like to address my thoughts/suggestions on 2 issues in option a. 1) The data limit should be addressed in term of blocks, not records. When = the record size is not the full size, some user might not know what to do. = When the record size is 1 block, the limit of 2^24.5 blocks (records) is wa= y too low unnecessarily for the margin of 2^-60. In that case, 2^34.5 1-bl= ock records is the limit which still achieves the margin of 2^-60. I respectfully disagree. TLS deals in records not in blocks, so in the end = any semantic change here will just confuse implementors, which isn't a good= idea in my opinion. Over the discussion of the PRs, the preference was blocks. I don't see a clear preference. I see Brian Smith suggested switching to bl= ocks to be more precise in a PR. But in general it seems to me that "Option= A" was preferred in this thread anyhow - so these PRs aren't relevant? I'm= not sure that text on key-usage limits in blocks in a spec that fundamenta= lly deals in records is less confusing, quite the opposite (at least to me)= . As I pointed out earlier: I strongly recommend that any changes to the sp= ec are as clear als possible to engineers (non-crypto/math people) -- e.g. = why the spec is suddenly dealing in blocks instead of records et cetera. Ag= ain; I really don't see any reason to change text here - to me all suggeste= d changes are even more confusing. Hi Aaron, The technical reasons I explained are reasons for using records. I don=92t= see how that is confusing. If you like records, then the record number =3D the total blocks / the reco= rd size in blocks: this is simplest already. Quynh. Aaron --_000_D4DC4473311F2qdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <62B4F4EBC219C747A5E248B268771BCD@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable


From: Aaron Zauner <azet@azet.org>
Date: Wednesday, March 1, 2017 at 9= :24 AM
To: 'Quynh' <Quynh.Dang@nist.gov>
Cc: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tl= s@ietf.org>, IRTF CFRG <cfrg@irt= f.org>
Subject: Re: [Cfrg] Closing out tls= 1.3 "Limits on key usage" PRs (#765/#769).


On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
From: Aaron Zauner <azet@azet.org<= /a>>
Date: Wednesday, March 1, 2017 at 8:11 AM
Cc: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>"= ; <tls@ietf.org>, IRTF CFRG <<= a href=3D"mailto:cfrg@irtf.org">cfrg@irtf.org>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage"= PRs (#765/#769).
On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
Hi Sean, Joe, Eric and all,
I would like to address my thoughts/suggestions on 2 issues in option = a.
1) The data limit should be addressed in term of blocks, not records. = When the record size is not the full size, some user might not know what to= do. When the record size is 1 block, the limit of 2^24.5 blocks (records) = is way too low unnecessarily for the margin of 2^-60.  In that case, 2^34.5 1-block records is th= e limit which still achieves the margin of 2^-60.
I respectfully disagree. TLS deals in records not in blocks, so in the= end any semantic change here will just confuse implementors, which isn't a= good idea in my opinion.
Over the discussion of the PRs, the preference was blocks.

I don't see a clear preference. I see Brian Smith suggested switching = to blocks to be more precise in a PR. But in general it seems to me that &q= uot;Option A" was preferred in this thread anyhow - so these PRs aren'= t relevant? I'm not sure that text on key-usage limits in blocks in a spec that fundamentally deals in records is less con= fusing, quite the opposite (at least to me). As I pointed out earlier: I st= rongly recommend that any changes to the spec are as clear als possible to = engineers (non-crypto/math people) -- e.g. why the spec is suddenly dealing in blocks instead of records et c= etera. Again; I really don't see any reason to change text here - to me all= suggested changes are even more confusing.

Hi Aaron,

The  technical reasons I explained are reasons for using records.= I don=92t see how that is confusing.

If you like records, then the record number =3D the total blocks / the= record size in blocks: this is simplest already. 

Quynh.  





Aaron


 --_000_D4DC4473311F2qdangnistgov_-- From nobody Wed Mar 1 06:38:14 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D265129476 for ; Wed, 1 Mar 2017 06:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glYS0I5oWLPJ for ; Wed, 1 Mar 2017 06:38:08 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0075.outbound.protection.outlook.com [104.47.1.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9AD129486 for ; Wed, 1 Mar 2017 06:38:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P9i0mCP6vGjwxggAbO+vsotzgjbmLCuISYVIWWdGU/c=; b=Q6e7xcuPBlbUx7GwdV6Exb6FitYH2/tUls2LF1tI0plBjfeRMzHihvF63vI5CCHCuRErXekN0glE2baokpfle7Pe77Qm2al1i+VsimC+Q4505Pfw0cX3wYWotxBHTfl0Z+mU4KaRTxFYz94tCxiO9kG5Ka/kRSA39EUl7Od8s+8= Received: from HE1PR0301MB1916.eurprd03.prod.outlook.com (10.167.188.8) by HE1PR0301MB1913.eurprd03.prod.outlook.com (10.167.187.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Wed, 1 Mar 2017 14:38:04 +0000 Received: from HE1PR0301MB1916.eurprd03.prod.outlook.com ([10.167.188.8]) by HE1PR0301MB1916.eurprd03.prod.outlook.com ([10.167.188.8]) with mapi id 15.01.0933.020; Wed, 1 Mar 2017 14:38:04 +0000 From: "Paterson, Kenny" To: "Dang, Quynh (Fed)" , Aaron Zauner Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). Thread-Index: AQHSkplvWMtDYzfg7Eqo+yVbFyANhQ== Date: Wed, 1 Mar 2017 14:38:04 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: nist.gov; dkim=none (message not signed) header.d=none;nist.gov; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [118.7.148.183] x-microsoft-exchange-diagnostics: 1; HE1PR0301MB1913; 7:FDHJwklbiyuFwGPDyLZ1xFrnb9JN/9xrzFN9iUwVPV7SkB7oE55/ByPyIBL2H06okEfKSBIfaPAQ7s/UD07Nr/FkQFxjDNcCmVyqeJ7SwBF8ri7MwCWZQocsFOjY5UIVmQ2/I38HA3ThKJXUYIP8gm7EPcyTmneU7e2sR2jZF2BkMZNLAStDd7yoj7qRlcYUWGG0yJ6hj6FOF/RgFbk9qqDyaL5+V/a0t15WTHd0lTiaAIPbsrmf4Zz3RqPlgwjfLfYcWfg51zUlanJ+yBNeZ5kA9UGv/dMIrF+NeZ3zMaIM6cLAfa0E49YyEReEfYm6hSFvnYF4D4sOwLXr9Ibiww== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(377454003)(6436002)(74482002)(66066001)(54906002)(83506001)(93886004)(25786008)(53936002)(86362001)(7736002)(8676002)(53546006)(6486002)(38730400002)(2950100002)(5660300001)(42882006)(77096006)(2900100001)(92566002)(6506006)(50986999)(6512007)(106116001)(3846002)(76176999)(54356999)(6246003)(102836003)(6116002)(229853002)(189998001)(8656002)(81166006)(99286003)(8936002)(3660700001)(3280700002)(122556002)(2906002)(36756003)(4326008)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0301MB1913; H:HE1PR0301MB1916.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: c2659d18-a81b-458f-e98d-08d460b091cf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0301MB1913; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:HE1PR0301MB1913; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB1913; x-forefront-prvs: 0233768B38 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 14:38:04.2446 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB1913 Archived-At: Cc: IRTF CFRG , "" Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 14:38:11 -0000 SGksDQoNCk9uIDAxLzAzLzIwMTcgMTQ6MzEsICJUTFMgb24gYmVoYWxmIG9mIERhbmcsIFF1eW5o IChGZWQpIg0KPHRscy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBxdXluaC5kYW5nQG5p c3QuZ292PiB3cm90ZToNCj5Gcm9tOiBBYXJvbiBaYXVuZXIgPGF6ZXRAYXpldC5vcmc+DQo+RGF0 ZTogV2VkbmVzZGF5LCBNYXJjaCAxLCAyMDE3IGF0IDk6MjQgQU0NCj5UbzogJ1F1eW5oJyA8UXV5 bmguRGFuZ0BuaXN0Lmdvdj4NCj5DYzogU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPiwgIjx0 bHNAaWV0Zi5vcmc+IiA8dGxzQGlldGYub3JnPiwgSVJURg0KPkNGUkcgPGNmcmdAaXJ0Zi5vcmc+ DQo+U3ViamVjdDogUmU6IFtDZnJnXSBDbG9zaW5nIG91dCB0bHMxLjMgIkxpbWl0cyBvbiBrZXkg dXNhZ2UiIFBScw0KPigjNzY1LyM3NjkpLg0KPg0KPg0KPg0KPj4NCj4+DQo+Pj5PbiAwMSBNYXIg MjAxNywgYXQgMTM6MTgsIERhbmcsIFF1eW5oIChGZWQpIDxxdXluaC5kYW5nQG5pc3QuZ292PiB3 cm90ZToNCj4+PkZyb206IEFhcm9uIFphdW5lciA8YXpldEBhemV0Lm9yZz4NCj4+PkRhdGU6IFdl ZG5lc2RheSwgTWFyY2ggMSwgMjAxNyBhdCA4OjExIEFNDQo+Pj5UbzogJ1F1eW5oJyA8UXV5bmgu RGFuZ0BuaXN0Lmdvdj4NCj4+PkNjOiBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+LCAiPHRs c0BpZXRmLm9yZz4iIDx0bHNAaWV0Zi5vcmc+LCBJUlRGDQo+Pj5DRlJHIDxjZnJnQGlydGYub3Jn Pg0KPj4+U3ViamVjdDogUmU6IFtDZnJnXSBDbG9zaW5nIG91dCB0bHMxLjMgIkxpbWl0cyBvbiBr ZXkgdXNhZ2UiIFBScw0KPj4+KCM3NjUvIzc2OSkuDQo+Pj4+Pk9uIDI1IEZlYiAyMDE3LCBhdCAx NDoyOCwgRGFuZywgUXV5bmggKEZlZCkgPHF1eW5oLmRhbmdAbmlzdC5nb3Y+DQo+Pj4+Pndyb3Rl Og0KPj4+Pj5IaSBTZWFuLCBKb2UsIEVyaWMgYW5kIGFsbCwNCj4+Pj4+SSB3b3VsZCBsaWtlIHRv IGFkZHJlc3MgbXkgdGhvdWdodHMvc3VnZ2VzdGlvbnMgb24gMiBpc3N1ZXMgaW4gb3B0aW9uDQo+ Pj4+PmEuDQo+Pj4+PjEpIFRoZSBkYXRhIGxpbWl0IHNob3VsZCBiZSBhZGRyZXNzZWQgaW4gdGVy bSBvZiBibG9ja3MsIG5vdCByZWNvcmRzLg0KPj4+Pj5XaGVuIHRoZSByZWNvcmQgc2l6ZSBpcyBu b3QgdGhlIGZ1bGwgc2l6ZSwgc29tZSB1c2VyIG1pZ2h0IG5vdCBrbm93DQo+Pj4+PndoYXQgdG8g ZG8uIFdoZW4gdGhlIHJlY29yZCBzaXplIGlzIDEgYmxvY2ssIHRoZSBsaW1pdCBvZiAyXjI0LjUN Cj4+Pj4+YmxvY2tzIChyZWNvcmRzKSBpcyB3YXkgdG9vIGxvdyB1bm5lY2Vzc2FyaWx5IGZvcg0K Pj4+Pj4gdGhlIG1hcmdpbiBvZiAyXi02MC4gIEluIHRoYXQgY2FzZSwgMl4zNC41IDEtYmxvY2sg cmVjb3JkcyBpcyB0aGUNCj4+Pj4+bGltaXQgd2hpY2ggc3RpbGwgYWNoaWV2ZXMgdGhlIG1hcmdp biBvZiAyXi02MC4NCj4+Pj5JIHJlc3BlY3RmdWxseSBkaXNhZ3JlZS4gVExTIGRlYWxzIGluIHJl Y29yZHMgbm90IGluIGJsb2Nrcywgc28gaW4gdGhlDQo+Pj4+ZW5kIGFueSBzZW1hbnRpYyBjaGFu Z2UgaGVyZSB3aWxsIGp1c3QgY29uZnVzZSBpbXBsZW1lbnRvcnMsIHdoaWNoDQo+Pj4+aXNuJ3Qg YSBnb29kIGlkZWEgaW4gbXkgb3Bpbmlvbi4NCj4+Pk92ZXIgdGhlIGRpc2N1c3Npb24gb2YgdGhl IFBScywgdGhlIHByZWZlcmVuY2Ugd2FzIGJsb2Nrcy4NCj4+DQo+Pg0KPj5JIGRvbid0IHNlZSBh IGNsZWFyIHByZWZlcmVuY2UuIEkgc2VlIEJyaWFuIFNtaXRoIHN1Z2dlc3RlZCBzd2l0Y2hpbmcg dG8NCj4+YmxvY2tzIHRvIGJlIG1vcmUgcHJlY2lzZSBpbiBhIFBSLiBCdXQgaW4gZ2VuZXJhbCBp dCBzZWVtcyB0byBtZSB0aGF0DQo+PiJPcHRpb24gQSIgd2FzIHByZWZlcnJlZCBpbiB0aGlzIHRo cmVhZCBhbnlob3cgLSBzbyB0aGVzZSBQUnMgYXJlbid0DQo+PnJlbGV2YW50PyBJJ20gbm90IHN1 cmUgdGhhdCB0ZXh0IG9uIGtleS11c2FnZQ0KPj4gbGltaXRzIGluIGJsb2NrcyBpbiBhIHNwZWMg dGhhdCBmdW5kYW1lbnRhbGx5IGRlYWxzIGluIHJlY29yZHMgaXMgbGVzcw0KPj5jb25mdXNpbmcs IHF1aXRlIHRoZSBvcHBvc2l0ZSAoYXQgbGVhc3QgdG8gbWUpLiBBcyBJIHBvaW50ZWQgb3V0DQo+ PmVhcmxpZXI6IEkgc3Ryb25nbHkgcmVjb21tZW5kIHRoYXQgYW55IGNoYW5nZXMgdG8gdGhlIHNw ZWMgYXJlIGFzIGNsZWFyDQo+PmFscyBwb3NzaWJsZSB0byBlbmdpbmVlcnMgKG5vbi1jcnlwdG8v bWF0aCBwZW9wbGUpDQo+PiAtLSBlLmcuIHdoeSB0aGUgc3BlYyBpcyBzdWRkZW5seSBkZWFsaW5n IGluIGJsb2NrcyBpbnN0ZWFkIG9mIHJlY29yZHMNCj4+ZXQgY2V0ZXJhLiBBZ2FpbjsgSSByZWFs bHkgZG9uJ3Qgc2VlIGFueSByZWFzb24gdG8gY2hhbmdlIHRleHQgaGVyZSAtIHRvDQo+Pm1lIGFs bCBzdWdnZXN0ZWQgY2hhbmdlcyBhcmUgZXZlbiBtb3JlIGNvbmZ1c2luZy4NCj4+DQo+Pg0KPg0K Pg0KPkhpIEFhcm9uLA0KPg0KPg0KPlRoZSAgdGVjaG5pY2FsIHJlYXNvbnMgSSBleHBsYWluZWQg YXJlIHJlYXNvbnMgZm9yIHVzaW5nIHJlY29yZHMuIEkgZG9u4oCZdA0KPnNlZSBob3cgdGhhdCBp cyBjb25mdXNpbmcuDQo+DQo+DQo+SWYgeW91IGxpa2UgcmVjb3JkcywgdGhlbiB0aGUgcmVjb3Jk IG51bWJlciA9IHRoZSB0b3RhbCBibG9ja3MgLyB0aGUNCj5yZWNvcmQgc2l6ZSBpbiBibG9ja3M6 IHRoaXMgaXMgc2ltcGxlc3QgYWxyZWFkeS4NCj4NCg0KVGhhdCBmb3JtdWxhIGRvZXMgbm90IGNv cnJlY3RseSBjb21wdXRlIGhvdyBtYW55IHJlY29yZHMgaGF2ZSBiZWVuIHNlbnQgb24NCmEgY29u bmVjdGlvbiwgYmVjYXVzZSB0aGUgcmVjb3JkIHNpemUgaW4gYmxvY2tzIGlzIHZhcmlhYmxlLCBu b3QgY29uc3RhbnQuDQpZb3UgY2FuIG1vZGlmeSBpdCB0byBnZXQgYm91bmRzIG9uIHRoZSB0b3Rh bCBudW1iZXIgb2YgcmVjb3JkcyBzZW50LCBidXQNCnRoZSBib3VuZHMgYXJlIHNsb3BweSBiZWNh dXNlIHNvbWUgcmVjb3JkcyBvbmx5IGNvbnN1bWUgMiBibG9ja3MgKG9uZSBmb3INCmVuY3J5cHRp b24sIG9uZSBmb3IgbWFza2luZyBpbiBHSEFTSCkgd2hpbGUgc29tZSBjb25zdW1lIGZhciBtb3Jl Lg0KDQpJdCdzIHNpbXBsZXIgZm9yIGFuIGltcGxlbWVudGF0aW9uIHRvIGNvdW50IGhvdyBtYW55 IHJlY29yZHMgaGF2ZSBiZWVuDQpzZW50IG9uIGEgY29ubmVjdGlvbiAuLi4uIGJ5IHVzaW5nIHRo ZSBjb25uZWN0aW9uJ3Mgc2VxdWVuY2UgbnVtYmVyLiBUaGlzDQpwdXRzIGxlc3MgYnVyZGVuIG9u IHRoZSBpbXBsZW1lbnRhdGlvbi9pbXBsZW1lbnRlci4NCg0KQ2hlZXJzDQoNCktlbm55IA0KDQoN Cg== From nobody Wed Mar 1 06:48:43 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8991294A3 for ; Wed, 1 Mar 2017 06:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWcLWS16OgGI for ; Wed, 1 Mar 2017 06:48:38 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0098.outbound.protection.outlook.com [23.103.200.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2952D129495 for ; Wed, 1 Mar 2017 06:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bLv61Wtg4Svazk8WLu3tH4b3nL9WJLz46ZVIoYhzRn0=; b=AHz+vLxleJrH1VngnmE8T/U4ENzv4MZhq0ALzsaV/ASTAzxjmmU+76iiZ7RtbfpKBktaJ4m2pr3pTOdMf+6fqxllnYGcqa7H4I4g7zpO730H4owkEyGpigsgvp5SzlzjDwdjwxBODLBPk1MQXJgYHJIwNSI+iEc+sVBXPMKphCw= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Wed, 1 Mar 2017 14:48:37 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0933.016; Wed, 1 Mar 2017 14:48:36 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , "Dang, Quynh (Fed)" , Aaron Zauner Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). Thread-Index: AQHSj3N1z8IXvDyfJEuMUkRo/k0w1KF/+8GA//+uQQCAAGYzgP//rheAgABVqwD//68bAA== Date: Wed, 1 Mar 2017 14:48:36 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: rhul.ac.uk; dkim=none (message not signed) header.d=none;rhul.ac.uk; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:AA82+RjZZ4p+C2u8Rsb/4F6pYO/Z8Eh4yTnzWeexjQc5hLnjSU6qlUMw5+0aEZO2LS7ajIWxHKuPwMItfSrvqabQ2WD7SPjJHGvYajmIDWr90Y8CUhjDVWqnkfHYdLfCVdpc9cW0XqxAGecoiTiruZATQojS0/bIqXnFNoEBaTIx9CPGPJXJPNLOhZ1H3HPWnnQp8JC12UC/R59HQsKd8I6IHftzP19opGkOHimRFACDHtA7fcMNsefSLu/goQLZvct60BrLzxE2Ib/KlATbaCf+6kf4BDYbMjjSEOcr08TqI1A9tmRy/rjpSS3ErhnwU+QDaEaOBMzsudVJyq5xPA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(24454002)(377454003)(6246003)(7736002)(86362001)(8656002)(54356999)(93886004)(76176999)(6486002)(50986999)(53936002)(2950100002)(4326008)(5660300001)(189998001)(38730400002)(106116001)(53546006)(3660700001)(102836003)(77096006)(2906002)(83506001)(66066001)(2900100001)(6436002)(6506006)(122556002)(229853002)(36756003)(8676002)(8936002)(92566002)(3846002)(236005)(6116002)(99286003)(54906002)(54896002)(6512007)(81166006)(25786008)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: a2f78698-ee32-40ba-28d6-08d460b20ab1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; x-forefront-prvs: 0233768B38 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4DC48E231204qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 14:48:36.2847 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461 Archived-At: Cc: IRTF CFRG , "" Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 14:48:41 -0000 --_000_D4DC48E231204qdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: "Paterson, Kenny" > Date: Wednesday, March 1, 2017 at 9:38 AM To: 'Quynh' >, Aaron Zauner= > Cc: IRTF CFRG >, ">" > Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769). Hi, On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)" on behalf of quynh.dang@= nist.gov> wrote: From: Aaron Zauner > Date: Wednesday, March 1, 2017 at 9:24 AM To: 'Quynh' > Cc: Sean Turner >, ">" >, IRTF CFRG > Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) > wrote: From: Aaron Zauner > Date: Wednesday, March 1, 2017 at 8:11 AM To: 'Quynh' > Cc: Sean Turner >, ">" >, IRTF CFRG > Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) > wrote: Hi Sean, Joe, Eric and all, I would like to address my thoughts/suggestions on 2 issues in option a. 1) The data limit should be addressed in term of blocks, not records. When the record size is not the full size, some user might not know what to do. When the record size is 1 block, the limit of 2^24.5 blocks (records) is way too low unnecessarily for the margin of 2^-60. In that case, 2^34.5 1-block records is the limit which still achieves the margin of 2^-60. I respectfully disagree. TLS deals in records not in blocks, so in the end any semantic change here will just confuse implementors, which isn't a good idea in my opinion. Over the discussion of the PRs, the preference was blocks. I don't see a clear preference. I see Brian Smith suggested switching to blocks to be more precise in a PR. But in general it seems to me that "Option A" was preferred in this thread anyhow - so these PRs aren't relevant? I'm not sure that text on key-usage limits in blocks in a spec that fundamentally deals in records is less confusing, quite the opposite (at least to me). As I pointed out earlier: I strongly recommend that any changes to the spec are as clear als possible to engineers (non-crypto/math people) -- e.g. why the spec is suddenly dealing in blocks instead of records et cetera. Again; I really don't see any reason to change text here - to me all suggested changes are even more confusing. Hi Aaron, The technical reasons I explained are reasons for using records. I don=92t see how that is confusing. If you like records, then the record number =3D the total blocks / the record size in blocks: this is simplest already. That formula does not correctly compute how many records have been sent on a connection, because the record size in blocks is variable, not constant. You can modify it to get bounds on the total number of records sent, but the bounds are sloppy because some records only consume 2 blocks (one for encryption, one for masking in GHASH) while some consume far more. It's simpler for an implementation to count how many records have been sent on a connection .... by using the connection's sequence number. This puts less burden on the implementation/implementer. I think the record size is configurable and it does not change regularly in= the same session (or connection). Somebody corrects me here! Quynh. Cheers Kenny --_000_D4DC48E231204qdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <33123FDCE82F2B4E9BFAEE9561EF5730@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable


From: "Paterson, Kenny" &= lt;Kenny.Paterson@rhul.ac.uk>
Date: Wednesday, March 1, 2017 at 9= :38 AM
To: 'Quynh' <Quynh.Dang@nist.gov>, Aaron Zauner <azet@azet.org>
Cc: IRTF CFRG <cfrg@irtf.org>, "<tls@ietf.org>" <tls@ie= tf.org>
Subject: Re: [TLS] [Cfrg] Closing o= ut tls1.3 "Limits on key usage" PRs (#765/#769).

Hi,

On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)"
<tls-bounces@ietf.org o= n behalf of quynh.dang@nist.gov> wrote:
From: Aaron Zauner <azet@azet.org<= /a>>
Date: Wednesday, March 1, 2017 at 9:24 AM
Cc: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>"= ; <tls@ietf.org>, IRTF
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage"= PRs
(#765/#769).





On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
From: Aaron Zauner <azet@azet.org<= /a>>
Date: Wednesday, March 1, 2017 at 8:11 AM
Cc: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>"= ; <tls@ietf.org>, IRTF
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage"= PRs
(#765/#769).
On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) <quynh.dang@nist.gov>
wrote:
Hi Sean, Joe, Eric and all,
I would like to address my thoughts/suggestions on 2 issues in option<= /div>
a.
1) The data limit should be addressed in term of blocks, not records.<= /div>
When the record size is not the full size, some user might not know
what to do. When the record size is 1 block, the limit of 2^24.5
blocks (records) is way too low unnecessarily for
the margin of 2^-60.  In that case, 2^34.5 1-block records i= s the
limit which still achieves the margin of 2^-60.
I respectfully disagree. TLS deals in records not in blocks, so in the=
end any semantic change here will just confuse implementors, which
isn't a good idea in my opinion.
Over the discussion of the PRs, the preference was blocks.


I don't see a clear preference. I see Brian Smith suggested switching = to
blocks to be more precise in a PR. But in general it seems to me that<= /div>
"Option A" was preferred in this thread anyhow - so these PR= s aren't
relevant? I'm not sure that text on key-usage
limits in blocks in a spec that fundamentally deals in records is less=
confusing, quite the opposite (at least to me). As I pointed out
earlier: I strongly recommend that any changes to the spec are as clea= r
als possible to engineers (non-crypto/math people)
-- e.g. why the spec is suddenly dealing in blocks instead of records<= /div>
et cetera. Again; I really don't see any reason to change text here - = to
me all suggested changes are even more confusing.




Hi Aaron,


The  technical reasons I explained are reasons for using rec= ords. I don=92t
see how that is confusing.


If you like records, then the record number =3D the total blocks / the=
record size in blocks: this is simplest already.


That formula does not correctly compute how many records have been sen= t on
a connection, because the record size in blocks is variable, not const= ant.
You can modify it to get bounds on the total number of records sent, b= ut
the bounds are sloppy because some records only consume 2 blocks (one = for
encryption, one for masking in GHASH) while some consume far more.

It's simpler for an implementation to count how many records have been=
sent on a connection .... by using the connection's sequence number. T= his
puts less burden on the implementation/implementer.

I think the record size is configurable and it does not change regular= ly in the same session (or connection).  Somebody corrects me here!&nb= sp;

Quynh. 



Cheers

Kenny



--_000_D4DC48E231204qdangnistgov_-- From nobody Wed Mar 1 10:37:02 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B90129668 for ; Wed, 1 Mar 2017 10:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcPHZd_yBmnw for ; Wed, 1 Mar 2017 10:36:59 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730DF12964E for ; Wed, 1 Mar 2017 10:36:59 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id 196so30956770wmm.1 for ; Wed, 01 Mar 2017 10:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u/zHggTYzfNirQVlKzJwj+TEM4D6LxIhVdKeKly5QQU=; b=rO7X1N66J3AE5uTmb9P7Z7RqX6tWi4gMsDzf7+iHHoFGDQMJgh/6D4FNoOTYC6f+sI oQFm6LlVEBrgmgQ6/Li4mhTGk3K0ouvq1fhuGhADv5KUZWn6Oq0neC2xYjClHR4Q6VzO SDBw6oC/UHeLIB9Zfgen1D6mbvjPBZpfynw7x6R4lzZf9sND7Zr8u68rYXZ8olwvMfIi CKxu++ePyf8TEBo7it/aWGbZxdbzolLmc7IYkQzs376OmlNqpEQwYjmqmthfu4jzrS1n xMpFT6QXqPhP0tg/g3vusLlF0r5/7UoXxGzaiWKy2c/yoPmBwC3+tcwKrbsKcDgkTmmN EC3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u/zHggTYzfNirQVlKzJwj+TEM4D6LxIhVdKeKly5QQU=; b=DywcfVzptelIybhD3pNictI/kVIfh35F6//Io7XqGA4x4Dtlqhxw9nfy9DbW9G7DNU 1pXi4vnmslxlkF4OO+mg1ywT0oQCvcB4pIrZWvSXbMgVA4amsqD0Lq85QRqb8YT9NTw0 DAN94TyhM8Ru+uTCKvPWTjAKsks7qJ8xMIBXpmZaMp9saMlw9L0OTuO4xRDuq1O0Gab0 1jALY1esQq6UpPLUfKBmRHY7gU7iBfcJ43X+0cGOnjSolfD3lP4ATJfGNgS698wvR+kW G0hwX2+GF6twNgZCMkb903olHDc6MzmsNO+wdyYAlMIndlySgfVz9KBnLyBitT8trguA bpIA== X-Gm-Message-State: AMke39nMmKenjfMCB8Rw4vfAMf7rRWl5PlKZEyllNRlggTgWlxDhH1Btsj8GR02Q106pe36E9a02lrErlGwSzQ== X-Received: by 10.28.165.147 with SMTP id o141mr4160034wme.67.1488393417898; Wed, 01 Mar 2017 10:36:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.163.2 with HTTP; Wed, 1 Mar 2017 10:36:57 -0800 (PST) Received: by 10.223.163.2 with HTTP; Wed, 1 Mar 2017 10:36:57 -0800 (PST) In-Reply-To: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> From: Watson Ladd Date: Wed, 1 Mar 2017 10:36:57 -0800 Message-ID: To: "Dang, Quynh" Content-Type: multipart/alternative; boundary=001a114b40aef5c17a0549af98f0 Archived-At: Cc: cfrg@irtf.org, tls@ietf.org Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 18:37:01 -0000 --001a114b40aef5c17a0549af98f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That is not how HTTP works. Lots of records are small because they result from small writes. On Mar 1, 2017 6:48 AM, "Dang, Quynh (Fed)" wrote: > > > From: "Paterson, Kenny" > Date: Wednesday, March 1, 2017 at 9:38 AM > To: 'Quynh' , Aaron Zauner > Cc: IRTF CFRG , "" > Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs > (#765/#769). > > Hi, > > On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)" > wrote: > > From: Aaron Zauner > Date: Wednesday, March 1, 2017 at 9:24 AM > To: 'Quynh' > Cc: Sean Turner , "" , IRTF > CFRG > Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs > (#765/#769). > > > > > > On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) wrote: > From: Aaron Zauner > Date: Wednesday, March 1, 2017 at 8:11 AM > To: 'Quynh' > Cc: Sean Turner , "" , IRTF > CFRG > Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs > (#765/#769). > > On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) > wrote: > Hi Sean, Joe, Eric and all, > I would like to address my thoughts/suggestions on 2 issues in option > a. > 1) The data limit should be addressed in term of blocks, not records. > When the record size is not the full size, some user might not know > what to do. When the record size is 1 block, the limit of 2^24.5 > blocks (records) is way too low unnecessarily for > the margin of 2^-60. In that case, 2^34.5 1-block records is the > limit which still achieves the margin of 2^-60. > > I respectfully disagree. TLS deals in records not in blocks, so in the > end any semantic change here will just confuse implementors, which > isn't a good idea in my opinion. > > Over the discussion of the PRs, the preference was blocks. > > > > I don't see a clear preference. I see Brian Smith suggested switching to > blocks to be more precise in a PR. But in general it seems to me that > "Option A" was preferred in this thread anyhow - so these PRs aren't > relevant? I'm not sure that text on key-usage > limits in blocks in a spec that fundamentally deals in records is less > confusing, quite the opposite (at least to me). As I pointed out > earlier: I strongly recommend that any changes to the spec are as clear > als possible to engineers (non-crypto/math people) > -- e.g. why the spec is suddenly dealing in blocks instead of records > et cetera. Again; I really don't see any reason to change text here - to > me all suggested changes are even more confusing. > > > > > Hi Aaron, > > > The technical reasons I explained are reasons for using records. I don= =E2=80=99t > see how that is confusing. > > > If you like records, then the record number =3D the total blocks / the > record size in blocks: this is simplest already. > > > That formula does not correctly compute how many records have been sent o= n > a connection, because the record size in blocks is variable, not constant= . > You can modify it to get bounds on the total number of records sent, but > the bounds are sloppy because some records only consume 2 blocks (one for > encryption, one for masking in GHASH) while some consume far more. > > It's simpler for an implementation to count how many records have been > sent on a connection .... by using the connection's sequence number. This > puts less burden on the implementation/implementer. > > > I think the record size is configurable and it does not change regularly > in the same session (or connection). Somebody corrects me here! > > Quynh. > > > > Cheers > > Kenny > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114b40aef5c17a0549af98f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That is not how HTTP works. Lots of records are small bec= ause they result from small writes.

On Mar 1, 2017 6:48 AM, "Dang, Quynh (Fed)&quo= t; <quynh.dang@nist.gov> w= rote:


From: "Paterson, Kenny" &= lt;Kenny.Pat= erson@rhul.ac.uk>
Date: Wednesday, March 1, 2017 at 9= :38 AM
To: 'Quynh' <Quynh.Dang@nist.gov>, = Aaron Zauner <azet@az= et.org>
Cc: IRTF CFRG <cfrg@irtf.org>, "<tls@ietf.org>" <<= a href=3D"mailto:tls@ietf.org" target=3D"_blank">tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Closing o= ut tls1.3 "Limits on key usage" PRs (#765/#769).

Hi,

On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)"
From: Aaron Zauner <azet@azet.org>
Date: Wednesday, March 1, 2017 at 9:24 AM
To: 'Quynh' <Quynh.Dang@nist.gov>
Cc: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>, IRTF
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage"= PRs
(#765/#769).





On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
From: Aaron Zauner <azet@azet.org>
Date: Wednesday, March 1, 2017 at 8:11 AM
To: 'Quynh' <Quynh.Dang@nist.gov>
Cc: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>, IRTF
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage"= PRs
(#765/#769).
On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) <quynh.dang@nist.gov>
wrote:
Hi Sean, Joe, Eric and all,
I would like to address my thoughts/suggestions on 2 issues in option<= /div>
a.
1) The data limit should be addressed in term of blocks, not records.<= /div>
When the record size is not the full size, some user might not know
what to do. When the record size is 1 block, the limit of 2^24.5
blocks (records) is way too low unnecessarily for
the margin of 2^-60.=C2=A0=C2=A0In that case, 2^34.5 1-block records i= s the
limit which still achieves the margin of 2^-60.
I respectfully disagree. TLS deals in records not in blocks, so in the=
end any semantic change here will just confuse implementors, which
isn't a good idea in my opinion.
Over the discussion of the PRs, the preference was blocks.


I don't see a clear preference. I see Brian Smith suggested switch= ing to
blocks to be more precise in a PR. But in general it seems to me that<= /div>
"Option A" was preferred in this thread anyhow - so these PR= s aren't
relevant? I'm not sure that text on key-usage
limits in blocks in a spec that fundamentally deals in records is less=
confusing, quite the opposite (at least to me). As I pointed out
earlier: I strongly recommend that any changes to the spec are as clea= r
als possible to engineers (non-crypto/math people)
-- e.g. why the spec is suddenly dealing in blocks instead of records<= /div>
et cetera. Again; I really don't see any reason to change text her= e - to
me all suggested changes are even more confusing.




Hi Aaron,


The=C2=A0=C2=A0technical reasons I explained are reasons for using rec= ords. I don=E2=80=99t
see how that is confusing.


If you like records, then the record number =3D the total blocks / the=
record size in blocks: this is simplest already.


That formula does not correctly compute how many records have been sen= t on
a connection, because the record size in blocks is variable, not const= ant.
You can modify it to get bounds on the total number of records sent, b= ut
the bounds are sloppy because some records only consume 2 blocks (one = for
encryption, one for masking in GHASH) while some consume far more.

It's simpler for an implementation to count how many records have = been
sent on a connection .... by using the connection's sequence numbe= r. This
puts less burden on the implementation/implementer.

I think the record size is configurable and it does not change regular= ly in the same session (or connection).=C2=A0 Somebody corrects me here!=C2= =A0

Quynh.=C2=A0



Cheers

Kenny




_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114b40aef5c17a0549af98f0-- From nobody Wed Mar 1 10:44:19 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F038812965F for ; Wed, 1 Mar 2017 10:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFBGLjzS4owp for ; Wed, 1 Mar 2017 10:44:12 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0125.outbound.protection.outlook.com [23.103.201.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26226129642 for ; Wed, 1 Mar 2017 10:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Uf0WwVwZLXEOzzDyvS1n84LjUz2/sxbZ8TNYd7onACs=; b=ueK2QWLTUHjThBj2ttyWpACac/RO4v+oIVDSc4jPYfQ7sZqLaCKH2oRKiwau3czDXA/zZ36LhAhzeYXvNXRjn+fSJ1dt60cvaHB75E0pSr32kt+2j3G93ejyIiv94ow1P51g33YcNlcYZhrM4PZ/kd0XTBGJH1xpviQTSxjD0Nc= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1462.namprd09.prod.outlook.com (10.173.191.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Wed, 1 Mar 2017 18:44:10 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0933.016; Wed, 1 Mar 2017 18:44:09 +0000 From: "Dang, Quynh (Fed)" To: Watson Ladd , "Dang, Quynh (Fed)" Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). Thread-Index: AQHSj3N1z8IXvDyfJEuMUkRo/k0w1KF/+8GA//+uQQCAAGYzgP//rheAgABVqwD//68bAAASdHaA//+uLQA= Date: Wed, 1 Mar 2017 18:44:08 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:cCFTDdcsJG7geALs0+m7jmfU+h/QYecWU5t2729P5fQt+Pxqra9c5yrM3nQTg8lH0cWmqpf09d6YaLvYytoJwwDeHLeD97Odtbqyghoknv9ZrbWjTEQah793uHLCKk7+BvMWXhFcJ+fm69g3FOGIFcjYbceRWTrKgwgRwhn164M3p8Zvcc/UxPqds/S/q4eIls93jypLoa2r33RxWiAbCHh3IodBgjoY3Z2GFASYeocqeuxzAEoE96ECTl5nbBHoT5dJ4PjX75C1GqSKzNjBe3Xa8EOnekNz713VIk5lj24i+KqygSSWTVONNptWCXVnZkO7hlMxTA8KBRYDJekpWA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39850400002)(39840400002)(39450400003)(39410400002)(377454003)(24454002)(99286003)(6512007)(2900100001)(66066001)(122556002)(189998001)(54896002)(54906002)(236005)(6306002)(39060400002)(8936002)(4001350100001)(2906002)(83506001)(76176999)(7906003)(77096006)(7736002)(6486002)(3660700001)(25786008)(50986999)(229853002)(8656002)(3280700002)(36756003)(38730400002)(6506006)(106116001)(5660300001)(6436002)(102836003)(53546006)(86362001)(92566002)(81166006)(54356999)(2950100002)(6246003)(8676002)(53936002)(3846002)(6116002)(4326008)(606005)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: e53225a8-85d4-432d-1bed-08d460d2f261 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; x-forefront-prvs: 0233768B38 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4DC7F7F3122Dqdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 18:44:08.9829 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462 Archived-At: Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 18:44:15 -0000 --_000_D4DC7F7F3122Dqdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Watson Ladd > Date: Wednesday, March 1, 2017 at 1:36 PM To: 'Quynh' > Cc: "tls@ietf.org" >= , "cfrg@irtf.org" >, Aaron Zauner >, "Paterson, Kenny" <= Kenny.Paterson@rhul.ac.uk> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769). That is not how HTTP works. Lots of records are small OK. What is the percentage ? Even all records were small, providing a corre= ct number would be a good thing. If someone wants to rekey a lot often, I a= m not suggesting against that. Quynh. because they result from small writes. On Mar 1, 2017 6:48 AM, "Dang, Quynh (Fed)" > wrote: From: "Paterson, Kenny" > Date: Wednesday, March 1, 2017 at 9:38 AM To: 'Quynh' >, Aaron Zauner= > Cc: IRTF CFRG >, ">" > Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769). Hi, On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)" on behalf of quynh.dang@= nist.gov> wrote: From: Aaron Zauner > Date: Wednesday, March 1, 2017 at 9:24 AM To: 'Quynh' > Cc: Sean Turner >, ">" >, IRTF CFRG > Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) > wrote: From: Aaron Zauner > Date: Wednesday, March 1, 2017 at 8:11 AM To: 'Quynh' > Cc: Sean Turner >, ">" >, IRTF CFRG > Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) > wrote: Hi Sean, Joe, Eric and all, I would like to address my thoughts/suggestions on 2 issues in option a. 1) The data limit should be addressed in term of blocks, not records. When the record size is not the full size, some user might not know what to do. When the record size is 1 block, the limit of 2^24.5 blocks (records) is way too low unnecessarily for the margin of 2^-60. In that case, 2^34.5 1-block records is the limit which still achieves the margin of 2^-60. I respectfully disagree. TLS deals in records not in blocks, so in the end any semantic change here will just confuse implementors, which isn't a good idea in my opinion. Over the discussion of the PRs, the preference was blocks. I don't see a clear preference. I see Brian Smith suggested switching to blocks to be more precise in a PR. But in general it seems to me that "Option A" was preferred in this thread anyhow - so these PRs aren't relevant? I'm not sure that text on key-usage limits in blocks in a spec that fundamentally deals in records is less confusing, quite the opposite (at least to me). As I pointed out earlier: I strongly recommend that any changes to the spec are as clear als possible to engineers (non-crypto/math people) -- e.g. why the spec is suddenly dealing in blocks instead of records et cetera. Again; I really don't see any reason to change text here - to me all suggested changes are even more confusing. Hi Aaron, The technical reasons I explained are reasons for using records. I don=92t see how that is confusing. If you like records, then the record number =3D the total blocks / the record size in blocks: this is simplest already. That formula does not correctly compute how many records have been sent on a connection, because the record size in blocks is variable, not constant. You can modify it to get bounds on the total number of records sent, but the bounds are sloppy because some records only consume 2 blocks (one for encryption, one for masking in GHASH) while some consume far more. It's simpler for an implementation to count how many records have been sent on a connection .... by using the connection's sequence number. This puts less burden on the implementation/implementer. I think the record size is configurable and it does not change regularly in= the same session (or connection). Somebody corrects me here! Quynh. Cheers Kenny _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_D4DC7F7F3122Dqdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5F1E939A8BA7284A85C0EA5D4A3FD77C@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable


From: Watson Ladd <watsonbladd@gmail.com>
Date: Wednesday, March 1, 2017 at 1= :36 PM
To: 'Quynh' <Quynh.Dang@nist.gov>
Cc: "tls@ietf.org" <tls@ietf.= org>, "cfrg@irtf.org"= <cfrg@irtf.org>, Aaron Zauner <azet@azet.org>, "Paterson= , Kenny" <Kenny.Paters= on@rhul.ac.uk>
Subject: Re: [TLS] [Cfrg] Closing o= ut tls1.3 "Limits on key usage" PRs (#765/#769).

That is not how HTTP works. Lots of records are small

OK. What is the percentage ? Even all records were small, providing a = correct number would be a good thing. If someone wants to rekey a lot often= , I am not suggesting against that.

Quynh. 

because they result from small writes.

On Mar 1, 2017 6:48 AM, "Dang, Quynh (Fed)&= quot; <quynh.dang@nist.gov>= ; wrote:


From: "Paterson, Kenny" &= lt;Kenny.Pat= erson@rhul.ac.uk>
Date: Wednesday, March 1, 2017 at 9= :38 AM
To: 'Quynh' <Quynh.Dang@nist.gov>, Aaron Za= uner <azet@azet.org>
Cc: IRTF CFRG <cfrg@irtf.org>, "<tls@ietf.org>" <<= a href=3D"mailto:tls@ietf.org" target=3D"_blank">tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Closing o= ut tls1.3 "Limits on key usage" PRs (#765/#769).

Hi,

On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)"
From: Aaron Zauner <azet@azet.org>
Date: Wednesday, March 1, 2017 at 9:24 AM
To: 'Quynh' <Quynh.Dang@nist.gov>
Cc: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>, IRTF
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage"= PRs
(#765/#769).





On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
From: Aaron Zauner <azet@azet.org>
Date: Wednesday, March 1, 2017 at 8:11 AM
To: 'Quynh' <Quynh.Dang@nist.gov>
Cc: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>, IRTF
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage"= PRs
(#765/#769).
On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) <quynh.dang@nist.gov>
wrote:
Hi Sean, Joe, Eric and all,
I would like to address my thoughts/suggestions on 2 issues in option<= /div>
a.
1) The data limit should be addressed in term of blocks, not records.<= /div>
When the record size is not the full size, some user might not know
what to do. When the record size is 1 block, the limit of 2^24.5
blocks (records) is way too low unnecessarily for
the margin of 2^-60.  In that case, 2^34.5 1-block records i= s the
limit which still achieves the margin of 2^-60.
I respectfully disagree. TLS deals in records not in blocks, so in the=
end any semantic change here will just confuse implementors, which
isn't a good idea in my opinion.
Over the discussion of the PRs, the preference was blocks.


I don't see a clear preference. I see Brian Smith suggested switching = to
blocks to be more precise in a PR. But in general it seems to me that<= /div>
"Option A" was preferred in this thread anyhow - so these PR= s aren't
relevant? I'm not sure that text on key-usage
limits in blocks in a spec that fundamentally deals in records is less=
confusing, quite the opposite (at least to me). As I pointed out
earlier: I strongly recommend that any changes to the spec are as clea= r
als possible to engineers (non-crypto/math people)
-- e.g. why the spec is suddenly dealing in blocks instead of records<= /div>
et cetera. Again; I really don't see any reason to change text here - = to
me all suggested changes are even more confusing.




Hi Aaron,


The  technical reasons I explained are reasons for using rec= ords. I don=92t
see how that is confusing.


If you like records, then the record number =3D the total blocks / the=
record size in blocks: this is simplest already.


That formula does not correctly compute how many records have been sen= t on
a connection, because the record size in blocks is variable, not const= ant.
You can modify it to get bounds on the total number of records sent, b= ut
the bounds are sloppy because some records only consume 2 blocks (one = for
encryption, one for masking in GHASH) while some consume far more.

It's simpler for an implementation to count how many records have been=
sent on a connection .... by using the connection's sequence number. T= his
puts less burden on the implementation/implementer.

I think the record size is configurable and it does not change regular= ly in the same session (or connection).  Somebody corrects me here!&nb= sp;

Quynh. 



Cheers

Kenny




_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

 --_000_D4DC7F7F3122Dqdangnistgov_-- From nobody Wed Mar 1 13:18:27 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1782C127076 for ; Wed, 1 Mar 2017 13:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enNlGfdcjZEs for ; Wed, 1 Mar 2017 13:18:22 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CCD1296BD for ; Wed, 1 Mar 2017 13:18:22 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id u188so92613710qkc.2 for ; Wed, 01 Mar 2017 13:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vrCITNjcd07mVfW48E4dyb9ZT0FeLYXbjNqQymK8pAM=; b=nOSw+LES7Hn4IE3qnSnU2cr5N87fh/JMcaEWSgZAGbNVJfXM2ydtWYuCcvod+6Y3Ei Svqadgsre21VVe3YAcb2/5u9C593pT7dSTsduhl81SY4zvQspaiBiF6Cx3Bqody88w0V J05zf/XIxzKVGRVN4PDYLTplulPCilod1OTw6GRd2GuoAasq8KC5yqLMjG3V5X9fYnXN ZlDzZcTlq27O/DjMiFIjkwmEv9gzMq+GdTEhYJEHrbwEKoPn1NwSpM1iquZDIIm0qGAb VNjWlSHnejSlQALXnZ+tOWdpD2jWajHdU+Z0NwVco9kMHhfTSqj2boSN+8+op3kaQYG/ zH9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vrCITNjcd07mVfW48E4dyb9ZT0FeLYXbjNqQymK8pAM=; b=Z395kgniA0a0SeHM6orCEQClGc0P1jGf0TIXVmVEozzCe8vh3/lXTFauOf+Ysn90GK EDhbOROKjsjJktv7idM89BEJDh81w5rwLs//wZS0ThlseyIOOczgnFC5bIy6MNA7BZll YiLdwl3MBc6lVjmuFdRi2lvzlkrB9ajKeyf7eriTt5xwSbphSCtx7kHdRJ5jz1LfimlD CF1MYkOnvW75MTbLvVmvOHEWzq/PNzGFTqZGVLlEC2qoE+rcNUtdG8mkTH0pxaeTlL1i bgFevix82eEe3FonGempgGqlP3FIRv6J3dj37MiYp7AyJgzDNsOe7vEFT+ALFWZ3Agit 8TNA== X-Gm-Message-State: AMke39k4/PGTOj2XN1Kl/2HP9AX09NdRyoHZCGaZ3Ttv5TuYGiRWW4ekNPnMrMbPzurHqlujHVHWr01aYtsJlg== X-Received: by 10.200.46.208 with SMTP id i16mr12941392qta.13.1488403101872; Wed, 01 Mar 2017 13:18:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 1 Mar 2017 13:18:21 -0800 (PST) In-Reply-To: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> From: Martin Thomson Date: Thu, 2 Mar 2017 08:18:21 +1100 Message-ID: To: "Dang, Quynh (Fed)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 21:18:24 -0000 On 2 March 2017 at 05:44, Dang, Quynh (Fed) wrote: > OK. What is the percentage ? Even all records were small, providing a > correct number would be a good thing. If someone wants to rekey a lot often, > I am not suggesting against that. It will vary greatly depending on circumstance. Most of the time the record size matches the MTU. Other times it matches the write size, which can be only a small number of octets. For bulk transfers it can approach the record maximum. All on the same connection sometimes. I really don't know what you are suggesting here. The point is the accounting in terms of records doesn't really give you any insight into the number of blocks. From nobody Thu Mar 2 03:01:04 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2791297EA for ; Thu, 2 Mar 2017 03:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rc3BZRyOj4io for ; Thu, 2 Mar 2017 03:01:01 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0131.outbound.protection.outlook.com [23.103.201.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D381297BE for ; Thu, 2 Mar 2017 03:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hsnxmx9cMie9T1+Te4F1Qw1zNV5eUuPaN9hRfBtPUCA=; b=W+/xqfraHXEeNpqtXfsd/EZBE3X/K1hglVjdwXZjwjnCj1yno8n1DwY3lGAVYBVCUcn/1ewAYaYxfDmRU1A6TQJ6qQvHjK95LwTGQWrVuwTikXvRPn7ahBEUoNdA9I4pRRVd/oXdWNq4GCRO9m/vZ/vDD++Fss51A3zRKejQZYM= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1462.namprd09.prod.outlook.com (10.173.191.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Thu, 2 Mar 2017 11:00:59 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0933.016; Thu, 2 Mar 2017 11:00:59 +0000 From: "Dang, Quynh (Fed)" To: Martin Thomson , "Dang, Quynh (Fed)" Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). Thread-Index: AQHSj3N1z8IXvDyfJEuMUkRo/k0w1KF/+8GA//+uQQCAAGYzgP//rheAgABVqwD//68bAAASdHaA//+uLQCAAH7rgIAAkgOA Date: Thu, 2 Mar 2017 11:00:59 +0000 Message-ID: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.222.254] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:3wBgkCXzCTsK9Yco7/Pecnp+hnHMKYEMg9QjfGd0/24piOW8Qw6/4c5ngm5ge97eLxXRc9gVVW3/r4F/u8K8UZ4KT+AEo0PPV3WSJ2KaR/xjMVu/olAxXGMIhYFEoZBly++6YfOy3n/nySrNOrwhkyC3fYmV7MG7etTu1Racy9CSFJa70jVSt7RaphruNPXbyZz2ZneTwv4qyF5PT8Xcp3+cYt4ECUK2DJLWspK4bns6olvY6e36f6bYcAP+pkaywwTbv/JwwkEirTtjrNm07TlxCaZ3m9QLPCKOSH+GN119GR0iJ2eKAU0UQsrU9EaJQmVDuZsDPbtIkWyCyEPEeQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39450400003)(39840400002)(39850400002)(39860400002)(24454002)(377454003)(99286003)(6512007)(83506001)(236005)(2900100001)(54896002)(2906002)(39060400002)(4001350100001)(345774005)(189998001)(122556002)(8936002)(77096006)(7736002)(76176999)(54906002)(6486002)(25786008)(3660700001)(229853002)(3280700002)(50986999)(6436002)(36756003)(102836003)(38730400002)(5660300001)(6506006)(86362001)(53546006)(66066001)(106116001)(92566002)(81166006)(54356999)(2950100002)(68736007)(6246003)(8676002)(3846002)(53936002)(6116002)(93886004)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 69fbdab1-3946-40f4-15da-08d4615b68c3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(155532106045638)(12901024606220)(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; x-forefront-prvs: 023495660C spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4DD63AF31268qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2017 11:00:59.1484 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462 Archived-At: Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 11:01:03 -0000 --_000_D4DD63AF31268qdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Martin Thomson > Date: Wednesday, March 1, 2017 at 4:18 PM To: 'Quynh' > Cc: Watson Ladd >, "cfr= g@irtf.org" >, "t= ls@ietf.org" > Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76= 5/#769). On 2 March 2017 at 05:44, Dang, Quynh (Fed) > wrote: OK. What is the percentage ? Even all records were small, providing a correct number would be a good thing. If someone wants to rekey a lot often= , I am not suggesting against that. It will vary greatly depending on circumstance. Most of the time the record size matches the MTU. Other times it matches the write size, which can be only a small number of octets. For bulk transfers it can approach the record maximum. All on the same connection sometimes. I really don't know what you are suggesting here. The point is the accounting in terms of records doesn't really give you any insight into the number of blocks. Hi Martin, Thank you for the information. In the PRs=92 discussions, I saw that Brian and Rich wanted blocks. You, Er= ic and other people were comfortably discussing the issue in term of blocks= . Implementing and running TLS were your career, so I made suggestions base= d on blocks. Aaron wanted records, so I gave him the equation to figure that out. I did = not mean to suggest to use records. Quynh. --_000_D4DD63AF31268qdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Martin Thomson <martin.thomson@gmail.com>
Date: Wednesday, March 1, 2017 at 4= :18 PM
To: 'Quynh' <Quynh.Dang@nist.gov>
Cc: Watson Ladd <watsonbladd@gmail.com>, "cfrg@irtf.org" <cfrg@irtf.org>, "tls@iet= f.org" <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Closing o= ut tls1.3 "Limits on key usage" PRs (#765/#769).

On 2 March 2017 at 05:44, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
OK. What is the percentage ? Even all records were small, providing a<= /div>
correct number would be a good thing. If someone wants to rekey a lot = often,
I am not suggesting against that.

It will vary greatly depending on circumstance.  Most of the= time the
record size matches the MTU.  Other times it matches the wri= te size,
which can be only a small number of octets.  For bulk transf= ers it can
approach the record maximum.  All on the same connection som= etimes.

I really don't know what you are suggesting here.  The point= is the
accounting in terms of records doesn't really give you any insight
into the number of blocks.

Hi Martin,

Thank you for the information. 

In the PRs=92 discussions, I saw that Brian and Rich wanted blocks. Yo= u, Eric and other people were comfortably discussing the issue in term of b= locks. Implementing and running TLS were your career, so I made suggestions= based on blocks.

Aaron wanted records, so I gave him the equation to figure that out. I= did not mean to suggest to use records.

Quynh. 

 --_000_D4DD63AF31268qdangnistgov_-- From nobody Thu Mar 2 13:44:21 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914911295EF for ; Thu, 2 Mar 2017 13:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpKmkJogGfaQ for ; Thu, 2 Mar 2017 13:44:14 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3544129535 for ; Thu, 2 Mar 2017 13:44:13 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id 203so1946582ith.0 for ; Thu, 02 Mar 2017 13:44:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PmXHXrUwBBn3FKB1UU9gitiSHibI8xN3gm54gcAYriU=; b=nVw1c2CYUAg2mngp1P/32NRJLF60WVhHh9snq/T6MNTSUENcNmMs3+n36J0Gm4dieL WXAa8EFoaHcqfV5FVHGuVPjlrTIC3da9ED58GUDkIWVi1Zo9JJkPhdP77vDbbEarXkSi T5cFmzyTAHG/X+NeMUVTFhqYXOsvYxC2js5PpW/Hzailv+rVbXc/4dbyFzE7rkhDHjWI 2LXyyhfN2i6/G0TJtrIWq3SLsuL4KjPwpxK7HedbkrFG8HyIOC793+a067NeRSBHOJ7d A+5SyLNPlZTnViNplQ4rWdEIq2xg1a55n8DXA/ghM3za1Js8M/rHUwkigAx3zVa7ZE2v 4asQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PmXHXrUwBBn3FKB1UU9gitiSHibI8xN3gm54gcAYriU=; b=eePb6xWxbc1jP83aJ4r5FTymB7hrGiL0NiEAXXtUCGFnlsZkg3fQINIkekZ8+69GAo AdozoUrIfMunUx9BbtNjcOeZr2F0o6RZq7Kh1XYmI2va20qR2azul4t/BSJ3THtHTYWx 8Q5mjMX0YTx+c7X5wROtI8+KGVNUERJ9mPa8MFGsY+qFnM6uj/+Y9XKI+mFOcM5BlkZZ 5u21u5NeBH8Dpx7+zx5hlohgkksvfi3uJBe2SHXloGepBb7hXHw56bCOlYAKNFBJPXW+ hgxqZ4y6JnjTFo83uN6ag1cuHQtCm5tq1tuzkqPZi0EInahv9m5ogP/smS5MYadXUm7d RWIw== X-Gm-Message-State: AMke39l/OhC/9WElsY5s6i6DxuKteLTWxlyvMbGbtAfiLfoNDzO8Wd8eWyn8pfYCs340lTKYaWe9JjHlwdVeVA== X-Received: by 10.36.60.211 with SMTP id m202mr493249ita.58.1488491053194; Thu, 02 Mar 2017 13:44:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.87.82 with HTTP; Thu, 2 Mar 2017 13:44:12 -0800 (PST) In-Reply-To: <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> From: Brian Smith Date: Thu, 2 Mar 2017 11:44:12 -1000 Message-ID: To: Aaron Zauner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IRTF CFRG , "" Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 21:44:15 -0000 Aaron Zauner wrote: > I'm not sure that text on key-usage limits in blocks in a spec > that fundamentally deals in records is less confusing, quite > the opposite (at least to me). 1. Consider an implementation that negotiates with another implementation to use a very large record size such as 1MB records. If the limit is specified in terms of records then the limit would need to be readjusted to the new max record size, or else the new extension is potentially unsafe to use. This shows that specifying the limits in terms of records is brittle. 2. If it is only safe to use an AES-GCM key for a certain number of blocks, where in the code is the best place to enforce the limit on the number of blocks? IMO, it is better to enforce it in the AES-GCM implementation itself, underneath the TLS layer. In that case the limit is best expressed in terms of the number of blocks. Specifying the limit in terms of records would be optimizing for implementations that enforce the limit at the wrong layer of abstraction. > As I pointed out earlier: I strongly recommend that any changes > to the spec are as clear als possible to engineers > (non-crypto/math people) -- e.g. why the spec is suddenly > dealing in blocks instead of records et cetera. Again; I really > don't see any reason to change text here - to me all suggested > changes are even more confusing. Given a limit in blocks, the arithmetic to keep track of the number of blocks is trivial, and very similar to the arithmetic that's already needed to split up a large byte stream into records and keep track of the record sequence number. Cheers, Brian -- https://briansmith.org/ From nobody Thu Mar 2 15:15:38 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF9E127601 for ; Thu, 2 Mar 2017 15:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh8BqT0FjY0N for ; Thu, 2 Mar 2017 15:15:32 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A926127ABE for ; Thu, 2 Mar 2017 15:15:31 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-09v.sys.comcast.net with SMTP id jZwXc8oMPODBvjZwYcF1fe; Thu, 02 Mar 2017 23:15:30 +0000 Received: from [IPv6:::1] ([24.5.144.109]) by resomta-po-14v.sys.comcast.net with SMTP id jZwXcMFBsBKYljZwXcdZdR; Thu, 02 Mar 2017 23:15:30 +0000 To: tls@ietf.org, cfrg@ietf.org References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> From: Andrey Jivsov Message-ID: Date: Thu, 2 Mar 2017 15:15:28 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfBf7lS8Q0JEbAWXCA/HtzBX4ko3u6Qf3WoVF+wD0qO/OO7ObLu4M76RVC1o0+e6YW8KtbyAx5IHKn4rlkXoBLIkEz3iKUYmGU31G1ClFzxNs8wrpUdw6 13jFtXnJXtzwVMMceT6uWzV4jcZEq5xBiOle6GZ008GlMNrkE+C1y9oluNcwRSU/fnN+DPnPeObVEQ== Archived-At: Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 23:15:34 -0000 I also think that counting in blocks is cleaner. Counting in bytes is a close alternative. I have a few nits below: On 03/02/2017 01:44 PM, Brian Smith wrote: > Aaron Zauner wrote: >> I'm not sure that text on key-usage limits in blocks in a spec >> that fundamentally deals in records is less confusing, quite >> the opposite (at least to me). > > 1. Consider an implementation that negotiates with another > implementation to use a very large record size such as 1MB records. If > the limit is specified in terms of records then the limit would need > to be readjusted to the new max record size, or else the new extension > is potentially unsafe to use. This shows that specifying the limits in > terms of records is brittle. Hm, while I agree that counting in wrong units is the main problem here, we over-count with records, which means that we re-key faster than needed. > 2. If it is only safe to use an AES-GCM key for a certain number of > blocks, where in the code is the best place to enforce the limit on > the number of blocks? IMO, it is better to enforce it in the AES-GCM > implementation itself, underneath the TLS layer. In that case the > limit is best expressed in terms of the number of blocks. Specifying > the limit in terms of records would be optimizing for implementations > that enforce the limit at the wrong layer of abstraction. Given that the event of reaching the limit requires TLS-level action, checking the limit at the TLS level seems reasonable. The lower-level block-cipher code should still have the logic to error out (using a more relaxed limit). > >> As I pointed out earlier: I strongly recommend that any changes >> to the spec are as clear als possible to engineers >> (non-crypto/math people) -- e.g. why the spec is suddenly >> dealing in blocks instead of records et cetera. Again; I really >> don't see any reason to change text here - to me all suggested >> changes are even more confusing. > > Given a limit in blocks, the arithmetic to keep track of the number of > blocks is trivial, and very similar to the arithmetic that's already > needed to split up a large byte stream into records and keep track of > the record sequence number. Also please consider counting in bytes. This may be more natural, especially with AES-GCM that doesn't expose higher levels to the block size granularity (as much as CBC does, anyway). > > Cheers, > Brian > From nobody Thu Mar 2 17:54:23 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC87A129431; Thu, 2 Mar 2017 17:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB97MqqNptY7; Thu, 2 Mar 2017 17:54:20 -0800 (PST) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id E366E1279EB; Thu, 2 Mar 2017 17:54:19 -0800 (PST) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id CC005406061; Thu, 2 Mar 2017 17:54:18 -0800 (PST) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Andrey Jivsov From: Hal Murray In-Reply-To: Message from Andrey Jivsov of "Thu, 02 Mar 2017 15:15:28 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Mar 2017 17:54:18 -0800 Message-Id: <20170303015418.CC005406061@ip-64-139-1-69.sjc.megapath.net> Archived-At: Cc: cfrg@ietf.org, tls@ietf.org Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 01:54:22 -0000 crypto@brainhub.org said: > I also think that counting in blocks is cleaner. Counting in bytes is a > close alternative. Does counting bytes work? If the real limit is blocks, I think you will have to round up the byte count when you send a partial block. If re-keying too often isn't too expensive, you could get a safe answer by counting bytes and assuming that every byte went in a separate block. You might want to round down many more orders of magnitude so the re-key code gets exercised often enough. Or maybe provide a back door to set the limit so that path can be tested with reasonable resources. -- These are my opinions. I hate spam. From nobody Thu Mar 2 18:33:10 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736F9129460 for ; Thu, 2 Mar 2017 18:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_Muijw8pl6h for ; Thu, 2 Mar 2017 18:33:01 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920641294C4 for ; Thu, 2 Mar 2017 18:33:01 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-01v.sys.comcast.net with SMTP id jd1Xc5PZCEkHpjd1gcSdiV; Fri, 03 Mar 2017 02:33:00 +0000 Received: from [IPv6:::1] ([24.5.144.109]) by resomta-po-01v.sys.comcast.net with SMTP id jd1fcqYwG8jz5jd1gc1zIs; Fri, 03 Mar 2017 02:33:00 +0000 To: Hal Murray References: <20170303015418.CC005406061@ip-64-139-1-69.sjc.megapath.net> From: Andrey Jivsov Message-ID: Date: Thu, 2 Mar 2017 18:32:59 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170303015418.CC005406061@ip-64-139-1-69.sjc.megapath.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfH3tVOs1W5JO6eUaHvUYL+A87IgD3LIENcTPlu4GC2Oum77KKCkQphZCelAjc94Jmek9toovK9KI3Rc0C8jv5qClqrLDOipcVgv8a9HfUDC4I3hzDfFN vG5l3cpEPg45bPODvNN077c9eI7DTmW59orWygaA1dXLO+N487YUkx2tZn0DRoQ0rRIZsFeYrY7exkx5r42JJU5clD2tDFvoqSs= Archived-At: Cc: cfrg@ietf.org, tls@ietf.org Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 02:33:03 -0000 On 03/02/2017 05:54 PM, Hal Murray wrote: > > crypto@brainhub.org said: >> I also think that counting in blocks is cleaner. Counting in bytes is a >> close alternative. > > Does counting bytes work? If the real limit is blocks, I think you will have > to round up the byte count when you send a partial block. > > If re-keying too often isn't too expensive, you could get a safe answer by > counting bytes and assuming that every byte went in a separate block. > > You might want to round down many more orders of magnitude so the re-key code > gets exercised often enough. Or maybe provide a back door to set the limit > so that path can be tested with reasonable resources. > I like the idea of setting the rekey limits, so that the code can be tested. There is no 3DES in TLS 1.3. You refer to some under-counting. The worst case is mod 16 = 1 byte sized TLS records, in which case the "tails" will only be counted as 1 block per 16 TLS records v.s. desired 16. We are undercounting less than one 16-byte block per record. One can count in record_size_in_bytes + 16 as one solution (overcount). However, is it true that 1-byte terminal blocks must be counted as full 16-byte blocks? 1-byte blocks don't seem to directly apply to the proofs with distinguishing game. With 1-byte plaintext / ciphertext we are not making statements about two values from the 1^128 members space. Rather, we are discussing two values from the tiny 256 members space. Also, a truncated AES-GCM encryption behaves as PRF and not PRP. From nobody Fri Mar 3 01:22:19 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9097912942F; Fri, 3 Mar 2017 01:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i41Kgq-7D_p4; Fri, 3 Mar 2017 01:22:12 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7DA1293F4; Fri, 3 Mar 2017 01:22:12 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id m70so2131184wma.1; Fri, 03 Mar 2017 01:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wEWtpphl9RZzzGtA1kNj91g6/6XNiY0y+GjbawoKf/I=; b=mYwqRfErUJ2ceUdPSJo6dt/yBYDQw7/eWlQAPFMtuG++CExL2eSZbDi12jvISDZOsR MBasr4wNIFfGVbVswigQYqaBmhRioXXEXzn4ViCl5aLFau74zzx1F+GU/4MjmLq634MB AbBRXt21iHCI2ms7azBw6Hmawj5mT/cipCF6HuO//FVcsPrRDlZVf5J9PqJfh939NfQQ GvcMJZYkaEeZGOrG536wXSMg7vUuFpwEr9rlXJrMgrQ+tjclUbc5NDYMvR+atQ9z2Qua S6mJTJDemtRi41zblR8l0mXtEby9W6TuAX/YoyFniOttJiQX/+Zeogf1ruHtugVzd9Rh OEmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=wEWtpphl9RZzzGtA1kNj91g6/6XNiY0y+GjbawoKf/I=; b=OOWsFkkkau1+2S+sAKngeixrBlFZb9WLC1MvPQoKpOF7wBmN/C+WUDuAhqGbrdYxb9 d6Ybx4s+KXPgw7DLvOmWP/AaUczacuXm/Gy0/VKXY9lyWGPITIgBpCchoFmJUcqtz34M 4yqSKadcu7F25tmqre3LFKw9CUlwB3sy6xgOvdvqVdrgnzZ4Tqf35gasNGbZKxT2jYZY PBq0vfEP13u9Gfe4kyboUMqbECdcy+2nc14lkF3+mcma3i+HpWCrvkaIIFaL31GSFCr0 ynh7Hk6GSQYOPXGA1ciF4DZeSgCRWAMwJmCtHBSk4433rf8Pv8aNeocJR3hPdQifCS2F /FKA== X-Gm-Message-State: AMke39lL1MbVY/Jsjxvnd/WxAIyXGzoaQrx4WVGtEEzVW99w34o7lqbPOrxXqIFo2VIZBg== X-Received: by 10.28.198.132 with SMTP id w126mr1749078wmf.69.1488532930820; Fri, 03 Mar 2017 01:22:10 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id r195sm2250748wme.25.2017.03.03.01.22.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 01:22:10 -0800 (PST) From: Yoav Nir Message-Id: <3F458D44-2232-498C-944F-C3F72A53291A@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E2B79941-1801-4DDA-9E97-E175F83AF075"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 3 Mar 2017 11:22:08 +0200 In-Reply-To: To: Andrey Jivsov References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <26137F3B-5655-44CA-877E-7168CE02DBF1@azet.org> <2572E3FC-0139-4946-A12D-9D9509C402F1@azet.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: cfrg@ietf.org, "tls@ietf.org list" Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769). X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 09:22:13 -0000 --Apple-Mail=_E2B79941-1801-4DDA-9E97-E175F83AF075 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi As an implementer I have no problem counting records, bytes or blocks = (OK, the last you usually don=E2=80=99t count directly but (n+15)/16 is = not beyond the capabilities of any implementer) So IMO whichever gives the tightest bound should be selected, and that = means blocks. Exercising the rekey code is up to developers, not document writers. Yoav --Apple-Mail=_E2B79941-1801-4DDA-9E97-E175F83AF075 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYuTXAAAoJELhJCxUKWMyZUR8H/iYd6W3i+BVVgeR1ApHqfkXL W2M5Omn2J9+8ivXDpMkYZpaJpvId46+wCr+VlLCxwI7dMLhRVdkrp9iVgXdA+TSO Q5hzUQGZAdPiG1LBti6tD+uY711YVXZS4QWAnQE24kpQKwmnc/SlsDpMMAKrTzIA qld80MMneGopfP9X3WXunpO1YCajaR5c2rAsTCj9J0fXG6MYU5izqNnhnKmOEcBC IK+Vf/WNtiPXEkGZEoGY1CmePCG9cnFmTC43zoPZTeLfo7AV4Va1iKmfLAdZGmHE YIMJY90ooPjIhcXvZGhJ3PF5meVbqUR+YqtackskvXWp4HxoP8ko0WAQpywhWnY= =2uHZ -----END PGP SIGNATURE----- --Apple-Mail=_E2B79941-1801-4DDA-9E97-E175F83AF075-- From nobody Sat Mar 4 09:04:36 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8A6129552 for ; Sat, 4 Mar 2017 09:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT9exNfMpNgq for ; Sat, 4 Mar 2017 09:04:33 -0800 (PST) Received: from mailsrv.math.unipd.it (mailsrv.math.unipd.it [147.162.22.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0317E1294DB for ; Sat, 4 Mar 2017 09:04:32 -0800 (PST) Received: from server0.math.unipd.it (smtpout.math.unipd.it [147.162.22.54]) by mailsrv.math.unipd.it (8.15.2/8.15.2) with ESMTPS id v24H4Oi7001369 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 4 Mar 2017 17:04:24 GMT Received: from webmail.math.unipd.it (v0b1.math.unipd.it [147.162.22.157]) by server0.math.unipd.it (8.15.1/8.15.1) with ESMTPS id v24H49bY071841 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 4 Mar 2017 17:04:10 GMT Received: from host209-14-dynamic.233-95-r.retail.telecomitalia.it (host209-14-dynamic.233-95-r.retail.telecomitalia.it [95.233.14.209]) by webmail.math.unipd.it (Horde Framework) with HTTPS; Sat, 04 Mar 2017 18:04:28 +0100 Date: Sat, 04 Mar 2017 18:04:27 +0100 Message-ID: <20170304180428.Horde.q4vLYzOIbW644o3ebHWkv3B@webmail.math.unipd.it> From: riccardo.lazzeretti@math.unipd.it To: cfrg@irtf.org User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-DCC--Metrics: server5.math.unipd.it 1102; Body=8 Fuz1=8 Fuz2=8 X-IMP-Checker: SpamAssassin on webmail.math.unipd.it/imp checker X-Spam-Warning: SpamAssassin says this -probably- is not SPAM X-Scanned-By: MIMEDefang 2.78 Archived-At: Subject: [Cfrg] [CfP] ICCST-2017: 51st IEEE International Carnahan Conference on Security Technologies X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 17:04:35 -0000 Madrid, Spain, October 23 - 26, 2017 http://atvs.ii.uam.es/iccst2017/ The IEEE International Carnahan Conference on Security Technologies is one of the longest-running international technical symposia. This conference has a broad scope and invites papers that advance security technologies including physical, cyber and electronic security research, development, systems engineering, testing, evaluation, case studies and new research lines to face current and future challenges. All papers will be carefully subjected to a blind review process.Conference proceedings will be submitted for posting to IEEE Xplore. As well as this top ranking technical event, Madrid also offers you the amazing features of a major, modern and historical European city, its legendary social activity, and the appeal of its Mediterranean gastronomy and lifestyle. The main social event at ICCST-2017 will include a display of flamenco dancing. Important Dates: Abstract Submission Date: April 28, 2017 Decision to Authors: May 26, 2017 Final Manuscript Due: July 20, 2017 Early Registration: August 15, 2017 Best Regards, ICCST-2017 Organizing Committee ICCST-2017 Executive Committee http://atvs.ii.uam.es/iccst2017/ From nobody Sun Mar 5 16:08:00 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E95124281; Sun, 5 Mar 2017 16:07:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148875887875.26305.3209917017517693524.idtracker@ietfa.amsl.com> Date: Sun, 05 Mar 2017 16:07:58 -0800 Archived-At: Cc: cfrg@ietf.org Subject: [Cfrg] I-D Action: draft-mcgrew-hash-sigs-06.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 00:07:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum of the IETF. Title : Hash-Based Signatures Authors : David McGrew Michael Curcio Scott Fluhrer Filename : draft-mcgrew-hash-sigs-06.txt Pages : 44 Date : 2017-03-05 Abstract: This note describes a digital signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and naturally resist side-channel attacks. Unlike most other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-mcgrew-hash-sigs-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-mcgrew-hash-sigs-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 7 08:38:00 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8F11294B2; Tue, 7 Mar 2017 08:37:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148890467906.30370.7990441856168255441@ietfa.amsl.com> Date: Tue, 07 Mar 2017 08:37:59 -0800 Archived-At: Cc: cfrg@ietf.org Subject: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-01.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 16:37:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum of the IETF. Title : Re-keying Mechanisms for Symmetric Keys Authors : Stanislav Smyshlyaev Russ Housley Mihir Bellare Evgeny Alekseev Ekaterina Smyshlyaeva Filename : draft-irtf-cfrg-re-keying-01.txt Pages : 39 Date : 2017-03-07 Abstract: This specification contains a description of a variety of methods to increase the lifetime of symmetric keys. It provides external and internal re-keying mechanisms that can be used with such modes of operations as CTR, GCM, CBC, CFB, OFB and OMAC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-re-keying-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 9 18:25:46 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A151126579 for ; Thu, 9 Mar 2017 18:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnou07wj7yYv for ; Thu, 9 Mar 2017 18:25:33 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6011294E0 for ; Thu, 9 Mar 2017 18:25:20 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id y76so149386922qkb.0 for ; Thu, 09 Mar 2017 18:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U6LBCog31s4ivf+Z+ydpGgC6wr1LlEd0L6pWB1eUjTU=; b=Cwx3XJbL9usQaMUgxu5mXoao7sr8ZMe2PJhWLp4KJK5xp65aDPgIUVfezpiyzA8Eru iClY2HiWo5lSt7pxs1oKPJdjOmZXMu2XHISPf5YKO+wpdt7NUifPhNovQ1TQgkXkpjlW NAm0YAGFg2WyirS4X+bT5B+408fkFggdndMZw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U6LBCog31s4ivf+Z+ydpGgC6wr1LlEd0L6pWB1eUjTU=; b=k2F7tCp9od7AFNVDnPpxBsYTgKeufk3ZvFvUyfZ62W3TZH8PbqZnPiaGj7vnwF7sYu 4Wps3WESOBTk1rIL5flS9dKrPEgLQZCUm0KAN4oCaCM31wSzR0/EVtoEQhzROxLu3ZO3 mTNMT81UKSIrvTgGNX+2X66EtJKlcmARUmdP3oyC62pA9dn4WxVWnXfVyZKvz96TApoJ ZcZ6xmicDeyo6SK4Kp98cG5BfmhQ+WHZiVj5a6WtI4uir19RNxbS7JLDSzIMOWzx9LJp fRxuHEZDQKwnbqOSUqQi1JV3qIocmDmMdkJK7aQ9/DLp/F57DqGsBcUzacLAIc5aCtl4 iEaw== X-Gm-Message-State: AFeK/H0D582oK6CsGoRh/4F5HR7JdKVCCMMa1uZH7nQa1B6fzRz1aOPiQIli7s0CfuO4Ig== X-Received: by 10.55.185.70 with SMTP id j67mr18117091qkf.4.1489112319996; Thu, 09 Mar 2017 18:18:39 -0800 (PST) Received: from [172.16.0.18] ([96.231.228.203]) by smtp.gmail.com with ESMTPSA id f21sm5546309qtg.3.2017.03.09.18.18.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 18:18:39 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Sean Turner In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> Date: Thu, 9 Mar 2017 21:18:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> To: "" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IRTF CFRG Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:25:43 -0000 After many emails about the wording for s5.5 Limits on Key Usage, it=E2=80= =99s time to judge consensus on whether or not to make any changes to = that section. The important thing is that the SHOULD implement the key = update from s4.5.3 was never in question. There was no consensus to = change the actual GCM limits on key usage; again the text related to = ChaCha20/Poly1305 never really was in question. The discussion has = wound down to whether it was better to count records or bytes/blocks for = the GCM limit calculation. We didn=E2=80=99t see any strong consensus = to change this description. Therefore, we see no consensus to change = the text in s5.5. ekr please close PR#765 and PR#769. J&S > On Feb 10, 2017, at 12:07 AM, Sean Turner wrote: >=20 > All, >=20 > We=E2=80=99ve got two outstanding PRs that propose changes to = draft-ietf-tls-tls13 Section 5.5 =E2=80=9CLimits on Key Usage=E2=80=9D. = As it relates to rekeying, these limits have been discussed a couple of = times and we need to resolve once and for all whether the TLS WG wants = to: >=20 > a) Close these two PRs and go with the existing text [0] > b) Adopt PR#765 [1] > c) Adopt PR#769 [2] >=20 > Please indicate you preference to the TLS mailing list before Feb 17. = Note that unless there=E2=80=99s clear consensus to change the text will = remain as is (i.e., option a). >=20 > J&S >=20 > [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5 > [1] https://github.com/tlswg/tls13-spec/pull/765 > [2] https://github.com/tlswg/tls13-spec/pull/769 From nobody Fri Mar 10 07:42:13 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3A0129651 for ; Fri, 10 Mar 2017 07:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZbLvvQUzYrt for ; Fri, 10 Mar 2017 07:42:10 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2173129649 for ; Fri, 10 Mar 2017 07:42:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 32DA83004AF for ; Fri, 10 Mar 2017 10:42:10 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0lNjnOMi0EL1 for ; Fri, 10 Mar 2017 10:42:09 -0500 (EST) Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 06B09300267; Fri, 10 Mar 2017 10:42:08 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 10 Mar 2017 10:42:08 -0500 References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> To: IETF TLS , IRTF CFRG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 15:42:11 -0000 Thanks. I agree. I think that the existing text is more helpful to the = implementer. If the details of the analysis do in the document, it = should be in the security considerations. Russ > On Mar 9, 2017, at 9:18 PM, Sean Turner wrote: >=20 > After many emails about the wording for s5.5 Limits on Key Usage, = it=E2=80=99s time to judge consensus on whether or not to make any = changes to that section. The important thing is that the SHOULD = implement the key update from s4.5.3 was never in question. There was = no consensus to change the actual GCM limits on key usage; again the = text related to ChaCha20/Poly1305 never really was in question. The = discussion has wound down to whether it was better to count records or = bytes/blocks for the GCM limit calculation. We didn=E2=80=99t see any = strong consensus to change this description. Therefore, we see no = consensus to change the text in s5.5. ekr please close PR#765 and = PR#769. >=20 > J&S >=20 >> On Feb 10, 2017, at 12:07 AM, Sean Turner wrote: >>=20 >> All, >>=20 >> We=E2=80=99ve got two outstanding PRs that propose changes to = draft-ietf-tls-tls13 Section 5.5 =E2=80=9CLimits on Key Usage=E2=80=9D. = As it relates to rekeying, these limits have been discussed a couple of = times and we need to resolve once and for all whether the TLS WG wants = to: >>=20 >> a) Close these two PRs and go with the existing text [0] >> b) Adopt PR#765 [1] >> c) Adopt PR#769 [2] >>=20 >> Please indicate you preference to the TLS mailing list before Feb 17. = Note that unless there=E2=80=99s clear consensus to change the text = will remain as is (i.e., option a). >>=20 >> J&S >>=20 >> [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5 >> [1] https://github.com/tlswg/tls13-spec/pull/765 >> [2] https://github.com/tlswg/tls13-spec/pull/769 From nobody Fri Mar 10 07:55:43 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F360712964F; Fri, 10 Mar 2017 07:55:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148916134095.7523.2902255880255088390@ietfa.amsl.com> Date: Fri, 10 Mar 2017 07:55:40 -0800 Archived-At: Cc: cfrg@ietf.org Subject: [Cfrg] I-D Action: draft-irtf-cfrg-xmss-hash-based-signatures-08.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 15:55:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum of the IETF. Title : XMSS: Extended Hash-Based Signatures Authors : Andreas Huelsing Denis Butin Stefan-Lukas Gazdag Aziz Mohaisen Filename : draft-irtf-cfrg-xmss-hash-based-signatures-08.txt Pages : 67 Date : 2017-03-10 Abstract: This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system. It follows existing descriptions in scientific literature. The note specifies the WOTS+ one-time signature scheme, a single-tree (XMSS) and a multi-tree variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can withstand attacks using quantum computers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-xmss-hash-based-signatures/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-xmss-hash-based-signatures-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 07:27:55 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7A112966D for ; Mon, 13 Mar 2017 07:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO5FIS46y2z5 for ; Mon, 13 Mar 2017 07:27:52 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5218812940B for ; Mon, 13 Mar 2017 07:27:52 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id z13so85141855iof.2 for ; Mon, 13 Mar 2017 07:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=5z7kurj3lj0P6miHf53M4MzOV4iMmJCPTKXMZteIysQ=; b=afr9gdoQ5PX74j/cNDooxSTtVP+r2SrSwq1T1xMjImlf4v4iXifebNgsn+WIbc5GQX 00OUoqa3LCGCMNTBaxYCeN/gybUVCBfWkh0Lf5jEIWaAOs7SK01WKaAtGQ+RvT9yg/EP ifcl4qmCAGSbhbLEZy044Ij4g2DqPviaMzHTipcdLllYC4Hqem+YqcKGtRyodJSf80HI EHGucZbGmG+7NvXdx5KvVjA36OznhvGkgqnThlsl0xVfJbluDMw0XNwgzgakPPHGC5ia 8mx1AXP8rNNEzqtKoGKgOEvcsfXA8JGmuJCzNfmmnspUMbLaowhBRyNo4IkuQjhgDGMS plKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5z7kurj3lj0P6miHf53M4MzOV4iMmJCPTKXMZteIysQ=; b=dWHrbU+qLrxjDCD9BDpLkNOvwcrI2gFPN/sOlFjD75n8vTm7YtAtY6UmFb/HyJASEy TeEc9BDq7/rTrISvTPskjy+/e/9C4uyT9jgYwyuXQ3PGjC2CYA1ZLUbWXLtr4v8TM9HB jkoG2Trd61V540w3igViElX+sK7pDxUKIXWL5++8IBLxuhmaDbWV+ctN4KwQ5d00ip8r JJBii0TWFoFXm2LCYlZpMzKIVe97XTUhx3qgN0ZGNUNV5pGpzyB2CmeMsdas9LyQqoCG Wl8qFNKHxfDx34au4s2ib8g8nOInJaLLQqIuQ6mCmbMNVy7jSF+GODa6M4lsKN7zGYpv KKvg== X-Gm-Message-State: AMke39m9Wsn0J/Y0XsJAv9NVqbGPmB1UVmGNgJrbk5AHqznhQCCMFuiJI9m8KOGXr7hJy1bAh000E6SadfFhgQ== X-Received: by 10.107.135.136 with SMTP id r8mr27091914ioi.36.1489415271693; Mon, 13 Mar 2017 07:27:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.141.197 with HTTP; Mon, 13 Mar 2017 07:27:11 -0700 (PDT) From: Sharon Goldberg Date: Mon, 13 Mar 2017 10:27:11 -0400 Message-ID: To: cfrg@irtf.org Content-Type: multipart/alternative; boundary=001a113ec77c314817054a9d841f Archived-At: Subject: [Cfrg] new draft specifying VRFs (verifiable random functions) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 14:27:54 -0000 --001a113ec77c314817054a9d841f Content-Type: text/plain; charset=UTF-8 Several of us have been working a draft specification for Verifiable Random Functions (VRFs). A VRF is the public-key version of a keyed cryptographic hash function. Only the holder of the private VRF key can compute the hash, but anyone with the corresponding public key can verify the correctness of the hash. This draft has one VRF based on RSA, and another based on elliptic curves. https://datatracker.ietf.org/doc/draft-goldbe-vrf/ Our team is using a VRF to prevent zone enumeration with NSEC5 for DNSSEC [1,2]. The Google Key Transparency project is using a similar VRF to prevent key enumeration [3,4]. Open Whisper systems has also specified a similar VRF [5]. We think VRFs will be useful for other applications as well, so we think it would be helpful to have a standard way to implement them. We've requested an agenda slot at SAAG to talk about VRFs. The chairs have requested that we send out a note to CFRG ahead of time, so here it is. Hope to chat in person at IETF and/or on this list. Thanks, Sharon (with Dimitris Papadopoulos, Jan Vcelak, Leonid Reyzin, Shumon Huque, David C Lawrence) [1] https://datatracker.ietf.org/doc/draft-vcelak-nsec5/ [2] https://gitlab.labs.nic.cz/knot/nsec5-crypto [3] https://security.googleblog.com/2017/01/security-through-transparency.html [4] https://github.com/google/keytransparency/blob/master/core/vrf/vrf.go [5] https://whispersystems.org/docs/specifications/xeddsa/ --- Sharon Goldberg Associate Professor, Computer Science, Boston University Sloan Research Fellow http://www.cs.bu.edu/~goldbe --001a113ec77c314817054a9d841f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Several of us have been working a draft specification= for Verifiable Random Functions (VRFs). A VRF is the public-key version of= a keyed cryptographic hash function.=C2=A0 Only the holder of the private = VRF key can compute the hash, but anyone with the corresponding public key = can verify the correctness of the hash. =C2=A0 This draft has one VRF based= on RSA, and another based on elliptic curves.
=C2=A0
=C2=A0htt= ps://datatracker.ietf.org/doc/draft-goldbe-vrf/

Our team is using a VRF to prevent zone enumeration with NSEC5 for DNSSEC= [1,2]. The Google Key Transparency project is using a similar VRF to preve= nt key enumeration [3,4]. Open Whisper systems has also specified a similar= VRF [5]. =C2=A0 We think VRFs will be useful for other applications as wel= l, so we think it would be helpful to have a standard way to implement them= .

We've requested an agenda slot at SAAG to ta= lk about VRFs.=C2=A0 The chairs have requested that we send out a note to C= FRG ahead of time, so here it is. Hope to chat in person at IETF and/or on = this list.

Thanks,

Sharon=
(with Dimitris Papadopoulos, Jan Vcelak,=C2=A0Leonid Reyzin, Shu= mon Huque, David C Lawrence)

--001a113ec77c314817054a9d841f-- From nobody Tue Mar 14 10:31:56 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2431329EE for ; Tue, 14 Mar 2017 10:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-IUcVBADi7T for ; Tue, 14 Mar 2017 10:31:46 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E1A1329D9 for ; Tue, 14 Mar 2017 10:31:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 1C71620E2A for ; Tue, 14 Mar 2017 18:31:44 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ic6Wyan-Y4Kn for ; Tue, 14 Mar 2017 18:31:42 +0100 (CET) Received: from mail-essen-02.secunet.de (205.40.53.10.in-addr.arpa [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 368D020DF7 for ; Tue, 14 Mar 2017 18:31:42 +0100 (CET) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 18:31:41 +0100 From: "Tams, Benjamin" To: "cfrg@irtf.org" Thread-Topic: Re: [Cfrg] Postquantum cryptography in IETF protocols Thread-Index: AdKc6H+hT+ZGq8rlRg2W3GjGUDXWBw== Date: Tue, 14 Mar 2017 17:31:41 +0000 Message-ID: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.36.126.244] x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 x-g-data-mailsecurity-for-exchange-state: 0 x-g-data-mailsecurity-for-exchange-error: 0 x-g-data-mailsecurity-for-exchange-sender: 23 x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c x-g-data-mailsecurity-for-exchange-guid: 7ED01411-6E16-4D28-BCF8-475755A34029 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 17:31:49 -0000 Hi John, > Good that CFRG starts some more detailed discussion on PQC. It makes sens= e > to support post-quantum key exchange for use cases that need long-term > confidentiality (15 years). For other use cases I think it can wait until > PQC key exchange algorithms has been thoroughly evaluated and > standardized. If implemented now, it should be used in addition to ECDHE, > just like Google has done with their experimental New Hope implementation= . I absolutely agree with your view on the subject. Especially for those use cases where the attack scenario "collect today, decrypt tomorrow" is a thre= at,=20 we should start thinking of PQ-safe key exchange methods in time. Even if they eventually turn out to be insecure; we can now combine them with classical key exchange algorithms. We have nothing to lose. There is already IETF work addressing PQ-security in Internet protocols, e.= g. IKE and an Internet Draft for a Quantum-Safe Hybrid Ciphersuite for TLS https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-03 https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 On the other hand, there is (to my knowledge) no specification for a PQ-saf= e patent-free key exchange algorithm suitable for implementation. In fact, in= =20 https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 only NTRUEncrypt is specified but is subject to patents. A possible first step is that CFRG creates an Internet Draft. In fact, the algorithm New Hope has already been implemented as a plugin for strongSwan (IPSec implementation for the Linux kernel) https://github.com/strongswan/strongswan/tree/master/src/libstrongswan/plug= ins/newhope So why do we not start with a draft for which the above implementation can= =20 serve as a reference implementation? Kind regards, Benjamin From nobody Tue Mar 14 12:36:12 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B80129A04 for ; Tue, 14 Mar 2017 12:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70hFL-H3O01L for ; Tue, 14 Mar 2017 12:35:23 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695ED13010C for ; Tue, 14 Mar 2017 12:35:18 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id t189so7272467wmt.1 for ; Tue, 14 Mar 2017 12:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w4EUYvWvvso2bMXxyPluOYh3HHN5tGjdz1RbYSTitW4=; b=KqU7m2Iopw6zGXz+tKEaikywe7IjIDV7oudMNf8fICda7Vr0jpVVjfYJ0upqtzH7IM mqclCaB/rXK3dHHZtdEvfbCnMwmHqsd/LR0HT51CO2XdUyi6cAHDNi2wV5TUpGZ6nLKM F+b/H41UhxNY4iXc37ebDHWV3xolQRyVf5ukE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w4EUYvWvvso2bMXxyPluOYh3HHN5tGjdz1RbYSTitW4=; b=PSkopen3uE7m8fA2JU9teOpTzAkFRceoCI1MriG7DuZCZ9is6I1b3PBYECDEZFFv8V RyxeA6Sw9NoptVFFbWNCHoR/qpMkoiZdDXeQ04KS5G3Lq6BN56I4Ozjj5lRPtzf2iK1z 3BKO4kx8rfBunzTyE0GnhqOA/5PAsI7vmSRFrwNYczUJZKHC3UMZvb575+5Y0rmQJEQU Rky5GdXeB3FmJ6f7/9mCkkZunVzUzpmNKqNJV1uiQowYiH7jUPaISEZvCkZlXdq43hrz gJgZp8+HnEjy8gjh7swZyzsXmKJ9VieSry30BvEGEkQiULAo9BkizCF2MNaQ1LsV0w/o w9wQ== X-Gm-Message-State: AFeK/H3j5aAVTyUQQdT2ZwYqLJeWfbRfXFAF13F+Sfd3P5BLs1jzIKmMjCp55i0++eLqsmBuaSBMdYqyr1jc7Q== X-Received: by 10.28.35.151 with SMTP id j145mr16105547wmj.50.1489520116859; Tue, 14 Mar 2017 12:35:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.166.5 with HTTP; Tue, 14 Mar 2017 12:34:56 -0700 (PDT) In-Reply-To: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> From: William Whyte Date: Tue, 14 Mar 2017 15:34:56 -0400 Message-ID: To: "Tams, Benjamin" Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a113eaee67387ef054ab5ed7c Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 19:35:52 -0000 --001a113eaee67387ef054ab5ed7c Content-Type: text/plain; charset=UTF-8 I should note that Security Innovation, which owns the patents for NTRU and which I work for, has announced an intent to make the NTRUEncrypt IP public domain. A formal announcement should follow shortly. Cheers, William On Tue, Mar 14, 2017 at 1:31 PM, Tams, Benjamin wrote: > Hi John, > > > Good that CFRG starts some more detailed discussion on PQC. It makes > sense > > to support post-quantum key exchange for use cases that need long-term > > confidentiality (15 years). For other use cases I think it can wait until > > PQC key exchange algorithms has been thoroughly evaluated and > > standardized. If implemented now, it should be used in addition to ECDHE, > > just like Google has done with their experimental New Hope > implementation. > > I absolutely agree with your view on the subject. Especially for those use > cases where the attack scenario "collect today, decrypt tomorrow" is a > threat, > we should start thinking of PQ-safe key exchange methods in time. Even if > they eventually turn out to be insecure; we can now combine them with > classical key exchange algorithms. We have nothing to lose. > > There is already IETF work addressing PQ-security in Internet protocols, > e.g. > IKE and an Internet Draft for a Quantum-Safe Hybrid Ciphersuite for TLS > > https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-03 > https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 > > On the other hand, there is (to my knowledge) no specification for a > PQ-safe > patent-free key exchange algorithm suitable for implementation. In fact, in > https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 > only NTRUEncrypt is specified but is subject to patents. > > A possible first step is that CFRG creates an Internet Draft. In fact, > the algorithm New Hope has already been implemented as a plugin for > strongSwan (IPSec implementation for the Linux kernel) > > https://github.com/strongswan/strongswan/tree/master/src/ > libstrongswan/plugins/newhope > > So why do we not start with a draft for which the above implementation can > serve as a reference implementation? > > Kind regards, > Benjamin > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a113eaee67387ef054ab5ed7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I should note that Security Innovation, which owns the pat= ents for NTRU and which I work for, has announced an intent to make the NTR= UEncrypt IP public domain. A formal announcement should follow shortly.
Cheers,

William

On Tue, Mar 14, 2017 at = 1:31 PM, Tams, Benjamin <Benjamin.Tams@secunet.com> = wrote:
Hi John,

> Good that CFRG starts some more detailed discussion on PQC. It makes s= ense
> to support post-quantum key exchange for use cases that need long-term=
> confidentiality (15 years). For other use cases I think it can wait un= til
> PQC key exchange algorithms has been thoroughly evaluated and
> standardized. If implemented now, it should be used in addition to ECD= HE,
> just like Google has done with their experimental New Hope implementat= ion.

I absolutely agree with your view on the subject. Especially for those use<= br> cases where the attack scenario "collect today, decrypt tomorrow"= is a threat,
we should start thinking of PQ-safe key exchange methods in time. Even if they eventually turn out to be insecure; we can now combine them with
classical key exchange algorithms. We have nothing to lose.

There is already IETF work addressing PQ-security in Internet protocols, e.= g.
IKE and an Internet Draft for a Quantum-Safe Hybrid Ciphersuite for TLS

https://tools.ietf.org/html/draft-fluhrer-= qr-ikev2-03
https://tools.ietf.org/html/draft-whyte-qsh= -tls13-03

On the other hand, there is (to my knowledge) no specification for a PQ-saf= e
patent-free key exchange algorithm suitable for implementation. In fact, in=
https://tools.ietf.org/html/draft-whyte-qsh= -tls13-03
only NTRUEncrypt is specified but is subject to patents.

A possible first step is that CFRG creates an Internet Draft. In fact,
the algorithm New Hope has already been implemented as a plugin for
strongSwan (IPSec implementation for the Linux kernel)

https://github= .com/strongswan/strongswan/tree/master/src/libstrongswan/plugins/= newhope

So why do we not start with a draft for which the above implementation can<= br> serve as a reference implementation?

Kind regards,
Benjamin


_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--001a113eaee67387ef054ab5ed7c-- From nobody Tue Mar 14 14:11:39 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7B9131548 for ; Tue, 14 Mar 2017 14:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qOAgclX_8rC for ; Tue, 14 Mar 2017 14:11:31 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B956F13154B for ; Tue, 14 Mar 2017 14:11:30 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id n11so9008134wma.0 for ; Tue, 14 Mar 2017 14:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z1jc3PhEEN+4zFChgFk/JCPNF0HKS4ysZC7UXPBxYtI=; b=KfzHFnYBzPAdKJHRVpKvkTdWMFmQ6tsGQjLdfyG5Mb/+o9lAxqZcKaKJ3pNHUgLdMV xdNUT9Vt5w45ZwlhOQnVl0fS+8MBtGz93n+CscEQAVMWBQSSbsC3X+OyDmXG/qh38hMe o65uD/oSzdW+1OSrdeQ+Uoqv1tUPCvmgbUB+FUQ6gaq3aXNbPZBidkkJo2D61JTXNfml Bjb+YjBRw4myIdFpxzajc0/Y/gG30mEw33nSbBstppCj7q74uCF1MU0klQZPxeOWhNKI je0UASXbs34WHVUpmkSHpVrO0XfIpvW7APUeWopoDQvPn4foVg+KEGINKFxxujSD4/pY +sEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z1jc3PhEEN+4zFChgFk/JCPNF0HKS4ysZC7UXPBxYtI=; b=d3VVEIVeayhVjcbWqwhiFkrJVVs7m21/neQA9uxRAcvyd6TRuhd8cdsFRc5ziKSoQf M0ZL1gUQaSSKDSESumIAcshlRuXOO2gTwVcgsKu4m5YFWP7fa2LbPLINBFMDQCYd30zJ C9dGubUJKv2nDPlK3Oxo4iB5OPosiO18re+vytFU71urDRpxC9hkO53pPbFkt+fwGoN6 ITVxepSi6wBOJgzx66scCwuAiwvYT8wK/cKyBVSUch11Dat43NTnLpc4EnGq4tXU00vP zeIXTsr6pGXC+8Bop9Mr84D+baYUxS7o/h8d1E5fvFaLk1rj7dgjjspr6xRW5n465NtZ G0lw== X-Gm-Message-State: AFeK/H0iTt7vFJiZ9zhwSs6//5yrbmSAlsApj5uJQithkyYpj+W0nesYrsBv+ExASW9S9A0XIMwdWP4K8xyd/w== X-Received: by 10.28.93.68 with SMTP id r65mr1568182wmb.133.1489525888934; Tue, 14 Mar 2017 14:11:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Tue, 14 Mar 2017 14:11:28 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Tue, 14 Mar 2017 17:11:28 -0400 Message-ID: To: Sharon Goldberg Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a11467a9a7e7cda054ab7457a Archived-At: Subject: Re: [Cfrg] new draft specifying VRFs (verifiable random functions) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:11:39 -0000 --001a11467a9a7e7cda054ab7457a Content-Type: text/plain; charset=UTF-8 Hey Sharon, Thanks for writing this up. One quick, probably trivial question: How do these VRFs differ from signature schemes? From the API point of view, they seem very similar, if you view the proof as the signature value. Thanks, --Richard On Mon, Mar 13, 2017 at 10:27 AM, Sharon Goldberg wrote: > Several of us have been working a draft specification for Verifiable > Random Functions (VRFs). A VRF is the public-key version of a keyed > cryptographic hash function. Only the holder of the private VRF key can > compute the hash, but anyone with the corresponding public key can verify > the correctness of the hash. This draft has one VRF based on RSA, and > another based on elliptic curves. > > https://datatracker.ietf.org/doc/draft-goldbe-vrf/ > > Our team is using a VRF to prevent zone enumeration with NSEC5 for DNSSEC > [1,2]. The Google Key Transparency project is using a similar VRF to > prevent key enumeration [3,4]. Open Whisper systems has also specified a > similar VRF [5]. We think VRFs will be useful for other applications as > well, so we think it would be helpful to have a standard way to implement > them. > > We've requested an agenda slot at SAAG to talk about VRFs. The chairs > have requested that we send out a note to CFRG ahead of time, so here it > is. Hope to chat in person at IETF and/or on this list. > > Thanks, > > Sharon > (with Dimitris Papadopoulos, Jan Vcelak, Leonid Reyzin, Shumon Huque, > David C Lawrence) > > [1] https://datatracker.ietf.org/doc/draft-vcelak-nsec5/ > [2] https://gitlab.labs.nic.cz/knot/nsec5-crypto > [3] https://security.googleblog.com/2017/01/security-through- > transparency.html > [4] https://github.com/google/keytransparency/blob/master/core/vrf/vrf.go > [5] https://whispersystems.org/docs/specifications/xeddsa/ > > --- > Sharon Goldberg > Associate Professor, Computer Science, Boston University > Sloan Research Fellow > http://www.cs.bu.edu/~goldbe > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --001a11467a9a7e7cda054ab7457a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Sharon,

Thanks for writing= this up.=C2=A0 One quick, probably trivial question: How do these VRFs dif= fer from signature schemes?=C2=A0 From the API point of view, they seem ver= y similar, if you view the proof as the signature value.

Thank= s,
--Richard

On Mon, Mar 13, 2017 at 10:27 AM, Sharon Goldberg <s= haron.goldbe@gmail.com> wrote:
Several of us have been working a draft specifica= tion for Verifiable Random Functions (VRFs). A VRF is the public-key versio= n of a keyed cryptographic hash function.=C2=A0 Only the holder of the priv= ate VRF key can compute the hash, but anyone with the corresponding public = key can verify the correctness of the hash. =C2=A0 This draft has one VRF b= ased on RSA, and another based on elliptic curves.
=C2=A0




--001a11467a9a7e7cda054ab7457a-- From nobody Tue Mar 14 14:15:59 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92222129B40 for ; Tue, 14 Mar 2017 14:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWBcoEtRfIBj for ; Tue, 14 Mar 2017 14:15:57 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E42129B46 for ; Tue, 14 Mar 2017 14:15:57 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id g2so78724936pge.3 for ; Tue, 14 Mar 2017 14:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jKlnEDCXGVCUfDHKSDFMs9bdHQaI1ywBtC8vqXfIGDg=; b=GlNEp4GqT8JWedja8f8iUxWzMuY1V3qgoez3KOcSI480OC5TYmH0dfKb3kHGVRYlRY WAvYh/3eH+plHibPNN5Zj/zBAmcMa8U5ynCbFkyiBKdPTQEfeOEXJ4qy3BHnwfNwFTAh nWcr18IbDdiH0UG+MMir5hsbEK/zNCk3MCfiRZo4FDWXMayQUZi7job5bwzdhxKzyWSY pbyl1MbhrrZjEYMW0xyR9dT+xcqdt06A87w2qCseTtHOnKrzrI6kpRl0bUiWysq/Rgjm J9Muu5HBnghDJLrda97/L990l/bqBAd/KgrVfNdL4407XIUtGS12qBvh0rSlv2CJjK/Q IXyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jKlnEDCXGVCUfDHKSDFMs9bdHQaI1ywBtC8vqXfIGDg=; b=OqLsENuLDqOWcwgx/XKv5nyIOfafXb/4AQAygUKOSSrQXRH5jwhtpCKAVJOvja78Ts UeqS0x3rKXeAcaAv6fAMQHZvxkabA0mvP3qpvFqUsg+4MCg4gurmLKtiQax9fqRonDqn KzKZuvjOK/+hbPgbYolA9ijWLtXSgm7tfQOBZdvypIFMR09FRjeqA/6gCNyqnwPWlW+c 9KrxaEsTXzwmuBHY/Tj7bu2niQXzNxCNI2Zgo/HJMsddmnV4+XcLdlmNTbcXqDoKnHF+ 27ohBEpzp4FQHNyVqTilQei7kEh1XMhu359Fhvp/hR2V2+e+ERd/QE5IozhkNXXNyUTh Yl3Q== X-Gm-Message-State: AMke39m7Q2eBCnN++X8IEIjVb1KVEaT/EGcl9BgcohxeNbLmEjGbwqglhfyy1AFOpyeLrbxFXxWNECIkRYdhKQ== X-Received: by 10.84.129.195 with SMTP id b61mr58497343plb.83.1489526156785; Tue, 14 Mar 2017 14:15:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.178.234 with HTTP; Tue, 14 Mar 2017 14:15:36 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Tue, 14 Mar 2017 14:15:36 -0700 Message-ID: To: Richard Barnes Cc: Sharon Goldberg , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=94eb2c144968757cd6054ab75514 Archived-At: Subject: Re: [Cfrg] new draft specifying VRFs (verifiable random functions) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:15:58 -0000 --94eb2c144968757cd6054ab75514 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 14, 2017 at 2:11 PM, Richard Barnes wrote: > Thanks for writing this up. One quick, probably trivial question: How do > these VRFs differ from signature schemes? From the API point of view, they > seem very similar, if you view the proof as the signature value. > They are similar, however VRFs are not malleable in the same way as signatures (VRFs guarantee a unique mapping of input to random output), and specifically designed so the proof can be delivered separately from the output (so the output can e.g. be recorded in a Merkle tree for timestamping/transparency purposes). The latter prevents low-entropy inputs from being preimaged, even if the public key and output are known to the attacker (but not the proof). -- Tony Arcieri --94eb2c144968757cd6054ab75514 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 14, 2017 at 2:11 PM, Richard Barnes <rlb@ipv.sx> wrote:
Thanks for= writing this up.=C2=A0 One quick, probably trivial question: How do these = VRFs differ from signature schemes?=C2=A0 From the API point of view, they = seem very similar, if you view the proof as the signature value.

They are similar, however VRFs are not malleable in th= e same way as signatures (VRFs guarantee a unique mapping of input to rando= m output), and specifically designed so the proof can be delivered separate= ly from the output (so the output can e.g. be recorded in a Merkle tree for= timestamping/transparency purposes). The latter prevents low-entropy input= s from being preimaged, even if the public key and output are known to the = attacker (but not the proof).

-- =
Tony = Arcieri
--94eb2c144968757cd6054ab75514-- From nobody Tue Mar 14 15:29:35 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523561315D7 for ; Tue, 14 Mar 2017 15:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSkhGJ5qcmFC for ; Tue, 14 Mar 2017 15:29:32 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061241315CE for ; Tue, 14 Mar 2017 15:29:28 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id g138so9032528itb.0 for ; Tue, 14 Mar 2017 15:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=njLC18ORAt0dM7Km0YPiiGdOizkvf6XO5VkgiGLa7+c=; b=SbkRkqSM7LshV0BZjsvgk4DtJcrwZJoYyQ1jgPxsZo47Fg8ZJcmeVA8MO9P+jKj4yt ApmdTt5EIquA4VtFjMyjwbwQqYvi5q17JtNVA4BTU+iheMNiHltIxrmqNUJlgAra7tBT Ln3/G/EGUEzYdMGn4NWqBhgUdB7yK+rqRvIFy8Zi5xYz41zepPf5HwtnlROCH6WaXIMP FQb3E7hooEey5VRo8c9j13papPO9oAf31/ihEEgOiqYqxTRzr56ro4rYap2J10S5hsxB sKmnP9m9OMyhxLlaee5xrP+i8YwdgKXB3cGNpj9SbQBu75c0oTPBmqE7dLDZI1YTNaUM i6HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=njLC18ORAt0dM7Km0YPiiGdOizkvf6XO5VkgiGLa7+c=; b=iC2ZsTs1EFXUhTWBJ2c839SlXOJ9fNIG1vj96MM+BVZQ9oXvTZbCGdi+ZgYu9nSoS2 qp/AA86TZ9qoowe+9F0rJ5BaXsqTj8M+RELRkF624aRs9outmrSbgmSAN4XjKabSWJGg yM+HZaEkbgdIYt+FL3nQTa6BbfCsIu67OgCs3q810oLph0wtLAw64QmgNyzFqWrZD9e5 fTP44DN41MvPkfuCxtVhDFpTP1YJwwIXIXsfQxH1BtROVHRflj+uyWTbAHh9FZZRTMFA cWkhMqXHIyHIkyf8s/D9LyzwXw6JEkkqIIMu+0CEnqzvPUZQnpZLPvbFEPXbtrUDVzfb PVaw== X-Gm-Message-State: AFeK/H21FJMCTJJp9zocsDpCUIeBxSXBXjaM+eCi0FiCMk3cIg9E3bT2U7l00xN6+AGGja9HvjBwz9557gMpkg== X-Received: by 10.36.84.211 with SMTP id t202mr2301609ita.96.1489530567403; Tue, 14 Mar 2017 15:29:27 -0700 (PDT) MIME-Version: 1.0 Sender: sharon.goldbe@gmail.com Received: by 10.107.141.197 with HTTP; Tue, 14 Mar 2017 15:29:26 -0700 (PDT) In-Reply-To: References: From: Sharon Goldberg Date: Tue, 14 Mar 2017 18:29:26 -0400 X-Google-Sender-Auth: C6t6Rrjk7lXJC6pMX0HfXgHCAiQ Message-ID: To: Tony Arcieri Cc: Richard Barnes , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a1139ad8e5a33b0054ab85c6f Archived-At: Subject: Re: [Cfrg] new draft specifying VRFs (verifiable random functions) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:29:33 -0000 --001a1139ad8e5a33b0054ab85c6f Content-Type: text/plain; charset=UTF-8 Yes that's true. See the "uniqueness"security property defined in the draft. It's also very important that VRF hash outputs look pseudorandom even given knowledge of the public key. (But not given knowledge of the corresponding proof or secret key.) That's why the RSA-FDH-VRF hash output is the Hash of a deterministic RSA signature, not the signature itself. See the security considerations section of the draft for more details. Sharon On Tuesday, March 14, 2017, Tony Arcieri wrote: > On Tue, Mar 14, 2017 at 2:11 PM, Richard Barnes > wrote: > >> Thanks for writing this up. One quick, probably trivial question: How do >> these VRFs differ from signature schemes? From the API point of view, they >> seem very similar, if you view the proof as the signature value. >> > > They are similar, however VRFs are not malleable in the same way as > signatures (VRFs guarantee a unique mapping of input to random output), and > specifically designed so the proof can be delivered separately from the > output (so the output can e.g. be recorded in a Merkle tree for > timestamping/transparency purposes). The latter prevents low-entropy inputs > from being preimaged, even if the public key and output are known to the > attacker (but not the proof). > > -- > Tony Arcieri > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a1139ad8e5a33b0054ab85c6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes that's true. See the "uniqueness"security property define= d=C2=A0in the draft.=C2=A0

It's also very important= =C2=A0that VRF hash outputs look pseudorandom even given knowledge of the p= ublic key. (But not given knowledge of the corresponding proof or secret ke= y.)=C2=A0That's why the RSA-FDH-VRF hash output is the Hash of a determ= inistic RSA signature, not the signature itself.=C2=A0See the security cons= iderations section of the draft for more details.=C2=A0

= Sharon

On Tuesday, March 14, 2017, Tony Arcieri <bascule@gmail.com> wrote:
On Tue, Mar 14, 2017 at 2:11 PM, Richard Barnes <rlb@ipv.sx> wrote:
Thanks for writing this up.=C2= =A0 One quick, probably trivial question: How do these VRFs differ from sig= nature schemes?=C2=A0 From the API point of view, they seem very similar, i= f you view the proof as the signature value.

They are similar, however VRFs are not malleable in the same way as signat= ures (VRFs guarantee a unique mapping of input to random output), and speci= fically designed so the proof can be delivered separately from the output (= so the output can e.g. be recorded in a Merkle tree for timestamping/transp= arency purposes). The latter prevents low-entropy inputs from being preimag= ed, even if the public key and output are known to the attacker (but not th= e proof).

--
Tony Arcieri


--
Sharon Goldberg
Computer Science= , Boston University
http://www.cs.bu.edu/~goldbe
--001a1139ad8e5a33b0054ab85c6f-- From nobody Tue Mar 14 19:38:37 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D290F129468 for ; Tue, 14 Mar 2017 19:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUXbtlS7o5-J for ; Tue, 14 Mar 2017 19:38:33 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBC312946E for ; Tue, 14 Mar 2017 19:38:32 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id j5so2269534pfb.2 for ; Tue, 14 Mar 2017 19:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZBUs2VtqoycmtVy1ErdFqxxC8fA3CpgPjfCjh9AP8zc=; b=p3cllEATDxwB1WdTTl28pOpTadNDLgy5huSu2XdW6rjIZb02goYDZOT7AQUi1p68i+ 5z8wHj0SOpYGTyR/atr4QgOKOJsy1U3XlGfyfSwY9QhQIwW6w2N7DTtaXMAPLji6QwZR Y8CqORNDoKPYlOj87Yv1FWS0UqqTKxpknm4n4cIAyiwN02sgaHbzajn2sPJG5M1O/Z7p nVE2XavSqX2aHW/y6YGdekLhzkCfk6kEoVeZ1tatHDA+gy0EdjROhAqicB/QaNLy/ZI2 sfc24abge+DfRAJ5bNN2OgSBNpA3JP3Upn/danuMnbzexb/nA5FyneOegiMp/nElrNl8 VYlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZBUs2VtqoycmtVy1ErdFqxxC8fA3CpgPjfCjh9AP8zc=; b=UOGMvxkft17Ba2gHBqeYiiLsRXrfR1zdTR9bI/UCWojhiULIqZmqjl4oo9M45uUS3o iwFNNHHVM0iwhjyG04GWLwOJSDnFFmT3I2cVkt2Bf5VmL1K8xJAtnlOr4iHPbld2UZ3D sxKVxFFRBiQ5wDpeqN3UKOS1CPVEkbbVX/iL+mrY8szDMyDjEh/JMQBcx148BM/Pabe1 FC1XLp7nGc+8Lw98g9fvHRiBC0oygNtuDKxqGQMv5O+PREKlLltg8BacfQz/PY4ohd/l bbb8Rbc+H3qezNkm5CTvSiJfblBBrqIejwMW3aWwqGxlhyiWCy3OmyPwyyPbpq2uoB2z j+1A== X-Gm-Message-State: AFeK/H1yGGWf8vZupqTNLaQw0YKoFA51HABHvfh07VVc0LZsXswm9fuO2TikepZjx3PiTn7lQ982j6Qv883kVg== X-Received: by 10.98.13.16 with SMTP id v16mr1042279pfi.38.1489545512323; Tue, 14 Mar 2017 19:38:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.138 with HTTP; Tue, 14 Mar 2017 19:38:31 -0700 (PDT) In-Reply-To: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> From: Watson Ladd Date: Tue, 14 Mar 2017 19:38:31 -0700 Message-ID: To: "Tams, Benjamin" Cc: "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 02:38:36 -0000 On Tue, Mar 14, 2017 at 10:31 AM, Tams, Benjamin wrote: > Hi John, > >> Good that CFRG starts some more detailed discussion on PQC. It makes sense >> to support post-quantum key exchange for use cases that need long-term >> confidentiality (15 years). For other use cases I think it can wait until >> PQC key exchange algorithms has been thoroughly evaluated and >> standardized. If implemented now, it should be used in addition to ECDHE, >> just like Google has done with their experimental New Hope implementation. > > I absolutely agree with your view on the subject. Especially for those use > cases where the attack scenario "collect today, decrypt tomorrow" is a threat, > we should start thinking of PQ-safe key exchange methods in time. Even if > they eventually turn out to be insecure; we can now combine them with > classical key exchange algorithms. We have nothing to lose. > > There is already IETF work addressing PQ-security in Internet protocols, e.g. > IKE and an Internet Draft for a Quantum-Safe Hybrid Ciphersuite for TLS > > https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-03 > https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 > > On the other hand, there is (to my knowledge) no specification for a PQ-safe > patent-free key exchange algorithm suitable for implementation. In fact, in > https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 > only NTRUEncrypt is specified but is subject to patents. > > A possible first step is that CFRG creates an Internet Draft. In fact, > the algorithm New Hope has already been implemented as a plugin for > strongSwan (IPSec implementation for the Linux kernel) > > https://github.com/strongswan/strongswan/tree/master/src/libstrongswan/plugins/newhope > > So why do we not start with a draft for which the above implementation can > serve as a reference implementation? Why should we preempt the current NIST postquantum standardization efforts? > > Kind regards, > Benjamin > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Mar 15 06:12:09 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A42513149A for ; Wed, 15 Mar 2017 06:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WFYTKhbMViQ for ; Wed, 15 Mar 2017 06:12:06 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53216131499 for ; Wed, 15 Mar 2017 06:12:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 71F0E20E77; Wed, 15 Mar 2017 14:12:02 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKzVgz2wywYH; Wed, 15 Mar 2017 14:11:52 +0100 (CET) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 8247120E75; Wed, 15 Mar 2017 14:10:50 +0100 (CET) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0319.002; Wed, 15 Mar 2017 14:10:50 +0100 From: "Tams, Benjamin" To: William Whyte CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] Postquantum cryptography in IETF protocols Thread-Index: AQHSnPofrOb/Rr16m0y9A6m0gRW4e6GV4LPQ Date: Wed, 15 Mar 2017 13:10:49 +0000 Message-ID: <78B0B91A8FEB2E43B20BCCE1326131812D6B6CAC@mail-essen-01.secunet.de> References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.36.126.244] x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 x-g-data-mailsecurity-for-exchange-state: 0 x-g-data-mailsecurity-for-exchange-error: 0 x-g-data-mailsecurity-for-exchange-sender: 23 x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c x-g-data-mailsecurity-for-exchange-guid: 8BE205BF-B194-4422-9ACC-A46FE118294F Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:12:08 -0000 SGkgV2lsbGlhbSwNCg0KPiBJIHNob3VsZCBub3RlIHRoYXQgU2VjdXJpdHkgSW5ub3ZhdGlvbiwg d2hpY2ggb3ducyB0aGUgcGF0ZW50cyBmb3IgTlRSVSBhbmQgd2hpY2ggSSB3b3JrIGZvciwgaGFz IGFubm91bmNlZCBhbiBpbnRlbnQgdG8gbWFrZSB0aGUgTlRSVUVuY3J5cHQgSVAgcHVibGljIGRv bWFpbi4gQSBmb3JtYWwgYW5ub3VuY2VtZW50IHNob3VsZCBmb2xsb3cgc2hvcnRseS4NCg0KR29v ZCB0byBrbm93LiBJcyB0aGVyZSBhbHJlYWR5IGEgdGltZWxpbmUgZm9yIG1ha2luZyBOVFJVRW5j cnlwdCBJUCBwdWJsaWMgZG9tYWluPw0KDQpLaW5kIHJlZ2FyZHMsDQpCZW5qYW1pbg0K From nobody Wed Mar 15 06:12:37 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52983131493 for ; Wed, 15 Mar 2017 06:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daun_3SfOrf9 for ; Wed, 15 Mar 2017 06:12:34 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D5E1314A2 for ; Wed, 15 Mar 2017 06:12:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 7C4B820E79; Wed, 15 Mar 2017 14:12:30 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkl7nfjcoVRM; Wed, 15 Mar 2017 14:12:19 +0100 (CET) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id A4EEC20E84; Wed, 15 Mar 2017 14:10:59 +0100 (CET) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0319.002; Wed, 15 Mar 2017 14:10:59 +0100 From: "Tams, Benjamin" To: Watson Ladd CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] Postquantum cryptography in IETF protocols Thread-Index: AQHSnTVAjC974e0YRUO7yMHUwccYLqGV1MdA Date: Wed, 15 Mar 2017 13:10:58 +0000 Message-ID: <78B0B91A8FEB2E43B20BCCE1326131812D6B6CC3@mail-essen-01.secunet.de> References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.36.126.244] x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 x-g-data-mailsecurity-for-exchange-state: 0 x-g-data-mailsecurity-for-exchange-error: 0 x-g-data-mailsecurity-for-exchange-sender: 23 x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c x-g-data-mailsecurity-for-exchange-guid: 46F1370E-EA29-42F3-BEBF-FFB0C0A3C23A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:12:35 -0000 SGkgV2F0c29uLA0KDQo+IFdoeSBzaG91bGQgd2UgcHJlZW1wdCB0aGUgY3VycmVudCBOSVNUIHBv c3RxdWFudHVtIHN0YW5kYXJkaXphdGlvbiBlZmZvcnRzPw0KDQpBY2NvcmRpbmcgdG8gdGhlIHRp bWVsaW5lIHN1Z2dlc3RlZCBpbiANCg0KaHR0cDovL2NzcmMubmlzdC5nb3YvZ3JvdXBzL1NUL3Bv c3QtcXVhbnR1bS1jcnlwdG8vd29ya3Nob3BzLmh0bWwNCg0KZmlyc3QgTklTVCBzdGFuZGFyZGl6 YXRpb24gZHJhZnRzICBmb3IgcG9zdHF1YW50dW0ga2V5IGV4Y2hhbmdlIGFsZ29yaXRobXMgd2ls bCBhcHBlYXIgaW4gMjAyMyAtIDIwMjUuIEZvciB0aGUgdXNlIGNhc2VzIHRoYXQgbmVlZCBsb25n LXRlcm0gY29uZmlkZW50aWFsaXR5IG9mIGFwcHJveC4gMTUgeWVhcnMgKGFzIG1lbnRpb25lZCBp biBKb2huJ3MgcG9zdCkgd2Ugc2hvdWxkIG5vdCB3YWl0IDYtOCB5ZWFycyBiZWZvcmUgd2UgY2Fu IGV2ZW4gc3RhcnQgd2l0aCBpbXBsZW1lbnRpbmcgUFEtc2FmZSBrZXkgZXhjaGFuZ2UgYWxnb3Jp dGhtcyBmb3IgdGhlc2UgcHVycG9zZXMuDQoNCkkgYXBwcmVjaWF0ZSB0aGUgZWZmb3J0cyBvZiBO SVNUIGJlY2F1c2UgdGhlIHNwZWNpZmljYXRpb24gb3V0cHV0cyB3aWxsIGhhdmUgcGFzc2VkIGEg My01IHllYXIgYW5hbHlzaXMgcGhhc2UgYW5kIGNhbiB0aGVuIGJlIGNvbnNpZGVyZWQgbW9yZSBy b2J1c3QgYXMgcG9zdC1xdWFudHVtIGtleSBleGNoYW5nZSBhbGdvcml0aG1zIHRoYXQgd2UgaGF2 ZSB0b2RheTsgYW5kLCBtYXliZSBhbnkgc3BlY2lmaWNhdGlvbiB0aGF0IHdlIGNhbiBlc3RhYmxp c2ggbm93LCB3aWxsIGV2ZW50dWFsbHkgdHVybiBvdXQgdG8gYmUgdnVsbmVyYWJsZS4gT24gdGhl IG90aGVyIGhhbmQsIGlmIHdlIGltcGxlbWVudCBhIGh5YnJpZCBrZXkgZXhjaGFuZ2UgYWxnb3Jp dGhtIHN1aXRhYmxlIGZvciBpbXBsZW1lbnRhdGlvbiwgYXMgaW4NCg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXdoeXRlLXFzaC10bHMxMy0wMw0KDQp3ZSB3aWxsIG5vdCBsb3Nl IHNlY3VyaXR5IGJ1dCBnYWluIHRoZSBwb3NzaWJpbGl0eSBvZiBoYXZpbmcgUFEtc2FmZXR5IGFs cmVhZHkgaW4gdGhlIG5lYXIgZnV0dXJlLiBGdXJ0aGVybW9yZSwgdGhlIGRyYWZ0IGFscmVhZHkg cmVmZXJzIHRvIGZvdXIgUFEtc2FmZSBhbGdvcml0aG1zIGJ1dCBvbmx5IHRvIG9uZSBzcGVjaWZp YyAtIE5UUlUuICBXaHkgbm90IHNwZWNpZnkgdGhlIHJlbWFpbmluZyBieSBDRlJHPyBOb3QgZm9y IHJlY29tbWVuZGluZyB0aGVtIGFzIGEgZmluYWwgc3BlY2lmaWNhdGlvbiBidXQgZm9yIHRlbXBv cmFyeSB1c2luZyB0aGVtIGluIGFwcGxpY2F0aW9ucyB3aGVyZSBQUS1zYWZldHkgaXMgcmVxdWly ZWQgYWxyZWFkeSBub3cuDQoNCktpbmQgcmVnYXJkcywNCkJlbmphbWluDQoNCiANCg0KDQo= From nobody Wed Mar 15 06:37:20 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C20F1314CB for ; Wed, 15 Mar 2017 06:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjhxEdI2lMCI for ; Wed, 15 Mar 2017 06:37:18 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79231314C4 for ; Wed, 15 Mar 2017 06:37:17 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id g10so11176470wrg.2 for ; Wed, 15 Mar 2017 06:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YRkjz0J0JfUsDvxmUCPuEe+/prdMCkhTgfN9/Evxigc=; b=HxQRpyxmGDGDvgx/F98NQrj4Ov3UipWLh5FTDtqRfgVUlW7KG72L5G3SkaK1p7Cvh1 OEc4rwFTzW+Nl5mYfSEy4gTG9eWiVx9r8+1MS3RG63HoBoTPMuSpcfXS/85IDNhlct8R dA2JNaw4SidqEiSGXdgMfHx9Yp1MKg+o4XXZk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YRkjz0J0JfUsDvxmUCPuEe+/prdMCkhTgfN9/Evxigc=; b=shbDbuAOGyGo9xF5ItzYNPu+20/i6jkaiVTSYnTYD2VjCDA3aygdg8tYb6oO4leyNS H4lcqvGhF2yh5MVLarANJ8h7uZqhy6nsr0AffecanUS/hRQTcTG+lXWUBWeo2LyvduUC Mh6D+3MYe0a29jVFO+E5rtUdHEsqCZ6eumScSYnQ+Vm6uSpNF8HmcgCKegck1A8d7m0k xQQmIDc881w5XyXU51PJeTbE1oUd7MzpeyISbgE8pS/kHt9+yr+QP5FfLRGy0RSTjlYA jJ1Q53rPGyyLYF8HYd42IBkqLsk8awcjpaZD8QSvvGLTf5L+cYXA0gALZWrmDSQeKyF9 j2vQ== X-Gm-Message-State: AFeK/H3W/PPlgI99QNSDth703iGWIEh1bPChrtaKU0yJuBDFxFdw+q+wO7/p4d6Fdv7pTBOQgohSQLjJPp5WVw== X-Received: by 10.223.168.80 with SMTP id l74mr3182998wrc.184.1489585035833; Wed, 15 Mar 2017 06:37:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.166.5 with HTTP; Wed, 15 Mar 2017 06:36:55 -0700 (PDT) In-Reply-To: <78B0B91A8FEB2E43B20BCCE1326131812D6B6CAC@mail-essen-01.secunet.de> References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> <78B0B91A8FEB2E43B20BCCE1326131812D6B6CAC@mail-essen-01.secunet.de> From: William Whyte Date: Wed, 15 Mar 2017 09:36:55 -0400 Message-ID: To: "Tams, Benjamin" Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=f403045f4cf0ec9234054ac50a5d Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:37:19 -0000 --f403045f4cf0ec9234054ac50a5d Content-Type: text/plain; charset=UTF-8 I don't want to overcommit and disappoint, but we hope it'll be soon. Cheers, William On Wed, Mar 15, 2017 at 9:10 AM, Tams, Benjamin wrote: > Hi William, > > > I should note that Security Innovation, which owns the patents for NTRU > and which I work for, has announced an intent to make the NTRUEncrypt IP > public domain. A formal announcement should follow shortly. > > Good to know. Is there already a timeline for making NTRUEncrypt IP public > domain? > > Kind regards, > Benjamin > --f403045f4cf0ec9234054ac50a5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't want to overcommit and disappoint, but we hope= it'll be soon.

Cheers,

Wil= liam

O= n Wed, Mar 15, 2017 at 9:10 AM, Tams, Benjamin <Benjamin.Tams@secu= net.com> wrote:
Hi William,=

> I should note that Security Innovation, which owns the patents for NTR= U and which I work for, has announced an intent to make the NTRUEncrypt IP = public domain. A formal announcement should follow shortly.

Good to know. Is there already a timeline for making NTRUEncrypt IP = public domain?

Kind regards,
Benjamin

--f403045f4cf0ec9234054ac50a5d-- From nobody Wed Mar 15 08:24:40 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C71131680 for ; Wed, 15 Mar 2017 08:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZolbqfuxFPq for ; Wed, 15 Mar 2017 08:24:37 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id DD6B813167B for ; Wed, 15 Mar 2017 08:24:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 13D0F23BCA; Wed, 15 Mar 2017 17:24:35 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 8AutznPUp2Sx; Wed, 15 Mar 2017 17:24:34 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 2F3FA2313; Wed, 15 Mar 2017 17:24:34 +0200 (EET) Date: Wed, 15 Mar 2017 17:24:26 +0200 From: Ilari Liusvaara To: "Tams, Benjamin" Cc: "cfrg@irtf.org" Message-ID: <20170315152426.GA22135@LK-Perkele-V2.elisa-laajakaista.fi> References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> <78B0B91A8FEB2E43B20BCCE1326131812D6B6CC3@mail-essen-01.secunet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <78B0B91A8FEB2E43B20BCCE1326131812D6B6CC3@mail-essen-01.secunet.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:24:39 -0000 On Wed, Mar 15, 2017 at 01:10:58PM +0000, Tams, Benjamin wrote: > Hi Watson, > > > Why should we preempt the current NIST postquantum standardization efforts? > > https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 Briefly read that document. Some quick comments: - Looks quite confusing. Especially the parts about HelloRetryRequest. But looking closer, that message is not used except for handling missed algorithm guess, right? So that if client guesses right (and it can make multiple guesses at cost of computation and bandwidth) there might not be HRR, right? - I don't think extending TLS extensions past 64kB is feasible. Especially in ClientHello It would require changes with nasty side-effects. - The document looks to be made for older draft of TLS 1.3. The way key is combined is bit unclear. I presume the key mixing should be done in two steps (adding a new step into TLS 1.3 key schedule, as the two existing mixing steps are already used for PSK and DH) because that's likely the easiest to implement. - Adding new handshake messages should be avoided, but AFAICT, there are none added. -Ilari From nobody Wed Mar 15 08:31:41 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF13C131692 for ; Wed, 15 Mar 2017 08:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGKQjfpcgcBx for ; Wed, 15 Mar 2017 08:31:37 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796D61315AE for ; Wed, 15 Mar 2017 08:31:37 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id u132so13765158wmg.0 for ; Wed, 15 Mar 2017 08:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aP2QoyARnHQ8bMFanUbXZ/LU43uawUjIVxmAnVKp/pc=; b=d+G9NYXbMV+L2J1nDZdqOCW9XGSF641N3mxZ7Q8e/D6hpPdTR095ICxv74610Amvp7 bkEQ+Ftq2urSxRSlCnmPxO6h4KqMBl8NodOkiciJhdWTqiKQPf8EHmyS9fudE/e93DWB AhWLK+YMMv5pPzz6Pa9C1uA2eeingRP2T565U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aP2QoyARnHQ8bMFanUbXZ/LU43uawUjIVxmAnVKp/pc=; b=t2KgK15r448OII4wnSXLsyXfqZTOzLUGmOP6sXc2hXu2yNmN/cUZ1O34Rd05EE3PW6 5o/xgh8glYGtEQcfqZ8RkTPYELxvxjWS5vST42Oo/fp7lLOCH+SGbuQC+M6MK6upandI Wl9pcpx8quNJUgBWlw8bhc/24p5yHweOLugj/3WkKp5Nx/YLIolyBUfqgY/owKkRVmBg j6r5NzWb7zzQ5y1iEl4QTcSoubiKRUUQO76CVYsAGAHKJ5o2G+06qLAFk+CBjgCJaslI yagTVOBQ8Z1qZsejfCPxVSsTmvVIdttLpkRNsIkFIm9+yAzIDRBUYiFI+JfzwZVCnnuN hVrw== X-Gm-Message-State: AFeK/H3EaUWRkOJIFIC26Gw7wwFkXtO0LWi9lnGrP0iZYGONgkEhwy8fEvvNQ78RegqFDJbsihGH5xwdLAkOsw== X-Received: by 10.28.170.67 with SMTP id t64mr20071734wme.18.1489591895867; Wed, 15 Mar 2017 08:31:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.166.5 with HTTP; Wed, 15 Mar 2017 08:31:15 -0700 (PDT) In-Reply-To: <20170315152426.GA22135@LK-Perkele-V2.elisa-laajakaista.fi> References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> <78B0B91A8FEB2E43B20BCCE1326131812D6B6CC3@mail-essen-01.secunet.de> <20170315152426.GA22135@LK-Perkele-V2.elisa-laajakaista.fi> From: William Whyte Date: Wed, 15 Mar 2017 11:31:15 -0400 Message-ID: To: Ilari Liusvaara Cc: "Tams, Benjamin" , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a11442286d07a1f054ac6a302 Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:31:40 -0000 --001a11442286d07a1f054ac6a302 Content-Type: text/plain; charset=UTF-8 There's a new draft of that document on the way, which has been developed in collaboration with some other stakeholders and should be more up-to-date wrt TLS 1.3. Again, not to overpromise, but hopefully by the end of next week. Cheers, William On Wed, Mar 15, 2017 at 11:24 AM, Ilari Liusvaara wrote: > On Wed, Mar 15, 2017 at 01:10:58PM +0000, Tams, Benjamin wrote: > > Hi Watson, > > > > > Why should we preempt the current NIST postquantum standardization > efforts? > > > > https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 > > Briefly read that document. Some quick comments: > > - Looks quite confusing. Especially the parts about HelloRetryRequest. > But looking closer, that message is not used except for handling > missed algorithm guess, right? So that if client guesses right (and > it can make multiple guesses at cost of computation and bandwidth) > there might not be HRR, right? > - I don't think extending TLS extensions past 64kB is feasible. > Especially in ClientHello It would require changes with nasty > side-effects. > - The document looks to be made for older draft of TLS 1.3. The > way key is combined is bit unclear. I presume the key mixing > should be done in two steps (adding a new step into TLS 1.3 > key schedule, as the two existing mixing steps are already > used for PSK and DH) because that's likely the easiest to > implement. > - Adding new handshake messages should be avoided, but AFAICT, > there are none added. > > > -Ilari > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a11442286d07a1f054ac6a302 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's a new draft of that document on the way, which= has been developed in collaboration with some other stakeholders and shoul= d be more up-to-date wrt TLS 1.3. Again, not to overpromise, but hopefully = by the end of next week.

Cheers,

William

On Wed, Mar 15, 2017 at 11:24 AM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
On Wed, Mar 15, 2017 at 01:10:58PM +0000, Tams, Benjamin wrote:<= br> > Hi Watson,
>
> > Why should we preempt the current NIST postquantum standardizatio= n efforts?
>
> https://tools.ietf.org/html/dra= ft-whyte-qsh-tls13-03

Briefly read that document. Some quick comments:

- Looks quite confusing. Especially the parts about HelloRetryRequest.
=C2=A0 But looking closer, that message is not used except for handling
=C2=A0 missed algorithm guess, right? So that if client guesses right (and<= br> =C2=A0 it can make multiple guesses at cost of computation and bandwidth) =C2=A0 there might not be HRR, right?
- I don't think extending TLS extensions past 64kB is feasible.
=C2=A0 Especially in ClientHello It would require changes with nasty
=C2=A0 side-effects.
- The document looks to be made for older draft of TLS 1.3. The
=C2=A0 way key is combined is bit unclear. I presume the key mixing
=C2=A0 should be done in two steps (adding a new step into TLS 1.3
=C2=A0 key schedule, as the two existing mixing steps are already
=C2=A0 used for PSK and DH) because that's likely the easiest to
=C2=A0 implement.
- Adding new handshake messages should be avoided, but AFAICT,
=C2=A0 there are none added.


-Ilari

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--001a11442286d07a1f054ac6a302-- From nobody Wed Mar 15 10:09:31 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E5013171B for ; Wed, 15 Mar 2017 10:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqO6Vo3VxOS2 for ; Wed, 15 Mar 2017 10:09:27 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53C213171A for ; Wed, 15 Mar 2017 10:09:23 -0700 (PDT) X-AuditID: c1b4fb30-25b3698000007738-f3-58c975411287 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id E3.B4.30520.14579C85; Wed, 15 Mar 2017 18:09:22 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 15 Mar 2017 18:08:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IP7A1HMYJCs3CAtIg8DG7BKt103fWepm4Jx8Y2JoJDE=; b=U4QD2G3nMPnlTZuuna+z9SAQ4zzhmWvpKYX1pgjICOV7cn7q5z5BQFBrns84c/8OFlQHMv1sEHGJw/e2/XKIV/RzZ7jtnSTCQ8Cg87V15ejfuUiMXk0KgGWMwTMAtzPNN2hQAna/gw9ORShWAY+1cjnv5E0dZNxU0Vtpk7loFu8= Received: from DB5PR07MB1256.eurprd07.prod.outlook.com (10.164.41.146) by DB5PR07MB1253.eurprd07.prod.outlook.com (10.164.41.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 17:08:27 +0000 Received: from DB5PR07MB1256.eurprd07.prod.outlook.com ([fe80::f4cc:2ed2:b5c9:edb7]) by DB5PR07MB1256.eurprd07.prod.outlook.com ([fe80::f4cc:2ed2:b5c9:edb7%14]) with mapi id 15.01.0977.010; Wed, 15 Mar 2017 17:08:27 +0000 From: John Mattsson To: Ilari Liusvaara , "Tams, Benjamin" CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] Postquantum cryptography in IETF protocols Thread-Index: AQHSnTVSkd2C5muk90qpn8ubO1BhqqGV4MEAgAAlSgCAAC3SAA== Date: Wed, 15 Mar 2017 17:08:27 +0000 Message-ID: References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> <78B0B91A8FEB2E43B20BCCE1326131812D6B6CC3@mail-essen-01.secunet.de> <20170315152426.GA22135@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170315152426.GA22135@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: welho.com; dkim=none (message not signed) header.d=none;welho.com; dmarc=none action=none header.from=ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [82.214.42.176] x-microsoft-exchange-diagnostics: 1; DB5PR07MB1253; 7:D8qUdrAbh45KSs+lwixjhjNsIVgBAEjW6H8peD9RffJSxTe7UzUhU7qTLAMhisPJ59RWqVHvXzLez7hULwS+pFNeZYesJ+j5gdMTKuKPGQd/MG1F0MHluW/GdZowYQxainASb3Yd0/11niL7AD/uAxFMm2MK2lfbpTJd5x/Rdov0HacmOy02ot8TGo1HlZXYd3UfsoyZ9ym2HMkAk3fhtqQrVwbF5yxzioMHZ12Ol2UOZ1el7yehQaaXZscIHDgv8V40YJIeJtGrw3FpFynhNDzZH2B1XbYQvJg1D9rjtwWi+blYXEw1fMKCezIrc+j/WuOfXV4WawyeVPtq624doA== x-ms-office365-filtering-correlation-id: 06621f06-d8c2-47b8-02b7-08d46bc5e5d3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB5PR07MB1253; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:DB5PR07MB1253; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1253; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(377424004)(7736002)(305945005)(6436002)(99286003)(6486002)(189998001)(36756003)(53546007)(6506006)(2900100001)(229853002)(86362001)(66066001)(50986999)(8676002)(81166006)(38730400002)(3660700001)(2950100002)(5660300001)(6246003)(8936002)(54356999)(6306002)(6512007)(4001350100001)(76176999)(3846002)(102836003)(4326008)(93886004)(53936002)(6116002)(3280700002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB1253; H:DB5PR07MB1256.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <59049A20E8522347B58E656E553002BD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 17:08:27.3216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1253 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUyM2K7k65T6ckIg6/tHBav731ktej+cZDJ 4v3u6SwOzB6TNx5m89jUuoTV43b3HLYA5igum5TUnMyy1CJ9uwSujCevX7EU3BGpeLmhhbGB cYZIFyMnh4SAicSan7tYuhi5OIQE1jFKTF33kg3COcEosfHXGlYQh0Wgl1mi8ftzdojMVCaJ o5cPMUI4jxklLr36zgIyjE3AQGLungagfg4OEYE4if17tUDCzALKEovWn2ACsYUF7CSat15k BbFFBOwlznZ1MULYThKfu6eygdgsAqoSqxdNAavnFTCX2HP/PZgtJDCLSeLVRRcQm1PAQ6Jv 4VmwOKOAmMT3U2uYIHaJS9x6Mp8J4jcBiSV7zjND2KISLx//A9srKqAnsfz5GmaQ+xkFehkl Gn5+ZYEo0pE4e/0JI4StKHGjfQcrhN3DLPGutwTC9pW4dm05K4y9bPFlqPpsiUWvr0EttpZY 1HAZbIEEyNFfbryFapCR+HvnCpS9k0Vi3sHKCYw6s5AcPgsYdswCmhLrd+lDhD0k/t84wA5h K0pM6X4IZvMKCEqcnPmEZQEj6ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwBRzcMtvgx2M L587HmIU4GBU4uH9EHYyQog1say4MvcQowQHs5II76ZioBBvSmJlVWpRfnxRaU5q8SFGaQ4W JXFes5X3w4UE0hNLUrNTUwtSi2CyTBycUg2ME1edOe55eUdJcNZxmZWLf8/KtpgbMTOsScXE LzWvdMHGvkNWy1ccinicse9hxqHVuv9yc1TZ11p76+6fphjW/tbrwjzJ3GQRL/UPxxLiHwj9 YRH+3VfCae6+Z7Po07v/Nnlof0yNc/7C8UI2Pv5EJ0ebZ3hs+NLLe27capm0P3CbzbE1io9k lViKMxINtZiLihMB8WEsiS0DAAA= Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 17:09:29 -0000 VExTIDEuMyBmb3JiaWRzIHN0YXRpYyBSU0EgZm9yIGEgcmVhc29uLCBkcmFmdC13aHl0ZS1xc2gt dGxzMTMtMDMgc2VlbXMgdG8NCmJyaW5nIGl0IGJhY2sgaW4gdGhlIGZvcm0gb2Ygc3RhdGljIE5U UlVFbmNyeXB0LiBJIHNlZSBubyByZWFzb24gdG8gZG8NCnRoYXQuIElmIHNvbWVvbmUgd2FudHMg dG8gZG8gZWFybHkgUENRIGluIFRMUyAxLjMsIEkgdGhpbmsgdGhlIHR3byBsYXR0aWNlDQpiYXNl ZCBwcm90b2NvbHMgc3VnZ2VzdGVkIGJ5IERhdmlkIE1jR3JldyAoRnJvZG8sIE5ldyBIb3BlKSBh cyB3ZWxsIGFzDQpTdXBlcnNpbmd1bGFyIEVsbGlwdGljIEN1cnZlIElnb2dlbnkgRGlmZmllLUhl bGxtYW4gKFNJREgpIGlzIHRoZSB3YXkgdG8NCmdvLiBUaGUgbGF0dGljZS1iYXNlZCB2YXJpYW50 cyBhcmUgZmFzdCB3aGlsZSBTSURIIGhhcyBtdWNoIHNtYWxsZXINCmVwaGVtZXJhbCBrZXlzLg0K DQpKb2huDQoNCg0KDQpPbiAyMDE3LTAzLTE1LCAxNjoyNCwgIkNmcmcgb24gYmVoYWxmIG9mIEls YXJpIExpdXN2YWFyYSINCjxjZnJnLWJvdW5jZXNAaXJ0Zi5vcmcgb24gYmVoYWxmIG9mIGlsYXJp bGl1c3ZhYXJhQHdlbGhvLmNvbT4gd3JvdGU6DQoNCj5PbiBXZWQsIE1hciAxNSwgMjAxNyBhdCAw MToxMDo1OFBNICswMDAwLCBUYW1zLCBCZW5qYW1pbiB3cm90ZToNCj4+IEhpIFdhdHNvbiwNCj4+ IA0KPj4gPiBXaHkgc2hvdWxkIHdlIHByZWVtcHQgdGhlIGN1cnJlbnQgTklTVCBwb3N0cXVhbnR1 bSBzdGFuZGFyZGl6YXRpb24NCj4+ZWZmb3J0cz8NCj4+IA0KPj4gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXdoeXRlLXFzaC10bHMxMy0wMw0KPg0KPkJyaWVmbHkgcmVhZCB0aGF0 IGRvY3VtZW50LiBTb21lIHF1aWNrIGNvbW1lbnRzOg0KPg0KPi0gTG9va3MgcXVpdGUgY29uZnVz aW5nLiBFc3BlY2lhbGx5IHRoZSBwYXJ0cyBhYm91dCBIZWxsb1JldHJ5UmVxdWVzdC4NCj4gIEJ1 dCBsb29raW5nIGNsb3NlciwgdGhhdCBtZXNzYWdlIGlzIG5vdCB1c2VkIGV4Y2VwdCBmb3IgaGFu ZGxpbmcNCj4gIG1pc3NlZCBhbGdvcml0aG0gZ3Vlc3MsIHJpZ2h0PyBTbyB0aGF0IGlmIGNsaWVu dCBndWVzc2VzIHJpZ2h0IChhbmQNCj4gIGl0IGNhbiBtYWtlIG11bHRpcGxlIGd1ZXNzZXMgYXQg Y29zdCBvZiBjb21wdXRhdGlvbiBhbmQgYmFuZHdpZHRoKQ0KPiAgdGhlcmUgbWlnaHQgbm90IGJl IEhSUiwgcmlnaHQ/DQo+LSBJIGRvbid0IHRoaW5rIGV4dGVuZGluZyBUTFMgZXh0ZW5zaW9ucyBw YXN0IDY0a0IgaXMgZmVhc2libGUuDQo+ICBFc3BlY2lhbGx5IGluIENsaWVudEhlbGxvIEl0IHdv dWxkIHJlcXVpcmUgY2hhbmdlcyB3aXRoIG5hc3R5DQo+ICBzaWRlLWVmZmVjdHMuDQo+LSBUaGUg ZG9jdW1lbnQgbG9va3MgdG8gYmUgbWFkZSBmb3Igb2xkZXIgZHJhZnQgb2YgVExTIDEuMy4gVGhl DQo+ICB3YXkga2V5IGlzIGNvbWJpbmVkIGlzIGJpdCB1bmNsZWFyLiBJIHByZXN1bWUgdGhlIGtl eSBtaXhpbmcNCj4gIHNob3VsZCBiZSBkb25lIGluIHR3byBzdGVwcyAoYWRkaW5nIGEgbmV3IHN0 ZXAgaW50byBUTFMgMS4zDQo+ICBrZXkgc2NoZWR1bGUsIGFzIHRoZSB0d28gZXhpc3RpbmcgbWl4 aW5nIHN0ZXBzIGFyZSBhbHJlYWR5DQo+ICB1c2VkIGZvciBQU0sgYW5kIERIKSBiZWNhdXNlIHRo YXQncyBsaWtlbHkgdGhlIGVhc2llc3QgdG8NCj4gIGltcGxlbWVudC4NCj4tIEFkZGluZyBuZXcg aGFuZHNoYWtlIG1lc3NhZ2VzIHNob3VsZCBiZSBhdm9pZGVkLCBidXQgQUZBSUNULA0KPiAgdGhl cmUgYXJlIG5vbmUgYWRkZWQuDQo+DQo+DQo+LUlsYXJpDQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5DZnJnIG1haWxpbmcgbGlzdA0KPkNmcmdA aXJ0Zi5vcmcNCj5odHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcNCg0K From nobody Wed Mar 15 10:28:58 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59ED3131743 for ; Wed, 15 Mar 2017 10:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykoVCS-qbZVQ for ; Wed, 15 Mar 2017 10:28:54 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A1113174E for ; Wed, 15 Mar 2017 10:28:39 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id u108so15734838wrb.3 for ; Wed, 15 Mar 2017 10:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E1iHjkD5ZC1o/lTTCjDf2khEVPcNVn8+PxiBdg4PFRI=; b=CLERl4O+r5CvF0i/NA6SljX7woxshwwOGah/Dlw1t5iUiC7ErJD33tok0e0RmbWy9Y WzBOVdgjH6+y0T+2JQfjD7hXzv5x8D/aCttcRBnZKNsmRFCIuri3k9s+JtPVvlevKtJT lBpXwPlFoVArA4KzuYGtc67NyBmmyTSw49ijU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E1iHjkD5ZC1o/lTTCjDf2khEVPcNVn8+PxiBdg4PFRI=; b=mLv4xh9js+uDBq0jfwZ4oa7+Dw3dcaYTQhBOT/BWonhtUTJ2/rDdvQ/gacrM/qE4xW +e4j1UxUuKUSIVZJnJEygnS9360sYcxv0tXdHFv7NdYvJGYoG8JIKRBx0fbATOgI0nz/ lFm6N79z8+Y6SQdcUHcV3MdPJY86xnRDxYZSdzVzWDpxzOeYr7dl/sch6XLJM9vPYoij hL16ycpd3x+1VQLJEhGK1/X4QRDdS7XQH3tRjGq3vyPm9wt9miKv+VzS0NbqanqTIKhC xqZWGM/BXfXA3XDUuLe5gSK7KUYFNS+nL7so1Ob57ygw/8SC8xiRYtr++1CM79OCVtpU UH7g== X-Gm-Message-State: AFeK/H1OVSoOOI5Ff3OcLnXvulR30j4GI3ov1lVXhVEl0mlyGZMttN8G8akFF6lPfgxGBysxtLvmMtmv1bHHQw== X-Received: by 10.223.171.78 with SMTP id r14mr3852109wrc.113.1489598918242; Wed, 15 Mar 2017 10:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.166.5 with HTTP; Wed, 15 Mar 2017 10:28:17 -0700 (PDT) In-Reply-To: References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> <78B0B91A8FEB2E43B20BCCE1326131812D6B6CC3@mail-essen-01.secunet.de> <20170315152426.GA22135@LK-Perkele-V2.elisa-laajakaista.fi> From: William Whyte Date: Wed, 15 Mar 2017 13:28:17 -0400 Message-ID: To: John Mattsson Cc: Ilari Liusvaara , "Tams, Benjamin" , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=94eb2c1b40ac61521a054ac8467d Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 17:28:57 -0000 --94eb2c1b40ac61521a054ac8467d Content-Type: text/plain; charset=UTF-8 That draft is in the process of being updated, but it was never intended to propose static NTRU keys; if it looks like it does, it needs to be clarified. NTRU key generation is fast enough that there's no need to avoid ephemeral keys. Cheers, William On Wed, Mar 15, 2017 at 1:08 PM, John Mattsson wrote: > TLS 1.3 forbids static RSA for a reason, draft-whyte-qsh-tls13-03 seems to > bring it back in the form of static NTRUEncrypt. I see no reason to do > that. If someone wants to do early PCQ in TLS 1.3, I think the two lattice > based protocols suggested by David McGrew (Frodo, New Hope) as well as > Supersingular Elliptic Curve Igogeny Diffie-Hellman (SIDH) is the way to > go. The lattice-based variants are fast while SIDH has much smaller > ephemeral keys. > > John > > > > On 2017-03-15, 16:24, "Cfrg on behalf of Ilari Liusvaara" > wrote: > > >On Wed, Mar 15, 2017 at 01:10:58PM +0000, Tams, Benjamin wrote: > >> Hi Watson, > >> > >> > Why should we preempt the current NIST postquantum standardization > >>efforts? > >> > >> https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 > > > >Briefly read that document. Some quick comments: > > > >- Looks quite confusing. Especially the parts about HelloRetryRequest. > > But looking closer, that message is not used except for handling > > missed algorithm guess, right? So that if client guesses right (and > > it can make multiple guesses at cost of computation and bandwidth) > > there might not be HRR, right? > >- I don't think extending TLS extensions past 64kB is feasible. > > Especially in ClientHello It would require changes with nasty > > side-effects. > >- The document looks to be made for older draft of TLS 1.3. The > > way key is combined is bit unclear. I presume the key mixing > > should be done in two steps (adding a new step into TLS 1.3 > > key schedule, as the two existing mixing steps are already > > used for PSK and DH) because that's likely the easiest to > > implement. > >- Adding new handshake messages should be avoided, but AFAICT, > > there are none added. > > > > > >-Ilari > > > >_______________________________________________ > >Cfrg mailing list > >Cfrg@irtf.org > >https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --94eb2c1b40ac61521a054ac8467d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That draft is in the process of being updated, but it was = never intended to propose static NTRU keys; if it looks like it does, it ne= eds to be clarified. NTRU key generation is fast enough that there's no= need to avoid ephemeral keys.

Cheers,

William

On Wed, Mar 15, 2017 at 1:08 PM, John Mattsson = <john.ma= ttsson@ericsson.com> wrote:
TLS 1.3 forbids static RSA for a reason, draft-whyte-qsh-tls13-03 seems to=
bring it back in the form of static NTRUEncrypt. I see no reason to do
that. If someone wants to do early PCQ in TLS 1.3, I think the two lattice<= br> based protocols suggested by David McGrew (Frodo, New Hope) as well as
Supersingular Elliptic Curve Igogeny Diffie-Hellman (SIDH) is the way to go. The lattice-based variants are fast while SIDH has much smaller
ephemeral keys.

John



On 2017-03-15, 16:24, "Cfrg on behalf of Ilari Liusvaara"
<cfrg-bounces@irtf.org on behalf of ilariliusvaara@welho.com> wrote:

>On Wed, Mar 15, 2017 at 01:10:58PM +0000, Tams, Benjamin wrote:
>> Hi Watson,
>>
>> > Why should we preempt the current NIST postquantum standardiz= ation
>>efforts?
>>
>> https://tools.ietf.org/html/draft-= whyte-qsh-tls13-03
>
>Briefly read that document. Some quick comments:
>
>- Looks quite confusing. Especially the parts about HelloRetryRequest.<= br> >=C2=A0 But looking closer, that message is not used except for handling=
>=C2=A0 missed algorithm guess, right? So that if client guesses right (= and
>=C2=A0 it can make multiple guesses at cost of computation and bandwidt= h)
>=C2=A0 there might not be HRR, right?
>- I don't think extending TLS extensions past 64kB is feasible.
>=C2=A0 Especially in ClientHello It would require changes with nasty >=C2=A0 side-effects.
>- The document looks to be made for older draft of TLS 1.3. The
>=C2=A0 way key is combined is bit unclear. I presume the key mixing
>=C2=A0 should be done in two steps (adding a new step into TLS 1.3
>=C2=A0 key schedule, as the two existing mixing steps are already
>=C2=A0 used for PSK and DH) because that's likely the easiest to >=C2=A0 implement.
>- Adding new handshake messages should be avoided, but AFAICT,
>=C2=A0 there are none added.
>
>
>-Ilari
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--94eb2c1b40ac61521a054ac8467d-- From nobody Thu Mar 16 07:16:45 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C0E129534 for ; Thu, 16 Mar 2017 07:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiLXuZOX84YD for ; Thu, 16 Mar 2017 07:16:39 -0700 (PDT) Received: from www363.your-server.de (www363.your-server.de [78.46.179.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C546F129537 for ; Thu, 16 Mar 2017 07:16:25 -0700 (PDT) Received: from [88.198.220.131] (helo=sslproxy02.your-server.de) by www363.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1coWCV-0002Gz-0c for cfrg@ietf.org; Thu, 16 Mar 2017 15:16:23 +0100 Received: from [131.155.71.113] by sslproxy02.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1coWCU-0003ph-R0 for cfrg@ietf.org; Thu, 16 Mar 2017 15:16:22 +0100 To: cfrg@ietf.org References: <148916134095.7523.2902255880255088390@ietfa.amsl.com> From: "A. Huelsing" Message-ID: <61e3e29c-1c01-eaa3-ad7e-148fcdb7cc5c@huelsing.net> Date: Thu, 16 Mar 2017 15:17:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148916134095.7523.2902255880255088390@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Authenticated-Sender: ietf@huelsing.net X-Virus-Scanned: Clear (ClamAV 0.99.2/23209/Thu Mar 16 13:14:31 2017) Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-xmss-hash-based-signatures-08.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 14:16:43 -0000 Hi, this new version handles the comments from Kenny's review. Cheers, Andreas Am 10-03-17 um 16:55 schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Crypto Forum of the IETF. > > Title : XMSS: Extended Hash-Based Signatures > Authors : Andreas Huelsing > Denis Butin > Stefan-Lukas Gazdag > Aziz Mohaisen > Filename : draft-irtf-cfrg-xmss-hash-based-signatures-08.txt > Pages : 67 > Date : 2017-03-10 > > Abstract: > This note describes the eXtended Merkle Signature Scheme (XMSS), a > hash-based digital signature system. It follows existing > descriptions in scientific literature. The note specifies the WOTS+ > one-time signature scheme, a single-tree (XMSS) and a multi-tree > variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main > building block. XMSS provides cryptographic digital signatures > without relying on the conjectured hardness of mathematical problems. > Instead, it is proven that it only relies on the properties of > cryptographic hash functions. XMSS provides strong security > guarantees and is even secure when the collision resistance of the > underlying hash function is broken. It is suitable for compact > implementations, relatively simple to implement, and naturally > resists side-channel attacks. Unlike most other signature systems, > hash-based signatures can withstand attacks using quantum computers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-irtf-cfrg-xmss-hash-based-signatures/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-xmss-hash-based-signatures-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Tue Mar 21 12:42:35 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF92912894A for ; Tue, 21 Mar 2017 12:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dI9k5_kpya8M for ; Tue, 21 Mar 2017 12:42:31 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC113127286 for ; Tue, 21 Mar 2017 12:42:31 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id n190so98253512pga.0 for ; Tue, 21 Mar 2017 12:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=bjn9i+eu0XjhwC3hxmfMNBHF99Ku8Pez/ZrPzAMkHR4=; b=DaG/ntAd48mtYK4s74FO79xlRMjHAu4NhmVaFhSpT8iQ0tNz04x6ll1nG04LIAgfE+ 4l5CPqY/QXYlxCNdQkXCaIXe9Ve1VZfQatLOIDb3Ck/S3fQobLn8j0AVv9D70j0NCql3 y5htit8tZr3x2ul0QQuEP3AoUEa/mHXwn4qgrXHsEdccZyaT2RBBzHA9RUg+6341BoiZ +tLKWXLrnCfPHIVm1WhJ82yCdkiA86TcBxCQke0Fk55p6RHBgBm8KUN8BlmdrZGU4D9L qVKXsx+wdK5e+IxCYOny07MvGadnRBMdJ+ZG6JwPLIv5l4eSMSN+589xpDrkSc2zQZ4G wnGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bjn9i+eu0XjhwC3hxmfMNBHF99Ku8Pez/ZrPzAMkHR4=; b=EEMaWUpoyDMh+CoCR/IAcqmaK2NogvXF6Emt0Dm7YYhHyNXNVP5c4lCTMqwPGPPMji rBJUxYNlNR2cy92lnqIJwSSAQEjimyrL9Hk4rXvesPZiV1xDYEuA6t5jQvy9/jGLyrS1 ZpDVMJRTm6IOU2L6ORaK09pqKKQIPl5qQUjze6ViCAi7j2xWgE/dZUc2lSljM4vubJjm rRN2sS9t2CEmfyDBinA0J7BOMa+FZEnVv3TV3M0ScugSvyZME97kzGdo7bY+e3GFBX4M QsIjUaEJweMrly5C6rKGSmwyAo9ZE6Rdx4Cc19s+aqFThBRrgScTGLuuBxCwg8h35fAO eF+A== X-Gm-Message-State: AFeK/H3ELtCYCdU92JSDb96GaSAQLeZfMvWBAVbbIJms5e8Hm0X4WbGdPOv9SJvSn33X+jKbK47nWvyarz/5hg== X-Received: by 10.84.178.195 with SMTP id z61mr50268999plb.139.1490125351181; Tue, 21 Mar 2017 12:42:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.178.234 with HTTP; Tue, 21 Mar 2017 12:42:10 -0700 (PDT) From: Tony Arcieri Date: Tue, 21 Mar 2017 12:42:10 -0700 Message-ID: To: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=94eb2c11a66c3a67a5054b42d86f Archived-At: Subject: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 19:42:34 -0000 --94eb2c11a66c3a67a5054b42d86f Content-Type: text/plain; charset=UTF-8 Hierarchical key derivation (also sometimes described as "semiprivate keys" or "key blinding") is an increasingly popular technique for generating unlinkable child keys from master public and private keys. The Tor Project has been exploring such an approach as the basis for their next-generation hidden services design for several years now[1], during which time it has received security proofs[2]. Their latest design[3] allegedly includes feedback from Dan Bernstein. Application of hierarchical key derivation is perhaps most notable in the cryptocurrency space, where Bitcoin's BIP32[4] provided a means for unlinkable single-use signature keys for the secp256k1 elliptic curve. There are several designs for applying the ideas from BIP32 to Ed25519, including ones from Evernym[5] and Chain[6] (where I am an employee). The designs in [3], [5], and [6] are all highly similar and accomplish the same goals. Personally I would love to see a single standard design for producing Ed25519 signatures from hierarchically derived keys, notably one which produces signatures that can be verified by any off-the-shelf RFC 8032-compatible Ed25519 implementation. There's already been some discussion of this on the moderncrypto.org curves list: https://moderncrypto.org/mail-archive/curves/2017/000858.html I'd be curious to know if anyone else would be interested in collaborating on a draft for such a standard, which can be a synthesis of the existing work in this space. [1]: https://lists.torproject.org/pipermail/tor-dev/2012-September/004026.html [2]: https://www-users.cs.umn.edu/~hopper/basic-proof.pdf [3]: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1979 [4]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki [5]: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/HDKeys-Ed25519.pdf [6]: https://chain.com/docs/protocol/specifications/chainkd -- Tony Arcieri --94eb2c11a66c3a67a5054b42d86f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hierarchical key derivation (also sometimes described as &= quot;semiprivate keys" or "key blinding") is an increasingly= popular technique for generating unlinkable child keys from master public = and private keys.

The Tor Project has been exploring suc= h an approach as the basis for their next-generation hidden services design= for several years now[1], during which time it has received security proof= s[2]. Their latest design[3] allegedly includes feedback from Dan Bernstein= .

Application of hierarchical key derivation is pe= rhaps most notable in the cryptocurrency space, where Bitcoin's BIP32[4= ] provided a means for unlinkable single-use signature keys for the secp256= k1 elliptic curve. There are several designs for applying the ideas from BI= P32 to Ed25519, including ones from Evernym[5] and Chain[6] (where I am an = employee).

The designs in [3], [5], and [6] are al= l highly similar and accomplish the same goals. Personally I would love to = see a single standard design for producing Ed25519 signatures from hierarch= ically derived keys, notably one which produces signatures that can be veri= fied by any off-the-shelf RFC 8032-compatible Ed25519 implementation.
=

There's already been some discussion of this on the= moderncrypto.org curves list:


I'd be curious to know if anyon= e else would be interested in collaborating on a draft for such a standard,= which can be a synthesis of the existing work in this space.
--94eb2c11a66c3a67a5054b42d86f-- From nobody Tue Mar 21 16:27:37 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30BA129407 for ; Tue, 21 Mar 2017 16:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u89uma2rCNGT for ; Tue, 21 Mar 2017 16:27:33 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F3A128708 for ; Tue, 21 Mar 2017 16:27:33 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id 196so5276950wmm.1 for ; Tue, 21 Mar 2017 16:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=FIDFWbna2VTQFEG/CSRuLsoQjKSj4yQZa+qrdGyBth0=; b=ECCGaYgjGdbNnK4NyjD/L5N0mx84YUtVBHRmqTiGuT7UNhUoLHoqbuPJeatnRcjT3v cs78MuCrJOU2dWMbSPB1uGPo18F/d+MC2lGXlaWU9bEPf8ho7p5JbV1Jw2ypkIsnkNLy ddfPNREcZfQ6gVz+cCvycA0nbOOBhu9dG9+FQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=FIDFWbna2VTQFEG/CSRuLsoQjKSj4yQZa+qrdGyBth0=; b=crO4VblSVx1HW3Msbkt20W86CFlkZO4ISpmVbh0JimkKcFijRRVHff0EYy2Os24pUm 1zD/JY4D7OoENviUaq4TvZ8Z4t0YTk2aZDr2fF1gTI6Vnxh8lPH0cfWlx8K1E2hrhO1L cqPGw4DvN2fO0agEKbmQM0E9fifvtyVCrPIuem1H+OFcyEso3FtL1nVCpszMLDcyOl5S 8AAnZ5eEL/HNNqR0Qv3NAsdoaQhCElWt37UBxNXdfvBOzvs32axhO3/HDtxEJxjTSFJx 1TlyaScutZY+wWjcAZi373yF6yQMouO7MU9PQc2IY2JHR0lmVIHiPbf5EzhKeYrZaEQR a/Jg== X-Gm-Message-State: AFeK/H1qVQjhR+klJk1vf9ZfrYObs/D+JSp90lC1wMtB06Zeh26s4smnJRLlzhRIGJH5Tg== X-Received: by 10.28.95.85 with SMTP id t82mr5203215wmb.107.1490138846991; Tue, 21 Mar 2017 16:27:26 -0700 (PDT) Received: from [192.168.3.194] ([217.5.149.10]) by smtp.gmail.com with ESMTPSA id t63sm19355705wme.16.2017.03.21.16.27.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Mar 2017 16:27:26 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_36B5F71F-9E8D-44A7-A0D0-B38CF0D6B33B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Aaron Zauner In-Reply-To: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> Date: Wed, 22 Mar 2017 00:27:16 +0100 Cc: "cfrg@irtf.org" Message-Id: <51780B9E-8BE5-493F-8338-AB3E80E9BFEC@azet.org> References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> To: "Tams, Benjamin" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 23:27:36 -0000 --Apple-Mail=_36B5F71F-9E8D-44A7-A0D0-B38CF0D6B33B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Quick comment: > On 14 Mar 2017, at 18:31, Tams, Benjamin = wrote: >=20 > Hi John, >=20 >> Good that CFRG starts some more detailed discussion on PQC. It makes = sense >> to support post-quantum key exchange for use cases that need = long-term >> confidentiality (15 years). For other use cases I think it can wait = until >> PQC key exchange algorithms has been thoroughly evaluated and >> standardized. If implemented now, it should be used in addition to = ECDHE, >> just like Google has done with their experimental New Hope = implementation. >=20 > I absolutely agree with your view on the subject. Especially for those = use > cases where the attack scenario "collect today, decrypt tomorrow" is a = threat, > we should start thinking of PQ-safe key exchange methods in time. Even = if > they eventually turn out to be insecure; we can now combine them with > classical key exchange algorithms. We have nothing to lose. >=20 > There is already IETF work addressing PQ-security in Internet = protocols, e.g. > IKE and an Internet Draft for a Quantum-Safe Hybrid Ciphersuite for = TLS >=20 > https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-03 > https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 >=20 > On the other hand, there is (to my knowledge) no specification for a = PQ-safe > patent-free key exchange algorithm suitable for implementation. In = fact, in > https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 > only NTRUEncrypt is specified but is subject to patents. >=20 > A possible first step is that CFRG creates an Internet Draft. In fact, > the algorithm New Hope has already been implemented as a plugin for > strongSwan (IPSec implementation for the Linux kernel) >=20 > = https://github.com/strongswan/strongswan/tree/master/src/libstrongswan/plu= gins/newhope >=20 > So why do we not start with a draft for which the above implementation = can > serve as a reference implementation? NewHope has been implemented in Tor and also in Chrome for testing = purposes. As for StrongSwan: they implement quite a lot. There's also a = NTRU IKE implementation available in StrongSwan = (https://wiki.strongswan.org/projects/strongswan/wiki/NTRU). Just = because there's an implementation of something doesn't necessarily = warrant work on an internet draft/standard. To me PQC is quite a new = field and security boundaries are not as established as they're for say = symmetric or public key cryptography (someone correct me if I've missed = major news in that area). BTW there was a recent paper with some = "improved" attacks on NewHope (it doesn't break the scheme, they just = recommend more conservative parameter choices) - = https://eprint.iacr.org/2017/221 Aaron --Apple-Mail=_36B5F71F-9E8D-44A7-A0D0-B38CF0D6B33B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY0bbVAAoJEOTbZJL9ubXV4TgQAJwnNGFpQnjLhISdLPnoOWxj +pfgbyp2Shz/RS6A1EOsqPnUF+Bk0VyCs21946yZst5EHIV78A3j43wv1HCxmJOc Am2OhLZS71mU9nhXxcPayrxD/lhvygXErXKk7opTz0ej7TzMXDOxq3iiDp2vvtT6 zE/wvrezx6p5lxVxKaa6mnaIGiaolRyGoVCCj8fxXuJtVb2iLNlwmU5p7hm4Rnxw cOue8Fbrw+u3KbUFw0E0B+BMqZas1ebFJ69YyHTHG6Dgs1/RNgq7TEPHHeBgwinC GaQRL4KQlN5q8Oku+nKB1htWWom1ZMjcZfFXQo/NJcjWCxr/XrCNWWzPzk4Evz1B TNqQX9IpLC6B/0YcZK8ihtFEGt7yqSWMaYO4kTCYGM7VDj3LO9uBo2OvuhF8FaUf urjFNHungXLGHc6qNCfn5+NFAVm7LCd3ZWh3+yMww+Byg7eitspOtY6dv6U4vHQY gKkO6G+xmBgA+hzTOTTMmZExLE3lw8Vav8r9Z55RLasl9X/WHRtJC0ErPiJd17bV CaqLpR3/JxUW+23kG29jnkaVcfZ1+W6szd+HOPcSiXp7n94Q3GXB7maQP9JiFwdO zCgzgaaKZdKim1yIH4S8dpl1HR8TP1fS1M9N2mt+2fda+54wTxEmlyn8MqntkmNZ N8tvrVkPOJwyS7ZhTYDg =bt/g -----END PGP SIGNATURE----- --Apple-Mail=_36B5F71F-9E8D-44A7-A0D0-B38CF0D6B33B-- From nobody Tue Mar 21 17:25:09 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B68D13010D for ; Tue, 21 Mar 2017 17:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXtV1aFp6Sei for ; Tue, 21 Mar 2017 17:25:06 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15B5129412 for ; Tue, 21 Mar 2017 17:25:05 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n11so24135915wma.0 for ; Tue, 21 Mar 2017 17:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=V38Eo0HJqI9i3bQJJfOUxlAJmKys0ZItnBTLX3k/ZQc=; b=Ozw6RcIDlImxq7ZanQzEKijXDZsBx27t8vOO/b9fXTsFQxBwUevbSUXZ+AWKilRo8L v5v67GPnWzE8l7TpRTOFgMxgAyGAk7eTIM0QxrBWvr212s4r1b80+NprglfOoBF34mkJ IxP23WS8jlMk8jNKMyHOgq96jaoiKVxQWeZCg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=V38Eo0HJqI9i3bQJJfOUxlAJmKys0ZItnBTLX3k/ZQc=; b=hCnyLXWdJjxbulyA8tp5KCdEmULvQCJfed3czoNmYdxKgttSd0J5GadsLVW5uxQqNV zyQo35REqBPJNSvuN+B0HVRUPrTJDGROXQ7SAkMGvCKNhocvyojzSQgSReY5otuVAkf3 88H5t6dFB5euAyrD3xS4+oau/SLJimlkubLzGWoJS8x3tZM+QUYUgRyV9EBvGHnogsS+ IOQAKg3L/3dNWFfvfzuDyeZLuOPoHSM9G0QfpZJMxK6hV5qOKPohm37J+/gHdC1i04kJ BxSn9qmtAWZ9JrkT5kyowqiFKmi5XMzqW6FxDgf8BEe4KTsWcwCN4Du+mnkyktleKBf6 hVNw== X-Gm-Message-State: AFeK/H0iMRe2lY3up06YgUi5KHXoSvYvppuKvwuOy0EKoCBr1d7vuRVoEJRfwFOf82cL1w== X-Received: by 10.28.51.140 with SMTP id z134mr5409316wmz.55.1490142304296; Tue, 21 Mar 2017 17:25:04 -0700 (PDT) Received: from [192.168.3.194] ([217.5.149.10]) by smtp.gmail.com with ESMTPSA id g5sm26698700wrb.48.2017.03.21.17.25.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Mar 2017 17:25:03 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A4FBA875-381F-449E-9CCE-C0E43D51A686"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Aaron Zauner In-Reply-To: Date: Wed, 22 Mar 2017 01:24:27 +0100 Cc: "cfrg@irtf.org" Message-Id: References: To: Tony Arcieri X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 00:25:08 -0000 --Apple-Mail=_A4FBA875-381F-449E-9CCE-C0E43D51A686 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 21 Mar 2017, at 20:42, Tony Arcieri wrote: >=20 > Hierarchical key derivation (also sometimes described as "semiprivate = keys" or "key blinding") is an increasingly popular technique for = generating unlinkable child keys from master public and private keys. >=20 > The Tor Project has been exploring such an approach as the basis for = their next-generation hidden services design for several years now[1], = during which time it has received security proofs[2]. Their latest = design[3] allegedly includes feedback from Dan Bernstein. >=20 > Application of hierarchical key derivation is perhaps most notable in = the cryptocurrency space, where Bitcoin's BIP32[4] provided a means for = unlinkable single-use signature keys for the secp256k1 elliptic curve. = There are several designs for applying the ideas from BIP32 to Ed25519, = including ones from Evernym[5] and Chain[6] (where I am an employee). >=20 > The designs in [3], [5], and [6] are all highly similar and accomplish = the same goals. Personally I would love to see a single standard design = for producing Ed25519 signatures from hierarchically derived keys, = notably one which produces signatures that can be verified by any = off-the-shelf RFC 8032-compatible Ed25519 implementation. >=20 > There's already been some discussion of this on the moderncrypto.org = curves list: >=20 > https://moderncrypto.org/mail-archive/curves/2017/000858.html >=20 > I'd be curious to know if anyone else would be interested in = collaborating on a draft for such a standard, which can be a synthesis = of the existing work in this space. I feel this is a useful input to CFRG and would be willing to review = such a document. I think it's also a good idea if you talk to the = original authors of the design documents you've linked to for = collaboration. Aaron --Apple-Mail=_A4FBA875-381F-449E-9CCE-C0E43D51A686 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY0cQ/AAoJEOTbZJL9ubXVPBYP/jRjPghMIwzbDfrzF4r51dT1 TuZL0YiFLdFl+DlXqyYNDoKUBTFxg8V+phUbDdRDfgBA9bi8JUsWrtMFhUv4Va09 AW7/b1ij7wg0BcWyFx8BCjt95+4D+/0rfVrjw78r7+KUmK/5/4MtReu2C82LUQbv ytxheYbS1sqP/NyD4EiUpGdSeetIkcy3xfV6tC3FSv2EajXXmEWR+4TWbZs1Zr/h eE839b0qlQJ1RG3jJVfDJt3RnkqAG5oS9e+Wy+L4MoYulvgMIvHzvY0A0SFFptpM 2dfzdthconPfCozehBGA2meJ7Ud4JGpraNs1fAKW4wFyJGiKwKBuZNeO1xUNelfS 3kXzxOygzwzvbnZDlcyDAhPafcwNSIxbPeH6F1kX1d7l3ZRxAo+CFnMOLOa/T+Xh CLtDfbtBcFC/9wgGRAD/YNC+08AgZXfFF8wb75TrxV5ykgO18yNJsGl4JjV0w1TT /zicLc10KKgC577BUqxDu06p9umDHcZQsjfPDVTE2jEFJNsrIzblUtJ+W6bVboRs lyz3RwaxNa0k3LXkdByn7a1zg9hVXE/RAw71ZSuxh1z6hh3sodxxfIndNDa3/hGA EVB7up/f2d877DMearHxFoLlmeCp7UCe6XH9eJDoTAT89FnU8TaTvQ4Zb3OmzRsM MXQY6ErDX8eNcai9djFy =VEK9 -----END PGP SIGNATURE----- --Apple-Mail=_A4FBA875-381F-449E-9CCE-C0E43D51A686-- From nobody Tue Mar 21 17:35:09 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3389130141 for ; Tue, 21 Mar 2017 17:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcSsmQmJ_afL for ; Tue, 21 Mar 2017 17:35:00 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C830012940A for ; Tue, 21 Mar 2017 17:34:59 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id l203so10945537oia.0 for ; Tue, 21 Mar 2017 17:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+YgVnKJ7S0YRHBO0AtDstHB0bbRXvTzsMtoUKTvI/n8=; b=Vb99S/Y/y3BOTvOPzt0+zLDm4JEHxbCFmzTBoKlYngVUur2HYF/kf+C5TfwLdEtYWp dgUIkgi6U1RQAfUfCK+rOfygaC8rFnBPovT7zLG6Zz8Pl/rvD8LgAEJOg5nOc12mANMe /HaR4NWN79c1D2ClKoekqpg2skgM0UI43TM7eumyvNCRoNbHgPy7yimxrQeZKmGv6rbM hebRCYj5W+ZdMlV8v+YQixgxVbIJghyIoPrgJq3oKj+MFHWyb5oHfQxi3DIoLtM+QFAG ovsft/QK5s4RL1bE2PNJIcU6eHnbiNIWCPuZQiHqVBYQ93qu3Z/Z7OfVzlbw1Lw9MGa0 4kuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+YgVnKJ7S0YRHBO0AtDstHB0bbRXvTzsMtoUKTvI/n8=; b=UJD6L6IBZ/curi8Pia24vPGNZQE3g49t1L9tSUKjtJZV+1ULoM92qmJypmk6qDrpyq A8txtVRhyK/MqwtVWuy2oamYTjRMyKGYK+1mZ/6Dr8n/VdmktXjEeadfUJMpBCAEgJiB FQZOOKetqguILGrOEJamhE9G/CjL7WB32TlzDJRvf97y9SBl/TE2EUpyWvWR70YVGUYc UhP53MPRtq0DK2t/SPC1WpYQB9E9jd/CKwSFzPRLXx2NM5BqW0R5GyD5dGu8Pp0ZyZPJ hZaOcl3WAf5JYqpIUsGTxZKJQ6pEL5X2YtjuFgibfL5LsJoeFsKv9lZPjy2b7NeRbkG7 r1wQ== X-Gm-Message-State: AFeK/H1A4pgLaWtsGi2fHkSQdNLa72eGXRmV9pwdvJmPV8LA6QZxW9guQ2QaX0ve3KBiIOtpI5lBwDD5F0zLQA== X-Received: by 10.202.71.195 with SMTP id u186mr11535400oia.9.1490142899205; Tue, 21 Mar 2017 17:34:59 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.14.123 with HTTP; Tue, 21 Mar 2017 17:34:58 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Tue, 21 Mar 2017 20:34:58 -0400 X-Google-Sender-Auth: aOS2dRsgbsgV01NNRPcTWIoYtpg Message-ID: To: Tony Arcieri Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a113e54362bfccb054b46ee80 Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 00:35:02 -0000 --001a113e54362bfccb054b46ee80 Content-Type: text/plain; charset=UTF-8 I have just implemented Proxy Re-Encryption under Ed-25519 and Ed448. I think EdCurve Crypto is a good plan. Or we could do it on the Montgomery Curves and give the algorithm for point addition. On Tue, Mar 21, 2017 at 3:42 PM, Tony Arcieri wrote: > Hierarchical key derivation (also sometimes described as "semiprivate > keys" or "key blinding") is an increasingly popular technique for > generating unlinkable child keys from master public and private keys. > > The Tor Project has been exploring such an approach as the basis for their > next-generation hidden services design for several years now[1], during > which time it has received security proofs[2]. Their latest design[3] > allegedly includes feedback from Dan Bernstein. > > Application of hierarchical key derivation is perhaps most notable in the > cryptocurrency space, where Bitcoin's BIP32[4] provided a means for > unlinkable single-use signature keys for the secp256k1 elliptic curve. > There are several designs for applying the ideas from BIP32 to Ed25519, > including ones from Evernym[5] and Chain[6] (where I am an employee). > > The designs in [3], [5], and [6] are all highly similar and accomplish the > same goals. Personally I would love to see a single standard design for > producing Ed25519 signatures from hierarchically derived keys, notably one > which produces signatures that can be verified by any off-the-shelf RFC > 8032-compatible Ed25519 implementation. > > There's already been some discussion of this on the moderncrypto.org > curves list: > > https://moderncrypto.org/mail-archive/curves/2017/000858.html > > I'd be curious to know if anyone else would be interested in collaborating > on a draft for such a standard, which can be a synthesis of the existing > work in this space. > > [1]: https://lists.torproject.org/pipermail/tor-dev/2012- > September/004026.html > [2]: https://www-users.cs.umn.edu/~hopper/basic-proof.pdf > [3]: https://gitweb.torproject.org/torspec.git/ > tree/proposals/224-rend-spec-ng.txt#n1979 > [4]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki > [5]: https://github.com/WebOfTrustInfo/rebooting-the- > web-of-trust-fall2016/blob/master/topics-and-advance- > readings/HDKeys-Ed25519.pdf > [6]: https://chain.com/docs/protocol/specifications/chainkd > > -- > Tony Arcieri > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --001a113e54362bfccb054b46ee80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I h= ave just implemented Proxy Re-Encryption under Ed-25519 and Ed448. I think = EdCurve Crypto is a good plan.

Or we could do it on the Montgomery Curves and give the algorithm for= point addition.

On Tue, Mar 21, 2017 at 3:42 PM, Tony Arcieri = <bascule@gmail.co= m> wrote:
= Hierarchical key derivation (also sometimes described as "semiprivate = keys" or "key blinding") is an increasingly popular techniqu= e for generating unlinkable child keys from master public and private keys.=

The Tor Project has been exploring such an approach as = the basis for their next-generation hidden services design for several year= s now[1], during which time it has received security proofs[2]. Their lates= t design[3] allegedly includes feedback from Dan Bernstein.

<= /div>
Application of hierarchical key derivation is perhaps most notabl= e in the cryptocurrency space, where Bitcoin's BIP32[4] provided a mean= s for unlinkable single-use signature keys for the secp256k1 elliptic curve= . There are several designs for applying the ideas from BIP32 to Ed25519, i= ncluding ones from Evernym[5] and Chain[6] (where I am an employee).
<= div>
The designs in [3], [5], and [6] are all highly similar = and accomplish the same goals. Personally I would love to see a single stan= dard design for producing Ed25519 signatures from hierarchically derived ke= ys, notably one which produces signatures that can be verified by any off-t= he-shelf RFC 8032-compatible Ed25519 implementation.

There's already been some discussion of this on the moderncrypto.org curves list:


I'= d be curious to know if anyone else would be interested in collaborating on= a draft for such a standard, which can be a synthesis of the existing work= in this space.

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


--001a113e54362bfccb054b46ee80-- From nobody Tue Mar 21 21:00:48 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E374512944B for ; Tue, 21 Mar 2017 21:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUmhTiCLsjW1 for ; Tue, 21 Mar 2017 21:00:44 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA599129677 for ; Tue, 21 Mar 2017 21:00:44 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id a12so93949314ota.0 for ; Tue, 21 Mar 2017 21:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ixM4I9uDVABxvr/ON042Q9mkoa10Sr6jNvLHTeI71o4=; b=W/Xzn3qtL612GBt7DQFEL9TM8tF2mv8la3TDpk8YzeMlo9mbJaOwi3/QyqdimkV3RF dFr9Z1u8VmmuWsuGzNpGtuEcU9WFxltBRpUjwfTMBXXYE3Gd2kGuCUJje159TlMgeiFN L8937+uEBMiJOiDltzL+8dJG0eORPJE8xcC20r46BVdJBHSpS1kryaKVnfhX7GXWHBBb xqq7PHHvE9rXau7nwwrxKIiwlDM9JE/wOj6rB3Bm94Vv4hmZSIhlcDAuswJfkzJRzM21 hlNkzCtJrwnQD60sJCJbNa66GkWmy05QJ0hrJev0TFtguWdBAetP5Ulj1Hq8G5vg395e hJmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ixM4I9uDVABxvr/ON042Q9mkoa10Sr6jNvLHTeI71o4=; b=irvCy/4q6+ni9STMtNw5S97UtVCfF31+pe7pSI42prhS8ug4Ae5yNoJ3Yc2tnclgCo d1LPByAMopPgwyutiRhHmetNU37BcU69Qmwu9ORT9CNlwRxTQiyHWQAqAmwI8zzzTxz7 DGR15z6zGe1Kr3clWCU576+F/PDXPb1rtwqtiw1KMbU0+5hp8bpdEAqQ19FIXGCfgIG+ O8KPAubsm9LsXPesTcByjy+8iSoUDT/wsXnvax4Uind6i2U4Uaw1dk3yPNtk9pHblHPZ ABxdaLv+2wG4PjRpV75rh1zepHcQOqJXp8OfcbKoOmKilO2Sc+QQ7ywBtd/HQFFd3Jgc IQuA== X-Gm-Message-State: AFeK/H1h8FcU1D0sdm1aQ5Gruf7YQpq8baKuJve0CFLyiQDoC9heGJd5Z+JVEiQow83OqxoSnAyMHaKns2sgUw== X-Received: by 10.157.15.38 with SMTP id 35mr21894773ott.49.1490155244104; Tue, 21 Mar 2017 21:00:44 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.14.123 with HTTP; Tue, 21 Mar 2017 21:00:43 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 22 Mar 2017 00:00:43 -0400 X-Google-Sender-Auth: NyMLrLnkOsyTYpYd9doECVRjBBY Message-ID: To: Tony Arcieri Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=94eb2c045e26fc325b054b49cd8f Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 04:00:47 -0000 --94eb2c045e26fc325b054b49cd8f Content-Type: text/plain; charset=UTF-8 You can do hierarchical key derivation in Montgomery without the need for an add. Say your master key is x. To generate a key for site 'example.com' we take xs = (x + H('example.com')) mod q Where q is the sub group order. In fact that isn't really using any EC relevant operation at all. Perhaps I am not understanding the full requirements for the scheme. I don't follow the argument about small subgroups in the referenced post. With Curve25519 and Ed25519 we have chosen the curve cofactor and the generator point. So there is only one group that our point can possibly be in regardless of whether our private key is (x mod q) or (x mod q + nq). We are going to arrive at the same set of points regardless. I do very much prefer the Edwards curves though because we can combine two keypairs by simply adding the corresponding public and private keys. That allows us to do the co-generation trick I showed a while back. We can also split the key, give one part to a recryption service and encrypt the other half under the public key of the recipient. This allows us to support group messaging through proxy re-encryption. Some applications of that are encumbered (possibly) under a soon to expire patent. On Tue, Mar 21, 2017 at 8:34 PM, Phillip Hallam-Baker wrote: > I have just implemented Proxy Re-Encryption under Ed-25519 and Ed448. I > think EdCurve Crypto is a good plan. > > Or we could do it on the Montgomery Curves and give the algorithm for > point addition. > > On Tue, Mar 21, 2017 at 3:42 PM, Tony Arcieri wrote: > >> Hierarchical key derivation (also sometimes described as "semiprivate >> keys" or "key blinding") is an increasingly popular technique for >> generating unlinkable child keys from master public and private keys. >> >> The Tor Project has been exploring such an approach as the basis for >> their next-generation hidden services design for several years now[1], >> during which time it has received security proofs[2]. Their latest >> design[3] allegedly includes feedback from Dan Bernstein. >> >> Application of hierarchical key derivation is perhaps most notable in the >> cryptocurrency space, where Bitcoin's BIP32[4] provided a means for >> unlinkable single-use signature keys for the secp256k1 elliptic curve. >> There are several designs for applying the ideas from BIP32 to Ed25519, >> including ones from Evernym[5] and Chain[6] (where I am an employee). >> >> The designs in [3], [5], and [6] are all highly similar and accomplish >> the same goals. Personally I would love to see a single standard design for >> producing Ed25519 signatures from hierarchically derived keys, notably one >> which produces signatures that can be verified by any off-the-shelf RFC >> 8032-compatible Ed25519 implementation. >> >> There's already been some discussion of this on the moderncrypto.org >> curves list: >> >> https://moderncrypto.org/mail-archive/curves/2017/000858.html >> >> I'd be curious to know if anyone else would be interested in >> collaborating on a draft for such a standard, which can be a synthesis of >> the existing work in this space. >> >> [1]: https://lists.torproject.org/pipermail/tor-dev/2012-Sep >> tember/004026.html >> [2]: https://www-users.cs.umn.edu/~hopper/basic-proof.pdf >> [3]: https://gitweb.torproject.org/torspec.git/tree/ >> proposals/224-rend-spec-ng.txt#n1979 >> [4]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki >> [5]: https://github.com/WebOfTrustInfo/rebooting-the-web-of- >> trust-fall2016/blob/master/topics-and-advance-readings/HDKeys-Ed25519.pdf >> [6]: https://chain.com/docs/protocol/specifications/chainkd >> >> -- >> Tony Arcieri >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> >> > --94eb2c045e26fc325b054b49cd8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You= can do hierarchical key derivation in Montgomery without the need for an a= dd.

<= div class=3D"gmail_default" style=3D"font-size:small">Say your master key i= s x. To generate a key for site 'example= .com' we take=C2=A0

xs =3D (x + H('example.com'))= mod q

Where q is the sub= group order.
<= br>
In fact tha= t isn't really using any EC relevant operation at all. Perhaps I am not= understanding the full requirements for the scheme.


I don't follow the argument about small subgroups in = the referenced post. With Curve25519 and Ed25519 we have chosen the curve c= ofactor and the generator point. So there is only one group that our point = can possibly be in regardless of whether our private key is (x mod q) or (x= mod q + nq). We are going to arrive at the same set of points regardless.<= /div>


I do very much prefer the Edwards c= urves though because we can combine two keypairs by simply adding the corre= sponding public and private keys. That allows us to do the co-generation tr= ick I showed a while back.

We can also split the key, give one part to a recryption service and encr= ypt the other half under the public key of the recipient. This allows us to= support group messaging through proxy re-encryption.

Some applications of that are encumbered (poss= ibly) under a soon to expire patent.=C2=A0



On Tue, Mar 21, 2017 at 8:34 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
I have just implemented Proxy Re-Encryption under Ed-25519 and Ed448. I t= hink EdCurve Crypto is a good plan.

Or we could do it on the Montgomery Curves and give the algorith= m for point addition.

On Tue, Mar 21, 2017 at 3:42 PM, To= ny Arcieri <bascule@gmail.com> wrote:
Hierarchica= l key derivation (also sometimes described as "semiprivate keys" = or "key blinding") is an increasingly popular technique for gener= ating unlinkable child keys from master public and private keys.

The Tor Project has been exploring such an approach as the basis f= or their next-generation hidden services design for several years now[1], d= uring which time it has received security proofs[2]. Their latest design[3]= allegedly includes feedback from Dan Bernstein.

A= pplication of hierarchical key derivation is perhaps most notable in the cr= yptocurrency space, where Bitcoin's BIP32[4] provided a means for unlin= kable single-use signature keys for the secp256k1 elliptic curve. There are= several designs for applying the ideas from BIP32 to Ed25519, including on= es from Evernym[5] and Chain[6] (where I am an employee).

The designs in [3], [5], and [6] are all highly similar and accompl= ish the same goals. Personally I would love to see a single standard design= for producing Ed25519 signatures from hierarchically derived keys, notably= one which produces signatures that can be verified by any off-the-shelf RF= C 8032-compatible Ed25519 implementation.

There= 9;s already been some discussion of this on the moderncrypto.org curves list:

=

I'd be curiou= s to know if anyone else would be interested in collaborating on a draft fo= r such a standard, which can be a synthesis of the existing work in this sp= ace.

--
Tony Arcier= i

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg



--94eb2c045e26fc325b054b49cd8f-- From nobody Wed Mar 22 03:54:37 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C93F1296AD for ; Wed, 22 Mar 2017 03:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi-IHaszUZFy for ; Wed, 22 Mar 2017 03:54:32 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741181316EE for ; Wed, 22 Mar 2017 03:54:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 0E75321069; Wed, 22 Mar 2017 11:54:30 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nnnUmjiv0lt; Wed, 22 Mar 2017 11:54:18 +0100 (CET) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 8342221067; Wed, 22 Mar 2017 11:54:07 +0100 (CET) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0319.002; Wed, 22 Mar 2017 11:54:07 +0100 From: "Tams, Benjamin" To: Aaron Zauner CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] Postquantum cryptography in IETF protocols Thread-Index: AQHSopq2hRcBTqqnzEiFdQAC6FZfhqGgmnPQ Date: Wed, 22 Mar 2017 10:54:06 +0000 Message-ID: <78B0B91A8FEB2E43B20BCCE1326131812D6C308E@mail-essen-01.secunet.de> References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> <51780B9E-8BE5-493F-8338-AB3E80E9BFEC@azet.org> In-Reply-To: <51780B9E-8BE5-493F-8338-AB3E80E9BFEC@azet.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.36.126.244] x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 x-g-data-mailsecurity-for-exchange-state: 0 x-g-data-mailsecurity-for-exchange-error: 0 x-g-data-mailsecurity-for-exchange-sender: 23 x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c x-g-data-mailsecurity-for-exchange-guid: A13E5602-FF9A-4461-B111-6B2BA052CA33 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 10:54:35 -0000 Hi Aaron, > NewHope has been implemented in Tor and also in Chrome for testing purpos= es. > As for StrongSwan: they implement quite a lot. There's also a NTRU IKE im= plementation > available in StrongSwan (https://wiki.strongswan.org/projects/strongswan/= wiki/NTRU).=20 > Just because there's an implementation of something doesn't necessarily w= arrant work > on an internet draft/standard. The other way round does neither: Just because there are Internet Drafts sp= ecifying PQ-safe key exchange algorithms, this does not mean they have to be impleme= nted. Anyway, existing implementations are indications for the need of PQ-safe key exchan= ge algorithms.=20 Therefore, in my view, it is reasonable to specify Internet Drafts for stat= e-of-the-art PQ-safe key exchange algorithms suitable for implementation. > To me PQC is quite a new field and security boundaries are not as establi= shed as they're > for say symmetric or public key cryptography (someone correct me if I've = missed major > news in that area). I agree. But as I mentioned in an earlier post (https://www.ietf.org/mail-a= rchive/web/cfrg/current/msg09070.html) we will not lose anything on security if we couple candidates for PQ-safe k= ey exchange algorithms with classical key exchange algorithms. Not for recommending the= m as a final specification but for temporarily using them in applications where PQ-safet= y is needed. As I noted above, it depends on the application whether a hybrid key exchan= ge algorithm is used that has the chance of being PQ-secure at the cost of increased key= size and increased running complexity. But if for an application one is willing to h= ave that trade-off, specifications for candidates of PQ-safe key exchange algorithms would be v= ery useful. Again, not for recommending them as a final specification but for temporarily usin= g them in applications where PQ-safety is needed. > BTW there was a recent paper with some "improved" attacks on NewHope (it= doesn't > break the scheme, they just recommend more conservative parameter choices= ) -=20 > https://eprint.iacr.org/2017/221 @CFRG: Is there anyone interested in specifying PQ-safe key exchange algori= thms at the state of the art suitable for implementation=20 (e.g., implementations of protocols as https://tools.ietf.org/html/draft-wh= yte-qsh-tls13-03)? Kind regards, Benjamin=20 From nobody Wed Mar 22 04:26:01 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DCA129683 for ; Wed, 22 Mar 2017 04:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAT-nZ8Rt4YE for ; Wed, 22 Mar 2017 04:25:56 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8973129483 for ; Wed, 22 Mar 2017 04:25:55 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id v76so126642052ywg.0 for ; Wed, 22 Mar 2017 04:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0FbLwdEQ8+t/8+HMgZ139fLuB3Iz/rZ9Ol8UQIV9sog=; b=k9vft1uQUAjiYXua0O1gcd71Q/FgbR66LzInH8UZQYF6MvL0LvypLEFU49Uc5KD03A HQMtrefa7rmQCQKJT+XDJcFSjWluU2FxSHbKeqfH1JzI6rF63pUzr9tHoYGTaTzMiK/r PaiExCowE7PjkeIAAsjfEz54ZHcjAMqRSnLuDjOWuttHhf1Vq0qyPgPc2WYXGcnUvC/2 gHQ91VDD5sjWer+4YlA77Y8pvRJ++NV8biIhVPeqWe2SaTuT6GSmZSbJ/bRf/VMTnA4D uqBAtG2s9pqF93a0v+TaMKEZa+16eKLhkC16QU0Ln6+M0ZsuJxatE/k/SgGt8I6zNach N7uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0FbLwdEQ8+t/8+HMgZ139fLuB3Iz/rZ9Ol8UQIV9sog=; b=XqMlevzAzoBvZItZL8USDVb4cJzdlR6uhvW2tFhiXC8+KLrKfLQl1RTevw8CCnbhwR uEDratqNV+wS0v6dSspjnjx7M8ESKAGAxoZWjmezndnL6NKfcR/uQybgGP4rRjv6QFTb BztxpR+PAE1h6tj1+DM5D/q9j1AoPuZqX72KHmldmAg06x1uteZ0BgP16Y/rIT6XQUzj 8nupYm8MJaRdtDQqMtfIJPAYZa55LtbYqicyX84DKCI8bfeYMkP0Z39JZ6UoGk3L5vRQ gsnl0wPNx0fM3dyyL1caP1tZRdWhFE5fdpTjeF0HS4z61wU5kWZu1cFjcfLgXuqcnAFq Nmcg== X-Gm-Message-State: AFeK/H1XqtgXCZPHD5EmHa1zTjOIQto7eAz6+WBmKaF2a5nJaRwH0BTU2+hNF77t1WlXhD5uCE0h1Rsl86g9vA== X-Received: by 10.129.111.8 with SMTP id k8mr15446566ywc.303.1490181954683; Wed, 22 Mar 2017 04:25:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.67.35 with HTTP; Wed, 22 Mar 2017 04:25:39 -0700 (PDT) In-Reply-To: References: From: Dmitry Khovratovich Date: Wed, 22 Mar 2017 12:25:39 +0100 Message-ID: To: Phillip Hallam-Baker , Jason Law Cc: Tony Arcieri , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a1145ec6a0f5498054b5006b1 Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 11:25:59 -0000 --001a1145ec6a0f5498054b5006b1 Content-Type: text/plain; charset=UTF-8 Being a co-author of [5], I am ready to contribute to such a document. I will present our own proposal at http://prosecco.gforge.inria.fr/ieee-blockchain2016/ in Paris just before the CFRG meeting at the same place next day. It would be great if we come up with some proposal to discuss it already there. The most recent version is https://drive.google.com/open?id=0ByMtMw2hul0EMFJuNnZORDR2NDA It has some critique of [6], hopefully not too offensive:) Our motivation in [5] was to generate private keys satisfying the Curve25519 requirements too so that the code can be reused, even if in the signature setting some attacks would not apply. But it would be great to have comments from the community as well. Best regards, Dmitry On Wed, Mar 22, 2017 at 5:00 AM, Phillip Hallam-Baker wrote: > You can do hierarchical key derivation in Montgomery without the need for > an add. > > Say your master key is x. To generate a key for site 'example.com' we > take > > xs = (x + H('example.com')) mod q > > Where q is the sub group order. > > In fact that isn't really using any EC relevant operation at all. Perhaps > I am not understanding the full requirements for the scheme. > > > I don't follow the argument about small subgroups in the referenced post. > With Curve25519 and Ed25519 we have chosen the curve cofactor and the > generator point. So there is only one group that our point can possibly be > in regardless of whether our private key is (x mod q) or (x mod q + nq). We > are going to arrive at the same set of points regardless. > > > I do very much prefer the Edwards curves though because we can combine two > keypairs by simply adding the corresponding public and private keys. That > allows us to do the co-generation trick I showed a while back. > > We can also split the key, give one part to a recryption service and > encrypt the other half under the public key of the recipient. This allows > us to support group messaging through proxy re-encryption. > > Some applications of that are encumbered (possibly) under a soon to expire > patent. > > > > On Tue, Mar 21, 2017 at 8:34 PM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> I have just implemented Proxy Re-Encryption under Ed-25519 and Ed448. I >> think EdCurve Crypto is a good plan. >> >> Or we could do it on the Montgomery Curves and give the algorithm for >> point addition. >> >> On Tue, Mar 21, 2017 at 3:42 PM, Tony Arcieri wrote: >> >>> Hierarchical key derivation (also sometimes described as "semiprivate >>> keys" or "key blinding") is an increasingly popular technique for >>> generating unlinkable child keys from master public and private keys. >>> >>> The Tor Project has been exploring such an approach as the basis for >>> their next-generation hidden services design for several years now[1], >>> during which time it has received security proofs[2]. Their latest >>> design[3] allegedly includes feedback from Dan Bernstein. >>> >>> Application of hierarchical key derivation is perhaps most notable in >>> the cryptocurrency space, where Bitcoin's BIP32[4] provided a means for >>> unlinkable single-use signature keys for the secp256k1 elliptic curve. >>> There are several designs for applying the ideas from BIP32 to Ed25519, >>> including ones from Evernym[5] and Chain[6] (where I am an employee). >>> >>> The designs in [3], [5], and [6] are all highly similar and accomplish >>> the same goals. Personally I would love to see a single standard design for >>> producing Ed25519 signatures from hierarchically derived keys, notably one >>> which produces signatures that can be verified by any off-the-shelf RFC >>> 8032-compatible Ed25519 implementation. >>> >>> There's already been some discussion of this on the moderncrypto.org >>> curves list: >>> >>> https://moderncrypto.org/mail-archive/curves/2017/000858.html >>> >>> I'd be curious to know if anyone else would be interested in >>> collaborating on a draft for such a standard, which can be a synthesis of >>> the existing work in this space. >>> >>> [1]: https://lists.torproject.org/pipermail/tor-dev/2012-Sep >>> tember/004026.html >>> [2]: https://www-users.cs.umn.edu/~hopper/basic-proof.pdf >>> [3]: https://gitweb.torproject.org/torspec.git/tree/proposal >>> s/224-rend-spec-ng.txt#n1979 >>> [4]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki >>> [5]: https://github.com/WebOfTrustInfo/rebooting-the-web-of- >>> trust-fall2016/blob/master/topics-and-advance-readings/HDKey >>> s-Ed25519.pdf >>> [6]: https://chain.com/docs/protocol/specifications/chainkd >>> >>> -- >>> Tony Arcieri >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg >>> >>> >> > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > -- Best regards, Dmitry Khovratovich --001a1145ec6a0f5498054b5006b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Being a co-author of [5], I am ready to contribute to such= a document. I will present our own proposal at=C2=A0http://prosecco.gforge.inria.fr/= ieee-blockchain2016/ in Paris =C2=A0just before the CFRG meeting at the= same place next day. It would be great if we come up with some proposal to= discuss it already there.

The most recent version is=C2= =A0https://drive.google.com/open?id=3D0ByMtMw2hul0EMFJuNnZORDR2NDA It = has some critique of [6], hopefully not too offensive:)

<= div>Our motivation in [5] was to generate private keys satisfying the Curve= 25519 requirements too so that the code can be reused, even if in the signa= ture setting some attacks would not apply. But it would be great to have co= mments from the community as well.

Best regards,
Dmitry

On Wed, Mar 22, 2017 at 5:00 AM, Phillip Hallam-Baker <phill@halla= mbaker.com> wrote:
You can do hiera= rchical key derivation in Montgomery without the need for an add.

Say you= r master key is x. To generate a key for site 'example.com' we take=C2=A0

xs =3D (x + H= ('example.com'= )) mod q

Where q is the sub group order.

In fact that isn't really = using any EC relevant operation at all. Perhaps I am not understanding the = full requirements for the scheme.

<= /div>

I don't follow the argument about small subgroups in the referenced p= ost. With Curve25519 and Ed25519 we have chosen the curve cofactor and the = generator point. So there is only one group that our point can possibly be = in regardless of whether our private key is (x mod q) or (x mod q + nq). We= are going to arrive at the same set of points regardless.


I do very much prefer the Edwards curves though= because we can combine two keypairs by simply adding the corresponding pub= lic and private keys. That allows us to do the co-generation trick I showed= a while back.

We can also split the key, give one part to a recryption s= ervice and encrypt the other half under the public key of the recipient. Th= is allows us to support group messaging through proxy re-encryption.
<= div style=3D"font-size:small">
Some= applications of that are encumbered (possibly) under a soon to expire pate= nt.=C2=A0



On Tue, Mar = 21, 2017 at 8:34 PM, Phillip Hallam-Baker <phill@hallambaker.com&g= t; wrote:
I have just implemented Proxy Re= -Encryption under Ed-25519 and Ed448. I think EdCurve Crypto is a good plan= .

Or we could do it on the Montgomery Curves and give the algorithm for p= oint addition.

On Tue, Mar 21, = 2017 at 3:42 PM, Tony Arcieri <bascule@gmail.com> wrote:
=
Hierarchical key deri= vation (also sometimes described as "semiprivate keys" or "k= ey blinding") is an increasingly popular technique for generating unli= nkable child keys from master public and private keys.

T= he Tor Project has been exploring such an approach as the basis for their n= ext-generation hidden services design for several years now[1], during whic= h time it has received security proofs[2]. Their latest design[3] allegedly= includes feedback from Dan Bernstein.

Application= of hierarchical key derivation is perhaps most notable in the cryptocurren= cy space, where Bitcoin's BIP32[4] provided a means for unlinkable sing= le-use signature keys for the secp256k1 elliptic curve. There are several d= esigns for applying the ideas from BIP32 to Ed25519, including ones from Ev= ernym[5] and Chain[6] (where I am an employee).

Th= e designs in [3], [5], and [6] are all highly similar and accomplish the sa= me goals. Personally I would love to see a single standard design for produ= cing Ed25519 signatures from hierarchically derived keys, notably one which= produces signatures that can be verified by any off-the-shelf RFC 8032-com= patible Ed25519 implementation.

There's alread= y been some discussion of this on the moderncrypto.org curves list:

https://moderncrypto.org/mail-archive/curves/2017/00= 0858.html

I'd be curious to know = if anyone else would be interested in collaborating on a draft for such a s= tandard, which can be a synthesis of the existing work in this space.
=
[5]:=C2=A0https://github.com/WebOfTrustInfo/rebooting-the-web-of-tru= st-fall2016/blob/master/topics-and-advance-readings/HDKeys-Ed2551= 9.pdf

--
Tony Arcieri

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg




_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg




--
Best regards,
Dmitry Khovratovich
--001a1145ec6a0f5498054b5006b1-- From nobody Wed Mar 22 05:20:37 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8271296FD for ; Wed, 22 Mar 2017 05:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzdTdIm7C0rY for ; Wed, 22 Mar 2017 05:20:32 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4831E1296C8 for ; Wed, 22 Mar 2017 05:20:32 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id r203so45487281oib.3 for ; Wed, 22 Mar 2017 05:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kUwdsjsfiykgL8h1aD6Y3W2OLYcnDi5Zr89mL+FB8hs=; b=ERGcThkm4egxblJM8TBmfegKWEFTJ/I7cfWsp3ePH3Vj7x9D0rqpDUHXQRj7RjgbLV OTPko+ju+KU9Nf1mUA7bgPvHLelE6Kkpqu966jcH7LV/EOKNsgQ1nsxTfu0/5jWdZ9R2 4RFoCNSTC5+CSadGEUB74Xevd0MlNORbJ8UbE8vdQ1zxK8n2ITwA/aE+H0xgH1w6aaiU 9KXB+TZoakfq60plSlgrZTcMGj+XGMIhAdg20NFf9bZ+J07n0gdbQX5ScH1vh2aEuezZ 7rlUNSxRLIxDwDDrIFiYaeW6j9ZiED0OuoifVDsuovJpFxEMLu9uPGlVi2RKgdhjIsr1 iXYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kUwdsjsfiykgL8h1aD6Y3W2OLYcnDi5Zr89mL+FB8hs=; b=FWs4pEWt9QPXnlfxyCHGEfh4ny6SuSbfZviHEOPy1lo5JEkKg1uLCTOXtb0DE4MVDi Sf2tJHBFx/zfupkCDAgQz1YOnVjpvWTeIrgF4GcCuyUHgLtLzNxC9fA0Tgc5E+goDV4P dZSurKhIH7a1A2HwXVH+tCAcJ+g6Oxipy+HEG6l7uCEXWbTxX3c97qYLkkmffUw3q/Wl NrRV9X4bNSNEj45J6Vm8whroFBrSc5jD5MIy63Yp8wdfK6aaSZ0dKn5PrS8Y2XE6O4jA OXRoPJctvofTvYDi8oPvH4w+pO2dyysOnygOiTQXq8InXDi1dTVl524KqtD727N6GciE PNVw== X-Gm-Message-State: AFeK/H12lRN9qVrctkAKWc4iEoOdba0LOi7KiFj6s9W0A3vNJL6YKgPt5Jf/01bCm8qJevmUMU0uyckPCOtntw== X-Received: by 10.202.63.85 with SMTP id m82mr21720752oia.151.1490185231588; Wed, 22 Mar 2017 05:20:31 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.14.123 with HTTP; Wed, 22 Mar 2017 05:20:31 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 22 Mar 2017 08:20:31 -0400 X-Google-Sender-Auth: ZXT72d8BTebxQZpods2TGqVWqyk Message-ID: To: Dmitry Khovratovich Cc: Jason Law , Tony Arcieri , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a113dd49260e419054b50c958 Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 12:20:34 -0000 --001a113dd49260e419054b50c958 Content-Type: text/plain; charset=UTF-8 One of the things we need is a specification for the crypto API necessary to support interesting uses of ECDH/DH. Most implementations do not expose the necessary calls. It would be useful to guide them. --001a113dd49260e419054b50c958 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One= of the things we need is a specification for the crypto API necessary to s= upport interesting uses of ECDH/DH.

Most implementations do not expose the necessary calls. It would= be useful to guide them.
--001a113dd49260e419054b50c958-- From nobody Wed Mar 22 05:26:27 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06869129736 for ; Wed, 22 Mar 2017 05:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfGqVvlSplbG for ; Wed, 22 Mar 2017 05:26:21 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40060.outbound.protection.outlook.com [40.107.4.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C669912971E for ; Wed, 22 Mar 2017 05:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Je60JljYxiqkj8+MKc1I2HDlOrSqs0iKYnnW7XiFbp0=; b=NVF9mAg/Y7ENj+8+yPkRLw3X3Fq0dPOT24aQwRRQZZ5KdiEKPFGOKknL9Wq4cc79GmR6WqYvbkndgUzPf0eL3129gC5v90xF27jKbgfVdkYisNW013kBGdt+wdVPhSJK1++16O5JgiJH/k99lxYU0CMWB+MZAWI/BeDT8YzmwqM= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1905.eurprd03.prod.outlook.com (10.168.2.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Wed, 22 Mar 2017 12:26:17 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0977.019; Wed, 22 Mar 2017 12:26:17 +0000 From: "Paterson, Kenny" To: Watson Ladd , "Tams, Benjamin" CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] Postquantum cryptography in IETF protocols Thread-Index: AQHSnTVJcjR350Po60+E6F5IvEbv/KGVkP8AgAtEM4A= Date: Wed, 22 Mar 2017 12:26:17 +0000 Message-ID: References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1905; 7:BWCPwt1WH8zKmud5NbXwx8EG86vcjRWam873rEI19qq7XMBj5k6paliL1m5vok+BYPX4tAdX4tMrp5um9g8nM1L7iCAAhkun0J2LVEM+H/wuRVi85G6z2dKBbcd1RX692Xm6HSSerUnnrN4BbK+1fxyofeB3lDXvCMfJOj1274ah52+D+9uZ+w7lvCHw6pDNX5FCA2npZk54w1xZRXtcGYCDptnE2wkmh/YITlZpQIuVp66y4Cf/pKbYcECmbxqst2CWGueKZLx+azvzIPEAYBmUuKgDI2d80XGIiG3XZkIxaUSEJC0stIV3kfg0DaUwWQ+2J9P1LnjJ29vtDcaQ3w== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(377454003)(2900100001)(102836003)(54356999)(6116002)(74482002)(3846002)(50986999)(66066001)(86362001)(76176999)(189998001)(4001350100001)(3660700001)(2906002)(36756003)(3280700002)(6436002)(122556002)(6512007)(6486002)(4326008)(53936002)(77096006)(83506001)(99286003)(6306002)(305945005)(6246003)(229853002)(561944003)(2950100002)(81166006)(38730400002)(8936002)(6506006)(8676002)(39060400002)(53546009)(42882006)(7736002)(5660300001)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1905; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 27b4cb43-b72d-425b-0cc2-08d4711ea3e8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM4PR0301MB1905; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:AM4PR0301MB1905; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1905; x-forefront-prvs: 02543CD7CD spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <796FA76825C3EA4E84BEC717FAF7C3AD@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 12:26:17.6892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1905 Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 12:26:26 -0000 SGksDQoNClRoaXMgZS1tYWlsIEkgc2VudCBiYWNrIG9uIDE1dGggTWFyY2ggbGF5aW5nIG91dCB0 aGUgQ0ZSRyBsZWFkZXJzaGlwJ3MNCmN1cnJlbnQgcG9zaXRpb24gb24gcG9zdC1xdWFudHVtIGFs Z29yaXRobXMgZG9lcyBub3QgYXBwZWFyIHRvIGhhdmUgbWFkZQ0KaXQgaW50byB0aGUgQ0ZSRyBh cmNoaXZlIGFuZCBwZXJoYXBzIGRpZCBub3QgbWFrZSBpdCB0byB0aGUgbGlzdC4gSXQgc2VlbQ0K cGVydGluZW50IHRvIHNlbmQgaXQgYWdhaW4sIGluIHZpZXcgb2YgYW4gb24tZ29pbmcgZGlzY3Vz c2lvbiBvbiB0aGUgbGlzdC4NCg0KUmVnYXJkcw0KDQpLZW5ueSANCg0KT24gMTUvMDMvMjAxNyAw ODoyMywgIlBhdGVyc29uLCBLZW5ueSIgPEtlbm55LlBhdGVyc29uQHJodWwuYWMudWs+IHdyb3Rl Og0KDQo+SGkgQmVuamFtaW4sDQo+DQo+RnVsbCBkaXNjbG9zdXJlOiBJIGFtIGludm9sdmVkIGlu IG9uZSBwcm9wb3NhbCBiZWluZyBwcmVwYXJlZCBmb3IgdGhlIE5JU1QNCj5wcm9jZXNzLg0KPg0K Pg0KPldlYXJpbmcgbXkgQ0ZSRyBjby1jaGFpcidzIGhhdCwgSSB3b3VsZCBzYXkgdGhhdCBXYXRz b24gaXMgY29ycmVjdCwgaW4gdGhlDQo+c2Vuc2UgdGhhdCB0aGUgY3VycmVudCBDRlJHIGFwcHJv YWNoIGlzIHRvIGRlZmluZSBSRkNzIGZvciBhIGZldw0KPnJlbGF0aXZlbHkgbWF0dXJlIHBvc3Qt cXVhbnR1bSBwcmltaXRpdmVzLCBzdWNoIGFzIGhhc2gtYmFzZWQgc2lnbmF0dXJlcywNCj5idXQg dG8gd2FpdCBmb3IgdGhlIHJlc3VsdHMgb2YgdGhlIE5JU1QgcHJvY2VzcyBmb3IgZXZlcnl0aGlu ZyBlbHNlLg0KPg0KPlRoZSBOSVNUIHByb2Nlc3MgaXMgZ29pbmcgdG8gcnVuIGZvciBtYW55IHll YXJzIC0gaXQganVzdCBzdGFydGVkLCBhbmQgaXMNCj5zbGF0ZWQgYXQgNS03IHllYXJzLiBJdCB3 aWxsIGVudGFpbCBhIHNpZ25pZmljYW50IGVmZm9ydCBieSB0aGUgcmVzZWFyY2gNCj5jb21tdW5p dHksIHdoaWNoIGlzIHJpZ2h0IGFuZCBwcm9wZXIgZ2l2ZW4gdGhlIGN1cnJlbnQgc3RhdGUgb2Yg dGhlIGZpZWxkLg0KPg0KPlJlZ2FyZHMsDQo+DQo+S2VubnkNCj4NCj5PbiAxNS8wMy8yMDE3IDAy OjM4LCAiQ2ZyZyBvbiBiZWhhbGYgb2YgV2F0c29uIExhZGQiDQo+PGNmcmctYm91bmNlc0BpcnRm Lm9yZyBvbiBiZWhhbGYgb2Ygd2F0c29uYmxhZGRAZ21haWwuY29tPiB3cm90ZToNCj4NCj4+T24g VHVlLCBNYXIgMTQsIDIwMTcgYXQgMTA6MzEgQU0sIFRhbXMsIEJlbmphbWluDQo+PjxCZW5qYW1p bi5UYW1zQHNlY3VuZXQuY29tPiB3cm90ZToNCj4+PiBIaSBKb2huLA0KPj4+DQo+Pj4+IEdvb2Qg dGhhdCBDRlJHIHN0YXJ0cyBzb21lIG1vcmUgZGV0YWlsZWQgZGlzY3Vzc2lvbiBvbiBQUUMuIEl0 IG1ha2VzDQo+Pj4+c2Vuc2UNCj4+Pj4gdG8gc3VwcG9ydCBwb3N0LXF1YW50dW0ga2V5IGV4Y2hh bmdlIGZvciB1c2UgY2FzZXMgdGhhdCBuZWVkIGxvbmctdGVybQ0KPj4+PiBjb25maWRlbnRpYWxp dHkgKDE1IHllYXJzKS4gRm9yIG90aGVyIHVzZSBjYXNlcyBJIHRoaW5rIGl0IGNhbiB3YWl0DQo+ Pj4+dW50aWwNCj4+Pj4gUFFDIGtleSBleGNoYW5nZSBhbGdvcml0aG1zIGhhcyBiZWVuIHRob3Jv dWdobHkgZXZhbHVhdGVkIGFuZA0KPj4+PiBzdGFuZGFyZGl6ZWQuIElmIGltcGxlbWVudGVkIG5v dywgaXQgc2hvdWxkIGJlIHVzZWQgaW4gYWRkaXRpb24gdG8NCj4+Pj5FQ0RIRSwNCj4+Pj4ganVz dCBsaWtlIEdvb2dsZSBoYXMgZG9uZSB3aXRoIHRoZWlyIGV4cGVyaW1lbnRhbCBOZXcgSG9wZQ0K Pj4+PmltcGxlbWVudGF0aW9uLg0KPj4+DQo+Pj4gSSBhYnNvbHV0ZWx5IGFncmVlIHdpdGggeW91 ciB2aWV3IG9uIHRoZSBzdWJqZWN0LiBFc3BlY2lhbGx5IGZvciB0aG9zZQ0KPj4+dXNlDQo+Pj4g Y2FzZXMgd2hlcmUgdGhlIGF0dGFjayBzY2VuYXJpbyAiY29sbGVjdCB0b2RheSwgZGVjcnlwdCB0 b21vcnJvdyIgaXMgYQ0KPj4+dGhyZWF0LA0KPj4+IHdlIHNob3VsZCBzdGFydCB0aGlua2luZyBv ZiBQUS1zYWZlIGtleSBleGNoYW5nZSBtZXRob2RzIGluIHRpbWUuIEV2ZW4NCj4+PmlmDQo+Pj4g dGhleSBldmVudHVhbGx5IHR1cm4gb3V0IHRvIGJlIGluc2VjdXJlOyB3ZSBjYW4gbm93IGNvbWJp bmUgdGhlbSB3aXRoDQo+Pj4gY2xhc3NpY2FsIGtleSBleGNoYW5nZSBhbGdvcml0aG1zLiBXZSBo YXZlIG5vdGhpbmcgdG8gbG9zZS4NCj4+Pg0KPj4+IFRoZXJlIGlzIGFscmVhZHkgSUVURiB3b3Jr IGFkZHJlc3NpbmcgUFEtc2VjdXJpdHkgaW4gSW50ZXJuZXQNCj4+PnByb3RvY29scywgZS5nLg0K Pj4+IElLRSBhbmQgYW4gSW50ZXJuZXQgRHJhZnQgZm9yIGEgUXVhbnR1bS1TYWZlIEh5YnJpZCBD aXBoZXJzdWl0ZSBmb3IgVExTDQo+Pj4NCj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZmx1aHJlci1xci1pa2V2Mi0wMw0KPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC13aHl0ZS1xc2gtdGxzMTMtMDMNCj4+Pg0KPj4+IE9uIHRoZSBvdGhlciBoYW5kLCB0 aGVyZSBpcyAodG8gbXkga25vd2xlZGdlKSBubyBzcGVjaWZpY2F0aW9uIGZvciBhDQo+Pj5QUS1z YWZlDQo+Pj4gcGF0ZW50LWZyZWUga2V5IGV4Y2hhbmdlIGFsZ29yaXRobSBzdWl0YWJsZSBmb3Ig aW1wbGVtZW50YXRpb24uIEluDQo+Pj5mYWN0LCBpbg0KPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC13aHl0ZS1xc2gtdGxzMTMtMDMNCj4+PiBvbmx5IE5UUlVFbmNyeXB0IGlz IHNwZWNpZmllZCBidXQgaXMgc3ViamVjdCB0byBwYXRlbnRzLg0KPj4+DQo+Pj4gQSBwb3NzaWJs ZSBmaXJzdCBzdGVwIGlzIHRoYXQgQ0ZSRyBjcmVhdGVzIGFuIEludGVybmV0IERyYWZ0LiBJbiBm YWN0LA0KPj4+IHRoZSBhbGdvcml0aG0gTmV3IEhvcGUgaGFzIGFscmVhZHkgYmVlbiBpbXBsZW1l bnRlZCBhcyBhIHBsdWdpbiBmb3INCj4+PiBzdHJvbmdTd2FuIChJUFNlYyBpbXBsZW1lbnRhdGlv biBmb3IgdGhlIExpbnV4IGtlcm5lbCkNCj4+Pg0KPj4+IA0KPj4+aHR0cHM6Ly9naXRodWIuY29t L3N0cm9uZ3N3YW4vc3Ryb25nc3dhbi90cmVlL21hc3Rlci9zcmMvbGlic3Ryb25nc3dhbi9wDQo+ Pj5sDQo+Pj51Z2lucy9uZXdob3BlDQo+Pj4NCj4+PiBTbyB3aHkgZG8gd2Ugbm90IHN0YXJ0IHdp dGggYSBkcmFmdCBmb3Igd2hpY2ggdGhlIGFib3ZlIGltcGxlbWVudGF0aW9uDQo+Pj5jYW4NCj4+ PiBzZXJ2ZSBhcyBhIHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbj8NCj4+DQo+PldoeSBzaG91bGQg d2UgcHJlZW1wdCB0aGUgY3VycmVudCBOSVNUIHBvc3RxdWFudHVtIHN0YW5kYXJkaXphdGlvbg0K Pj5lZmZvcnRzPw0KPj4+DQo+Pj4gS2luZCByZWdhcmRzLA0KPj4+IEJlbmphbWluDQo+Pj4NCj4+ Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4gQ2ZyZyBtYWlsaW5nIGxpc3QNCj4+PiBDZnJnQGlydGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cu aXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZnJnDQo+Pg0KPj4NCj4+DQo+Pi0tIA0KPj4iTWFu IGlzIGJvcm4gZnJlZSwgYnV0IGV2ZXJ5d2hlcmUgaGUgaXMgaW4gY2hhaW5zIi4NCj4+LS1Sb3Vz c2VhdS4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PkNmcmcgbWFpbGluZyBsaXN0DQo+PkNmcmdAaXJ0Zi5vcmcNCj4+aHR0cHM6Ly93d3cu aXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZnJnDQo+DQoNCg== From nobody Wed Mar 22 05:34:52 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5B1129739 for ; Wed, 22 Mar 2017 05:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djfIifPLV46U for ; Wed, 22 Mar 2017 05:34:47 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A5A129722 for ; Wed, 22 Mar 2017 05:34:47 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id n11so35306566wma.1 for ; Wed, 22 Mar 2017 05:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l7X8JgQtZtjSoJaSWTEdK+QtWnJxK3zjJbCf1QwVWVE=; b=NSH6cQ2yKQYauokezvC2AjoiSU6TGD8DwYgDxiXuHKqePX9dWRL6CtBFjpZAW/Jh93 YaDN/k71GvvmS5Q2FXWc6hRkIk0O+thD3I6EUZVkdhYyQ3FqiMAeMBt3gJm+KR3l4bWy /PUQ2ZSWLL77HMm4Ipy2DHh9WPYXKZ9qtCDEM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l7X8JgQtZtjSoJaSWTEdK+QtWnJxK3zjJbCf1QwVWVE=; b=X54vtb94qxgrEJ1VGPBUTvObpGI5x8DWbbKJnx2P/KC5lWXVBrVD1fFb99Ats06gW6 h9SXmTxnilFafj/PnjP9n+N8M37R7+uzBFEzfg0+ahQ+ZfGsaHelavhL+WJcntk1vses 4UgZQfVp7CMgMAXOISFAz/5t8IALiwRX1mHI3jQ+O8Up3jA0PE0PTbg/Hyl7zSeNfgZL MVSs27wO7Gc065/+igvgLE5uiChsjqZd2KZMrr7M3BsqFw6kaRJtj19O4C5RnWcdg40j oXP/UG1RfLXU+f+Iy6w77RQATyjzTR0WH3CkreE2zMh5sXyPhIsIWUSdL1E59hSnBSRl T4RA== X-Gm-Message-State: AFeK/H3mbGNcFYPnB1wxiv2HFzjvgCkVDMEfZyQa7m07bSSkFZv76YNfokpKROrisT9Iazxzav3c3cX5tUmwvg== X-Received: by 10.28.30.19 with SMTP id e19mr7436377wme.52.1490186085803; Wed, 22 Mar 2017 05:34:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.166.5 with HTTP; Wed, 22 Mar 2017 05:34:25 -0700 (PDT) In-Reply-To: References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> From: William Whyte Date: Wed, 22 Mar 2017 08:34:25 -0400 Message-ID: To: "Paterson, Kenny" Cc: Watson Ladd , "Tams, Benjamin" , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a114b3c824b478b054b50fc5a Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 12:34:51 -0000 --001a114b3c824b478b054b50fc5a Content-Type: text/plain; charset=UTF-8 Hi Kenny, I didn't see that mail, thanks for forwarding. Personally I find Ben's position more convincing: >> The other way round does neither: Just because there are Internet Drafts specifying PQ-safe key exchange algorithms, this does not mean they have to be implemented. Anyway, existing implementations are indications for the need of PQ-safe key exchange algorithms. Therefore, in my view, it is reasonable to specify Internet Drafts for state-of-the-art PQ-safe key exchange algorithms suitable for implementation. There are organizations that need to plan for a migration now in order to properly manage risk and that can't wait for the NIST process to complete. Providing an interoperability specification for PQ algorithms to be used in a hybrid context allows these organizations to start development and prototype deployment. I'm not sure the "current CFRG approach" has been formally decided on; it's more "what CFRG happens to be doing at the moment". If CFRG members see value in specifying a wider range of algorithms, the CFRG approach can be changed. Cheers, William On Wed, Mar 22, 2017 at 8:26 AM, Paterson, Kenny wrote: > Hi, > > This e-mail I sent back on 15th March laying out the CFRG leadership's > current position on post-quantum algorithms does not appear to have made > it into the CFRG archive and perhaps did not make it to the list. It seem > pertinent to send it again, in view of an on-going discussion on the list. > > Regards > > Kenny > > On 15/03/2017 08:23, "Paterson, Kenny" wrote: > > >Hi Benjamin, > > > >Full disclosure: I am involved in one proposal being prepared for the NIST > >process. > > > > > >Wearing my CFRG co-chair's hat, I would say that Watson is correct, in the > >sense that the current CFRG approach is to define RFCs for a few > >relatively mature post-quantum primitives, such as hash-based signatures, > >but to wait for the results of the NIST process for everything else. > > > >The NIST process is going to run for many years - it just started, and is > >slated at 5-7 years. It will entail a significant effort by the research > >community, which is right and proper given the current state of the field. > > > >Regards, > > > >Kenny > > > >On 15/03/2017 02:38, "Cfrg on behalf of Watson Ladd" > > wrote: > > > >>On Tue, Mar 14, 2017 at 10:31 AM, Tams, Benjamin > >> wrote: > >>> Hi John, > >>> > >>>> Good that CFRG starts some more detailed discussion on PQC. It makes > >>>>sense > >>>> to support post-quantum key exchange for use cases that need long-term > >>>> confidentiality (15 years). For other use cases I think it can wait > >>>>until > >>>> PQC key exchange algorithms has been thoroughly evaluated and > >>>> standardized. If implemented now, it should be used in addition to > >>>>ECDHE, > >>>> just like Google has done with their experimental New Hope > >>>>implementation. > >>> > >>> I absolutely agree with your view on the subject. Especially for those > >>>use > >>> cases where the attack scenario "collect today, decrypt tomorrow" is a > >>>threat, > >>> we should start thinking of PQ-safe key exchange methods in time. Even > >>>if > >>> they eventually turn out to be insecure; we can now combine them with > >>> classical key exchange algorithms. We have nothing to lose. > >>> > >>> There is already IETF work addressing PQ-security in Internet > >>>protocols, e.g. > >>> IKE and an Internet Draft for a Quantum-Safe Hybrid Ciphersuite for TLS > >>> > >>> https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-03 > >>> https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 > >>> > >>> On the other hand, there is (to my knowledge) no specification for a > >>>PQ-safe > >>> patent-free key exchange algorithm suitable for implementation. In > >>>fact, in > >>> https://tools.ietf.org/html/draft-whyte-qsh-tls13-03 > >>> only NTRUEncrypt is specified but is subject to patents. > >>> > >>> A possible first step is that CFRG creates an Internet Draft. In fact, > >>> the algorithm New Hope has already been implemented as a plugin for > >>> strongSwan (IPSec implementation for the Linux kernel) > >>> > >>> > >>>https://github.com/strongswan/strongswan/tree/ > master/src/libstrongswan/p > >>>l > >>>ugins/newhope > >>> > >>> So why do we not start with a draft for which the above implementation > >>>can > >>> serve as a reference implementation? > >> > >>Why should we preempt the current NIST postquantum standardization > >>efforts? > >>> > >>> Kind regards, > >>> Benjamin > >>> > >>> > >>> _______________________________________________ > >>> Cfrg mailing list > >>> Cfrg@irtf.org > >>> https://www.irtf.org/mailman/listinfo/cfrg > >> > >> > >> > >>-- > >>"Man is born free, but everywhere he is in chains". > >>--Rousseau. > >> > >>_______________________________________________ > >>Cfrg mailing list > >>Cfrg@irtf.org > >>https://www.irtf.org/mailman/listinfo/cfrg > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a114b3c824b478b054b50fc5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Kenny,

I didn't see that mail, t= hanks for forwarding.

Personally I find Ben's = position more convincing:

>>=C2=A0The other way round does neither: Just because there= are Internet Drafts specifying
PQ-safe key exchange algorithms, this does not mean they have to be imple= mented. Anyway,
existing implementations are indications for the need of PQ-safe= key exchange algorithms.
Therefore, in my view, it is reasonable to specify In= ternet Drafts for state-of-the-art
PQ-safe key exchange algorithms suitable for = implementation.

There are organizations that need t= o plan for a migration now in order to properly manage risk and that can= 9;t wait for the NIST process to complete. Providing an interoperability sp= ecification for PQ algorithms to be used in a hybrid context allows these o= rganizations to start development and prototype deployment.

I'm not sure the "current CFRG approach" has b= een formally decided on; it's more "what CFRG happens to be doing = at the moment". If CFRG members see value in specifying a wider range = of algorithms, the CFRG approach can be changed.

Cheers,

William




On Wed, M= ar 22, 2017 at 8:26 AM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk= > wrote:
Hi,

This e-mail I sent back on 15th March laying out the CFRG leadership's<= br> current position on post-quantum algorithms does not appear to have made it into the CFRG archive and perhaps did not make it to the list. It seem pertinent to send it again, in view of an on-going discussion on the list.<= br>
Regards

Kenny

On 15/03/2017 08:23, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> wrote:

>Hi Benjamin,
>
>Full disclosure: I am involved in one proposal being prepared for the N= IST
>process.
>
>
>Wearing my CFRG co-chair's hat, I would say that Watson is correct,= in the
>sense that the current CFRG approach is to define RFCs for a few
>relatively mature post-quantum primitives, such as hash-based signature= s,
>but to wait for the results of the NIST process for everything else. >
>The NIST process is going to run for many years - it just started, and = is
>slated at 5-7 years. It will entail a significant effort by the researc= h
>community, which is right and proper given the current state of the fie= ld.
>
>Regards,
>
>Kenny
>
>On 15/03/2017 02:38, "Cfrg on behalf of Watson Ladd"
><cfrg-bounces@irtf.org on behalf of watsonbladd@gmail.com> wrote:
>
>>On Tue, Mar 14, 2017 at 10:31 AM, Tams, Benjamin
>><Benjamin.Tams@secu= net.com> wrote:
>>> Hi John,
>>>
>>>> Good that CFRG starts some more detailed discussion on PQC= . It makes
>>>>sense
>>>> to support post-quantum key exchange for use cases that ne= ed long-term
>>>> confidentiality (15 years). For other use cases I think it= can wait
>>>>until
>>>> PQC key exchange algorithms has been thoroughly evaluated = and
>>>> standardized. If implemented now, it should be used in add= ition to
>>>>ECDHE,
>>>> just like Google has done with their experimental New Hope=
>>>>implementation.
>>>
>>> I absolutely agree with your view on the subject. Especially f= or those
>>>use
>>> cases where the attack scenario "collect today, decrypt t= omorrow" is a
>>>threat,
>>> we should start thinking of PQ-safe key exchange methods in ti= me. Even
>>>if
>>> they eventually turn out to be insecure; we can now combine th= em with
>>> classical key exchange algorithms. We have nothing to lose. >>>
>>> There is already IETF work addressing PQ-security in Internet<= br> >>>protocols, e.g.
>>> IKE and an Internet Draft for a Quantum-Safe Hybrid Ciphersuit= e for TLS
>>>
>>> https://tools.ietf.org/html/d= raft-fluhrer-qr-ikev2-03
>>> https://tools.ietf.org/html/dr= aft-whyte-qsh-tls13-03
>>>
>>> On the other hand, there is (to my knowledge) no specification= for a
>>>PQ-safe
>>> patent-free key exchange algorithm suitable for implementation= . In
>>>fact, in
>>> https://tools.ietf.org/html/dr= aft-whyte-qsh-tls13-03
>>> only NTRUEncrypt is specified but is subject to patents.
>>>
>>> A possible first step is that CFRG creates an Internet Draft. = In fact,
>>> the algorithm New Hope has already been implemented as a plugi= n for
>>> strongSwan (IPSec implementation for the Linux kernel)
>>>
>>>
>>>https://github.c= om/strongswan/strongswan/tree/master/src/libstrongswan/p
>>>l
>>>ugins/newhope
>>>
>>> So why do we not start with a draft for which the above implem= entation
>>>can
>>> serve as a reference implementation?
>>
>>Why should we preempt the current NIST postquantum standardization<= br> >>efforts?
>>>
>>> Kind regards,
>>> Benjamin
>>>
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.org
>>> https://www.irtf.org/mailman/listinfo/cf= rg
>>
>>
>>
>>--
>>"Man is born free, but everywhere he is in chains".
>>--Rousseau.
>>
>>_______________________________________________
>>Cfrg mailing list
>>Cfrg@irtf.org
>>https://www.irtf.org/mailman/listinfo/cfrg
>

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--001a114b3c824b478b054b50fc5a-- From nobody Wed Mar 22 08:07:50 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B18131741 for ; Wed, 22 Mar 2017 07:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5UcgRCxkcLT for ; Wed, 22 Mar 2017 07:36:37 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0077.outbound.protection.outlook.com [104.47.2.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3147E131746 for ; Wed, 22 Mar 2017 07:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=au6ojWBNjQnjugRb5F+t5tqrjt5tKTM/t+2V5cNjbWY=; b=2iW1+cA2edyvOmaXSJC4H7lbIscgg80Kr/4Dn62Ol4rRbIy5imLH9XptaCiFeEIdP103sNaP7ZqJkGDEHfxLyVtVBjU0UDUZ5fEGbUvJ+gZk4w749VOGJuY6rw/V6uiHrnctXNQ08lDr/718QtqTl9tRb2s+gVqPmQ95tRkI2r4= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Wed, 22 Mar 2017 14:36:05 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0977.019; Wed, 22 Mar 2017 14:36:04 +0000 From: "Paterson, Kenny" To: William Whyte CC: Watson Ladd , "Tams, Benjamin" , "cfrg@irtf.org" Thread-Topic: [Cfrg] Postquantum cryptography in IETF protocols Thread-Index: AQHSnTVJcjR350Po60+E6F5IvEbv/KGVkP8AgAtEM4CAAAGqgIAAIo8A Date: Wed, 22 Mar 2017 14:36:04 +0000 Message-ID: References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: onboardsecurity.com; dkim=none (message not signed) header.d=none;onboardsecurity.com; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:lHjqncQuoIvvvUVyrEFUYy0fJSdBistw5Q6egkX8MKkatGfX+GaxQu06Pd1YPmga+4t0QUoKyIqeDIGOVir9pv2dZiqrolxQO+xPkk5kPgowG9Xuwh7AsTO8i9qNm4FnquGpKvA3cfSXpXQTdkTDduaJoo/ee+UJsfzYqa5/mHdCNYiDavh0YGqleX3tgy4JgwAG31y1mhlv4MKykEHLm7qCPFNhP6GwozsvbIdfRNCw9pna2BUsmwqV19UDecuk6NfZvD5MWQTXB4Z7VnXysysa7RmD2dTsnZHMAWXmGL3ESqsTNVG0R0yVApUiU6F6lbUTPLbcsoVd3liVDiFznw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(52314003)(24454002)(377454003)(2906002)(3846002)(8936002)(305945005)(50986999)(54906002)(2950100002)(6916009)(39060400002)(42882006)(4001350100001)(99286003)(6436002)(38730400002)(6512007)(83506001)(74482002)(53936002)(6306002)(110136004)(53546009)(54356999)(6486002)(229853002)(102836003)(122556002)(6246003)(561944003)(6506006)(189998001)(3660700001)(36756003)(86362001)(66066001)(4326008)(2900100001)(7736002)(77096006)(76176999)(3280700002)(81166006)(8676002)(5660300001)(93886004)(25786009)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 3e58d3c0-cb85-4257-e71d-08d47130c52b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM4PR0301MB1906; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1906; x-forefront-prvs: 02543CD7CD spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 14:36:04.5009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906 Archived-At: Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 14:36:43 -0000 SGkgV2lsbGlhbSwNCg0KWW91IGFyZSByaWdodCB0aGF0IHRoZXJlJ3Mgbm8gZm9ybWFsbHkgYWdy ZWVkIGFwcHJvYWNoIGZvciBDRlJHLCBidXQgdGhlDQpjdXJyZW50IGFwcHJvYWNoIHRoYXQgdGhl ICpsZWFkZXJzaGlwKiBvZiBDRlJHIChpLmUuIHRoZSBjby1jaGFpcnMpIHdvdWxkDQpsaWtlIHRv IHRha2UgaXMgdGhhdCBleHBsYWluZWQgaW4gbXkgbWVzc2FnZSBiZWxvdy4gQnV0IHdlIGNhbiBv ZiBjb3Vyc2UNCnJldmlzaXQgdGhlIHF1ZXN0aW9uIGFzIGEgcmVzZWFyY2ggZ3JvdXAuDQoNClRv IHJlaXRlcmF0ZTogSSB3b3VsZCBjb25zaWRlciBpdCBhIG1pc3Rha2UgZm9yIENGUkcgdG8gZ28g ZG93biB0aGUgcm91dGUNCm9mIHN0YW5kYXJkaXNpbmcgUFEgYWxnb3JpdGhtcyBhaGVhZCBvZiB0 aGUgTklTVCBwcm9jZXNzLCBhc2lkZSBmcm9tIGluDQptYXR1cmUgYXJlYXMgbGlrZSBoYXNoLWJh c2VkIHNpZ25hdHVyZXMgd2hlcmUgd2UgaGF2ZSBhIGxvdCBvZiByZXNlYXJjaA0KdGhhdCB3ZSBj YW4gZHJhdyBvbi4gRm9yIG1lLCB0aGUgcmVzdCBvZiB0aGUgZmllbGQgaXMgaW4gdG9vIG11Y2gg b2YgYQ0Kc3RhdGUgb2YgZmx1eCwgYW5kIHRoZSBleHBlcnRpc2UgdGhhdCBtaWdodCBvdGhlcndp c2UgYmUgYXZhaWxhYmxlIGlzDQoocmlnaHRseSkgZm9jdXNzZWQgb24gdGhlIE5JU1QgcHJvY2Vz cyB3aXRoIGl0cyAocmlnaHRseSkgbXVjaCBsb25nZXINCnRpbWVzY2FsZXMuIA0KDQpJIHdvdWxk IHdlbGNvbWUgYSBDRlJHLXdpZGUgZGVjaXNpb24gdG8gbG9vayBhdCAiYW4gaW50ZXJvcGVyYWJp bGl0eQ0Kc3BlY2lmaWNhdGlvbiBmb3IgUFEgYWxnb3JpdGhtcyB0byBiZSB1c2VkIGluIGEgaHli cmlkIGNvbnRleHQiIGFzIHlvdSBwdXQNCml0LiBCdXQgdGhhdCdzIG5vdCB0aGUgc2FtZSBhcyBs b29raW5nIGF0IFBRIGFsZ29yaXRobXMuIExldCdzIG5vdA0KY29uZmxhdGUvY29uZnVzZSB0aGVt Lg0KDQpGdXJ0aGVyIGNvbW1lbnRzL2Rpc2N1c3Npb24gdmVyeSB3ZWxjb21lIC0gYXMgYWx3YXlz Lg0KDQpDaGVlcnMsDQoNCktlbm55IA0KDQoNCk9uIDIyLzAzLzIwMTcgMTI6MzQsICJXaWxsaWFt IFdoeXRlIiA8d3doeXRlQG9uYm9hcmRzZWN1cml0eS5jb20+IHdyb3RlOg0KDQo+SGkgS2Vubnks DQo+DQo+DQo+SSBkaWRuJ3Qgc2VlIHRoYXQgbWFpbCwgdGhhbmtzIGZvciBmb3J3YXJkaW5nLg0K Pg0KPg0KPlBlcnNvbmFsbHkgSSBmaW5kIEJlbidzIHBvc2l0aW9uIG1vcmUgY29udmluY2luZzoN Cj4NCj4NCj4+PiBUaGUgb3RoZXIgd2F5IHJvdW5kIGRvZXMgbmVpdGhlcjogSnVzdCBiZWNhdXNl IHRoZXJlIGFyZSBJbnRlcm5ldA0KPj4+RHJhZnRzIHNwZWNpZnlpbmcNCj5QUS1zYWZlIGtleSBl eGNoYW5nZSBhbGdvcml0aG1zLCB0aGlzIGRvZXMgbm90IG1lYW4gdGhleSBoYXZlIHRvIGJlDQo+ aW1wbGVtZW50ZWQuIEFueXdheSwNCj5leGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYXJlIGluZGlj YXRpb25zIGZvciB0aGUgbmVlZCBvZiBQUS1zYWZlIGtleQ0KPmV4Y2hhbmdlIGFsZ29yaXRobXMu DQo+VGhlcmVmb3JlLCBpbiBteSB2aWV3LCBpdCBpcyByZWFzb25hYmxlIHRvIHNwZWNpZnkgSW50 ZXJuZXQgRHJhZnRzIGZvcg0KPnN0YXRlLW9mLXRoZS1hcnQNCj5QUS1zYWZlIGtleSBleGNoYW5n ZSBhbGdvcml0aG1zIHN1aXRhYmxlIGZvciBpbXBsZW1lbnRhdGlvbi4NCj4NCj5UaGVyZSBhcmUg b3JnYW5pemF0aW9ucyB0aGF0IG5lZWQgdG8gcGxhbiBmb3IgYSBtaWdyYXRpb24gbm93IGluIG9y ZGVyIHRvDQo+cHJvcGVybHkgbWFuYWdlIHJpc2sgYW5kIHRoYXQgY2FuJ3Qgd2FpdCBmb3IgdGhl IE5JU1QgcHJvY2VzcyB0bw0KPmNvbXBsZXRlLiBQcm92aWRpbmcgYW4gaW50ZXJvcGVyYWJpbGl0 eSBzcGVjaWZpY2F0aW9uIGZvciBQUSBhbGdvcml0aG1zDQo+dG8gYmUgdXNlZA0KPiBpbiBhIGh5 YnJpZCBjb250ZXh0IGFsbG93cyB0aGVzZSBvcmdhbml6YXRpb25zIHRvIHN0YXJ0IGRldmVsb3Bt ZW50IGFuZA0KPnByb3RvdHlwZSBkZXBsb3ltZW50Lg0KPg0KPg0KPkknbSBub3Qgc3VyZSB0aGUg ImN1cnJlbnQgQ0ZSRyBhcHByb2FjaCIgaGFzIGJlZW4gZm9ybWFsbHkgZGVjaWRlZCBvbjsNCj5p dCdzIG1vcmUgIndoYXQgQ0ZSRyBoYXBwZW5zIHRvIGJlIGRvaW5nIGF0IHRoZSBtb21lbnQiLiBJ ZiBDRlJHIG1lbWJlcnMNCj5zZWUgdmFsdWUgaW4gc3BlY2lmeWluZyBhIHdpZGVyIHJhbmdlIG9m IGFsZ29yaXRobXMsIHRoZSBDRlJHIGFwcHJvYWNoDQo+Y2FuIGJlDQo+IGNoYW5nZWQuDQo+DQo+ DQo+Q2hlZXJzLA0KPg0KPg0KPldpbGxpYW0NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj5PbiBX ZWQsIE1hciAyMiwgMjAxNyBhdCA4OjI2IEFNLCBQYXRlcnNvbiwgS2VubnkNCj48S2VubnkuUGF0 ZXJzb25Acmh1bC5hYy51az4gd3JvdGU6DQo+DQo+SGksDQo+DQo+VGhpcyBlLW1haWwgSSBzZW50 IGJhY2sgb24gMTV0aCBNYXJjaCBsYXlpbmcgb3V0IHRoZSBDRlJHIGxlYWRlcnNoaXAncw0KPmN1 cnJlbnQgcG9zaXRpb24gb24gcG9zdC1xdWFudHVtIGFsZ29yaXRobXMgZG9lcyBub3QgYXBwZWFy IHRvIGhhdmUgbWFkZQ0KPml0IGludG8gdGhlIENGUkcgYXJjaGl2ZSBhbmQgcGVyaGFwcyBkaWQg bm90IG1ha2UgaXQgdG8gdGhlIGxpc3QuIEl0IHNlZW0NCj5wZXJ0aW5lbnQgdG8gc2VuZCBpdCBh Z2FpbiwgaW4gdmlldyBvZiBhbiBvbi1nb2luZyBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0Lg0KPg0K PlJlZ2FyZHMNCj4NCj5LZW5ueQ0KPg0KPk9uIDE1LzAzLzIwMTcgMDg6MjMsICJQYXRlcnNvbiwg S2VubnkiIDxLZW5ueS5QYXRlcnNvbkByaHVsLmFjLnVrPiB3cm90ZToNCj4NCj4+SGkgQmVuamFt aW4sDQo+Pg0KPj5GdWxsIGRpc2Nsb3N1cmU6IEkgYW0gaW52b2x2ZWQgaW4gb25lIHByb3Bvc2Fs IGJlaW5nIHByZXBhcmVkIGZvciB0aGUNCj4+TklTVA0KPj5wcm9jZXNzLg0KPj4NCj4+DQo+Pldl YXJpbmcgbXkgQ0ZSRyBjby1jaGFpcidzIGhhdCwgSSB3b3VsZCBzYXkgdGhhdCBXYXRzb24gaXMg Y29ycmVjdCwgaW4NCj4+dGhlDQo+PnNlbnNlIHRoYXQgdGhlIGN1cnJlbnQgQ0ZSRyBhcHByb2Fj aCBpcyB0byBkZWZpbmUgUkZDcyBmb3IgYSBmZXcNCj4+cmVsYXRpdmVseSBtYXR1cmUgcG9zdC1x dWFudHVtIHByaW1pdGl2ZXMsIHN1Y2ggYXMgaGFzaC1iYXNlZCBzaWduYXR1cmVzLA0KPj5idXQg dG8gd2FpdCBmb3IgdGhlIHJlc3VsdHMgb2YgdGhlIE5JU1QgcHJvY2VzcyBmb3IgZXZlcnl0aGlu ZyBlbHNlLg0KPj4NCj4+VGhlIE5JU1QgcHJvY2VzcyBpcyBnb2luZyB0byBydW4gZm9yIG1hbnkg eWVhcnMgLSBpdCBqdXN0IHN0YXJ0ZWQsIGFuZCBpcw0KPj5zbGF0ZWQgYXQgNS03IHllYXJzLiBJ dCB3aWxsIGVudGFpbCBhIHNpZ25pZmljYW50IGVmZm9ydCBieSB0aGUgcmVzZWFyY2gNCj4+Y29t bXVuaXR5LCB3aGljaCBpcyByaWdodCBhbmQgcHJvcGVyIGdpdmVuIHRoZSBjdXJyZW50IHN0YXRl IG9mIHRoZQ0KPj5maWVsZC4NCj4+DQo+PlJlZ2FyZHMsDQo+Pg0KPj5LZW5ueQ0KPj4NCj4+T24g MTUvMDMvMjAxNyAwMjozOCwgIkNmcmcgb24gYmVoYWxmIG9mIFdhdHNvbiBMYWRkIg0KPj48Y2Zy Zy1ib3VuY2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZg0KPndhdHNvbmJsYWRkQGdtYWlsLmNvbT4g d3JvdGU6DQo+Pg0KPj4+T24gVHVlLCBNYXIgMTQsIDIwMTcgYXQgMTA6MzEgQU0sIFRhbXMsIEJl bmphbWluDQo+Pj48QmVuamFtaW4uVGFtc0BzZWN1bmV0LmNvbT4gd3JvdGU6DQo+Pj4+IEhpIEpv aG4sDQo+Pj4+DQo+Pj4+PiBHb29kIHRoYXQgQ0ZSRyBzdGFydHMgc29tZSBtb3JlIGRldGFpbGVk IGRpc2N1c3Npb24gb24gUFFDLiBJdCBtYWtlcw0KPj4+Pj5zZW5zZQ0KPj4+Pj4gdG8gc3VwcG9y dCBwb3N0LXF1YW50dW0ga2V5IGV4Y2hhbmdlIGZvciB1c2UgY2FzZXMgdGhhdCBuZWVkDQo+Pj4+ PmxvbmctdGVybQ0KPj4+Pj4gY29uZmlkZW50aWFsaXR5ICgxNSB5ZWFycykuIEZvciBvdGhlciB1 c2UgY2FzZXMgSSB0aGluayBpdCBjYW4gd2FpdA0KPj4+Pj51bnRpbA0KPj4+Pj4gUFFDIGtleSBl eGNoYW5nZSBhbGdvcml0aG1zIGhhcyBiZWVuIHRob3JvdWdobHkgZXZhbHVhdGVkIGFuZA0KPj4+ Pj4gc3RhbmRhcmRpemVkLiBJZiBpbXBsZW1lbnRlZCBub3csIGl0IHNob3VsZCBiZSB1c2VkIGlu IGFkZGl0aW9uIHRvDQo+Pj4+PkVDREhFLA0KPj4+Pj4ganVzdCBsaWtlIEdvb2dsZSBoYXMgZG9u ZSB3aXRoIHRoZWlyIGV4cGVyaW1lbnRhbCBOZXcgSG9wZQ0KPj4+Pj5pbXBsZW1lbnRhdGlvbi4N Cj4+Pj4NCj4+Pj4gSSBhYnNvbHV0ZWx5IGFncmVlIHdpdGggeW91ciB2aWV3IG9uIHRoZSBzdWJq ZWN0LiBFc3BlY2lhbGx5IGZvciB0aG9zZQ0KPj4+PnVzZQ0KPj4+PiBjYXNlcyB3aGVyZSB0aGUg YXR0YWNrIHNjZW5hcmlvICJjb2xsZWN0IHRvZGF5LCBkZWNyeXB0IHRvbW9ycm93IiBpcyBhDQo+ Pj4+dGhyZWF0LA0KPj4+PiB3ZSBzaG91bGQgc3RhcnQgdGhpbmtpbmcgb2YgUFEtc2FmZSBrZXkg ZXhjaGFuZ2UgbWV0aG9kcyBpbiB0aW1lLiBFdmVuDQo+Pj4+aWYNCj4+Pj4gdGhleSBldmVudHVh bGx5IHR1cm4gb3V0IHRvIGJlIGluc2VjdXJlOyB3ZSBjYW4gbm93IGNvbWJpbmUgdGhlbSB3aXRo DQo+Pj4+IGNsYXNzaWNhbCBrZXkgZXhjaGFuZ2UgYWxnb3JpdGhtcy4gV2UgaGF2ZSBub3RoaW5n IHRvIGxvc2UuDQo+Pj4+DQo+Pj4+IFRoZXJlIGlzIGFscmVhZHkgSUVURiB3b3JrIGFkZHJlc3Np bmcgUFEtc2VjdXJpdHkgaW4gSW50ZXJuZXQNCj4+Pj5wcm90b2NvbHMsIGUuZy4NCj4+Pj4gSUtF IGFuZCBhbiBJbnRlcm5ldCBEcmFmdCBmb3IgYSBRdWFudHVtLVNhZmUgSHlicmlkIENpcGhlcnN1 aXRlIGZvcg0KPj4+PlRMUw0KPj4+Pg0KPj4+PiANCj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZmx1aHJlci1xci1pa2V2Mi0wMw0KPjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZmx1aHJlci1xci1pa2V2Mi0wMz4NCj4+Pj4gDQo+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXdoeXRlLXFzaC10bHMxMy0wMw0KPjxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtd2h5dGUtcXNoLXRsczEzLTAzPg0KPj4+Pg0KPj4+PiBPbiB0aGUgb3Ro ZXIgaGFuZCwgdGhlcmUgaXMgKHRvIG15IGtub3dsZWRnZSkgbm8gc3BlY2lmaWNhdGlvbiBmb3Ig YQ0KPj4+PlBRLXNhZmUNCj4+Pj4gcGF0ZW50LWZyZWUga2V5IGV4Y2hhbmdlIGFsZ29yaXRobSBz dWl0YWJsZSBmb3IgaW1wbGVtZW50YXRpb24uIEluDQo+Pj4+ZmFjdCwgaW4NCj4+Pj4gDQo+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdoeXRlLXFzaC10bHMxMy0wMw0KPjxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2h5dGUtcXNoLXRsczEzLTAzPg0KPj4+PiBv bmx5IE5UUlVFbmNyeXB0IGlzIHNwZWNpZmllZCBidXQgaXMgc3ViamVjdCB0byBwYXRlbnRzLg0K Pj4+Pg0KPj4+PiBBIHBvc3NpYmxlIGZpcnN0IHN0ZXAgaXMgdGhhdCBDRlJHIGNyZWF0ZXMgYW4g SW50ZXJuZXQgRHJhZnQuIEluIGZhY3QsDQo+Pj4+IHRoZSBhbGdvcml0aG0gTmV3IEhvcGUgaGFz IGFscmVhZHkgYmVlbiBpbXBsZW1lbnRlZCBhcyBhIHBsdWdpbiBmb3INCj4+Pj4gc3Ryb25nU3dh biAoSVBTZWMgaW1wbGVtZW50YXRpb24gZm9yIHRoZSBMaW51eCBrZXJuZWwpDQo+Pj4+DQo+Pj4+ DQo+Pj4+aHR0cHM6Ly9naXRodWIuY29tL3N0cm9uZ3N3YW4vc3Ryb25nc3dhbi90cmVlL21hc3Rl ci9zcmMvbGlic3Ryb25nc3dhbi8NCj4+Pj5wDQo+Pj4+bA0KPj4+PnVnaW5zL25ld2hvcGUNCj4+ Pj4NCj4+Pj4gU28gd2h5IGRvIHdlIG5vdCBzdGFydCB3aXRoIGEgZHJhZnQgZm9yIHdoaWNoIHRo ZSBhYm92ZSBpbXBsZW1lbnRhdGlvbg0KPj4+PmNhbg0KPj4+PiBzZXJ2ZSBhcyBhIHJlZmVyZW5j ZSBpbXBsZW1lbnRhdGlvbj8NCj4+Pg0KPj4+V2h5IHNob3VsZCB3ZSBwcmVlbXB0IHRoZSBjdXJy ZW50IE5JU1QgcG9zdHF1YW50dW0gc3RhbmRhcmRpemF0aW9uDQo+Pj5lZmZvcnRzPw0KPj4+Pg0K Pj4+PiBLaW5kIHJlZ2FyZHMsDQo+Pj4+IEJlbmphbWluDQo+Pj4+DQo+Pj4+DQo+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IENmcmcgbWFp bGluZyBsaXN0DQo+Pj4+IENmcmdAaXJ0Zi5vcmcNCj4+Pj4gDQo+aHR0cHM6Ly93d3cuaXJ0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jZnJnDQo+PGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4v bGlzdGluZm8vY2ZyZz4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pi0tDQo+Pj4iTWFuIGlzIGJvcm4gZnJl ZSwgYnV0IGV2ZXJ5d2hlcmUgaGUgaXMgaW4gY2hhaW5zIi4NCj4+Pi0tUm91c3NlYXUuDQo+Pj4N Cj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5D ZnJnIG1haWxpbmcgbGlzdA0KPj4+Q2ZyZ0BpcnRmLm9yZw0KPj4+aHR0cHM6Ly93d3cuaXJ0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jZnJnDQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Q2ZyZyBtYWlsaW5nIGxpc3QNCj5DZnJnQGlydGYu b3JnDQo+aHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZnJnDQo+DQo+DQo+ DQo+DQo+DQo+DQo+DQoNCg== From nobody Wed Mar 22 13:47:57 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC20812778D for ; Wed, 22 Mar 2017 13:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAuOy3ibhjGx for ; Wed, 22 Mar 2017 13:47:54 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31AB6128BBB for ; Wed, 22 Mar 2017 13:47:54 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id g2so112151134pge.3 for ; Wed, 22 Mar 2017 13:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OnDY52H5VCWQL1vF0HLjux/fC3bwnGSyyh0Fse5T1wI=; b=mnLU7/fj5bF4vHjkMaO808OKmnABsdVgrc1nXFGvRfjuXMDNuvqv36VHTUUELn96NE W3TF4nRJjGhosfI9tn7dfiOIfZz8OYwGybNb+1E2xnEnyxPPFvHbnAskoGAAmN75aQZj RFyny+eOYdfh2UPnHmTkwUfZ+ajmJEuCEml+hbg8kl1+eERVtEFUiiMUsmLmwz2X6lqS AmzJ7k1OTpm/VA7ZiQG0RCxAs4zjBaKX7BsbmAO8diq4+FWHKO/ihSuuoqv7MqF0JF1r hbtgKAnGQr02xpzBkmHYDXkyNi0v9VdC8HKI6EeOyeH6nfhwxYejqry0GaaBcO4Jbgd1 TOlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OnDY52H5VCWQL1vF0HLjux/fC3bwnGSyyh0Fse5T1wI=; b=JeGcSbsNkrsuh6M+4HyUm2sJsuHh1VbmhiXKOABWeO0ChDfuHl+0gjOGN03GHv5t9Z Ige/QKx9l4DMHlncSmevo44JiIMIkGPItfngwJp3TpCvLthdSKiOWXVwMnND8SgHhohF JYAui5pKQYl8xaAIFwWxlKKyDCMx5gSI02CZ5cASEipPIGAPHcW7gxcH73hWwo+Juija yOUYCIzkd2XA3pPcl/qc/WXFbYABf9NjxFucU/C9EaENKxVcO/jJ43XU9sawptbx6RpF EEWM3xQlJfJ70fFD/mBMADcNGjjmPpIoG9aY/ncYBvLqpFb1bi/Rm/uC51BzXs9cXToW 9xpQ== X-Gm-Message-State: AFeK/H1s6wTQY6cNEf0uEw9ihl5geaPIa804AvyCaMxIkpzPlz4odLeS94S1M0apljIK+cs/1rAPUoX+PV2NDg== X-Received: by 10.99.247.83 with SMTP id f19mr12789152pgk.158.1490215673808; Wed, 22 Mar 2017 13:47:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.178.234 with HTTP; Wed, 22 Mar 2017 13:47:33 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Wed, 22 Mar 2017 13:47:33 -0700 Message-ID: To: Phillip Hallam-Baker Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a114c325ce04dec054b57df9a Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:47:56 -0000 --001a114c325ce04dec054b57df9a Content-Type: text/plain; charset=UTF-8 On Tue, Mar 21, 2017 at 9:00 PM, Phillip Hallam-Baker wrote: > You can do hierarchical key derivation in Montgomery without the need for > an add. > > Say your master key is x. To generate a key for site 'example.com' we > take > > xs = (x + H('example.com')) mod q > > Where q is the sub group order. > > In fact that isn't really using any EC relevant operation at all. Perhaps > I am not understanding the full requirements for the scheme. > One of the goals of the scheme is unlinkability: given a set of candidate keys, some of which are children of the same parent key, and others randomly generated, an attacker should not be able to do better than chance in determining which keys in the candidate set have the same parents. For example, Tor hidden services will be identified by constantly rotating "epoch keys". To find the "epoch key" for a given hidden service, a user in possession of the parent public key derives a child key offline from the parent key. However, it'd be undesirable for someone not in possession of the parent key to be able to link the child epoch keys together and enumerate hidden services without knowledge of their parent public keys. In your scheme, given z=H("example.com"), and a parent key xG, the derived child key would be (x+z)G. To recover the original parent public key, you can simply subtract out zG and recover xG. To prevent this from happening we need to use an operation which is not easily reversible, hence multiplication -- Tony Arcieri --001a114c325ce04dec054b57df9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 21, 2017 at 9:00 PM, Phillip Hallam-Baker <phill@hallambaker.c= om> wrote:
You can do hierarchical key derivation in M= ontgomery without the need for an add.
=
Say your master key is x. To gener= ate a key for site 'ex= ample.com' we take=C2=A0

xs =3D (x + H('example.com')) mod q

Where q is the s= ub group order.

In fact that isn't really using any EC relevant opera= tion at all. Perhaps I am not understanding the full requirements for the s= cheme.

One of the goals of the = scheme is unlinkability: given a set of candidate keys, some of which are c= hildren of the same parent key, and others randomly generated, an attacker = should not be able to do better than chance in determining which keys in th= e candidate set have the same parents.

For example= , Tor hidden services will be identified by constantly rotating "epoch= keys". To find the "epoch key" for a given hidden service, = a user in possession of the parent public key derives a child key offline f= rom the parent key. However, it'd be undesirable for someone not in pos= session of the parent key to be able to link the child epoch keys together = and enumerate hidden services without knowledge of their parent public keys= .

In your scheme, given z=3DH("example.com"), and a parent key xG, the de= rived child key would be (x+z)G. To recover the original parent public key,= you can simply subtract out zG and recover xG. To prevent this from happen= ing we need to use an operation which is not easily reversible, hence multi= plication

--
Tony Arcieri
--001a114c325ce04dec054b57df9a-- From nobody Wed Mar 22 14:40:50 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CF7129464 for ; Wed, 22 Mar 2017 14:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nadim.computer Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIz0MttH1ObH for ; Wed, 22 Mar 2017 14:40:46 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4181293D6 for ; Wed, 22 Mar 2017 14:40:45 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id t189so48968154wmt.1 for ; Wed, 22 Mar 2017 14:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nadim.computer; s=mail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fvidga30TJuvZ9mhUGV8Rs3LymYXoXKHyyOYlOuts4k=; b=cGxBfVkq1LHYAM4sjCELiuYm9U/1TASZ117GpXjV3SzW4WaiduwxplFdtYU+aethzG qQMDjk6Zzy5XWBG00ENz0cnNI/Ssa7dGYAXR1pEPadXeDXHE/yvbETUO4jpFwFG5A24r WoQKoWirDICMvnZNzQV92Ew+FnOErmRzFvex4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fvidga30TJuvZ9mhUGV8Rs3LymYXoXKHyyOYlOuts4k=; b=WrQ4XDZVtueHIj4RkMfW/CCotaIXeTh9PvvfagZYAzmGOGMPTdCqdaF2ZM38lTJKGQ oFvlNVlf3gGbxk/MOMNPujkvnmwUS7j1VidvFDDeilvWyVO9XRsHBvldETefrXTdhGgb mVdPgY0jN6YCIBKN86D2JTyV6d94HNzcZ0BOT3OB69sGOGe+/VOMxoE7Az2zhIkdg8p+ gkygiiei8iAPw4a826jK6sAP7M/UA7PDIXvMdOvwY5W8SFWAcxvqh42YXdWFWLv9GsXc 2gysuXmQs8nsmktNAqViq5k0mVvf5h3zme2mEHfQwKMeOxrGt7thICUnrO0+hNhrQFh8 iziw== X-Gm-Message-State: AFeK/H2fQPFAgwnmAw/3X/mSQIhLUe+X7cgP1i3Ke6UeKNGRePLoXrd6Q5OIYS9BhIL6Ug== X-Received: by 10.28.47.15 with SMTP id v15mr9950442wmv.116.1490218844322; Wed, 22 Mar 2017 14:40:44 -0700 (PDT) Received: from [192.168.0.11] (89-156-80-177.rev.numericable.fr. [89.156.80.177]) by smtp.gmail.com with ESMTPSA id b91sm3307661wrd.29.2017.03.22.14.40.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 14:40:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Nadim Kobeissi In-Reply-To: Date: Wed, 22 Mar 2017 22:40:42 +0100 Cc: Phillip Hallam-Baker , "cfrg@irtf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tony Arcieri X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 21:40:48 -0000 > On Mar 22, 2017, at 9:47 PM, Tony Arcieri wrote: >=20 > On Tue, Mar 21, 2017 at 9:00 PM, Phillip Hallam-Baker = wrote: > You can do hierarchical key derivation in Montgomery without the need = for an add. >=20 > Say your master key is x. To generate a key for site 'example.com' we = take=20 >=20 > xs =3D (x + H('example.com')) mod q >=20 > Where q is the sub group order. >=20 > In fact that isn't really using any EC relevant operation at all. = Perhaps I am not understanding the full requirements for the scheme. >=20 > One of the goals of the scheme is unlinkability: given a set of = candidate keys, some of which are children of the same parent key, and = others randomly generated, an attacker should not be able to do better = than chance in determining which keys in the candidate set have the same = parents. =46rom a potentially na=C3=AFve reading of this thread, it sounds like = the HKDF construction (the one proposed by Hugo Krawczyk and used by = Signal and TLS 1.3, among others) satisfies all of the properties = requested by =E2=80=9Chierarchical key derivation=E2=80=9D systems. Is = this right or am I missing something? Thanks, Nadim >=20 > For example, Tor hidden services will be identified by constantly = rotating "epoch keys". To find the "epoch key" for a given hidden = service, a user in possession of the parent public key derives a child = key offline from the parent key. However, it'd be undesirable for = someone not in possession of the parent key to be able to link the child = epoch keys together and enumerate hidden services without knowledge of = their parent public keys. >=20 > In your scheme, given z=3DH("example.com"), and a parent key xG, the = derived child key would be (x+z)G. To recover the original parent public = key, you can simply subtract out zG and recover xG. To prevent this from = happening we need to use an operation which is not easily reversible, = hence multiplication >=20 > --=20 > Tony Arcieri > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Wed Mar 22 14:46:42 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CFF129468 for ; Wed, 22 Mar 2017 14:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65NdJv4kYJ-a for ; Wed, 22 Mar 2017 14:46:40 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54D3126C0F for ; Wed, 22 Mar 2017 14:46:39 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id 20so48931949pfk.2 for ; Wed, 22 Mar 2017 14:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S88PH2FXHDVmvGZZ3o0uIYY2VXaPx11M8aJ4Daiy/OA=; b=Fnt/2iNbIyEZAhSgQ7eJUaJMgfKHP2ZaV8BLYyoGY4w+3Red8ahjyczi5NyidvFz9Z AqXqiSVLFyeULBeRKgz4mVB5BVvaMm2CvVIhRKtHVfKmBlO6ZePc4aSffWSwTHBCkyyZ +6lu5jgTO1ShiKNnu15A+h65GGUNHtc1sZ9cALiiji9JhIgsvc43rrYZNHQxKDn6UGIw i06p4/+2MfSTVng65Y9fsaCerNO0t/Flc12hoX5aQmVbUUfmjZewtNloVd2wzmi6jyg7 uqOFBakcbgn4EWIf6veMKetu7PqmuChaPHA+BDKe2YpKkThmQYMjIe6JM7fj0wBSImdQ jsJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S88PH2FXHDVmvGZZ3o0uIYY2VXaPx11M8aJ4Daiy/OA=; b=eLt1mqFpjIoy2BcpeyRgqa1+j0XGFKszZynkWu2oXCLtm6tFv+x24UQ11x0So2+ypO BV42YJthHlEVLgWSnY2NZCUckQKEkipCQYNUgpAdR1KgjUyn4bVbhLY9fvxI6LI0inOY WNPh8pbujd3fN5zoZ9NYmsrwcpHxQBMtyxmCWFCMtlm3NnIEXxG/Gd39LYP7RG8aAZTZ yTyJwIEOqQ7SgW4ojIFGoHR+aq4+H1oO9h52+fPB++ScAUeqqnExomEIkDMGIFPADu8P dS95nx6KIJq8KnEGFzW2ljEimRuwKWOq0QgGTZJodqkAf7kkCufweWJhhNtTR51WIT3W bkgQ== X-Gm-Message-State: AFeK/H15u4p8bA2LWPrk9B0HweuvoitP9fiEBI+PUii1ENNNxQn3+dGm1vWPFYtjBbS1lRUK2jpCV5ael+8Hww== X-Received: by 10.99.227.69 with SMTP id o5mr4770090pgj.133.1490219199539; Wed, 22 Mar 2017 14:46:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.178.234 with HTTP; Wed, 22 Mar 2017 14:46:19 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Wed, 22 Mar 2017 14:46:19 -0700 Message-ID: To: Nadim Kobeissi Cc: Phillip Hallam-Baker , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a114ade6a06b0f3054b58b2d7 Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 21:46:41 -0000 --001a114ade6a06b0f3054b58b2d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 22, 2017 at 2:40 PM, Nadim Kobeissi wrote: > From a potentially na=C3=AFve reading of this thread, it sounds like the = HKDF > construction (the one proposed by Hugo Krawczyk and used by Signal and TL= S > 1.3, among others) satisfies all of the properties requested by > =E2=80=9Chierarchical key derivation=E2=80=9D systems. Is this right or a= m I missing > something? HKDF is a symmetric construction. This scheme provides hierarchical / blinded keys for the Ed25519 digital signature algorithm. Someone holding the master public key for e.g. a Tor hidden service should be able to calculate the child public keys for each epic from the parent public key, but should not be able to produce digital signatures under any key (because they do not know any of the associated scalar values). --=20 Tony Arcieri --001a114ade6a06b0f3054b58b2d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 22, 2017 at 2:40 PM, Nadim Kobeissi <nadim@nadim.computer= > wrote:
From a potentially na= =C3=AFve reading of this thread, it sounds like the HKDF construction (the = one proposed by Hugo Krawczyk and used by Signal and TLS 1.3, among others)= satisfies all of the properties requested by =E2=80=9Chierarchical key der= ivation=E2=80=9D systems. Is this right or am I missing something?

HKDF is a symmetric construction. This scheme provi= des hierarchical / blinded keys for the Ed25519 digital signature algorithm= .

Someone holding the master public key for e.g. a= Tor hidden service should be able to calculate the child public keys for e= ach epic from the parent public key, but should not be able to produce digi= tal signatures under any key (because they do not know any of the associate= d scalar values).

--
Tony Arcieri
--001a114ade6a06b0f3054b58b2d7-- From nobody Wed Mar 22 14:53:57 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0171289B0 for ; Wed, 22 Mar 2017 14:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBND-oflIwVk for ; Wed, 22 Mar 2017 14:53:50 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC0E1294B5 for ; Wed, 22 Mar 2017 14:53:35 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id w81so55902070oig.1 for ; Wed, 22 Mar 2017 14:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MfXBcXyYng3HGGIMAFEGY0xjCfEanLWz5XaiwlcrPxE=; b=nhLWfWoZwukt/CNPpz+7HHm5UeZhqEja7OkACfLaYqj8oph1LKFJasWv+1B3UxM+JK hzkNsplRgMnBL6+KQMcFcro9NydBD8y/uGK46IHNpC9rd1TZGj02jTkwhsw0kcpJmkuN ecQ61PzixYZlZphgXhI5hPK4McGLx09/85wCEKEKcojfg4TKST0NXOLDYtZA6kYqA+Yc Ds7IWDwpUEK0Rvem4na1DmND6YEAevmax4P2xYWxQZ166+w4loKwToO7XYx1HJ4GNuNe gHEidJRSUyyf/hVX3DWdcCZNAOiLrG1XIJV8uT4D47dTZAIUn2/r0sIXltAK2Jf46IuZ 7HUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MfXBcXyYng3HGGIMAFEGY0xjCfEanLWz5XaiwlcrPxE=; b=HQuJB60jOEfreaLzkBR5eV5M/jk5ghXJtxy1rqJ9Ty3alaayo1zmFbQMUTB3MsnBTN C9G3y7f209y1PvBxaHnUN9hWnJkQ4keYyY8PDeGxh4fOO0iBnjvzAjOw0KekoCSqDze5 I5bW1fEjxy2O+H/mDsNllY2SKfccJ9SLFLlEibn8zKho29Gjod/N32JVQkhUFdGwwBBZ /KWg3It4FNBJaDAtd6hW+JqKtuTMWC+J+i8NgvzYqsfBBesdCctAZC/ZlXYFWvRn2DxS lA0HxY8xIEsKAG/5agi9gUaG8KWq/TwS+C5I+oRznzbGpJnvwV/KtpzMf4D7qa9UePAr 9UhA== X-Gm-Message-State: AFeK/H15CdwgEChEpCaFKWrNna7LBKByXdDjuEPftlr16BYKAzKL8MOLV3H6A1EEF/T/rxeUYEaKBRz3ARkDKA== X-Received: by 10.202.63.85 with SMTP id m82mr23419150oia.151.1490219614882; Wed, 22 Mar 2017 14:53:34 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.46.138 with HTTP; Wed, 22 Mar 2017 14:53:34 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 22 Mar 2017 17:53:34 -0400 X-Google-Sender-Auth: 8GpQJh7J1fF0K6sBUv5ittKdvFE Message-ID: To: Tony Arcieri Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a113dd492c85493054b58caf9 Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 21:53:54 -0000 --001a113dd492c85493054b58caf9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 22, 2017 at 4:47 PM, Tony Arcieri wrote: > On Tue, Mar 21, 2017 at 9:00 PM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> You can do hierarchical key derivation in Montgomery without the need fo= r >> an add. >> >> Say your master key is x. To generate a key for site 'example.com' we >> take >> >> xs =3D (x + H('example.com')) mod q >> >> Where q is the sub group order. >> >> In fact that isn't really using any EC relevant operation at all. Perhap= s >> I am not understanding the full requirements for the scheme. >> > > One of the goals of the scheme is unlinkability: given a set of candidate > keys, some of which are children of the same parent key, and others > randomly generated, an attacker should not be able to do better than chan= ce > in determining which keys in the candidate set have the same parents. > > For example, Tor hidden services will be identified by constantly rotatin= g > "epoch keys". To find the "epoch key" for a given hidden service, a user = in > possession of the parent public key derives a child key offline from the > parent key. However, it'd be undesirable for someone not in possession of > the parent key to be able to link the child epoch keys together and > enumerate hidden services without knowledge of their parent public keys. > > In your scheme, given z=3DH("example.com"), and a parent key xG, the > derived child key would be (x+z)G. To recover the original parent public > key, you can simply subtract out zG and recover xG. To prevent this from > happening we need to use an operation which is not easily reversible, hen= ce > multiplication > > That is the case if you disclose x.G. But why would you do that? You could also do: =E2=80=8Bxs =3D ( H(x + 'example.com')) mod q Which is more robust. --001a113dd492c85493054b58caf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Ma= r 22, 2017 at 4:47 PM, Tony Arcieri <bascule@gmail.com> wrot= e:
= On Tue, Mar 21, 2017 at 9:00 PM, Phillip Hallam-Baker <= ;phill@hallambak= er.com> wrote:
You can do hierarchi= cal key derivation in Montgomery without the need for an add.

Say your ma= ster key is x. To generate a key for site 'example.com' we take=C2=A0

xs =3D (x + H(= 9;example.com')) m= od q

Where q is the sub group order.
=
In fact that isn't really usin= g any EC relevant operation at all. Perhaps I am not understanding the full= requirements for the scheme.

One of the goals of the scheme is unlinkability: given a set of candi= date keys, some of which are children of the same parent key, and others ra= ndomly generated, an attacker should not be able to do better than chance i= n determining which keys in the candidate set have the same parents.
<= div>
For example, Tor hidden services will be identified by c= onstantly rotating "epoch keys". To find the "epoch key"= ; for a given hidden service, a user in possession of the parent public key= derives a child key offline from the parent key. However, it'd be unde= sirable for someone not in possession of the parent key to be able to link = the child epoch keys together and enumerate hidden services without knowled= ge of their parent public keys.

In your sche= me, given z=3DH("exam= ple.com"), and a parent key xG, the derived child key would be (x+= z)G. To recover the original parent public key, you can simply subtract out= zG and recover xG. To prevent this from happening we need to use an operat= ion which is not easily reversible, hence multiplication


That is the case if you disclose x.G. But why would you do = that?

You could also do:<= /div>

=E2=80=8Bxs =3D ( H(x + &= #39;example.com')= ) mod q

Which is more rob= ust.
--001a113dd492c85493054b58caf9-- From nobody Wed Mar 22 15:06:52 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7201298A3 for ; Wed, 22 Mar 2017 15:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4aa5m-POeD1 for ; Wed, 22 Mar 2017 15:06:46 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD14E129430 for ; Wed, 22 Mar 2017 15:06:45 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id 20so49067160pfk.2 for ; Wed, 22 Mar 2017 15:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eb0Ry3iHog3kzkdKH9iMkkplwQxPl3e/KwhAmtcHT58=; b=Up3uw0GqQwAQYQLybOeXlaBC+5/VQT0dHRrJwL3yxRD+hrZnFrwBV0urCVu9GWSLbn jsGqAQPOHHh0CWG96xap3JMLlwg05SEH6eTeOCRjc6UT68g2kj3egRwHjalgHxOu5YqZ 4UP3lzkrWW2WTCMUOgc188mh4aNSgFoRae8nipu4oz4iTanXqjCrZfybsVzWqVi9CjTQ RULsl1ElgZtqYtUlOP7sSWug7qwURj54ML4EX3yCCY7PbfcxwlNt0s6ytZfHir9YuYBQ CR95Aho1kqp1U6JiG+XaUaBe3T0Hmdkmf9vfs4ZuYnGazufaYL7QBr65Ep1X5WuDZYwu /Riw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eb0Ry3iHog3kzkdKH9iMkkplwQxPl3e/KwhAmtcHT58=; b=euNwR0IB9KrcQzVUA7Ga2exSbBqi50blYxgaIqWpNDEsRgfLZ4Sly2AxDymABv4Zy0 2FisnAcVOMLx6nD14WMfBCFKZcVIodZuEoFDOH19LnT8mGPnlC/ffCVISvQ36shBZ9EY qnC7v5PJuh5ris2qAGULE9BKM3ZRxGdv6myhgOikdn72rHGHsFGCDIiFUf7B8ki/8ppU QyRpbmniGGx1rpMPTh/hS3GHFansdmJPdI4Ca0kJY020WGwpPYK1LlKZgqNToR0G7ESh ekqDAWMSfQNMusmBRouy/v/biuJREaESY3mfdEdfk/aUq9MQ/EIzv79wKLP0/5gP5khG v8dw== X-Gm-Message-State: AFeK/H0Dk+CK5krhp/yllPvc3v+Sjhre4HpkKDkIYERjBqCg4EJOOLXmGfeb+Bcbd5OKSqWHTocx6dKVjUnKQA== X-Received: by 10.98.23.202 with SMTP id 193mr48248684pfx.141.1490220405391; Wed, 22 Mar 2017 15:06:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.178.234 with HTTP; Wed, 22 Mar 2017 15:06:24 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Wed, 22 Mar 2017 15:06:24 -0700 Message-ID: To: Phillip Hallam-Baker Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=94eb2c03d062e68929054b58f92a Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:06:48 -0000 --94eb2c03d062e68929054b58f92a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 22, 2017 at 2:53 PM, Phillip Hallam-Baker wrote: > In your scheme, given z=3DH("example.com"), and a parent key xG, the >> derived child key would be (x+z)G. To recover the original parent public >> key, you can simply subtract out zG and recover xG. To prevent this from >> happening we need to use an operation which is not easily reversible, he= nce >> multiplication >> >> > That is the case if you disclose x.G. But why would you do that? > xG can be recovered if you know (x+z)G and the "example.com" string, which is the problem. xG cannot be recovered if you know (x*z)G and the "example.com" string, which is the desirable unlinkability property. You could also do: > > =E2=80=8Bxs =3D ( H(x + 'example.com')) mod q > This requires knowledge of the parent scalar to derive child keys. One of the goals of a scheme like this is to allow a holder of a master public key to derive child public keys without any knowledge of secret scalars. --=20 Tony Arcieri --94eb2c03d062e68929054b58f92a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 22, 2017 at 2:53 PM, Phillip Hallam-Baker <phill@hallambaker.c= om> wrote:
In your scheme, given z=3DH("example.com"), and a parent key xG, = the derived child key would be (x+z)G. To recover the original parent publi= c key, you can simply subtract out zG and recover xG. To prevent this from = happening we need to use an operation which is not easily reversible, hence= multiplication
=
=C2=A0
= That is the case if you disclose x.G. But why would you do that?

xG can be recovered if you kn= ow (x+z)G and the "example.com"= ; string, which is the problem.

xG cannot be recov= ered if you know (x*z)G and the "exampl= e.com" string, which is the desirable unlinkability property.

= You could also do:

=E2=80=8Bxs =3D ( H(x + 'example.com')) mod q
=

This requires knowledge of the paren= t scalar to derive child keys. One of the goals of a scheme like this is to= allow a holder of a master public key to derive child public keys without = any knowledge of secret scalars.

--
Tony Arcieri
--94eb2c03d062e68929054b58f92a-- From nobody Wed Mar 22 15:17:05 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A09F128CFF for ; Wed, 22 Mar 2017 15:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZorhvlZfvzk for ; Wed, 22 Mar 2017 15:17:01 -0700 (PDT) Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB8F12949F for ; Wed, 22 Mar 2017 15:17:01 -0700 (PDT) Received: by jupiter.mumble.net (Postfix, from userid 1014) id C9464605C4; Wed, 22 Mar 2017 22:16:27 +0000 (UTC) From: Taylor R Campbell To: Tony Arcieri CC: cfrg@irtf.org In-reply-to: (bascule@gmail.com) Date: Wed, 22 Mar 2017 22:16:59 +0000 Sender: Taylor R Campbell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <20170322221627.C9464605C4@jupiter.mumble.net> Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:17:03 -0000 > Date: Tue, 21 Mar 2017 12:42:10 -0700 > From: Tony Arcieri >=20 > Hierarchical key derivation (also sometimes described as "semiprivate key= s" > or "key blinding") is an increasingly popular technique for generating > unlinkable child keys from master public and private keys. > > [...] >=20 > I'd be curious to know if anyone else would be interested in collaborating > on a draft for such a standard, which can be a synthesis of the existing > work in this space. This sounds like a good idea, because (a) it's mostly straightforward to invent a scheme in terms of, e.g., EdDSA, that basically works, but (b) there are some little details that need to be nailed down. Here's a quick summary for signatures. First, for reference, standard signatures have three operations -- keygen, sign, and verify: priv, pub <- keygen(seed) sig <- sign(priv, msg) ok <- verify(pub, sig, msg) Security contract: If seed is uniform random, then: Attacker knowing pub with oracle for msg |---> sign(priv, msg) can't find sig for which verify(pub, sig, msg) passes if msg not given to oracle. (Maybe attacker can find novel signatures for messages already signed -- malleability is a story for another day. Quantifying cost left as an exercise for the reader.) Blinded-key signatures, or perhaps `1-level hierarchical signatures', have five operations, with a natural extension to multi-level schemes: priv, pub <- keygen(seed) tpriv <- blindpriv(priv, tweak) tpub <- blindpub(pub, tweak) sig <- sign(tpriv, msg) ok <- verify(tpub, sig, msg) Security contract: If seed is uniform random, then: (a) Attacker knowing pub with oracle for (tweak, msg) |---> sign(blindpriv(priv, tweak), msg) can't find sig for which verify(blindpub(pub, tweak), sig, msg) passes for any (tweak, msg) not given to oracle. (Again, malleability is another story.) (b) Attacker with oracle for tweak |---> blindpub(pub, tweak) can't distinguish tpub from any other tpub' derived from independent uniform random seed' for any tweak not given to oracle. Example of standard signatures: EdDSA on twisted Edwards curve E(F_q) over (b - 1)-bit prime field F_q with base point B of n-bit order l, cofactor 2^c (c < n <=3D b), and 2b-bit hash H, ignoring details of encoding *except* for the clamp function: - pub is point A on curve E(F_q); - sig is (R, s) for point R and integer 0 <=3D s < l; - verification equation is 2^c s B =3D 2^c R + 2^c H(R,A,msg) A; - priv =3D seed is opaque b-bit k, a =3D clamp(low b bits of H(k)), A =3D a B, r =3D=3D H(high b bits of H(k), msg) (mod l), R =3D r B, s =3D=3D r + H(R,A,msg) a (mod l); thus, s B =3D r B + H(R,A,msg) a B =3D R + H(R,A,msg) A, as required. `clamp' maps an integer to the form 2^n + k*2^c for k < 2^(n - c) by clearing bits above n, setting bit n, and clearing the low c bits. This is done only so that the private-key-to-public-key map of EdDSA is equivalent to the corresponding map in, e.g. X25519, which demands of secret scalars (a) a fixed position for the high bit, to efficiently evaluate the Montgomery ladder in constant time, and (b) a multiple of the cofactor, to avoid revealing residues of the secret scalar to an attacker who supplies points on a small subgroup. I emphasize clamp because although it is irrelevant to the security of EdDSA as far as I know, it is prescribed by standards and performed by implementations, so we must address it if we want to enable reuse of existing standard EdDSA code. Example of a naive blinded-key variant of EdDSA, say B1-EdDSA, which I am *not* claiming guarantees the security contract but which serves as an illustration for discussion -- Dmitry's paper goes into much more detail about existing schemes and their engineering considerations, and I encourage reading it for anyone who wants more than my quick summary here: - pub is point A on curve E(F_q), - tpub is point A' =3D t A, where t =3D clamp(low b bits of H(A, tweak)) - sig is (R, s) for point R and integer 0 <=3D s < l, - verification equation is 2^c s B =3D 2^c R + 2^c H(R,A,A',msg) A', - priv =3D seed is opaque b-bit k, a =3D clamp(low b bits of H(k)), A =3D a B, tpriv is b-bit scalar a' =3D=3D t a (mod l) together with A' =3D t A =3D = t a B, r =3D=3D H(high b bits of H(k), A', msg) (mod l), R =3D r B, s =3D=3D r + H(R,A,A',msg) a' (mod l); thus, s B =3D r B + H(R,A,A',msg) a' B =3D r B + H(R,A,A',msg) t a B =3D R + H(R,A,A',msg) t A =3D R + H(R,A,A',msg) A', as required. Some convenient properties of this particular construction: - B1-EdDSA-verify(tpub, sig, msg) =3D EdDSA-verify(A', sig, A'||msg). - B1-EdDSA-sign(tpriv, msg) is almost EdDSA-sign with secret scalar a' of message A'||msg, except the EdDSA secret key is the seed k, not the scalar derived from it -- but EdDSA implementations almost certainly have an internal subroutine to compute this nevertheless. - B1-EdDSA-blindpriv(priv, tweak) =3D=3D t a (mod l) is multiplication of public and secret scalars modulo l, which EdDSA implementations are practically guaranteed to already have, perhaps with an additional addend (which can just be set to zero). Some caveats: - B1-EdDSA-blindpub(pub, tweak) =3D t A requires multiplication of a *possibly secret* curve point A by a public scalar. I'm not sure that EdDSA implementations will necessarily have constant-time scalar multiplication of secret curve points, though they probably do. - Some variants I have seen multiply by 2^c (mod l) instead of clearing the low c bits. Other variants clamp (or multiply by 2^c (mod l)) only one of the scalars -- a, t, or a' -- so that in multi-level hierarchical schemes, different-length paths produced by different factorizations of scalars have the same multiplicity of the cofactor. These practical considerations do not -- as far as I know -- affect signature security, but they do affect compatibility. - The security contract did not mention secrecy of the tweak. Is that important for applications? Not for any I know of, but my knowledge is limited. From nobody Wed Mar 22 18:30:57 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46006128AB0 for ; Wed, 22 Mar 2017 18:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIaL38v7xfRH for ; Wed, 22 Mar 2017 18:30:53 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868B312422F for ; Wed, 22 Mar 2017 18:30:53 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id r203so53173318oib.3 for ; Wed, 22 Mar 2017 18:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Mf2R/N8DfR9YZpqtzRBBjJ54B8Dz3uydlMX6dyLmvxA=; b=PWMaQKzTPj2hmY/ZSxv7a2gPLlFJTNw4EIVfLkjw1ZqOp/9Ysm0QFzTM00fQtVCGuW FvK3OVCCwA1Em7IXbV89mRmcU6z1V4wl6KSxM8x7TfHlMaaLv5TWt9C7rrc+hYWfi3vT a6xAfmBOAJk+U6CmptZl8YQuFChWfbLVljFdkStvb0SvHvsj155lalLraxHeWzqyXOaW 0xif6VeAMgjAUlc0du1gFOg7qGXpJSpTMLksXaYJW6wSN0EFY7BQxJPut8G+CoDvxqA4 8W45KRcujRclE2t25opTe7wNZmwCRqsbQD0F71I/XIZe2rVd8O1cVpXtGdjA50e35Ygg jGMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Mf2R/N8DfR9YZpqtzRBBjJ54B8Dz3uydlMX6dyLmvxA=; b=Y00TFaBObaYCKVf2kLFVaWb165SyCcieBWvBkRogRnKDNZnokyxIkHHnIoEXIyMjmD 0L/5amshqWLxiyFCV273qQs6VveVZ9P3JFeUqr4RblV1Z18OgvXYyIqxRS6rxQFzaKiu jWGn9eMDhFae9U61IoxkvddZfmiPSlGCusJjm4yUDPnSNwzpWEN0TQ5SVzVeiRnBUD4f Hx27bQT6KJDlN7biWertq/FQx2gUcye6S1yPsn84MeUgevKP8wH/mIdj8y+rnzKFX8vn Mrno/4y+oV0WiowG9r3Ayd6NiGB2In1ZTb58CVOk/eXGYiu5FZhWBHElN5QKcoPiKxO8 mtrA== X-Gm-Message-State: AFeK/H3lhS1R/INb4GLmjNkxxHY7aP0SBakXjPjoUkU2wLouEHLqTDjZ5cSrwKJRd7DvQaqWlqQA5ROUnJcUXg== X-Received: by 10.202.80.21 with SMTP id e21mr6237522oib.8.1490232652977; Wed, 22 Mar 2017 18:30:52 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.46.138 with HTTP; Wed, 22 Mar 2017 18:30:52 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 22 Mar 2017 21:30:52 -0400 X-Google-Sender-Auth: 00DHckqWTa-eNnrlb177kW4v0QQ Message-ID: To: Tony Arcieri Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a113d8408e9db6f054b5bd327 Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 01:30:55 -0000 --001a113d8408e9db6f054b5bd327 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 22, 2017 at 6:06 PM, Tony Arcieri wrote: > On Wed, Mar 22, 2017 at 2:53 PM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> In your scheme, given z=3DH("example.com"), and a parent key xG, the >>> derived child key would be (x+z)G. To recover the original parent publi= c >>> key, you can simply subtract out zG and recover xG. To prevent this fro= m >>> happening we need to use an operation which is not easily reversible, h= ence >>> multiplication >>> >>> >> That is the case if you disclose x.G. But why would you do that? >> > > xG can be recovered if you know (x+z)G and the "example.com" string, > which is the problem. > > xG cannot be recovered if you know (x*z)G and the "example.com" string, > which is the desirable unlinkability property. > > You could also do: >> >> =E2=80=8Bxs =3D ( H(x + 'example.com')) mod q >> > > This requires knowledge of the parent scalar to derive child keys. One of > the goals of a scheme like this is to allow a holder of a master public k= ey > to derive child public keys without any knowledge of secret scalars. > > =E2=80=8BAh, yes, you would want MAC ('example.com', k) However, g=E2=80=8Boing back to xs =3D x + ( MAC('example.com', k)) mod q You could play some interesting games with this. You could have quasi linkability so that the identifiers are unlikable unless you choose to claim them be revealing the difference between two of the keys. I have no idea what you would want to use it for but you could do it. --001a113d8408e9db6f054b5bd327 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Ma= r 22, 2017 at 6:06 PM, Tony Arcieri <bascule@gmail.com> wrot= e:
= On Wed, Mar 22, 2017 at 2:53 PM, Phillip Hallam-Baker <= ;phill@hallambak= er.com> wrote:
In your scheme, given z=3DH("example.com"), and a par= ent key xG, the derived child key would be (x+z)G. To recover the original = parent public key, you can simply subtract out zG and recover xG. To preven= t this from happening we need to use an operation which is not easily rever= sible, hence multiplication
=C2=A0
That is the case if= you disclose x.G. But why would you do that?

xG can be recovered if you know (x+z)G an= d the "example.com" string, which is the problem.

xG cannot be= recovered if you know (x*z)G and the "example.com" string, which is the desirable unli= nkability property.

You could = also do:

=E2=80=8Bxs =3D ( H(x + 'example.com')) mod q

This requires knowledge of the parent s= calar to derive child keys. One of the goals of a scheme like this is to al= low a holder of a master public key to derive child public keys without any= knowledge of secret scalars.


=E2=80= =8BAh, yes, you would want MAC ('example= .com', k)

However= , g=E2=80=8Boing back to

= xs =3D x + ( MAC('exa= mple.com', k)) mod q

You could play some interesting games with this. You could have qua= si linkability so that the identifiers are unlikable unless you choose to c= laim them be revealing the difference between two of the keys.

I have no idea what you would want to= use it for but you could do it.

--001a113d8408e9db6f054b5bd327-- From nobody Wed Mar 22 21:59:44 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF49129446 for ; Wed, 22 Mar 2017 21:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubn2Cu1Aj9XK for ; Wed, 22 Mar 2017 21:59:40 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA3212943A for ; Wed, 22 Mar 2017 21:59:40 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id o126so100419942pfb.3 for ; Wed, 22 Mar 2017 21:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WSk3okk/tJhHSpD6BPf5qiCOfRsoN53QhxL93xP7dkI=; b=aVn+oVsxLVmP2a6WfwWSDL3n9gGhTXK4llfY6W+Tjyij3h5YDXQZJtRc78bmJl7X3G I9uXY0wP3KeQMzsGeEwxfIMJbSfadwK9pYXmIvi3ZEWJsWB3fx2fiUtJCyntHRiP8J4X IViSNqeVxOOhIaFoXaPlq+h4QD97JHgm7bPH0wVpkBIMQl3/27KK+fPvAS2KSPxWZU8j 4a9HwgoFf/N3B2qPKcnKrZP/FegPwPLS1Jq8TBFNbaqvfz2caJvX+0UFSaE5I+12gtVZ yMc5gwP2/ko7/gxquMH4rUJ//0yZbtVKnaxgpTS9dl5EsipWnf32BYCHKpMPb2uC1veD W1Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WSk3okk/tJhHSpD6BPf5qiCOfRsoN53QhxL93xP7dkI=; b=PQWj0P052OxjZ5PM/KSk7ILi8icBZULo1dEqTxqykFif10C3KDno0O8N07PtEwWpXq Plc8whIuwUxPThl706QRQl37D8ImT2KtajDlD7sX5uYQhPl1biDZRp4oXNVTZxT/L8xv Vx16CbI0cIhqma+vK77dKci0RTdN1YAT3eU8hoSoT1fTdAyS8exoCeVI5scrWI73cb1H Klc9brMHRXo3dK2tIObPVcxsCiLSF6zLZyL6eroD2PIrYB7obaiz3ZFmWszyYjxNU3gi 1BkWQ064/eyos6MV0CCb5gXhIehTbBvM4Q+JpXxE2PzUudO3F+nD5RhvHjZb/hFWTWJA FFBQ== X-Gm-Message-State: AFeK/H0LkayPy1MrqAS1pl1NUNnORauNjydWNKIbW88sVSo083IZIu2cCBQ46pPRo0AdULu7OBBmeez+6T1dvA== X-Received: by 10.98.23.202 with SMTP id 193mr709209pfx.141.1490245179665; Wed, 22 Mar 2017 21:59:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.178.234 with HTTP; Wed, 22 Mar 2017 21:59:19 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Wed, 22 Mar 2017 21:59:19 -0700 Message-ID: To: Phillip Hallam-Baker Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=94eb2c03d0628ff6a3054b5ebe50 Archived-At: Subject: Re: [Cfrg] Interest in an "Ed25519-HD" standard? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 04:59:42 -0000 --94eb2c03d0628ff6a3054b5ebe50 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 22, 2017 at 6:30 PM, Phillip Hallam-Baker wrote: > However, g=E2=80=8Boing back to > > xs =3D x + ( MAC('example.com', k)) mod q > > You could play some interesting games with this. You could have quasi > linkability so that the identifiers are unlikable unless you choose to > claim them be revealing the difference between two of the keys. > In an Ed25519-HD scheme, you can demonstrate two keys are linked by revealing any public key in the hierarchy that links them together. Since the scheme is hierarchical, you can e.g. create sets of keys you wish to demonstrate are linked at any level in the hierarchy that you want without revealing a master/root public key. Instead you can demonstrate some set of keys at some level of the hierarchy are linked. --=20 Tony Arcieri --94eb2c03d0628ff6a3054b5ebe50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 22, 2017 at 6:30 PM, Phillip Hallam-Baker <phill@hallambaker.c= om> wrote:
However, g=E2=80=8Boing back to

xs =3D x + ( MAC('example.com', k)) mod= q

You could play some interesting games with this. You could have qu= asi linkability so that the identifiers are unlikable unless you choose to = claim them be revealing the difference between two of the keys.
=

In an Ed25519-HD scheme, you can demonstrate two keys are linked b= y revealing any public key in the hierarchy that links them together.
=

Since the scheme is hierarchical, you can e.g. create s= ets of keys you wish to demonstrate are linked at any level in the hierarch= y that you want without revealing a master/root public key. Instead you can= demonstrate some set of keys at some level of the hierarchy are linked.

--
Tony Arcieri
--94eb2c03d0628ff6a3054b5ebe50-- From nobody Thu Mar 23 16:38:11 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB88129511 for ; Thu, 23 Mar 2017 16:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2d8vl14EMqRW for ; Thu, 23 Mar 2017 16:38:07 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0084.outbound.protection.outlook.com [104.47.1.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF2D127058 for ; Thu, 23 Mar 2017 16:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0mbsJd2S5BKZSTv8brKctGCXea4FG2S8NSSVFeYqyIY=; b=d7nvjbEkoG/TzmAv79rSiO3SDhtNPDzzRSM6a6pHvM9L3l7xyZeQgNyrGc+VqVht5nvHb5jq4/29s4sqi9s4iYi5B9qa17EOhliCxqqDkm2snVRToGMxEoW57JiXvjMNTT+jQ6T0eGhpA/U1lcnmcOnCWkfW+wIaCtPIwVGuPx0= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1905.eurprd03.prod.outlook.com (10.168.2.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 23:38:03 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0977.021; Thu, 23 Mar 2017 23:38:03 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" Thread-Topic: CFRG meeting at Eurocrypt 2017 Thread-Index: AQHSpC6DxONxfHpoqU6V2XZ42hnkJw== Date: Thu, 23 Mar 2017 23:38:02 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [78.146.59.5] x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1905; 7:0OUmoqDJIXtUlyApIgBX/XNaqjgVzToNyqJs0+fgc1KbRzh+OEXH3IEFRmjP9v5BeOhHn6bQsoY7r2K1o0tNuDNgka0umxPzC6Vvh5PJqf5GMFVdrsBOlq5B+0dp5pvJ1UQCJNtew/MgPQDXYi+4rxsfd7ccDypHeIih2zkM4wwpAz8opkehWainEuKlgZALU7c+js6tP6j+42HkUPp1Ym3sJSVFOxlircICbFxKEQqp7hxDz4qkLz+8rFvB6oeowqkUZs/PZFVcoC7sutwlBmmBzcLdfPxMaQzGaLkViQ/CDpGRmXeV/UPc15ZQDpPZ+WJCp5XgrXTG+9fSPX1UUA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(50854003)(52564003)(66654002)(68196006)(3280700002)(39060400002)(8936002)(83506001)(2351001)(4001350100001)(122556002)(2900100001)(6916009)(25786009)(42882006)(74482002)(5640700003)(6436002)(77096006)(107886003)(110136004)(6246003)(6486002)(38730400002)(66066001)(2906002)(102836003)(1730700003)(6116002)(3660700001)(8676002)(81156014)(81166006)(3846002)(6506006)(5660300001)(4326008)(2501003)(189998001)(36756003)(53936002)(86362001)(561944003)(54356999)(7736002)(6306002)(50986999)(305945005)(54906002)(229853002)(6512007)(99286003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1905; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: a4eb2114-04ed-4ce3-37d3-08d47245a616 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM4PR0301MB1905; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(6072148); SRVR:AM4PR0301MB1905; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1905; x-forefront-prvs: 0255DF69B9 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <473F55EE547AC749A45CE6430E920A93@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 23:38:02.8584 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1905 Archived-At: Subject: Re: [Cfrg] CFRG meeting at Eurocrypt 2017 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 23:38:09 -0000 RGVhciBDRlJHLA0KDQpXZSB3aWxsIGhhdmUgYSBtZWV0aW5nIG9mIENGUkcgYXQgRXVyb2NyeXB0 IDIwMTcgaW4gUGFyaXMuIFRoZSBtZWV0aW5nDQp3aWxsIGJlIG9uIFN1bmRheSAzMHRoIEFwcmls IGZyb20gNHBtIHRvIDZwbSAobG9jYWwgdGltZSkuIFRoZSBtZWV0aW5nDQp3aWxsIGJlIGhlbGQg YXQgdGhlIGZvbGxvd2luZyBhZGRyZXNzOg0KDQpVUE1DIENhbXB1cyBKdXNzaWV1LCA0IHBsYWNl IEp1c3NpZXUsIDc1MDA1IFBhcmlzLCBGcmFuY2UNCg0KDQpUaGUgcHJlY2lzZSByb29tIHdpbGwg YmUgYW5ub3VuY2VkIGNsb3NlciB0byB0aGUgZGF0ZSBvZiB0aGUgZXZlbnQuDQoNCklmIHlvdSBw bGFuIHRvIGF0dGVuZCB0aGUgbWVldGluZywgeW91IG5lZWQgdG8gcmVnaXN0ZXIgdmlhOg0KDQpo dHRwczovL2V1cm9jcnlwdDIwMTcuZGkuZW5zLmZyL3JlZ2lzdHJhdGlvbi5odG1sDQoNCg0KTm90 ZSB0aGF0Og0KDQoxLiBUaGVyZSdzIGFuIG9wdGlvbiBvbiB0aGUgd2Vic2l0ZSB0byByZWdpc3Rl ciBvbmx5IGZvciB0aGUgdmFyaW91cw0Kd29ya3Nob3BzIHRoYXQgYXJlIHJ1bm5pbmcgaW4gcGFy YWxsZWwgb24gdGhlIFN1bmRheSwgcmF0aGVyIHRoYW4gYWxsIG9mDQp0aGUgRXVyb2NyeXB0IGNv bmZlcmVuY2UuIElmIHlvdSB3YW50IHRvIGF0dGVuZCBhbnkgb2YgdGhlIHdvcmtzaG9wcyBpbg0K YWRkaXRpb24gdG8gdGhlIENGUkcgbWVldGluZywgeW91IG5lZWQgdG8gcGF5IHRoZSByZWdpc3Ry YXRpb24gZmVlIG9mDQpVU0QkODAuIFlvdSBjYW4gdGhlbiBnbyB0byBhbnkgb2YgdGhlIFN1bmRh eSB3b3Jrc2hvcHMgYXMgd2VsbCBhcyB0aGUgQ0ZSRw0KbWVldGluZyAtIGFuZCBpdCdzIGEgZ3Jl YXQgbGlzdC4NCg0KMi4gSWYgeW91IHBsYW4gdG8gT05MWSBhdHRlbmQgdGhlIENGUkcgbWVldGlu ZywgYW5kIHdpbGwgbm90IGF0dGVuZCBhbnkgb2YNCnRoZSBvdGhlciB3b3Jrc2hvcHMsIHRoZW4g eW91IGRvIE5PVCBuZWVkIHRvIHJlZ2lzdGVyIG9ubGluZSBhbmQgcGF5IHRoZQ0KZmVlLCBidXQg eW91IE1VU1QgbGV0IG1lIGtub3cgYnkgZS1tYWlsIHRoYXQgeW91IHBsYW4gdG8gYXR0ZW5kIGlu IHRoaXMNCndheSwgc28gd2UgY2FuIGtlZXAgdHJhY2sgb2YgbnVtYmVycy4gKFRoZSBvcmdhbmlz ZXJzIGhhdmUga2luZGx5IGFncmVlZA0KdG8gd2FpdmUgdGhlIGZlZSBmb3IgIkNGUkcgb25seSIg YXR0ZW5kZWVzLikNCg0KMy4gVGhlIGVhcmx5IGJpcmQgcmF0ZSBleHBpcmVzIG9uIE1hcmNoIDMx c3QsIHNvIGdldCByZWdpc3RlcmluZyENCg0KUGxlYXNlIGFsc28gc2VuZCBtZSBhbmQgQWxleGV5 IChvZmYtbGlzdCkgcHJvcG9zYWwgZm9yIHRhbGtzLCB0b3BpY3MgZm9yDQpkaXNjdXNzaW9uIGV0 Yy4gV2Ugd2lsbCBhbm5vdW5jZSBhIHByb2dyYW0gYXMgc29vbiBhcyB3ZSBjYW4uDQoNCk1hbnkg dGhhbmtzLA0KDQpLZW5ueSANCg0K From nobody Sat Mar 25 10:21:11 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A36126CD8 for ; Sat, 25 Mar 2017 10:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2AxF6QOI0ru for ; Sat, 25 Mar 2017 10:21:09 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id E00E1126579 for ; Sat, 25 Mar 2017 10:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1490462468; d=isode.com; s=june2016; i=@isode.com; bh=cPfTsBUJMBdJYoICEvLVZYSk+pbKzW0T5y3Hja/R7VE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=umpqVTgukAwl+iZk0XmPzgSmx2Q0DcNaTluo6dAz/A+uYYxLBbgmHJvmRYLOoO7JmDFJii 4VOJCY9sMrfscTJw9v6W+41x/ziDJg9R6Z2r+gyHglP92JgQN5TeaRujGClG4BkBhWjUJp E/QOXauQ1XkSjR4l9gcGE6jlxXDJnpo=; Received: from [172.20.86.22] (50-203-222-3-static.hfc.comcastbusiness.net [50.203.222.3]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 25 Mar 2017 17:21:07 +0000 To: "cfrg@irtf.org" From: Alexey Melnikov Message-ID: <58D6A719.1070807@isode.com> Date: Sat, 25 Mar 2017 17:21:29 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Archived-At: Subject: [Cfrg] CFRG side meeting on re-keying in Chicago X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 17:21:10 -0000 Dear CRFG participants, While CFRG is not meeting in Chicago, there will be a 1 hour design-type meeting to talk about re-keying. Below is information about this meeting: When: On Thursday, March 30th, 10:30am-11:30am Where: BIANCO room of the meeting hotel (3rd Floor). This is IESG Breakout Room. Should the re-keying discussion finish early, other CFRG related topics may be discussed. If you have a topic, please reply to this email or to me directly. Thank you, Alexey, as a CFRG co-chair. From nobody Sun Mar 26 09:28:54 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FC712961E; Sun, 26 Mar 2017 09:28:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: kenny.paterson@rhul.ac.uk, cfrg@ietf.org, irtf-chair@irtf.org, cfrg-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149054573266.11822.5988812430555150755.idtracker@ietfa.amsl.com> Date: Sun, 26 Mar 2017 09:28:52 -0700 Archived-At: Subject: [Cfrg] cfrg - New Interim Meeting Request X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 16:28:53 -0000 A new interim meeting request has just been submitted by Kenny Paterson. This request requires approval by the IRTF Chair The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2017-cfrg-01 --------------------------------------------------------- Research Group Name: Crypto Forum Session Requester: Kenny Paterson City: Paris Country: FR Session 1: Date: 2017-04-30 Start Time: 16:00 Europe/Paris Duration: 02:00 Remote Participation Information: Remote participation is not supported Agenda Note: --------------------------------------------------------- From nobody Sun Mar 26 09:47:13 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2263412957F; Sun, 26 Mar 2017 09:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOHvDF2mHG7V; Sun, 26 Mar 2017 09:47:08 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30070.outbound.protection.outlook.com [40.107.3.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C94129438; Sun, 26 Mar 2017 09:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+5FmzIR6NANj5qrgoQxoC7wQmChAP0GGNUtYv/l9cGo=; b=mZrjvfzZUYmcZaDyYqN2/0UlHZBsJWAUCd/q0B/X0T/YEACOGEkMX3BKJsVXwYxRj3rWbwrgu6wTQrUcd9l9r3dtzTPkFOz0WSH0xvW1ENHlqIMt7wTiKMMykDCbxWiR3UWbfBSVIMBznBSIbEuWSbqR56o6Y6KfcOBf0RRMIpk= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1907.eurprd03.prod.outlook.com (10.168.3.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Sun, 26 Mar 2017 16:47:06 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0977.021; Sun, 26 Mar 2017 16:47:06 +0000 From: "Paterson, Kenny" To: "irsg@irtf.org" CC: "Eggert, Lars" , Alexey Melnikov , Allison Mankin , "cfrg@irtf.org" Thread-Topic: IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 Thread-Index: AQHSplCaq+TMeSvbmEmNdyOfQ3yIYA== Date: Sun, 26 Mar 2017 16:47:05 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [78.146.59.5] x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:mVWu4GzbEZEfmpL00VT/CG8jwolf5oiMg7f52A9s//bQiWhQ2kNxGzIQHjWbIv4Hk/fLCsF7Qbro74vxfhyGnePfEeu5owqXtlwRvFALcPtleOtTb7wNKKH8K+LULWaPdSO8aEKevFbGO8Uxn6cOXf34G+WNUqEf9PY9U09/bnEomDUw6HGXZ5zlqY8B5n1mBb2GNpvTyOkgme5kl2ilJluxlZkTspzBSvFX15rrz0brNgyfI0YMYxRJm5afVquj4fhHTbGwrNa+QKrZWmG9GcqEcIFAxhAY5/x3Eyf13XvJI72196PHPAQ5in/k4Y0Zc0KaBN5G1KW3qMuv43ENyQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39850400002)(39410400002)(39840400002)(5640700003)(2351001)(2900100001)(122556002)(4001350100001)(54356999)(50986999)(189998001)(305945005)(7736002)(39060400002)(4326008)(6506006)(5660300001)(110136004)(3280700002)(38730400002)(3660700001)(66066001)(2906002)(6512007)(77096006)(99286003)(6306002)(6486002)(54906002)(3846002)(102836003)(6116002)(6916009)(42882006)(2501003)(230783001)(25786009)(53936002)(8936002)(8676002)(68196006)(81166006)(1730700003)(74482002)(36756003)(6436002)(83506001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: cf4240f6-766f-4776-c97c-08d47467bca4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM4PR0301MB1907; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(20161123564025)(6072148); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1907; x-forefront-prvs: 0258E7CCD4 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2017 16:47:05.9300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907 Archived-At: Subject: [Cfrg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 16:47:11 -0000 RGVhciBJUlNHLA0KDQpUaGUgQ0ZSRyBjaGFpcnMgcmVxdWVzdCBhbiBJU1JHIHJldmlldyBvZiB0 aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KDQpYTVNTOiBFeHRlbmRlZCBIYXNoLUJhc2VkIFNpZ25h dHVyZXMNCg0KZHJhZnQtaXJ0Zi1jZnJnLXhtc3MtaGFzaC1iYXNlZC1zaWduYXR1cmVzLTA4DQoN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlydGYtY2ZyZy14bXNzLWhh c2gtYmFzZWQtc2lnbmF0dXJlcw0KLw0KDQoNCkkgcmV2aWV3ZWQgdGhlIHByZXZpb3VzIGRyYWZ0 IG9mIHRoaXMgZG9jdW1lbnQNCihodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2NmcmcvY3VycmVudC9tc2cwOTAyNC5odG1sKQ0KDQpUaGFua3MsDQoNCktlbm55IChmb3IgdGhl IGNoYWlycykNCg0KDQoNCg== From nobody Mon Mar 27 03:46:38 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BE71294D8; Mon, 27 Mar 2017 03:46:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149061159741.30566.11599293166376872082@ietfa.amsl.com> Date: Mon, 27 Mar 2017 03:46:37 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-argon2-02.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 10:46:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum of the IETF. Title : The memory-hard Argon2 password hash and proof-of-work function Authors : Alex Biryukov Daniel Dinu Dmitry Khovratovich Simon Josefsson Filename : draft-irtf-cfrg-argon2-02.txt Pages : 26 Date : 2017-03-27 Abstract: This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer oriented description together with sample code and test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-argon2-02 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-argon2-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 27 03:51:37 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD121294CF for ; Mon, 27 Mar 2017 03:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9Jr_Ziz8zXX for ; Mon, 27 Mar 2017 03:51:33 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A531C12947B for ; Mon, 27 Mar 2017 03:51:33 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id i203so28112480ywc.3 for ; Mon, 27 Mar 2017 03:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=NwuXKerL/S7v5bXrqf16nGtfg7dLgJ9+XU2wKps3NNc=; b=SI9dM/WQOcdy5GzEr+IJW83QGw2CIJeYHXI7DOxEboYUkOIvzOrFP+oTRyE9JWcJgV 7OKMJmj4mgDGC9pXaNKAqOYx6T1V20XqILp7p+01xLwCESRUaxVbs1ceuNKXMYEkBnyT y5wFSmEvTsfWnxIiD9jLZN8ap8oZJCWYRxWo87RnQojhcBkpyF8PewspbeIITdYIPEns 9i1jdKqfUWXlsBFAV3s+GjSNDVUX42UzUZmDS6XUrPth1ihuLboTFSQmMih1aug/ALk/ C2r2QtZsvwoI3Jsg4gbhcihEPh4U8g0A7X3nGzLbm6/POVguNAeHdsPSrQjO/EjE94ex dq5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=NwuXKerL/S7v5bXrqf16nGtfg7dLgJ9+XU2wKps3NNc=; b=ixhNnvI4STqie5MFbpppaN5Fx9PZ8sAAZeuwmCFpw2/T67eIVKcVsz0CqT6jRbbEAI iNXYQsgLnr/rAfr7izU/BqVWjiGXO++hks0pLc662+mOseNyjjOKsnyCxxaUQNEmntu0 H/VopY3dYDcmvp849n6xefvogk6nZNJeQ5M0/DI8Utef2bzjulxPXlBB/UB8h7e4X7Tf 2/JA0YF+z1CraJ4+vLk74HAN3DAcZl+Qck5nvd+jpp+7OhGZnIfs4PC/LfXeX2hZ84Mq lJuVl+CHcKK3AjDLBh3QlxZGiVhC+VaOCHnaKSH/9UE/aEYU6hdTPKFARiPQUAgwQOyH GU6A== X-Gm-Message-State: AFeK/H367hS0A3khXqnuBWM1uxiXy+lpE7JnwH9KUVTEPPzA5NZXCOtkTH81aYCUNZ5bAhQxFFGOvxoyS3f7mA== X-Received: by 10.37.80.208 with SMTP id e199mr15323015ybb.165.1490611892717; Mon, 27 Mar 2017 03:51:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.67.5 with HTTP; Mon, 27 Mar 2017 03:51:17 -0700 (PDT) In-Reply-To: <149061159741.30566.11599293166376872082@ietfa.amsl.com> References: <149061159741.30566.11599293166376872082@ietfa.amsl.com> From: Dmitry Khovratovich Date: Mon, 27 Mar 2017 12:51:17 +0200 Message-ID: Cc: cfrg@ietf.org Content-Type: multipart/alternative; boundary=001a113ea1465d10b2054bb4201b Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-argon2-02.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 10:51:36 -0000 --001a113ea1465d10b2054bb4201b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some comments on a new draft:Variants Argon2 fills M bytes of memory in T iterations over it, with M and T being the parameters supplied to Argon2 and determining its performance. Speed on a typical server is linear in the MT product. The Argon2 family has three variants: I, D, and ID, which differ in the way of reusing memory that has been filled. The I variant makes queries with predictable addresses, whereas D determines the addresses on the fly depending on the current state (and thus the password). The ID variant follows I for the first half of the memory used and D for the rest and while overwriting. Side-channels The side-channel attacks, which are of still rising concern in the security community, are applicable to the D variant as the memory addresses and thus information about the password or other secret inputs can be determined from the timing leaks. The I variant is completely invulnerable to this attack, and the ID variant provides only a constant factor improvement for the attacker. Hardware and tradeoffs The M and T parameters determine the cost of bruteforcing passwords on custom hardware, which is proportional to M2T if we follow the traditional time-area product metric. The time-memory tradeoff analysis [2] shows that the bruteforce cost for the I variant can be changed to M2T/Q(M,T) for some quality function Q. For instance, Q(230,1)=3D5, Q(230,4)=3D2.5. The D variant is invulnerable to the approach [2], and the savings factor in the ID variant is upper bounded by factor 2 for all parameters. Defender tradeoff and ultimate recommendations In public and private conversations with security architects in the industry we learned that the bottleneck in a system employing the password-hashing function is the function latency rather than memory costs. We then assume that a rational defender would like to maximize the bruteforce costs for the attacker equipped with a list of hashes, salts, and timing information, for fixed computing time on the defender=E2=80=99s = machine. In this assumption the defender keeps the MT product constant and maximizes the losses M/Q(M,T). The authors of [2] provides us with attack cost estimates for constant MT =3D 228,230,232 (measured in iteration-bytes) We ultimately recommend the ID variant with T=3D1 and maximum M as a defaul= t setting for all environments, which is secure against side-channel attacks and prohibit adversarial advantage on dedicated bruteforce hardware. References [1] =E2=80=9CEfficiently Computing Data-Independent Memory-Hard Functions= =E2=80=9D [2] =E2=80=9CTowards Practical Attacks on Argon2i and Balloon Hashing=E2=80= =9D On Mon, Mar 27, 2017 at 12:46 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Crypto Forum of the IETF. > > Title : The memory-hard Argon2 password hash and > proof-of-work function > Authors : Alex Biryukov > Daniel Dinu > Dmitry Khovratovich > Simon Josefsson > Filename : draft-irtf-cfrg-argon2-02.txt > Pages : 26 > Date : 2017-03-27 > > Abstract: > This document describes the Argon2 memory-hard function for password > hashing and proof-of-work applications. We provide an implementer > oriented description together with sample code and test vectors. The > purpose is to simplify adoption of Argon2 for Internet protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-irtf-cfrg-argon2-02 > https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-cfrg-argon2-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --=20 Best regards, Dmitry Khovratovich --001a113ea1465d10b2054bb4201b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Some comments on a new draft:<= /font>

Variants

Argon2 fills M bytes of memory in T i= terations over it, with M and T being the parameters supplied to Argon2 and= determining its performance. Speed on a typical server is linear in the MT= product.


The Argon2 family has three variants: I, D, and ID, which dif= fer in the way of reusing memory that has been filled. The I variant makes = queries with predictable addresses, whereas D determines the addresses on t= he fly depending on the current state (and thus the password). The ID varia= nt follows I for the first half of the memory used and D for the rest and w= hile overwriting.

Side-channels

The side-channe= l attacks, which are of still rising concern in the security community, are= applicable to the D variant as the memory addresses and thus information a= bout the password or other secret inputs can be determined from the timing = leaks. The I variant is completely invulnerable to this attack, and the ID = variant provides only a constant factor improvement for the attacker.

Hardware and tradeoffs

The M and T parameters determine the c= ost of bruteforcing passwords on custom hardware, which is proportional to = M2T if we = follow the traditional time-area product metric. The time-memory tradeoff a= nalysis [2] shows that the bruteforce cost for the I variant can be changed= to M2<= /span>T/Q(= M,T) for some quality function Q. For instance, Q(230,1)=3D5, Q(230,4)=3D2.5.


<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:arial;color:rgb(0,0,0);background-= color:transparent;vertical-align:baseline;white-space:pre-wrap">The D varia= nt is invulnerable to the approach [2], and the savings factor in the ID va= riant is upper bounded by factor 2 for all parameters.

= Defender tradeoff and ultimate recommendations

In public and privat= e conversations with security architects in the industry we learned that th= e bottleneck in a system employing the password-hashing function is the fun= ction latency rather than memory costs. We then assume that a rational defe= nder would like to maximize the bruteforce costs for the attacker equipped = with a list of hashes, salts, and timing information, for fi= xed computing time on the defender=E2=80=99s machine.=C2=A0 In this assumption= the defender keeps the MT product constant and maximizes the losses M/Q(M,= T). The authors of [2] provides us with attack cost estimates for constant = MT =3D 228= ,230,232 (measured i= n iteration-bytes)


We ultimately recommend the ID variant with T=3D1 an= d maximum M as a default setting for all environments, which is secure agai= nst side-channel attacks and prohibit adversarial advantage on dedicated br= uteforce hardware.


On Mon, Mar 27, 2017 at 12:46 PM, &= lt;internet-d= rafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Crypto Forum of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The memory-hard Argon2 password hash and proof-of-work function
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Alex= Biryukov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Daniel Dinu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Dmitry Khovratovich
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Simon Josefsson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-irt= f-cfrg-argon2-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 26
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-03-27

Abstract:
=C2=A0 =C2=A0This document describes the Argon2 memory-hard function for pa= ssword
=C2=A0 =C2=A0hashing and proof-of-work applications.=C2=A0 We provide an im= plementer
=C2=A0 =C2=A0oriented description together with sample code and test vector= s.=C2=A0 The
=C2=A0 =C2=A0purpose is to simplify adoption of Argon2 for Internet protoco= ls.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-= irtf-cfrg-argon2/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-irtf-cfr= g-argon2-02
https://datatracker.ietf.org/doc= /html/draft-irtf-cfrg-argon2-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-irtf-cfrg-argon2-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg



--
Best regards,<= /div>
Dmitry Khovratovich
--001a113ea1465d10b2054bb4201b-- From nobody Tue Mar 28 06:46:42 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78101299E3 for ; Tue, 28 Mar 2017 06:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHkXZoYgotgv for ; Tue, 28 Mar 2017 06:46:39 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E7C1299D5 for ; Tue, 28 Mar 2017 06:46:38 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id u1so106239967wra.2 for ; Tue, 28 Mar 2017 06:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=89xBswHVL5hUAoYobIh55jct/ok5/IIOc9WamVA94Sc=; b=Zz5NxPs6FPTsseGE6Uax9q8bGbySA8aW19zEStyHjpMUWNOJpIC0/1akr8CzXrfFZc usgqzaA2He3JNDD985IH/HjRg9Uou7hW19zU4+LiAtHB07fb87WOkn6vHMlHSfStJveN zF8dMVKMtW6j2tb4svBoKxNllmK9caUIDFQqw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=89xBswHVL5hUAoYobIh55jct/ok5/IIOc9WamVA94Sc=; b=ZY8SU6aBHwPpi9WRX5tDGsZeGHzF8RBiIikRoCChAN8Dx4OS91YWf+e/GoSA0wdnvr vqMpBu5DSEOmlay2vG1Gl00cikhA79gNyDiDPafheaNcpKO/RamHsYi7PGNbxxpeKOz0 zM6njwvWcgT2IPw8yre04kHqfFzZw6h49mAsLYNwOLSiH7pW9GT81Brnv7k+X6q/vTFd 1HZDAYSudwr6u/Oycg1igiPSzikTkChhdlx1LVE8l0SnnnZPicdJhpVEdhmQzFMRJ3dE QBygizws8KrCctDsXK1UwO/zbo3vToug11/guXqLtrk3rUgAEGG3ASwFD2nNAcLPIWfz ZQjw== X-Gm-Message-State: AFeK/H2cHA7S4uZLaBclm6PclPQDBsOMVpecMaQu6EP/+c1nfw2Tk4CJf30W935+/KLiJCMFMH9HE1clmy3q+w== X-Received: by 10.223.161.134 with SMTP id u6mr15012263wru.113.1490708796710; Tue, 28 Mar 2017 06:46:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.166.5 with HTTP; Tue, 28 Mar 2017 06:46:16 -0700 (PDT) From: William Whyte Date: Tue, 28 Mar 2017 09:46:16 -0400 Message-ID: To: CFRG Content-Type: multipart/alternative; boundary=f403045f3afa4abe6a054bcab0af Archived-At: Subject: [Cfrg] NTRUEncrypt + enhancements released into the public domain X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 13:46:41 -0000 --f403045f3afa4abe6a054bcab0af Content-Type: text/plain; charset=UTF-8 https://globenewswire.com/news-release/2017/03/28/945815/0/en/Security-Innovation-Makes-NTRUEncrypt-Patent-Free.html William --f403045f3afa4abe6a054bcab0af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
http= s://globenewswire.com/news-release/2017/03/28/945815/0/en/Security-Innovati= on-Makes-NTRUEncrypt-Patent-Free.html

William
--f403045f3afa4abe6a054bcab0af-- From nobody Tue Mar 28 07:47:23 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5344129545 for ; Tue, 28 Mar 2017 07:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgMRJzwMZkfM for ; Tue, 28 Mar 2017 07:47:20 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AFAF1298D3 for ; Tue, 28 Mar 2017 07:47:18 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id z204so90941324vkd.1 for ; Tue, 28 Mar 2017 07:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G1NAcFHfqHPyPn2FVjt02P4GhmttacvcozwMmZtwFQ0=; b=h4iBg3y+rHS5KXpfylL2Ymrf66DzfPxKoOmDVzFr/3cbyd80vHQ05Q+tnAqE9ykAeL BMzAKVkB1pTX+oG9WjXc9E0bENW/l5ikhKyO110Hg+GYjZgPh/8o1o2bU/I3x25E9X0C G7qyYU1+AeOjq+5CmH+1rrW524B91xAdJpwD9OGrZ7CxYK/2ywaQUobKfNrjZA+1+Z1n /0lT4AINwwCAFU8FTELyk2K4IIWR3u+u589rWp2T/7wkpprY07JW2PMB4rIGgVgFWJde 1GcMb51cR46KRO7Uu4tdUvw89MRTiP8b0KqdFsKz8/JmJMe5PfNwcYhLQHSIyJxeMDK4 H8qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G1NAcFHfqHPyPn2FVjt02P4GhmttacvcozwMmZtwFQ0=; b=BhacaS4W6I3bNZtTQ2cUK05x7g7SQfiYkl1G/DsXvvlgr/jJlycInP/fSXi8b0vfAn jCFcfSUra6BqTsgYTMxZ01CSx4BRSAqz2S9NlDu2fcdQTV+7Rl3nDLt8HNKzuljmdUyr HF0jYmrbjdLdCrY0bXWmZDS0a6zSx39Vgdt5F4QKu2MfOVIuWP/JhTp3VAdwwObjEAjZ EyXC3dDymsBBhFdNa63Qxlt0WhvCVp3CKCRZneENRKChp93WALLWlbzqTj5MBfWNhT0e zZeErkd5d+q4c1MzjQUkPSmAfq/rz4PzkQuYTOPSPEJzH31rtm2CnlzMi6KP4xlX5DGT IDPQ== X-Gm-Message-State: AFeK/H1SGSgZQrGflP58foLCC2DRl0zvOmOxpE0BwpC8l2PnDXnfxMrllAsJIN9ZOkW0h8JcinL3UiMftF7xEQNW X-Received: by 10.176.65.196 with SMTP id 62mr4194922uap.82.1490712436896; Tue, 28 Mar 2017 07:47:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.76.86 with HTTP; Tue, 28 Mar 2017 07:47:16 -0700 (PDT) Received: by 10.103.76.86 with HTTP; Tue, 28 Mar 2017 07:47:16 -0700 (PDT) In-Reply-To: References: From: Andy Lutomirski Date: Tue, 28 Mar 2017 07:47:16 -0700 Message-ID: To: William Whyte Cc: CFRG Content-Type: multipart/alternative; boundary=001a114fb3a443e8d4054bcb89d8 Archived-At: Subject: Re: [Cfrg] NTRUEncrypt + enhancements released into the public domain X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 14:47:22 -0000 --001a114fb3a443e8d4054bcb89d8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mar 28, 2017 6:46 AM, "William Whyte" wrote= : https://globenewswire.com/news-release/2017/03/28/945815/0/ en/Security-Innovation-Makes-NTRUEncrypt-Patent-Free.html William This makes no sense. The article says: "We are making the NTRUEncrypt patents available under the Creative Commons CC0 1.0 Universal License. By eliminating NTRUEncrypt patent hurdles, the industry can speed the adoption of quantum-resistant encryption, ensuring that the Internet remains secure long after the emergence of quantum computers," explained Peter Samson, President of OnBoard Security. >From the Creative Commons FAQ: CC0 very clearly states that trademark and patent rights of the affirmer are not affected =E2=80=93 CC0=E2=80=99s sole reach is copyright and relate= d and neighboring rights, including database rights. --001a114fb3a443e8d4054bcb89d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

<= div dir=3D"auto">This makes no sense.=C2=A0 The article says:

"We are making the NTRUEncrypt p= atents available under the Creative Commons CC0 1.0 Universal License. By e= liminating NTRUEncrypt patent hurdles, the industry can speed the adoption = of quantum-resistant encryption, ensuring that the Internet remains secure = long after the emergence of quantum computers," explained Peter Samson= , President of OnBoard Security.=C2=A0

From the Creative Commons FAQ:
CC0 very clearly states that trademark and patent= rights of the affirmer are not affected =E2=80=93 CC0=E2=80=99s sole reach= is copyright and related and neighboring rights, including database rights= .=C2=A0



--001a114fb3a443e8d4054bcb89d8-- From nobody Tue Mar 28 10:32:18 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF4312944B for ; Tue, 28 Mar 2017 10:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwuRv7j_sZsn for ; Tue, 28 Mar 2017 10:32:14 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686DD129704 for ; Tue, 28 Mar 2017 10:32:14 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id t189so4810096wmt.1 for ; Tue, 28 Mar 2017 10:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XGbVcE5ThNObJWzfSAodrrXWKSE+Weer6pO7Am+th8g=; b=CJNxlwUvIqn/Ol5AKoWy7RBAtm6n9d5qXY+BgBxaF5o8St1l1aSfv6lbysIMvNeEAD 3u47KdYJF8M2WtccqNxt4VeFHcFLEZ+7QkRUiaGp1a77nAnvh+Q0OhftdGXDOXuhUU72 4C0aemJIafONZGQMLNihtW/IvsXXYgbtmHxhs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XGbVcE5ThNObJWzfSAodrrXWKSE+Weer6pO7Am+th8g=; b=q4iKxXTlOVGYe5SdMxSSsDE+7CHle1u2+zDSGNXWdJhSTs7rcnwzXC4NdgbifIG+rI xdW1Q6ZKULWWQ3qNqQjjMlvus7mFKR63Gr4g275X0CgSMgbhBmmnKVXLAP8/S0gGc6HE xkfQurB7Bxd2of7mFFu3cW0dAwUpeZewnw0rqG/5BaaZweqgGyD1KoxYTa3oLzQUZkLV GgluRdLx8f3708+as6z+Jx7BD2Uvx4ksyUKGmyKkn2956XoFfCJyTZP1QW7m9D5b8xvR MOFPowOpx7ogkKp2+n/3XBhUQcO6Oz4vIL/MEVbPBnGAnM7cs0dNHrLIW/8nVdpifV90 DARA== X-Gm-Message-State: AFeK/H1SOAiTAfopPkuutM1wrCsGgzbtfjQHNuw8bKc5DcBduSLJ8LSkV2AvfsGAwHradGMyna8dGHs0CoIazw== X-Received: by 10.28.35.151 with SMTP id j145mr15545120wmj.50.1490722332627; Tue, 28 Mar 2017 10:32:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.166.5 with HTTP; Tue, 28 Mar 2017 10:31:51 -0700 (PDT) In-Reply-To: References: From: William Whyte Date: Tue, 28 Mar 2017 13:31:51 -0400 Message-ID: To: Andy Lutomirski Cc: CFRG Content-Type: multipart/alternative; boundary=001a113eaee6187019054bcdd77e Archived-At: Subject: Re: [Cfrg] NTRUEncrypt + enhancements released into the public domain X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 17:32:17 -0000 --001a113eaee6187019054bcdd77e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry for any confusion. The patents are also covered. The LICENSE statement has been updated at https://github.com/NTRUOpenSourceProject/NTRUEncrypt/blob/master/LICENSE as follows: Note that although CC0 1.0 expressly does not cover patents, this license statements encompasses the patents as well as the code. Specifically, Security Innovation and any successor organization with ownership of the specified patents will not take any enforcement action related to use of those patents on or after March 27th, 2017; the specified patents may be freely used with or without also making use of the source code. Cheers, William On Tue, Mar 28, 2017 at 10:47 AM, Andy Lutomirski wrote: > > > On Mar 28, 2017 6:46 AM, "William Whyte" > wrote: > > https://globenewswire.com/news-release/2017/03/28/945815/0/e > n/Security-Innovation-Makes-NTRUEncrypt-Patent-Free.html > > William > > > This makes no sense. The article says: > > "We are making the NTRUEncrypt patents available under the Creative > Commons CC0 1.0 Universal License. By eliminating NTRUEncrypt patent > hurdles, the industry can speed the adoption of quantum-resistant > encryption, ensuring that the Internet remains secure long after the > emergence of quantum computers," explained Peter Samson, President of > OnBoard Security. > > From the Creative Commons FAQ: > > CC0 very clearly states that trademark and patent rights of the affirmer > are not affected =E2=80=93 CC0=E2=80=99s sole reach is copyright and rela= ted and > neighboring rights, including database rights. > > > > --001a113eaee6187019054bcdd77e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for any confusion. The patents are also covered. The= LICENSE statement has been updated at=C2=A0https://github.com/NT= RUOpenSourceProject/NTRUEncrypt/blob/master/LICENSE as follows:

Note that although CC0 1.0 expressly does n= ot cover patents, this license
statements encompasses the patents= as well as the code. Specifically,=C2=A0
Security Innovation and= any successor organization with ownership of the
specified paten= ts will not take any enforcement action related to use of
those p= atents on or after March 27th, 2017; the specified patents may be
freely used with or without also making use of the source code.

Cheers,

William

On Tue, Mar 28, 201= 7 at 10:47 AM, Andy Lutomirski <luto@amacapital.net> wrote= :

This makes no sense.=C2=A0 The article says:

"We are making the NTRUEncrypt patents available= under the Creative Commons CC0 1.0 Universal License. By eliminating NTRUE= ncrypt patent hurdles, the industry can speed the adoption of quantum-resis= tant encryption, ensuring that the Internet remains secure long after the e= mergence of quantum computers," explained Peter Samson, President of O= nBoard Security.=C2=A0

From the Creative Commons FAQ:

CC0 very clearly states that trademark and patent rights of the a= ffirmer are not affected =E2=80=93 CC0=E2=80=99s sole reach is copyright an= d related and neighboring rights, including database rights.=C2=A0


=

--001a113eaee6187019054bcdd77e-- From nobody Wed Mar 29 13:48:07 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8189129982 for ; Wed, 29 Mar 2017 13:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7u4NTHNG-30 for ; Wed, 29 Mar 2017 13:47:51 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5794129991 for ; Wed, 29 Mar 2017 13:47:33 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id r142so24106600qke.2 for ; Wed, 29 Mar 2017 13:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/qrD3X0JJccTe826BOCFv3BoVJDs5unTFS3qVEcnrQM=; b=R/xGJ68c1mPAjEB1une6Fd1top53p0J5lUTYCbBJnY7M//P8BGjK9QzJ07RLbNco5m Rrk72HqFTBrky1diMMXs+xk07NSijnWyWopwgmYlvymlnl4N9ib0bCb6KNwfu2RbwThw X6Te6U+Y4+sHeeCeBhH2AVkjCg+IW+j25f/hgUbutFy93PTSqnCU8SBD5QFxxEVeAiVS x47MGH40LbwxOBQpRdIAOv+IHBgBN6AIXo06Ya8TIBRq76AiCWtdkZjMY0RkBJ30EAfP Y4dKg5b3zDcaVvUSm+TrOifv9u8GdUsECqb11iQZiYTeLzXvplyhQZdrF2efXOFg81xA 1E6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/qrD3X0JJccTe826BOCFv3BoVJDs5unTFS3qVEcnrQM=; b=B4I7aP1+XR5MovnGWhldJ0nIhQ0Vb+8skxkuqmeZikXRqbbItf2ht2ZG8DQiwUqi8J eHSmV10B4bUSuX1Hu9R+5TNPAyIiuev1pO9asKYb1JT39FMbTRNGrYfkOLKTjJBpIs/Z ADbaAW4ZqQEkElXPRxLuSnLdMHsu03NR5ywmEaOAYHAZ5pnNXWCtExmYMK8xZS9MPmoZ PCZiKVu6W1tNBsFl5vwzF7eptAH+AtR2Yo4KJfWAwX9cLIfCQTW3lzXT+ruq0BLPbrQc N1n3wRRjSPllGWk+wcduHqQWqa0szarxKIAmTlTgb7gSnPuWpeQZRanDrFKGU1xSbj10 k8MQ== X-Gm-Message-State: AFeK/H0j/fBH7g5NvMqetaStvvNCEgf5P4gBel2Qki/sQBudB5PyOeCokV40AjfmQeRw5POw+7qIGE3qrJheFw== X-Received: by 10.55.180.70 with SMTP id d67mr2699833qkf.280.1490820452980; Wed, 29 Mar 2017 13:47:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.132.4 with HTTP; Wed, 29 Mar 2017 13:47:32 -0700 (PDT) In-Reply-To: <58D6A719.1070807@isode.com> References: <58D6A719.1070807@isode.com> From: "Stanislav V. Smyshlyaev" Date: Wed, 29 Mar 2017 23:47:32 +0300 Message-ID: To: Alexey Melnikov Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=94eb2c0608d48629e3054be4af8b Archived-At: Subject: Re: [Cfrg] CFRG side meeting on re-keying in Chicago X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 20:47:57 -0000 --94eb2c0608d48629e3054be4af8b Content-Type: text/plain; charset=UTF-8 Dear IETF 98 attendees, Just a reminder that tomorrow (Thursday, 30th of March) at 10:30 we'll have a CFRG side meeting in Bianco room (3rd floor, IESG Breakout room). Please come if you have any considerations or thoughts about the topic of re-keying/key update/KDFs etc. The CFRG document on re-keying is at quite early stage currently, all your opinions and proposals are highly wanted. The current version of the document is the following: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-01. Best regards, Stanislav Smyshlyaev 2017-03-25 20:21 GMT+03:00 Alexey Melnikov : > Dear CRFG participants, > While CFRG is not meeting in Chicago, there will be a 1 hour design-type > meeting to talk about re-keying. Below is information about this meeting: > > When: On Thursday, March 30th, 10:30am-11:30am > > Where: BIANCO room of the meeting hotel (3rd Floor). This is IESG > Breakout Room. > > > Should the re-keying discussion finish early, other CFRG related topics > may be discussed. If you have a topic, please reply to this email or to > me directly. > > Thank you, > Alexey, as a CFRG co-chair. > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --94eb2c0608d48629e3054be4af8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear IETF 98 attendees,=C2=A0

Just a re= minder that tomorrow (Thursday, 30th of March) at 10:30 we'll have a CF= RG side meeting in Bianco room (3rd floor, IESG Breakout room).=C2=A0
=

Please come if you have any considerations or thoughts = about the topic of re-keying/key update/KDFs etc. The CFRG document on re-k= eying is at quite early stage currently, all your opinions and proposals ar= e highly wanted.

The current version of the docume= nt is the following:=C2=A0https://datatracker.ietf.org/doc/html/draft-i= rtf-cfrg-re-keying-01.

Best regards,
Stanislav Smyshlyaev

=

2017-03-25 20:21 GMT+03:00 Alexey Melnikov <= span dir=3D"ltr"><alexey.melnikov@isode.com>:
Dear CRFG participants,
While CFRG is not meeting in Chicago, there will be a 1 hour design-type meeting to talk about re-keying. Below is information about this meeting:
When: On Thursday, March 30th, 10:30am-11:30am

Where: BIANCO room of the meeting hotel (3rd Floor). This is IESG
Breakout Room.


Should the re-keying discussion finish early, other CFRG related topics
may be discussed. If you have a topic, please reply to this email or to
me directly.

Thank you,
Alexey, as a CFRG co-chair.



_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--94eb2c0608d48629e3054be4af8b-- From nobody Wed Mar 29 18:01:00 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BB0126D73 for ; Wed, 29 Mar 2017 18:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8Cok4t96ynC for ; Wed, 29 Mar 2017 18:00:56 -0700 (PDT) Received: from delta.cs.cinvestav.mx (delta.cs.cinvestav.mx [148.247.102.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6AE126CE8 for ; Wed, 29 Mar 2017 18:00:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id 6CC135C0A86; Wed, 29 Mar 2017 19:00:42 -0600 (CST) X-Virus-Scanned: amavisd-new at cs.cinvestav.mx Received: from delta.cs.cinvestav.mx ([127.0.0.1]) by localhost (delta.cs.cinvestav.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUlj8S+CCHLv; Wed, 29 Mar 2017 19:00:41 -0600 (CST) Received: by delta.cs.cinvestav.mx (Postfix, from userid 1507) id 1C46B5C0AFA; Wed, 29 Mar 2017 19:00:40 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id EBCEA5C0A86; Wed, 29 Mar 2017 19:00:40 -0600 (CST) Date: Wed, 29 Mar 2017 19:00:40 -0600 (CST) From: Francisco Rodriguez- Henriquez To: "cfrg@irtf.org" cc: Thomaz Oliveira , =?ISO-8859-15?Q?Julio_C=E9sar_Lopez?= In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-141290138-920918062-1490834242=:8996" Content-ID: Archived-At: Subject: [Cfrg] A note on how to (pre-)compute a ladder X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 01:00:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---141290138-920918062-1490834242=:8996 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Dear CFRG community, We would like to draw your attention to our IACR pre-print entitled, "A note on how to (pre-)compute a ladder Improving the performance of X25519 and X448" https://eprint.iacr.org/2017/264.pdf. For the point multiplication computation Q = kP, this note describes a right-to-left version of the Montgomery ladder, which is amenable for pre-computing multiples of the base point P. By requiring very modest memory resources and a small implementation effort, it obtains noticeable performance improvements with respect to the RFC 7748 classical ladder procedure. We stress that our proposal fully complies with the RFC 7748 specification, in the sense that given any arbitrary secret keys of Alice and Bob, our ladder generates exactly the same public keys that an implementation of the RFC 7748 would output. As a way of illustration, in Appendix B of our note, we include a magma script, which given Alice and Bob private keys of RFC7748 Sec. 6.2, it computes the same public keys as specified in that document. We would be delighted to receive feedback (including sightings of typos) from the CFRG community. With best regards, Thomaz Oliveira, Julio López and Francisco Rodríguez-Henríquez ---141290138-920918062-1490834242=:8996-- From nobody Thu Mar 30 06:33:34 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 803A6129401; Thu, 30 Mar 2017 06:33:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149088081247.15436.17429931970333748604@ietfa.amsl.com> Date: Thu, 30 Mar 2017 06:33:32 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-xmss-hash-based-signatures-09.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 13:33:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum of the IETF. Title : XMSS: Extended Hash-Based Signatures Authors : Andreas Huelsing Denis Butin Stefan-Lukas Gazdag Aziz Mohaisen Filename : draft-irtf-cfrg-xmss-hash-based-signatures-09.txt Pages : 67 Date : 2017-03-30 Abstract: This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system. It follows existing descriptions in scientific literature. The note specifies the WOTS+ one-time signature scheme, a single-tree (XMSS) and a multi-tree variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can withstand attacks using quantum computers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-xmss-hash-based-signatures/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-09 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-xmss-hash-based-signatures-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-xmss-hash-based-signatures-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 30 06:48:46 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F3A1294DB for ; Thu, 30 Mar 2017 06:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bFxTRlljwqR for ; Thu, 30 Mar 2017 06:48:43 -0700 (PDT) Received: from www363.your-server.de (www363.your-server.de [78.46.179.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D12C12422F for ; Thu, 30 Mar 2017 06:42:28 -0700 (PDT) Received: from [88.198.220.131] (helo=sslproxy02.your-server.de) by www363.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1ctaLK-0000YD-B0 for cfrg@ietf.org; Thu, 30 Mar 2017 15:42:26 +0200 Received: from [195.169.150.100] (helo=[10.1.0.143]) by sslproxy02.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1ctaLK-000827-53 for cfrg@ietf.org; Thu, 30 Mar 2017 15:42:26 +0200 References: <149088081247.15436.17429931970333748604@ietfa.amsl.com> To: cfrg@ietf.org From: "A. Huelsing" Message-ID: <68574203-6954-e545-ea67-5438a1a57c36@huelsing.net> Date: Thu, 30 Mar 2017 15:42:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149088081247.15436.17429931970333748604@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Authenticated-Sender: ietf@huelsing.net X-Virus-Scanned: Clear (ClamAV 0.99.2/23251/Thu Mar 30 14:36:05 2017) Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-xmss-hash-based-signatures-09.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 13:48:45 -0000 Hi, we fixed some typos that we were made aware of. No semantics are changed. Best Andreas Am 30-03-17 um 15:33 schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Crypto Forum of the IETF. > > Title : XMSS: Extended Hash-Based Signatures > Authors : Andreas Huelsing > Denis Butin > Stefan-Lukas Gazdag > Aziz Mohaisen > Filename : draft-irtf-cfrg-xmss-hash-based-signatures-09.txt > Pages : 67 > Date : 2017-03-30 > > Abstract: > This note describes the eXtended Merkle Signature Scheme (XMSS), a > hash-based digital signature system. It follows existing > descriptions in scientific literature. The note specifies the WOTS+ > one-time signature scheme, a single-tree (XMSS) and a multi-tree > variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main > building block. XMSS provides cryptographic digital signatures > without relying on the conjectured hardness of mathematical problems. > Instead, it is proven that it only relies on the properties of > cryptographic hash functions. XMSS provides strong security > guarantees and is even secure when the collision resistance of the > underlying hash function is broken. It is suitable for compact > implementations, relatively simple to implement, and naturally > resists side-channel attacks. Unlike most other signature systems, > hash-based signatures can withstand attacks using quantum computers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-irtf-cfrg-xmss-hash-based-signatures/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-09 > https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-xmss-hash-based-signatures-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-xmss-hash-based-signatures-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Mar 30 10:02:30 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279161299CD for ; Thu, 30 Mar 2017 10:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLtB3maz15p1 for ; Thu, 30 Mar 2017 10:02:26 -0700 (PDT) Received: from tauceti.org.au (mail.tauceti.org.au [203.32.61.25]) by ietfa.amsl.com (Postfix) with ESMTP id 29ECD12998D for ; Thu, 30 Mar 2017 10:02:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=ppp-223-24-78-130.revip6.asianet.co.th; To: cfrg@irtf.org References: From: Peter Dettman Message-ID: Date: Fri, 31 Mar 2017 00:02:11 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Authenticated-User: peter.dettman@bouncycastle.org Archived-At: Subject: Re: [Cfrg] A note on how to (pre-)compute a ladder X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 17:02:29 -0000 Hi Francisco, Seems like a nice performance win for key generation with very little extra effort over the variable-point ladder in RFC 7748. Would it be worth briefly addressing safe-error attacks? At first glance Algorithm 4 appears to not involve R2 in the final result, although it's made clear later in Algorithm 5 that both R1 and R2 are used in every addition due to the choice of addition formula. Remark 2 at the end of 5.1 presents this as a minor performance optimization, but fails to point out that it is needed to protect against safe-error attacks. Regards, Pete Dettman On 30/03/2017 8:00 AM, Francisco Rodriguez- Henriquez wrote: > Dear CFRG community, > > We would like to draw your attention to our IACR pre-print entitled, > > "A note on how to (pre-)compute a ladder > Improving the performance of X25519 and X448" > > https://eprint.iacr.org/2017/264.pdf. > > For the point multiplication computation Q = kP, this note describes a > right-to-left version of the Montgomery ladder, which is amenable for > pre-computing multiples of the base point P. By requiring very modest > memory resources and a small implementation effort, it obtains noticeable > performance improvements with respect to the RFC 7748 classical ladder > procedure. > > We stress that our proposal fully complies with the RFC 7748 > specification, in the sense that given any arbitrary secret keys of > Alice and Bob, our ladder generates exactly the same public keys that an > implementation of the RFC 7748 would output. > > As a way of illustration, in Appendix B of our note, we include a magma > script, which given Alice and Bob private keys of RFC7748 Sec. 6.2, it > computes the same public keys as specified in that document. > > We would be delighted to receive feedback (including sightings of typos) > from the CFRG community. > > With best regards, > > Thomaz Oliveira, Julio López and Francisco Rodríguez-Henríquez > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > From nobody Fri Mar 31 11:06:42 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5648128DF6 for ; Fri, 31 Mar 2017 11:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHqw8Kk2xA0W for ; Fri, 31 Mar 2017 11:06:36 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40B0129450 for ; Fri, 31 Mar 2017 11:06:36 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id x125so77970576pgb.0 for ; Fri, 31 Mar 2017 11:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=hBysr6SZvg/AX9ey5ZiNJYdRELW1qEMm+VgFTtNM5Fg=; b=eDtPazoBBR5YFDltMmUl96ApWdw5UNsY5XF8PO9Ch4zgLixKxXbtGYYTJ5ne7wzSMw EWU2JKcR5GTjW/Vpzw/wGEyTPwKWXiajGTEJ0698tatzdpx/kzmmEp2Ynrj7U5Iuee7S /6Igfeor9IJWz0//K4hQfowB4Jmqt67osFjlp3kYLOTFnhbe+becv15NQImVP9oI5oaq BvfGNO5ctlFIyOcv663dYCq6aKINwPRopkEyAV5f7SJmmzNsEipt2JlmcRnkw7U8zRPF n2coyiH8u27ICyf7p7n5uyMpz3weWRwWXmixDxLEqUj3P+u9Na1hpqSplpgiEognvrvW Mh/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=hBysr6SZvg/AX9ey5ZiNJYdRELW1qEMm+VgFTtNM5Fg=; b=iIaxr/NzhIgt/TqyXYzsFGDce89v6Tn1x6s64WynEZLNM79qZSdLvcVV3v6tLq3yW/ pr/lNb7LblC+8GHGK/AspwMhEdonW4Qcpf2ENBclhp7fzHEnhQG2NUKQ2r0P3zBh/SfO 4A4J0PD6fD6sat4gf+H3mIhNfAzJYzrWNzyTr4S0KOCKYhg8T3cJMu2zFtbH2L2JOr2t nqmU7EjZpb9tPSIQIbOTqoi3JoAjBnu4WbWi7BwAJFm/OkemSuBOYs8LDifmbzLM2qZw B7q3XrRl73E8zAR5jsW8rGRkM09N1AxCFrcV5uelaSdCmsmWsAbYmIL+XHLTHaEsLsln iZzA== X-Gm-Message-State: AFeK/H2hQ6tAY+snasqHZQD8kWZwExHNt46aU9deIfVbYIn4EZcxcVanr5kiVj+a4MhRng== X-Received: by 10.84.208.102 with SMTP id f35mr4863502plh.19.1490983595764; Fri, 31 Mar 2017 11:06:35 -0700 (PDT) Received: from ?IPv6:2601:642:4000:9d0c:fd08:5b9:6d11:bb3e? ([2601:642:4000:9d0c:fd08:5b9:6d11:bb3e]) by smtp.gmail.com with ESMTPSA id w186sm11874419pgb.35.2017.03.31.11.06.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 11:06:35 -0700 (PDT) From: Oleg Andreev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <83CC086B-5B89-41CA-8A20-D7D688DD00AC@gmail.com> Date: Fri, 31 Mar 2017 11:06:34 -0700 To: cfrg@irtf.org, khovratovich@gmail.com X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Cfrg] Questions regarding BIP32-Ed25519 (was: Interest in an "Ed25519-HD" standard?) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 18:06:41 -0000 Dmitry, Thanks for your with Jason paper on adopting BIP32 to Ed25519 and = critique of ChainKD, very appreciated. I have a few questions about it: 1. Why do you impose requirements on the master secret to yield 3rd high = bit to be zero, while you can simply set it to zero along with other 5 = bits. In two places you mention that you reject non-compliant master = secret, but in Security section (F) you say "we set 6 bits", which is = what seems to be the intention all along. 2. You choose 2^20 as a max depth level therefore leaving 2^230 bits for = the derived key. In your paper you round this down to whole number of = bytes (28 bytes -> 2^224) while it's actually possible to slightly = increase collision-resistance by taking 29 bytes instead and clearing = top 2 bits. Have you considered that, and if yes, is there any issues = with that? 3. What was the rationale for 2^20 as a depth limit? I myself don't have = a good framework to decide which limit is the best, so I'm wondering if = you have? :) 4. You effectively make xprv to be 96-byte string (32 bytes for the = scalar, 32 bytes for the "prefix" used in nonce generation and 32 byte = chain code), and use two HMAC calls to derive new chain code separately = from the privkey. Have you considered expanding the 64-byte privkey (as = defined by NaCl library) from the scalar itself? In my recent tweak to = ChainKD scheme [1] I'm doing that and to stay fully compatible with = EdDSA requirement that prefix originally has 256 bits of entropy, add = only one secret byte ("pepper") that eats 8 bits from the chain code = (which we call "salt"). This allows us to keep both xprv and xpub 64 = bytes long and avoid double-HMAC when deriving public keys - single hash = call produces a key component and another salt value. Thank you! [1] Updated ChainKD: = https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specification= s/chainkd.md =20 > Being a co-author of [5], I am ready to contribute to such a document. = I > will present our own proposal at > http://prosecco.gforge.inria.fr/ieee-blockchain2016/ in Paris just = before > the CFRG meeting at the same place next day. It would be great if we = come > up with some proposal to discuss it already there. >=20 > The most recent version is > https://drive.google.com/open?id=3D0ByMtMw2hul0EMFJuNnZORDR2NDA It has = some > critique of [6], hopefully not too offensive:) >=20 > Our motivation in [5] was to generate private keys satisfying the > Curve25519 requirements too so that the code can be reused, even if in = the > signature setting some attacks would not apply. But it would be great = to > have comments from the community as well. >=20 > Best regards, > Dmitry >=20 > On Wed, Mar 22, 2017 at 5:00 AM, Phillip Hallam-Baker = > wrote: >=20 > > You can do hierarchical key derivation in Montgomery without the = need for > > an add. > > > > Say your master key is x. To generate a key for site 'example.com' = we > > take > > > > xs =3D (x + H('example.com')) mod q > > > > Where q is the sub group order. > > > > In fact that isn't really using any EC relevant operation at all. = Perhaps > > I am not understanding the full requirements for the scheme. > > > > > > I don't follow the argument about small subgroups in the referenced = post. > > With Curve25519 and Ed25519 we have chosen the curve cofactor and = the > > generator point. So there is only one group that our point can = possibly be > > in regardless of whether our private key is (x mod q) or (x mod q + = nq). We > > are going to arrive at the same set of points regardless. > > > > > > I do very much prefer the Edwards curves though because we can = combine two > > keypairs by simply adding the corresponding public and private keys. = That > > allows us to do the co-generation trick I showed a while back. > > > > We can also split the key, give one part to a recryption service and > > encrypt the other half under the public key of the recipient. This = allows > > us to support group messaging through proxy re-encryption. > > > > Some applications of that are encumbered (possibly) under a soon to = expire > > patent. > > > > > > > > On Tue, Mar 21, 2017 at 8:34 PM, Phillip Hallam-Baker < > > phill@hallambaker.com> wrote: > > > >> I have just implemented Proxy Re-Encryption under Ed-25519 and = Ed448. I > >> think EdCurve Crypto is a good plan. > >> > >> Or we could do it on the Montgomery Curves and give the algorithm = for > >> point addition. > >> > >> On Tue, Mar 21, 2017 at 3:42 PM, Tony Arcieri = wrote: > >> > >>> Hierarchical key derivation (also sometimes described as = "semiprivate > >>> keys" or "key blinding") is an increasingly popular technique for > >>> generating unlinkable child keys from master public and private = keys. > >>> > >>> The Tor Project has been exploring such an approach as the basis = for > >>> their next-generation hidden services design for several years = now[1], > >>> during which time it has received security proofs[2]. Their latest > >>> design[3] allegedly includes feedback from Dan Bernstein. > >>> > >>> Application of hierarchical key derivation is perhaps most notable = in > >>> the cryptocurrency space, where Bitcoin's BIP32[4] provided a = means for > >>> unlinkable single-use signature keys for the secp256k1 elliptic = curve. > >>> There are several designs for applying the ideas from BIP32 to = Ed25519, > >>> including ones from Evernym[5] and Chain[6] (where I am an = employee). > >>> > >>> The designs in [3], [5], and [6] are all highly similar and = accomplish > >>> the same goals. Personally I would love to see a single standard = design for > >>> producing Ed25519 signatures from hierarchically derived keys, = notably one > >>> which produces signatures that can be verified by any = off-the-shelf RFC > >>> 8032-compatible Ed25519 implementation. > >>> > >>> There's already been some discussion of this on the = moderncrypto.org > >>> curves list: > >>> > >>> https://moderncrypto.org/mail-archive/curves/2017/000858.html > >>> > >>> I'd be curious to know if anyone else would be interested in > >>> collaborating on a draft for such a standard, which can be a = synthesis of > >>> the existing work in this space. > >>> > >>> [1]: https://lists.torproject.org/pipermail/tor-dev/2012-Sep > >>> tember/004026.html > >>> [2]: https://www-users.cs.umn.edu/~hopper/basic-proof.pdf > >>> [3]: https://gitweb.torproject.org/torspec.git/tree/proposal > >>> s/224-rend-spec-ng.txt#n1979 > >>> [4]: = https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki > >>> [5]: https://github.com/WebOfTrustInfo/rebooting-the-web-of- > >>> trust-fall2016/blob/master/topics-and-advance-readings/HDKey > >>> s-Ed25519.pdf > >>> [6]: https://chain.com/docs/protocol/specifications/chainkd > >>> > >>> -- > >>> Tony Arcieri > >>> > >>> _______________________________________________ > >>> Cfrg mailing list > >>> Cfrg@irtf.org > >>> https://www.irtf.org/mailman/listinfo/cfrg > >>> > >>> > >> > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > https://www.irtf.org/mailman/listinfo/cfrg > > > > >=20 >=20 > --=20 > Best regards, > Dmitry Khovratovich