From yaronf.ietf@gmail.com Mon Mar 4 12:36:02 2013 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 1134D21F8FE3 for ; Mon, 4 Mar 2013 12:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeaWaaXYMCdf for ; Mon, 4 Mar 2013 12:36:01 -0800 (PST) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFA021F8F7A for ; Mon, 4 Mar 2013 12:35:49 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id e53so4293340eek.40 for ; Mon, 04 Mar 2013 12:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=r7Y/bUhu7/NrhhuZ6WOTNLZ3lCX+jEQ30pxXbj+d/Rg=; b=dYaeRuUsqjWJpa+c5Xkp0unBuDAFnoy+ttJ7TvyjpT9IyabJK1nB0X5RxtlQ46Fpub O6R04XTQHWykJGlgEe4bu8s5xCsB+aEW7OK5/17aCzRJCUUiK4xOgpKvqbYCGwBLdBs6 Q0A/zhwtNLVS9ozK0tlyLHmjFwz0JlHS5U24FV276IEYXY80sfcQVH5zgupiOrirjXcW yBytbeu1wUPVRSjEg1VOTC2JtaFTxI/f6Vof5J34aFQcGF5KYL9Ly62N3jmgyz1LjDAK 1Zgudfu6U28dvmc2yKOIi/2AuZo77RWX/1S6PnqceQuVbvVyk0xcTOCO38wkADsrrbZu fq5g== X-Received: by 10.14.4.69 with SMTP id 45mr7049779eei.0.1362429349245; Mon, 04 Mar 2013 12:35:49 -0800 (PST) Received: from [10.0.0.2] (bzq-79-179-110-81.red.bezeqint.net. [79.179.110.81]) by mx.google.com with ESMTPS id t4sm33904070eel.0.2013.03.04.12.35.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 12:35:48 -0800 (PST) Message-ID: <513505A3.8090608@gmail.com> Date: Mon, 04 Mar 2013 22:35:47 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: cfrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Cfrg] Please review: additional Diffie Hellman tests for IKEv2 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:36:02 -0000 Hi, Scott Fluhrer came up with a set of tests that an IKEv2 peer receiving a public DH key needs to perform, so that its private DH key is not endangered, even if it is being reused with multiple peers (a.k.a. unsafe sex :-). The tests apply primarily to ECC groups. This is now an ipsecme draft, http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-00. We would appreciate further comments from this list. Thanks, Yaron From kmigoe@nsa.gov Thu Mar 7 11:00:37 2013 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 C983B21F8B25 for ; Thu, 7 Mar 2013 11:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEKqDxiK4dSH for ; Thu, 7 Mar 2013 11:00:37 -0800 (PST) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 116D421F8ADC for ; Thu, 7 Mar 2013 11:00:28 -0800 (PST) X-TM-IMSS-Message-ID: Received: from MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id c97352290013315c ; Thu, 7 Mar 2013 13:59:26 -0500 Received: from MSMR-GH1-UEA05.corp.nsa.gov (10.215.228.28) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 7 Mar 2013 14:00:25 -0500 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA05.corp.nsa.gov ([10.215.228.28]) with mapi id 14.01.0289.001; Thu, 7 Mar 2013 14:00:25 -0500 From: "Igoe, Kevin M." To: "cfrg@irtf.org" Thread-Topic: draft-irtf-cfrg-ocb-00 Thread-Index: Ac4bZgVE5O7oX4e1RiSMSOW73M51hw== Date: Thu, 7 Mar 2013 19:00:23 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA7A6B243B@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.225.46] Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CA7A6B243BMSMRGH1UEA03cor_" MIME-Version: 1.0 Subject: [Cfrg] draft-irtf-cfrg-ocb-00 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 19:00:37 -0000 --_000_3C4AAD4B5304AB44A6BA85173B4675CA7A6B243BMSMRGH1UEA03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In order to give everyone one last chance to comment, the last call for draft-irtf-cfrg-ocb-00 will be on the CFRG agenda for IETF-86. ----------------+-------------------------------------------------- Kevin M. Igoe | "We can't solve problems by using the same kind kmigoe@nsa.gov | of thinking we used when we created them." | - Albert Einstein - ----------------+-------------------------------------------------- --_000_3C4AAD4B5304AB44A6BA85173B4675CA7A6B243BMSMRGH1UEA03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In order to give everyone one last chance to comment, the last call
for draft-irtf-cfrg-ocb-00 will be on the CFRG agenda for IETF-86.
&nbs= p;
 
----------------+-------------------------= -------------------------
Kevin M. Igoe   | "We can't sol= ve problems by using the same kind
kmigoe@nsa.gov  | of thinking we used whe= n we created them."
       &nbs= p;        |     = ;         - Albert Einstein -
----------------+-------------------------= -------------------------
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_3C4AAD4B5304AB44A6BA85173B4675CA7A6B243BMSMRGH1UEA03cor_-- From internet-drafts@ietf.org Thu Mar 14 14:27:55 2013 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 9514111E81C6; Thu, 14 Mar 2013 14:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.069 X-Spam-Level: X-Spam-Status: No, score=-102.069 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gUUD37yFD91; Thu, 14 Mar 2013 14:27:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B53C211E8199; Thu, 14 Mar 2013 14:27:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130314212754.13851.8912.idtracker@ietfa.amsl.com> Date: Thu, 14 Mar 2013 14:27:54 -0700 Cc: cfrg@ietf.org Subject: [Cfrg] I-D Action: draft-irtf-cfrg-zssbn-00.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 21:27:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Crypto Forum Research Group Working Group= of the IETF. Title : ZSS Short Signature Scheme for BN Curves Author(s) : Laura Hitt Filename : draft-irtf-cfrg-zssbn-00.txt Pages : 21 Date : 2013-03-14 Abstract: This document describes the ZSS Short Signature Scheme for implementation from bilinear pairings on Barreto-Naerhig (BN) ordinary elliptic curves. The ZSS Short Signature Scheme uses general cryptographic hash functions such as SHA-1 or SHA-2 and is efficient in terms of pairing operations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-zssbn There's also a htmlized version available at: http://tools.ietf.org/html/draft-irtf-cfrg-zssbn-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Mar 14 14:30:32 2013 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 BA7D811E81D1; Thu, 14 Mar 2013 14:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSHeUI6P8Dso; Thu, 14 Mar 2013 14:30:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3213611E81A1; Thu, 14 Mar 2013 14:30:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130314213032.30118.25627.idtracker@ietfa.amsl.com> Date: Thu, 14 Mar 2013 14:30:32 -0700 Cc: cfrg@ietf.org Subject: [Cfrg] I-D Action: draft-irtf-cfrg-zss-00.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 21:30:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Crypto Forum Research Group Working Group= of the IETF. Title : ZSS Short Signature Scheme Author(s) : Laura Hitt Filename : draft-irtf-cfrg-zss-00.txt Pages : 19 Date : 2013-03-14 Abstract: This document describes the ZSS Short Signature Scheme for implementation from bilinear pairings on supersingular elliptic curves. The ZSS Short Signature Scheme uses general cryptographic hash functions such as SHA-1 or SHA-2 and is efficient in terms of pairing operations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-zss There's also a htmlized version available at: http://tools.ietf.org/html/draft-irtf-cfrg-zss-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mcgrew@cisco.com Thu Mar 14 15:22:50 2013 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 821AD11E8158 for ; Thu, 14 Mar 2013 15:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB9dRfRXJ0D8 for ; Thu, 14 Mar 2013 15:22:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9E39911E814D for ; Thu, 14 Mar 2013 15:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6940; q=dns/txt; s=iport; t=1363299769; x=1364509369; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=a4v/rjp+4ODZIyjoIz8yUirbLCqX4RDYbWAK6RFHM+4=; b=k0gKe+zRPFHa5O2+3wgs69oSy/J7OfbSkLiPf8NFEpmBmz5OEWyj8GVk P8D6QaHWpMiYG25eUtOHw8dlbc8/trntzWq59eIQC0rJbeg+9HXPXr4Kt nEImJwRuGv+JhUOLDBrDm6geXeAtkkQGXBnuSiCGzmf2rDBaSKLU6ClpD U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANFMQlGtJV2a/2dsb2JhbABDhB7AZ4FnFnSCKwEBAQQtTBIBCBEDAQILHTkUCQgBAQQBDQUIiAzCCY5lDRMGCweCX2EDp1qDCoIo X-IronPort-AV: E=Sophos;i="4.84,848,1355097600"; d="scan'208,217";a="187674450" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 14 Mar 2013 22:22:49 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2EMMnCh004517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 22:22:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 17:22:48 -0500 From: "David McGrew (mcgrew)" To: "Igoe, Kevin M." , "cfrg@irtf.org" Thread-Topic: [Cfrg] Upcoming meeting Thread-Index: Ac4UMZZIs2aMFW+oTA6Ys9iMNXNqyAM2T94A Date: Thu, 14 Mar 2013 22:22:48 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EA3C9@xmb-rcd-x04.cisco.com> In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CA751704D1@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B183EA3C9xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "Michael Curcio \(micurcio\)" Subject: Re: [Cfrg] Upcoming meeting X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:22:50 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B183EA3C9xmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kevin, I would like to make a presentation on a recently submitted draft, "Hash-Ba= sed Signatures", draft-mcgrew-hash-sigs-00. The presentation will cover = the goals, motivation, and the approach used in the draft. (For technical= details I will let people read the draft itself =96 comments welcome, and = please copy the list and both authors :-) Thanks, David From: , "Kevin M." > Date: Tuesday, February 26, 2013 10:57 AM To: "cfrg@irtf.org" > Subject: [Cfrg] Upcoming meeting Just a reminder that the CFRG will be meeting in Orlando. Agenda is not ye= t set, but we do have one item of interest. Jim Schaad, co-chair of the JOSE= WG, has kindly volunteered to gives us a presentation on the cryptographic algorithms and protocols used in JOSE. Anyone who would like to make a presentation, please don=92t be shy about c= oming forward. This is a research group, not a working group, and we want to en= courage and nurture new ideas. ----------------+-------------------------------------------------- Kevin M. Igoe | "We can't solve problems by using the same kind kmigoe@nsa.gov | of thinking we used when we create= d them." | - Albert Einstein - ----------------+-------------------------------------------------- --_000_747787E65E3FBD4E93F0EB2F14DB556B183EA3C9xmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Kevin,

I would like to make a presentation on a recently submitted draft, "Hash-Based Sig= natures", draft-mcgrew-hash-sigs-00.    The presentation will cover the goals, motivation, and the approach used in the draft. &nbs= p; (For technical details I will let people read the draft itself =96 comme= nts welcome, and please copy the list and both authors :-)

Thanks,

David

From: <Igoe>, "Kevin M.&= quot; <kmigoe@nsa.gov>
Date: Tuesday, February 26, 2013 10= :57 AM
To: "cfrg@irtf.org" <cfrg@i= rtf.org>
Subject: [Cfrg] Upcoming meeting

Just a reminder that the CFRG will be meeting in Orlando.  Agenda= is not yet
set, but we do have one item of interest.  Jim Schaad, co-chair o= f the JOSE WG,
has kindly volunteered to gives us a presentation on the cryptographic=
algorithms and protocols used in  JOSE. 
 
Anyone who would like to make a presentation, please don=92t be shy ab= out coming
forward.  This is a research group, not a working group, and we w= ant  to encourage
and nurture new ideas.
 
 
----------------+------------------------------------= --------------
Kevin M. Igoe   | "We can't solve problems= by using the same kind
kmigoe@nsa.gov = ; | of thinking we used when we created them."
         &nb= sp;      |      &nbs= p;       - Albert Einstein -
----------------+------------------------------------= --------------
 
 
 
 --_000_747787E65E3FBD4E93F0EB2F14DB556B183EA3C9xmbrcdx04ciscoc_-- From kmigoe@gmail.com Thu Mar 14 15:34:23 2013 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 F336111E8195 for ; Thu, 14 Mar 2013 15:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VICs+5OueI6s for ; Thu, 14 Mar 2013 15:34:22 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA3311E8173 for ; Thu, 14 Mar 2013 15:34:22 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id ro8so2892463pbb.4 for ; Thu, 14 Mar 2013 15:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=XfctD/X0PFp9iWNjkL9Z/v7Y9T3pmcVg19jZk4qIJQ8=; b=Su7awdXo3u4XionKaM2+RG2yNFF+9wMbk3zWwC/Splv3Z+jqaY4CYKleDVd06Rk3jX 2EdJin/CMO0ApLt3Jw0rw7wGA2Fc2+FydVD6wvZNG/Rg8lglP6A99t+J2/59EWYWcKEr dYouKfeEe7FHJfMCm5VWhHmWuZfzIqptKpBCSYhVlSjb0CWoPhigkJ4XdUDFkD8QA5bG QXDNfYumNMhm35kIyvPq0CTY2LZ3cJ2+6rbh+EaV/DxIn/g/d79qUFdhv2H3mpifBuZE 8oingfY7uiu68ewn4IM+1kCfEtZ1Sz3IrUhUT7HhO4umlA1nGvWzbb6+8HioD+cJ1lmB 8eiQ== X-Received: by 10.68.197.231 with SMTP id ix7mr10025073pbc.123.1363300462148; Thu, 14 Mar 2013 15:34:22 -0700 (PDT) Received: from ?IPv6:2001:df8::128:6534:82f4:383f:d92a? ([2001:df8:0:128:6534:82f4:383f:d92a]) by mx.google.com with ESMTPS id d7sm5189010pbh.45.2013.03.14.15.32.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 15:34:19 -0700 (PDT) References: <747787E65E3FBD4E93F0EB2F14DB556B183EA3C9@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183EA3C9@xmb-rcd-x04.cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-5C8B18BA-153C-41DC-86F5-619518B29749 Message-Id: <9414CDF5-0F8B-436F-B14B-99646A2E1E3F@gmail.com> X-Mailer: iPhone Mail (9B206) From: Kevin Igoe Date: Thu, 14 Mar 2013 18:32:48 -0400 To: "David McGrew (mcgrew)" Cc: "cfrg@irtf.org" , "Michael Curcio \(micurcio\)" Subject: Re: [Cfrg] Upcoming meeting X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:34:23 -0000 --Apple-Mail-5C8B18BA-153C-41DC-86F5-619518B29749 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 David: =20 I threw together a few slides on how hash based signatures work and put th= em up as meeting slides on the meeting materials under CFRG. I'm quite comfo= rtable with introducing this material if you'd like. Look the slides over - t= hey are graphics only, no text. Sent from my iPhone On Mar 14, 2013, at 6:22 PM, "David McGrew (mcgrew)" wrot= e: > Hi Kevin, >=20 > I would like to make a presentation on a recently submitted draft, "Hash-B= ased Signatures", draft-mcgrew-hash-sigs-00. The presentation will cover t= he goals, motivation, and the approach used in the draft. (For technical d= etails I will let people read the draft itself =E2=80=93 comments welcome, a= nd please copy the list and both authors :-) >=20 > Thanks, >=20 > David >=20 > From: , "Kevin M." > Date: Tuesday, February 26, 2013 10:57 AM > To: "cfrg@irtf.org" > Subject: [Cfrg] Upcoming meeting >=20 > Just a reminder that the CFRG will be meeting in Orlando. Agenda is not y= et > set, but we do have one item of interest. Jim Schaad, co-chair of the JOS= E WG, > has kindly volunteered to gives us a presentation on the cryptographic > algorithms and protocols used in JOSE.=20 > =20 > Anyone who would like to make a presentation, please don=E2=80=99t be shy a= bout coming > forward. This is a research group, not a working group, and we want to e= ncourage > and nurture new ideas. > =20 > =20 > ----------------+-------------------------------------------------- > Kevin M. Igoe | "We can't solve problems by using the same kind > kmigoe@nsa.gov | of thinking we used when we created them." > | - Albert Einstein - > ----------------+-------------------------------------------------- > =20 > =20 > =20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail-5C8B18BA-153C-41DC-86F5-619518B29749 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
David:  
  I threw together a few slides on how hash based signatur= es work and put them up as meeting slides on the meeting materials under CFR= G. I'm quite comfortable with introducing this material if you'd like. Look t= he slides over - they are graphics only, no text.

Sent from my iPhone=

On Mar 14, 2013, at 6:22 PM, "David McGrew (mcgrew)" <mcgrew@cisco.com> wrote:

Hi Kevin,

I would like to make a presentation on a recently submitted draft, "Hash-Based Signatures= ", draft-mcgrew-hash-sigs-00.    The presentation will cover the goals, motivation, and the approach used in the draft.  = ; (For technical details I will let people read the draft itself =E2=80=93 c= omments welcome, and please copy the list and both authors :-)

Thanks,

David

From: <Igoe>, "Kevin M." <<= a href=3D"mailto:kmigoe@nsa.gov">kmigoe@nsa.gov>
Date: Tuesday, February 26, 2013 10:= 57 AM
To: "cfrg@irtf.org" <cfrg@irtf.org&= gt;
Subject: [Cfrg] Upcoming meeting
=

Just a reminder that the CFRG will be meeting in Orlando.  Agenda i= s not yet
set, but we do have one item of interest.  Jim Schaad, co-chair of= the JOSE WG,
has kindly volunteered to gives us a presentation on the cryptographic<= /div>
algorithms and protocols used in  JOSE. 
 
Anyone who would like to make a presentation, please don=E2=80=99t be s= hy about coming
forward.  This is a research group, not a working group, and we wa= nt  to encourage
and nurture new ideas.
 
 
----------------+------------------------------------------= --------
Kevin M. Igoe   | "We can't solve problems by usi= ng the same kind
kmigoe@nsa.gov  |= of thinking we used when we created them."
          = ;      |       &= nbsp;      - Albert Einstein -
----------------+------------------------------------------= --------
 
 
 
____________________= ___________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/l= istinfo/cfrg
= --Apple-Mail-5C8B18BA-153C-41DC-86F5-619518B29749-- From Michael.Jones@microsoft.com Fri Mar 15 07:11:35 2013 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 7EBED21F86BA for ; Fri, 15 Mar 2013 07:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkpIjQYXha8i for ; Fri, 15 Mar 2013 07:11:34 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 376B421F86B8 for ; Fri, 15 Mar 2013 07:11:34 -0700 (PDT) Received: from BL2FFO11FD024.protection.gbl (10.173.161.204) by BL2FFO11HUB030.protection.gbl (10.173.161.54) with Microsoft SMTP Server (TLS) id 15.0.641.9; Fri, 15 Mar 2013 14:11:32 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD024.mail.protection.outlook.com (10.173.161.103) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Fri, 15 Mar 2013 14:11:31 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Fri, 15 Mar 2013 14:10:33 +0000 From: Mike Jones To: "cfrg@irtf.org" Thread-Topic: Draft describing encrypting JWK key representations with JWE Thread-Index: Ac4hhtqoIuSqFwxLTJyRJ12GCLuDBw== Date: Fri, 15 Mar 2013 14:10:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367522C60TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(56816002)(63696002)(46102001)(54356001)(80022001)(76482001)(49866001)(59766001)(551544001)(16406001)(512954001)(55846006)(77982001)(53806001)(56776001)(33656001)(69226001)(31966008)(44976002)(66066001)(20776003)(5343635001)(47976001)(65816001)(74502001)(54316002)(74662001)(50986001)(15202345001)(16236675001)(51856001)(4396001)(79102001)(47446002)(5343655001)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB030; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078693968A Subject: [Cfrg] Draft describing encrypting JWK key representations with JWE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:11:35 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367522C60TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 This also adds password-based encryption to the algorithm registry. -- Mike --_000_4E1F6AAD24975D4BA5B168042967394367522C60TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://tools.ietf.org/html/draft-miller-jose-jwe-= protected-jwk-01

 

This also adds password-based encryption to the algo= rithm registry.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B168042967394367522C60TK5EX14MBXC284r_-- From yaronf.ietf@gmail.com Fri Mar 15 08:15:43 2013 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 35DE721F859A for ; Fri, 15 Mar 2013 08:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKAwM+YZJZ6V for ; Fri, 15 Mar 2013 08:15:42 -0700 (PDT) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5F65721F8598 for ; Fri, 15 Mar 2013 08:15:41 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id t10so1681584eei.35 for ; Fri, 15 Mar 2013 08:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HgCYXP1Jlyaytrngmc8gzQBpzsFaeJjPJxw1HNmPR1A=; b=TfpKbUoe2D6X1YETbrjpsSuAqtMIn7LTlDMeM84JkMTLz5J2pKPpMao+4mCMTIKnb3 jBguKu3Vfd5iFF/jSdHPmqPSduA2mbIH8ocqYba68zCAjgGNja3Y4H95UYWdnlRDtzJc OZkpIdstsMlRfc+OV0Hnoad7PaEKq9FpzRrE3hVcIsYyFDKKqLhJk+VmX2+7kZtKiKBL 6tDJEOMF/Yswx5PgKL2giwWAGro42D4Hk7HEA/aSeeiC+6uQ9ovA558hYw7nxkvg0mR0 YI3aqgW0IlBJZAhZl89gb5dEAWf9vcKyLHdsNve39m/Xdm2UWVjA8kvfZRu72K/llrAT v5Nw== X-Received: by 10.14.1.130 with SMTP id 2mr19150882eed.15.1363360536180; Fri, 15 Mar 2013 08:15:36 -0700 (PDT) Received: from [10.0.0.5] (bzq-109-64-148-173.red.bezeqint.net. [109.64.148.173]) by mx.google.com with ESMTPS id f47sm10604690eep.13.2013.03.15.08.15.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 08:15:35 -0700 (PDT) Message-ID: <51433B12.1020703@gmail.com> Date: Fri, 15 Mar 2013 17:15:30 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: cfrg@irtf.org, Mike Jones References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Cfrg] Draft describing encrypting JWK key representations, with JWE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 15:15:43 -0000 Hi Mike, I'm probably missing something, but I'm worried about the security of this scheme (though I do appreciate the usability/convenience of passwords). PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a second line defense, once the server has been breached. Using it to encrypt data and then sending the data on the wire, makes the data vulnerable to this same dictionary attack (in this case the effort comes to the space of all possible passwords - say 1 million - times 1000). Moreover, this also puts the password itself in danger. Thanks, Yaron > > ------------------------------ > > Message: 5 > Date: Fri, 15 Mar 2013 14:10:32 +0000 > From: Mike Jones > To: "cfrg@irtf.org" > Subject: [Cfrg] Draft describing encrypting JWK key representations > with JWE > Message-ID: > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp.microsoft.com> > > Content-Type: text/plain; charset="us-ascii" > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > This also adds password-based encryption to the algorithm registry. > > -- Mike > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > End of Cfrg Digest, Vol 95, Issue 3 > *********************************** > From bew@cisco.com Fri Mar 15 09:02:39 2013 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 026CA21F8803; Fri, 15 Mar 2013 09:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6mdtqJn8vSz; Fri, 15 Mar 2013 09:02:38 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 636D421F87EA; Fri, 15 Mar 2013 09:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=810; q=dns/txt; s=iport; t=1363363357; x=1364572957; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=ha6RSLJEZDJEYxfk/4Yyx3vnhywEXMFDjgy5rKJqh6k=; b=LxQDfJplWHE34m/6OI/ZvJbL8h4wJMstOJfFOxie+uZsUGDvSi6wt606 N9lnQ2/c3b9fdzNYnMPTUixp8x0X2QgayAX0R49n6OM4GMBg8Ma9lvcOA 8WGXnmRHyUzMq/PygO5BG8RdRMH7NS1Oo/ZMMbcEb1VpXkDQ0qsf8c91Z E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAI1EQ1GrRDoG/2dsb2JhbABDh2y/FxZ0gi+COhuICg3DBpF7YQOWW4V9iwWDJiA X-IronPort-AV: E=Sophos;i="4.84,850,1355097600"; d="scan'208";a="73044972" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 15 Mar 2013 16:00:59 +0000 Received: from [10.21.119.81] ([10.21.119.81]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2FG0qA2029693; Fri, 15 Mar 2013 16:00:58 GMT From: Brian Weis Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <31556AB6-899F-4D81-9FBC-40708864EA55@cisco.com> Date: Fri, 15 Mar 2013 11:42:52 -0400 To: jose@ietf.org, cfrg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [Cfrg] Use of authenticated encryption for key wrapping X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:02:39 -0000 Jim Schaad gave a presentation on JOSE to CFRG today = (). The = question came up as to whether AES key wrap was necessarily the only = method that was safe for key wrapping in JOSE. The other algorithm under = consideration is AES-GCM.=20 Section 3.1 of NIST 800-38F (Methods for Key Wrapping) says: "Previously approved authenticated-encryption modes=97as well as = combinations of an approved encryption mode with an approved = authentication method=97are approved for the protection of cryptographic = keys, in addition to general data." So if one considers that to be good enough advice, AES-GCM would indeed = be an acceptable method of key wrapping. The chairs asked me to = cross-post this for discussion. Brian=20= From Michael.Jones@microsoft.com Fri Mar 15 09:15:45 2013 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 AAAC121F85E0 for ; Fri, 15 Mar 2013 09:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNuHKu8nXDgz for ; Fri, 15 Mar 2013 09:15:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id A6B0921F86B8 for ; Fri, 15 Mar 2013 09:15:43 -0700 (PDT) Received: from BL2FFO11FD002.protection.gbl (10.173.161.203) by BL2FFO11HUB026.protection.gbl (10.173.161.50) with Microsoft SMTP Server (TLS) id 15.0.641.9; Fri, 15 Mar 2013 16:15:36 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD002.mail.protection.outlook.com (10.173.160.102) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Fri, 15 Mar 2013 16:15:36 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Fri, 15 Mar 2013 16:14:48 +0000 From: Mike Jones To: Yaron Sheffer , "cfrg@irtf.org" , "jose@ietf.org" Thread-Topic: Draft describing encrypting JWK key representations, with JWE Thread-Index: AQHOIY/+XkwMmtTxxUOFp1D/v1T3ZZim6+BA Date: Fri, 15 Mar 2013 16:14:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <51433B12.1020703@gmail.com> In-Reply-To: <51433B12.1020703@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(13464002)(51704002)(164054002)(189002)(199002)(59766001)(5343655001)(4396001)(79102001)(77982001)(50466001)(69226001)(65816001)(46102001)(49866001)(20776003)(33656001)(46406002)(50986001)(76482001)(551544001)(47446002)(16406001)(80022001)(512954001)(74662001)(63696002)(54316002)(74502001)(23726001)(15202345001)(47736001)(56776001)(44976002)(66066001)(31966008)(47976001)(55846006)(51856001)(5343635001)(53806001)(56816002)(47776003)(54356001)(563064004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB026; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078693968A Subject: Re: [Cfrg] Draft describing encrypting JWK key representations, with JWE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:15:46 -0000 [Adding JOSE mailing list to the thread] For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme. This draft *adds* PBKDF2 to the set of algorithms= already specified for use with encryption in the JSON Web Algorithms (JWA)= specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorit= hms-08). In particular, other algorithms such as AES Key Wrap and AES GCM = are also present there. I'll let others who are experts in PBKDF2 and password-based encryption res= pond to Yaron's specific comment. -- Mike -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 Sent: Friday, March 15, 2013 8:16 AM To: cfrg@irtf.org; Mike Jones Subject: Re: Draft describing encrypting JWK key representations, with JWE Hi Mike, I'm probably missing something, but I'm worried about the security of this = scheme (though I do appreciate the usability/convenience of passwords). PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of = all possible passwords - say 1 million - times 1000).=20 Moreover, this also puts the password itself in danger. Thanks, Yaron > > ------------------------------ > > Message: 5 > Date: Fri, 15 Mar 2013 14:10:32 +0000 > From: Mike Jones > To: "cfrg@irtf.org" > Subject: [Cfrg] Draft describing encrypting JWK key representations > with JWE > Message-ID: > =09 > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > microsoft.com> > =09 > Content-Type: text/plain; charset=3D"us-ascii" > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > This also adds password-based encryption to the algorithm registry. > > -- Mike > > -------------- next part -------------- An HTML attachment was=20 > scrubbed... > URL:=20 > 24/attachment.htm> > > ------------------------------ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > End of Cfrg Digest, Vol 95, Issue 3 > *********************************** > From Michael.Jones@microsoft.com Fri Mar 15 09:49:22 2013 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 3AEB521F84F9 for ; Fri, 15 Mar 2013 09:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45h1Iu6YoxKu for ; Fri, 15 Mar 2013 09:49:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id AA9A221F8488 for ; Fri, 15 Mar 2013 09:49:17 -0700 (PDT) Received: from BL2FFO11FD010.protection.gbl (10.173.161.200) by BL2FFO11HUB018.protection.gbl (10.173.160.110) with Microsoft SMTP Server (TLS) id 15.0.641.9; Fri, 15 Mar 2013 16:49:14 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Fri, 15 Mar 2013 16:49:14 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Fri, 15 Mar 2013 16:48:51 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] Draft describing encrypting JWK key representations, with JWE Thread-Index: AQHOIZw3PQRi1iNdgk2MdX9lp+JWfJim9Wcw Date: Fri, 15 Mar 2013 16:48:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367526789TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(164054002)(13464002)(51704002)(24454001)(199002)(377454001)(49866001)(51856001)(16236675001)(31966008)(20776003)(56816002)(76482001)(66066001)(5343655001)(16601075001)(5343635001)(50986001)(55846006)(16297215001)(65816001)(47446002)(46102001)(4396001)(74502001)(54356001)(74662001)(54316002)(56776001)(79102001)(53806001)(47976001)(80022001)(512954001)(44976002)(63696002)(47736001)(33656001)(59766001)(16406001)(77982001)(69226001)(551544001)(15202345001)(563064004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB018; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078693968A Cc: Yaron Sheffer , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] [jose] Draft describing encrypting JWK key representations, with JWE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:49:22 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367526789TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's up to the working group. I'm actually hoping that experts on the li= sts will respond to Yaron's comments before we make a decision on whether P= BKDF2 as specified is an appropriate key wrapping algorithm or not. Assuming that the content in Matt's draft eventually becomes an RFC or part= of one, the PBKDF2 definition would end up in the algorithms registry eith= er way, even if it's not part of the JWA spec itself. Cheers, -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Friday, March 15, 2013 9:43 AM To: Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, wi= th JWE So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key wrappi= ng algorithm? --Richard On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones > wrote: [Adding JOSE mailing list to the thread] For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme. This draft *adds* PBKDF2 to the set of algorithms= already specified for use with encryption in the JSON Web Algorithms (JWA)= specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorit= hms-08). In particular, other algorithms such as AES Key Wrap and AES GCM = are also present there. I'll let others who are experts in PBKDF2 and password-based encryption res= pond to Yaron's specific comment. -- Mike -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Friday, March 15, 2013 8:16 AM To: cfrg@irtf.org; Mike Jones Subject: Re: Draft describing encrypting JWK key representations, with JWE Hi Mike, I'm probably missing something, but I'm worried about the security of this = scheme (though I do appreciate the usability/convenience of passwords). PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of = all possible passwords - say 1 million - times 1000). Moreover, this also puts the password itself in danger. Thanks, Yaron > > ------------------------------ > > Message: 5 > Date: Fri, 15 Mar 2013 14:10:32 +0000 > From: Mike Jones > > To: "cfrg@irtf.org" > > Subject: [Cfrg] Draft describing encrypting JWK key representations > with JWE > Message-ID: > > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > microsoft.com> > > Content-Type: text/plain; charset=3D"us-ascii" > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > This also adds password-based encryption to the algorithm registry. > > -- Mike > > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > 24/attachment.htm> > > ------------------------------ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > End of Cfrg Digest, Vol 95, Issue 3 > *********************************** > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394367526789TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That’s up to the wo= rking group.  I’m actually hoping that experts on the lists will= respond to Yaron’s comments before we make a decision on whether PBK= DF2 as specified is an appropriate key wrapping algorithm or not.

 <= /p>

Assuming that the content= in Matt’s draft eventually becomes an RFC or part of one, the PBKDF2= definition would end up in the algorithms registry either way, even if it’s not part of the JWA spec itself.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Cheers,

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 9:43 AM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representati= ons, with JWE

 

So, Mike, would you be OK with adding PBE to JWE / J= WA, as a new key wrapping algorithm?

 

--Richard

 

 

 

On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

[Adding JOSE mailing list to the thread]

For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme.  This draft *adds* PBKDF2 to the set of algor= ithms already specified for use with encryption in the JSON Web Algorithms = (JWA) specification (http://tools.ietf.org/html/draft-= ietf-jose-json-web-algorithms-08).  In particular, other algorithms such as AES Key Wrap and AES GCM are= also present there.

I'll let others who are experts in PBKDF2 and password-based encryption res= pond to Yaron's specific comment.

                     = ;           -- Mike

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf= .ietf@gmail.com]
Sent: Friday, March 15, 2013 8:16 AM
To: cfrg@irtf.org; Mike Jones
Subject: Re: Draft describing encrypting JWK key representations, with JWE<= br>
Hi Mike,

I'm probably missing something, but I'm worried about the security of this = scheme (though I do appreciate the usability/convenience of passwords).

PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of all possible passwords - say 1 = million - times 1000).
Moreover, this also puts the password itself in danger.

Thanks,
        Yaron

>
> ------------------------------
>
> Message: 5
> Date: Fri, 15 Mar 2013 14:10:32 +0000
> From: Mike Jones <Mi= chael.Jones@microsoft.com>
> To: "cfrg@irtf.org" <= ;cfrg@irtf.org>
> Subject: [Cfrg] Draft describing encrypting JWK key representations >       with JWE
> Message-ID:
>
> <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14M= BXC284.redmond.corp.
> microsoft.com>
>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01
>
> This also adds password-based encryption to the algorithm registry. >
>                     =                      = ;                    -- M= ike
>
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> <http://www.irtf.org/mail-archive/web/cfrg= /attachments/20130315/02e36b
> 24/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>
>
> End of Cfrg Digest, Vol 95, Issue 3
> ***********************************
>
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B168042967394367526789TK5EX14MBXC284r_-- From n.brownlee@auckland.ac.nz Fri Mar 15 10:14:35 2013 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 2D9B421F8678 for ; Fri, 15 Mar 2013 10:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PezYWishjABq for ; Fri, 15 Mar 2013 10:14:33 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id BF3ED21F86CA for ; Fri, 15 Mar 2013 10:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1363367673; x=1394903673; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=fxWGvizyQ7et86Vu3NMeKdxOCnhaHgH25t7pUomxBCY=; b=XoRdmsBfSHmkZXtxJ+b21M/pe1wSwuOHro2gR1Z/MIgcPlWooeOvuJvH jH/TH4ntiXKyYLeLTWlO5YZ9NbcaqJ7pb7Tj6gAPcieGLYpehi097AhAa B/GFjRE2b/5HYZJLHPUb2pKOp8QAkhxt54ORQBFrPpOy7eeuek0Ywfz81 w=; X-IronPort-AV: E=Sophos;i="4.84,853,1355050800"; d="scan'208";a="175669149" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.16.71 - Outgoing - Outgoing-SSL Received: from dhcp-1047.meeting.ietf.org (HELO [130.129.16.71]) ([130.129.16.71]) by mx2-int.auckland.ac.nz with ESMTP; 16 Mar 2013 06:14:31 +1300 Message-ID: <514356F0.5030706@auckland.ac.nz> Date: Fri, 15 Mar 2013 10:14:24 -0700 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "cfrg@irtf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Cfrg] test message, please ignore X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:14:36 -0000 -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From Michael.Jones@microsoft.com Fri Mar 15 10:15:17 2013 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 43E2E21F87F9 for ; Fri, 15 Mar 2013 10:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjXq3kphCJiV for ; Fri, 15 Mar 2013 10:15:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id C98BF21F87DF for ; Fri, 15 Mar 2013 10:15:09 -0700 (PDT) Received: from BL2FFO11FD017.protection.gbl (10.173.161.204) by BL2FFO11HUB028.protection.gbl (10.173.161.52) with Microsoft SMTP Server (TLS) id 15.0.641.9; Fri, 15 Mar 2013 17:15:07 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD017.mail.protection.outlook.com (10.173.161.35) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Fri, 15 Mar 2013 17:15:06 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Fri, 15 Mar 2013 17:14:36 +0000 From: Mike Jones To: "Peck, Michael A" , Richard Barnes Thread-Topic: [jose] Draft describing encrypting JWK key representations, with JWE Thread-Index: Ac4hoJESkbPUau2CRd2Y+GZP3Ym7fQ== Date: Fri, 15 Mar 2013 17:14:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367527A20@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367527A20TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51914002)(377454001)(13464002)(51704002)(243025002)(124975001)(164054002)(24454001)(189002)(199002)(59766001)(5343655001)(4396001)(79102001)(77982001)(69226001)(46102001)(65816001)(20776003)(49866001)(76482001)(33656001)(50986001)(551544001)(80022001)(16406001)(74662001)(512954001)(47446002)(63696002)(54316002)(74502001)(15202345001)(56776001)(47736001)(44976002)(16601075001)(47976001)(66066001)(31966008)(55846006)(5343635001)(51856001)(53806001)(16236675001)(56816002)(16297215001)(54356001)(563064004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB028; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078693968A Cc: Yaron Sheffer , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] [jose] Draft describing encrypting JWK key representations, with JWE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:15:17 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367527A20TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the pointer to the NIST draft, Mike. I agree that having PBKDF2 would give applications additional choices, as y= ou suggest. As background for those of you who weren't at the JOSE WG meeting, I took a= n action item there to produce a security analysis of the direct encryption= mode. (I intend to consult experts on Microsoft's crypto board, among oth= ers. And CFRG input on that would obviously be great too!) I suspect that= the Security Considerations text arising from that will contain statements= about appropriately limiting the number of times a shared symmetric key is= used. Single use is clearly fine. Using a key forever certainly isn't in= most contexts. Are there references on appropriate limits on reuse of symmetric keys that = experts on this thread could point me to, since the direct encryption topic= came up? Thanks all, -- Mike From: Peck, Michael A [mailto:mpeck@mitre.org] Sent: Friday, March 15, 2013 9:59 AM To: Richard Barnes; Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: RE: [jose] Draft describing encrypting JWK key representations, wi= th JWE +1 NIST Special Publication 800-132 provides recommendations for the parameter= s that the group may find useful. http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf It may also be worth thinking about using PBKDF2 instead of the "dir" (Dire= ct Encryption with a Shared Symmetric Key) mechanism described in draft-iet= f-jose-json-web-algorithms-08 section 4.6. The shared symmetric key would = be used as the PBKDF2 "password", and this would force a new key to be used= for each encryption, rather than the current "dir" approach of using the s= ame encryption key repeatedly. Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Friday, March 15, 2013 12:53 PM To: Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, wi= th JWE Do I count as an expert? :) As I understand it, PBDKF2 is completely fine for key protection. PBKDF2 h= as mechanisms to mitigate the dictionary attack risks, e.g., having a high = number of iterations. We might want to make some recommendations as to how = you set those parameters. And the actual key wrapping is done with somethin= g like AES-KW, so that step is fine. So I would be completely fine with adding this to JWE / JWA. We should do = this. --Richard On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones > wrote: That's up to the working group. I'm actually hoping that experts on the li= sts will respond to Yaron's comments before we make a decision on whether P= BKDF2 as specified is an appropriate key wrapping algorithm or not. Assuming that the content in Matt's draft eventually becomes an RFC or part= of one, the PBKDF2 definition would end up in the algorithms registry eith= er way, even if it's not part of the JWA spec itself. Cheers, -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Friday, March 15, 2013 9:43 AM To: Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, wi= th JWE So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key wrappi= ng algorithm? --Richard On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones > wrote: [Adding JOSE mailing list to the thread] For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme. This draft *adds* PBKDF2 to the set of algorithms= already specified for use with encryption in the JSON Web Algorithms (JWA)= specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorit= hms-08). In particular, other algorithms such as AES Key Wrap and AES GCM = are also present there. I'll let others who are experts in PBKDF2 and password-based encryption res= pond to Yaron's specific comment. -- Mike -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Friday, March 15, 2013 8:16 AM To: cfrg@irtf.org; Mike Jones Subject: Re: Draft describing encrypting JWK key representations, with JWE Hi Mike, I'm probably missing something, but I'm worried about the security of this = scheme (though I do appreciate the usability/convenience of passwords). PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of = all possible passwords - say 1 million - times 1000). Moreover, this also puts the password itself in danger. Thanks, Yaron > > ------------------------------ > > Message: 5 > Date: Fri, 15 Mar 2013 14:10:32 +0000 > From: Mike Jones > > To: "cfrg@irtf.org" > > Subject: [Cfrg] Draft describing encrypting JWK key representations > with JWE > Message-ID: > > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > microsoft.com> > > Content-Type: text/plain; charset=3D"us-ascii" > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > This also adds password-based encryption to the algorithm registry. > > -- Mike > > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > 24/attachment.htm> > > ------------------------------ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > End of Cfrg Digest, Vol 95, Issue 3 > *********************************** > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394367527A20TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the pointer to= the NIST draft, Mike.

 <= /p>

I agree that having PBKDF= 2 would give applications additional choices, as you suggest.

 <= /p>

As background for those o= f you who weren’t at the JOSE WG meeting, I took an action item there= to produce a security analysis of the direct encryption mode.  (I intend to consult experts on Microsoft’s crypto board, among othe= rs.  And CFRG input on that would obviously be great too!)  I sus= pect that the Security Considerations text arising from that will contain s= tatements about appropriately limiting the number of times a shared symmetric key is used.  Single use is clearly fine.=   Using a key forever certainly isn’t in most contexts.

 <= /p>

Are there references on a= ppropriate limits on reuse of symmetric keys that experts on this thread co= uld point me to, since the direct encryption topic came up?

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks all,

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: Peck, Mi= chael A [mailto:mpeck@mitre.org]
Sent: Friday, March 15, 2013 9:59 AM
To: Richard Barnes; Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: RE: [jose] Draft describing encrypting JWK key representati= ons, with JWE

 

+1<= /p>

 <= /p>

NIST Special Publication = 800-132 provides recommendations for the parameters that the group may find= useful.

http://csrc.nist.g= ov/publications/nistpubs/800-132/nist-sp800-132.pdf

 <= /p>

It may also be worth thin= king about using PBKDF2 instead of the “dir” (Direct Encryption= with a Shared Symmetric Key) mechanism described in draft-ietf-jose-json-w= eb-algorithms-08 section 4.6.  The shared symmetric key would be used as the PBKDF2 &#= 8220;password”, and this would force a new key to be used for each en= cryption, rather than the current “dir” approach of using the s= ame encryption key repeatedly.

 <= /p>

Mike

 <= /p>

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 12:53 PM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representati= ons, with JWE

 

Do I count as an expert?  :)

 

As I understand it, PBDKF2 is completely fine for ke= y protection.  PBKDF2 has mechanisms to mitigate the dictionary attack= risks, e.g., having a high number of iterations. We might want to make som= e recommendations as to how you set those parameters. And the actual key wrapping is done with something like AES-KW= , so that step is fine.

 

So I would be completely fine with adding this to JW= E / JWA.  We should do this.

 

--Richard

 

 

On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

That’s up to the working group. &= nbsp;I’m actually hoping that experts on the lists will respond to Ya= ron’s comments before we make a decision on whether PBKDF2 as specified is an ap= propriate key wrapping algorithm or not.

 

Assuming that the content in Matt’= ;s draft eventually becomes an RFC or part of one, the PBKDF2 definition would end up in the algorithms registry either way, even if it’s not= part of the JWA spec itself.

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   Cheers,

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   -- Mike

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 9:43 AM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representati= ons, with JWE

 

So, Mike, would you be OK with adding PBE to JWE / JWA, as a new k= ey wrapping algorithm?

 

--Richard

 

 

 

On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones <Michael.Jones@microsoft.com= > wrote:

[Adding JOSE mailing list to the thread]

For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme.  This draft *adds* PBKDF2 to the set of algor= ithms already specified for use with encryption in the JSON Web Algorithms = (JWA) specification (http://tools.ietf.org/html/draft-= ietf-jose-json-web-algorithms-08).  In particular, other algorithms such as AES Key Wrap and AES GCM are= also present there.

I'll let others who are experts in PBKDF2 and password-based encryption res= pond to Yaron's specific comment.

                     = ;           -- Mike

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Friday, March 15, 2013 8:16 AM
To: cfrg@irtf.org; M= ike Jones
Subject: Re: Draft describing encrypting JWK key representations, with JWE<= br>
Hi Mike,

I'm probably missing something, but I'm worried about the security of this = scheme (though I do appreciate the usability/convenience of passwords).

PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of all possible passwords - say 1 = million - times 1000).
Moreover, this also puts the password itself in danger.

Thanks,
        Yaron

>
> ------------------------------
>
> Message: 5
> Date: Fri, 15 Mar 2013 14:10:32 +0000
> From: Mike Jones <Michael.Jones@microsoft.com>
> To: "cfrg@irtf= .org" <cfrg@= irtf.org>
> Subject: [Cfrg] Draft describing encrypting JWK key representations >       with JWE
> Message-ID:
>
> <4E1F6AAD24975D4BA5B168042967394= 367522C60@TK5EX14MBXC284.redmond.corp.
> microsoft.com>
>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01
>
> This also adds password-based encryption to the algorithm registry. >
>                     =                      = ;                    -- M= ike
>
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> <http://www.irtf.org/mail-archive/web/cfrg= /attachments/20130315/02e36b
> 24/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg
>
>
> End of Cfrg Digest, Vol 95, Issue 3
> ***********************************
>
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

 

--_000_4E1F6AAD24975D4BA5B168042967394367527A20TK5EX14MBXC284r_-- From yaronf.ietf@gmail.com Fri Mar 15 10:42:32 2013 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 8137F21F8960 for ; Fri, 15 Mar 2013 10:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYqGH9893AeK for ; Fri, 15 Mar 2013 10:42:31 -0700 (PDT) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 01BBD21F87ED for ; Fri, 15 Mar 2013 10:42:22 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id b57so1688490eek.4 for ; Fri, 15 Mar 2013 10:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=v9YhPNtjWvRHBRKnuXjOOU63Alj156K+GGVTlyj7jVY=; b=MFUD9mflYqOjNwzTk2xM9rcrjayXtwgrXsFMezgBtABj4OF7SwsfH2J29y6VMfEXti bm+bXtlDqAiaYS4F7gm8KkiSpsDmiPqdfnSfap3klEZTNO0Zq0sz1lYI3Mp0/yw5jM1h zu3jMbiDH2n4JzjLsO2dXPKeANe7LUxNH7q+QEH3POQb6Fc8ARJ5sDA3da2wBGRSzWQ8 dtHQBbw351R8YptsLOmlR8JwlZDZHJaIJgjy74fkwYVUrJ4Ucya9Xi9YBZH/ATqt3vY+ 8EQtSUtp5ZO+S3mwZtt8EPfHV+GctOeceH12kCjTz8oVpMHK8nzXDvSu4kSBa1K8gesS FzGQ== X-Received: by 10.14.216.198 with SMTP id g46mr20208470eep.30.1363369342068; Fri, 15 Mar 2013 10:42:22 -0700 (PDT) Received: from [10.0.0.5] (bzq-109-64-148-173.red.bezeqint.net. [109.64.148.173]) by mx.google.com with ESMTPS id ca4sm11363943eeb.15.2013.03.15.10.42.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 10:42:21 -0700 (PDT) Message-ID: <51435D7A.7050800@gmail.com> Date: Fri, 15 Mar 2013 19:42:18 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Peck, Michael A" References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Richard Barnes , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] [jose] Draft describing encrypting JWK key representations, with JWE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:42:32 -0000 Hi Mike and Mike, The NIST SP is about using PBKDF2 for storage encryption (which I'm not thrilled with, either). Not for sending the encrypted blob over the wire, for an attacker to intercept and decrypt off-line. And if we read the NIST document, let's adopt the whole thing - quoting from sec. A.1: "Passwords shorter than 10 characters are usually considered to be weak." Are we going to make this recommendation too? Well I guess not. *Please* do not mix passwords with cryptographic keys. If the WG goes through the risk vs. benefit analysis and decides to have a password-based mechanism, fine. But please leave the shared-key mechanism as-is. It's important that readers of JOSE specs are very clear about the difference between randomly generated keys and user-memorable (or even -generated) passwords. Let's be clear: even a single use of a user-generated password for on-the-wire encryption is risky. So-called key rotation of actual cryptographic keys is a whole different matter. Thanks, Yaron On 03/15/2013 06:58 PM, Peck, Michael A wrote: > +1 > > NIST Special Publication 800-132 provides recommendations for the > parameters that the group may find useful. > > http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf > > It may also be worth thinking about using PBKDF2 instead of the “dir” > (Direct Encryption with a Shared Symmetric Key) mechanism described in > draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared > symmetric key would be used as the PBKDF2 “password”, and this would > force a new key to be used for each encryption, rather than the current > “dir” approach of using the same encryption key repeatedly. > > Mike > > *From:*jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Friday, March 15, 2013 12:53 PM > *To:* Mike Jones > *Cc:* Yaron Sheffer; cfrg@irtf.org; jose@ietf.org > *Subject:* Re: [jose] Draft describing encrypting JWK key > representations, with JWE > > Do I count as an expert? :) > > As I understand it, PBDKF2 is completely fine for key protection. > PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., > having a high number of iterations. We might want to make some > recommendations as to how you set those parameters. And the actual key > wrapping is done with something like AES-KW, so that step is fine. > > So I would be completely fine with adding this to JWE / JWA. We should > do this. > > --Richard > > On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones > > wrote: > > That’s up to the working group. I’m actually hoping that experts on the > lists will respond to Yaron’s comments before we make a decision on > whether PBKDF2 as specified is an appropriate key wrapping algorithm or not. > > Assuming that the content in Matt’s draft eventually becomes an RFC or > part of one, the PBKDF2 definition would end up in the algorithms > registry either way, even if it’s not part of the JWA spec itself. > > Cheers, > > -- Mike > > *From:*jose-bounces@ietf.org > [mailto:jose-bounces@ietf.org ] *On Behalf > Of *Richard Barnes > *Sent:* Friday, March 15, 2013 9:43 AM > *To:* Mike Jones > *Cc:* Yaron Sheffer; cfrg@irtf.org ; jose@ietf.org > > *Subject:* Re: [jose] Draft describing encrypting JWK key > representations, with JWE > > So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key > wrapping algorithm? > > --Richard > > On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones > > wrote: > > [Adding JOSE mailing list to the thread] > > For clarification, PBKDF2 is not the only algorithm that could be used > to wrap keys in this scheme. This draft *adds* PBKDF2 to the set of > algorithms already specified for use with encryption in the JSON Web > Algorithms (JWA) specification > (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). In > particular, other algorithms such as AES Key Wrap and AES GCM are also > present there. > > I'll let others who are experts in PBKDF2 and password-based encryption > respond to Yaron's specific comment. > > -- Mike > > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com > ] > Sent: Friday, March 15, 2013 8:16 AM > To: cfrg@irtf.org ; Mike Jones > Subject: Re: Draft describing encrypting JWK key representations, with JWE > > Hi Mike, > > I'm probably missing something, but I'm worried about the security of > this scheme (though I do appreciate the usability/convenience of passwords). > > PBKDF2 is meant to make dictionary attacks on stored passwords harder, > as a second line defense, once the server has been breached. Using it to > encrypt data and then sending the data on the wire, makes the data > vulnerable to this same dictionary attack (in this case the effort comes > to the space of all possible passwords - say 1 million - times 1000). > Moreover, this also puts the password itself in danger. > > Thanks, > Yaron > > > > > ------------------------------ > > > > Message: 5 > > Date: Fri, 15 Mar 2013 14:10:32 +0000 > > From: Mike Jones > > > To: "cfrg@irtf.org " > > > Subject: [Cfrg] Draft describing encrypting JWK key representations > > with JWE > > Message-ID: > > > > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > > > microsoft.com > > > > > Content-Type: text/plain; charset="us-ascii" > > > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > > > This also adds password-based encryption to the algorithm registry. > > > > -- Mike > > > > -------------- next part -------------- An HTML attachment was > > scrubbed... > > URL: > > > 24/attachment.htm> > > > > ------------------------------ > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > http://www.irtf.org/mailman/listinfo/cfrg > > > > > > End of Cfrg Digest, Vol 95, Issue 3 > > *********************************** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From mpeck@mitre.org Fri Mar 15 10:55:47 2013 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 9FBB321F8948 for ; Fri, 15 Mar 2013 10:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiH2hF56Pdf5 for ; Fri, 15 Mar 2013 10:55:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6621621F8945 for ; Fri, 15 Mar 2013 10:55:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0BEC31F03F4; Fri, 15 Mar 2013 13:55:46 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EDE5C1F03F2; Fri, 15 Mar 2013 13:55:45 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.94]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0342.003; Fri, 15 Mar 2013 13:55:46 -0400 From: "Peck, Michael A" To: Yaron Sheffer Thread-Topic: [jose] Draft describing encrypting JWK key representations, with JWE Thread-Index: AQHOIaVNCf0r3dt6lkWnLIyRUNEE4ZinB6HA Date: Fri, 15 Mar 2013 17:55:45 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFD5FBC@IMCMBX04.MITRE.ORG> References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> <51435D7A.7050800@gmail.com> In-Reply-To: <51435D7A.7050800@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] [jose] Draft describing encrypting JWK key representations, with JWE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:55:47 -0000 I'll try to clarify (and hopefully not dig a deeper hole). JWE currently provides a "dir" mechanism allowing a symmetric key previousl= y agreed to out of band to be used for content encryption. All of the other JWE mechanisms use a fresh symmetric key for each encrypti= on. My suggestion was that instead of directly using the pre-shared symmetric k= ey to encrypt content, if JWE makes the PBKDF2 mechanism available the symm= etric key could be used as the PBKDF2 "password", resulting in a fresh key = generated for each content encryption. In this particular case the passwor= d input to PBKDF2 would hopefully be very random - I would think there woul= d be no more risk than using the pre-shared key directly, rather less risk. General password considerations are a different matter. Passwords have lot= s of issues but if we're stuck with them we should at least advise how to d= o the best we can. Mike >-----Original Message----- >From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >Sent: Friday, March 15, 2013 1:42 PM >To: Peck, Michael A >Cc: Richard Barnes; Mike Jones; cfrg@irtf.org; jose@ietf.org >Subject: Re: [jose] Draft describing encrypting JWK key representations, w= ith >JWE > >Hi Mike and Mike, > >The NIST SP is about using PBKDF2 for storage encryption (which I'm not >thrilled with, either). Not for sending the encrypted blob over the >wire, for an attacker to intercept and decrypt off-line. And if we read >the NIST document, let's adopt the whole thing - quoting from sec. A.1: >"Passwords shorter than 10 characters are usually considered to be >weak." Are we going to make this recommendation too? Well I guess not. > >*Please* do not mix passwords with cryptographic keys. If the WG goes >through the risk vs. benefit analysis and decides to have a >password-based mechanism, fine. But please leave the shared-key >mechanism as-is. It's important that readers of JOSE specs are very >clear about the difference between randomly generated keys and >user-memorable (or even -generated) passwords. > >Let's be clear: even a single use of a user-generated password for >on-the-wire encryption is risky. So-called key rotation of actual >cryptographic keys is a whole different matter. > >Thanks, > Yaron > > >On 03/15/2013 06:58 PM, Peck, Michael A wrote: >> +1 >> >> NIST Special Publication 800-132 provides recommendations for the >> parameters that the group may find useful. >> >> http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf >> >> It may also be worth thinking about using PBKDF2 instead of the "dir" >> (Direct Encryption with a Shared Symmetric Key) mechanism described in >> draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared >> symmetric key would be used as the PBKDF2 "password", and this would >> force a new key to be used for each encryption, rather than the current >> "dir" approach of using the same encryption key repeatedly. >> >> Mike >> >> *From:*jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >> Of *Richard Barnes >> *Sent:* Friday, March 15, 2013 12:53 PM >> *To:* Mike Jones >> *Cc:* Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >> *Subject:* Re: [jose] Draft describing encrypting JWK key >> representations, with JWE >> >> Do I count as an expert? :) >> >> As I understand it, PBDKF2 is completely fine for key protection. >> PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., >> having a high number of iterations. We might want to make some >> recommendations as to how you set those parameters. And the actual key >> wrapping is done with something like AES-KW, so that step is fine. >> >> So I would be completely fine with adding this to JWE / JWA. We should >> do this. >> >> --Richard >> >> On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones >> > >wrote: >> >> That's up to the working group. I'm actually hoping that experts on the >> lists will respond to Yaron's comments before we make a decision on >> whether PBKDF2 as specified is an appropriate key wrapping algorithm or >not. >> >> Assuming that the content in Matt's draft eventually becomes an RFC or >> part of one, the PBKDF2 definition would end up in the algorithms >> registry either way, even if it's not part of the JWA spec itself. >> >> Cheers, >> >> -- Mike >> >> *From:*jose-bounces@ietf.org >> [mailto:jose-bounces@ietf.org ] *On >Behalf >> Of *Richard Barnes >> *Sent:* Friday, March 15, 2013 9:43 AM >> *To:* Mike Jones >> *Cc:* Yaron Sheffer; cfrg@irtf.org ; jose@ietf.org >> >> *Subject:* Re: [jose] Draft describing encrypting JWK key >> representations, with JWE >> >> So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key >> wrapping algorithm? >> >> --Richard >> >> On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones >> > >wrote: >> >> [Adding JOSE mailing list to the thread] >> >> For clarification, PBKDF2 is not the only algorithm that could be used >> to wrap keys in this scheme. This draft *adds* PBKDF2 to the set of >> algorithms already specified for use with encryption in the JSON Web >> Algorithms (JWA) specification >> (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). In >> particular, other algorithms such as AES Key Wrap and AES GCM are also >> present there. >> >> I'll let others who are experts in PBKDF2 and password-based encryption >> respond to Yaron's specific comment. >> >> -- Mike >> >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com >> ] >> Sent: Friday, March 15, 2013 8:16 AM >> To: cfrg@irtf.org ; Mike Jones >> Subject: Re: Draft describing encrypting JWK key representations, with J= WE >> >> Hi Mike, >> >> I'm probably missing something, but I'm worried about the security of >> this scheme (though I do appreciate the usability/convenience of >passwords). >> >> PBKDF2 is meant to make dictionary attacks on stored passwords harder, >> as a second line defense, once the server has been breached. Using it to >> encrypt data and then sending the data on the wire, makes the data >> vulnerable to this same dictionary attack (in this case the effort comes >> to the space of all possible passwords - say 1 million - times 1000). >> Moreover, this also puts the password itself in danger. >> >> Thanks, >> Yaron >> >> > >> > ------------------------------ >> > >> > Message: 5 >> > Date: Fri, 15 Mar 2013 14:10:32 +0000 >> > From: Mike Jones > > >> > To: "cfrg@irtf.org " > > >> > Subject: [Cfrg] Draft describing encrypting JWK key representations >> > with JWE >> > Message-ID: >> > >> > ><4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmon >d.corp. >> >edmond.corp.%0b>> >> microsoft.com > >> > >> > Content-Type: text/plain; charset=3D"us-ascii" >> > >> > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 >> > >> > This also adds password-based encryption to the algorithm registry. >> > >> > -- Mike >> > >> > -------------- next part -------------- An HTML attachment was >> > scrubbed... >> > URL: >> > archive/web/cfrg/attachments/20130315/02e36b >> > 24/attachment.htm> >> > >> > ------------------------------ >> > >> > _______________________________________________ >> > Cfrg mailing list >> > Cfrg@irtf.org >> > http://www.irtf.org/mailman/listinfo/cfrg >> > >> > >> > End of Cfrg Digest, Vol 95, Issue 3 >> > *********************************** >> > >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> From yaronf.ietf@gmail.com Fri Mar 15 11:20:37 2013 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 81D8521F8536 for ; Fri, 15 Mar 2013 11:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.239 X-Spam-Level: X-Spam-Status: No, score=-103.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjPkPnSbhmSK for ; Fri, 15 Mar 2013 11:20:36 -0700 (PDT) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9CC21F84A1 for ; Fri, 15 Mar 2013 11:20:35 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id c13so1785044eek.0 for ; Fri, 15 Mar 2013 11:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WTkO75xO7uTe3BzUnqHpJZPjLYfxcvaQ6VQrsy2BjGQ=; b=JlazpskRgq9VpETqiEZSXTPPxOavHe0cJgkpFuBaQZPUOuGbVpjwrnCa0aq7HxIO+6 LnGHq+3xDuwjP/OQH4BNC8Cb4Ec2Nf6d/GJfcgZ9/P1TljO3jW3e/LkDLw5HgK9cxzKf E5RH6l84wutVSqM3jBbaqYQlK8OaEKtlhpZlYFClnhUhunGwgQX97W2TUNys5j9AeI7d LCirIc7bJdcrr7TGZhIWI0dpcjIs46spnqG/cU9WOe1qBosWxhPX3613kBgrj1dcNF9i 81h5M0xqPB0FqVoloxMJnfZ6pOM7odZ9CeQEi0iIK86fUSABDdDFMI7bdq9f4GX2EbbJ Z7zA== X-Received: by 10.15.45.201 with SMTP id b49mr20880776eew.9.1363371635001; Fri, 15 Mar 2013 11:20:35 -0700 (PDT) Received: from [10.0.0.5] (bzq-109-64-148-173.red.bezeqint.net. [109.64.148.173]) by mx.google.com with ESMTPS id q5sm11568556eeo.17.2013.03.15.11.20.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 11:20:34 -0700 (PDT) Message-ID: <5143666F.7080701@gmail.com> Date: Fri, 15 Mar 2013 20:20:31 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Peck, Michael A" References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> <51435D7A.7050800@gmail.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5FBC@IMCMBX04.MITRE.ORG> In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFD5FBC@IMCMBX04.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Richard Barnes , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] [jose] Draft describing encrypting JWK key representations, with JWE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 18:20:37 -0000 Hi Mike, I understand your point, I believe. At the technical level, using PBKDF2 for crypto keys simply does not buy you any security, but has a high cost in performance (the performance cost is after all the whole point of PBKDF2). But the more important level is educational: I suggest that the document should make a very clear distinction between passwords and keys, so that implementors know what they're dealing with and the risks involved. Using password processing for keys would go against this goal. Thanks, Yaron On 03/15/2013 07:55 PM, Peck, Michael A wrote: > I'll try to clarify (and hopefully not dig a deeper hole). > > JWE currently provides a "dir" mechanism allowing a symmetric key previously agreed to out of band to be used for content encryption. > All of the other JWE mechanisms use a fresh symmetric key for each encryption. > > My suggestion was that instead of directly using the pre-shared symmetric key to encrypt content, if JWE makes the PBKDF2 mechanism available the symmetric key could be used as the PBKDF2 "password", resulting in a fresh key generated for each content encryption. In this particular case the password input to PBKDF2 would hopefully be very random - I would think there would be no more risk than using the pre-shared key directly, rather less risk. > > General password considerations are a different matter. Passwords have lots of issues but if we're stuck with them we should at least advise how to do the best we can. > > Mike > >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Friday, March 15, 2013 1:42 PM >> To: Peck, Michael A >> Cc: Richard Barnes; Mike Jones; cfrg@irtf.org; jose@ietf.org >> Subject: Re: [jose] Draft describing encrypting JWK key representations, with >> JWE >> >> Hi Mike and Mike, >> >> The NIST SP is about using PBKDF2 for storage encryption (which I'm not >> thrilled with, either). Not for sending the encrypted blob over the >> wire, for an attacker to intercept and decrypt off-line. And if we read >> the NIST document, let's adopt the whole thing - quoting from sec. A.1: >> "Passwords shorter than 10 characters are usually considered to be >> weak." Are we going to make this recommendation too? Well I guess not. >> >> *Please* do not mix passwords with cryptographic keys. If the WG goes >> through the risk vs. benefit analysis and decides to have a >> password-based mechanism, fine. But please leave the shared-key >> mechanism as-is. It's important that readers of JOSE specs are very >> clear about the difference between randomly generated keys and >> user-memorable (or even -generated) passwords. >> >> Let's be clear: even a single use of a user-generated password for >> on-the-wire encryption is risky. So-called key rotation of actual >> cryptographic keys is a whole different matter. >> >> Thanks, >> Yaron >> >> >> On 03/15/2013 06:58 PM, Peck, Michael A wrote: >>> +1 >>> >>> NIST Special Publication 800-132 provides recommendations for the >>> parameters that the group may find useful. >>> >>> http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf >>> >>> It may also be worth thinking about using PBKDF2 instead of the "dir" >>> (Direct Encryption with a Shared Symmetric Key) mechanism described in >>> draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared >>> symmetric key would be used as the PBKDF2 "password", and this would >>> force a new key to be used for each encryption, rather than the current >>> "dir" approach of using the same encryption key repeatedly. >>> >>> Mike >>> >>> *From:*jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >>> Of *Richard Barnes >>> *Sent:* Friday, March 15, 2013 12:53 PM >>> *To:* Mike Jones >>> *Cc:* Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >>> *Subject:* Re: [jose] Draft describing encrypting JWK key >>> representations, with JWE >>> >>> Do I count as an expert? :) >>> >>> As I understand it, PBDKF2 is completely fine for key protection. >>> PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., >>> having a high number of iterations. We might want to make some >>> recommendations as to how you set those parameters. And the actual key >>> wrapping is done with something like AES-KW, so that step is fine. >>> >>> So I would be completely fine with adding this to JWE / JWA. We should >>> do this. >>> >>> --Richard >>> >>> On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones >>> > >> wrote: >>> >>> That's up to the working group. I'm actually hoping that experts on the >>> lists will respond to Yaron's comments before we make a decision on >>> whether PBKDF2 as specified is an appropriate key wrapping algorithm or >> not. >>> >>> Assuming that the content in Matt's draft eventually becomes an RFC or >>> part of one, the PBKDF2 definition would end up in the algorithms >>> registry either way, even if it's not part of the JWA spec itself. >>> >>> Cheers, >>> >>> -- Mike >>> >>> *From:*jose-bounces@ietf.org >>> [mailto:jose-bounces@ietf.org ] *On >> Behalf >>> Of *Richard Barnes >>> *Sent:* Friday, March 15, 2013 9:43 AM >>> *To:* Mike Jones >>> *Cc:* Yaron Sheffer; cfrg@irtf.org ; jose@ietf.org >>> >>> *Subject:* Re: [jose] Draft describing encrypting JWK key >>> representations, with JWE >>> >>> So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key >>> wrapping algorithm? >>> >>> --Richard >>> >>> On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones >>> > >> wrote: >>> >>> [Adding JOSE mailing list to the thread] >>> >>> For clarification, PBKDF2 is not the only algorithm that could be used >>> to wrap keys in this scheme. This draft *adds* PBKDF2 to the set of >>> algorithms already specified for use with encryption in the JSON Web >>> Algorithms (JWA) specification >>> (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). In >>> particular, other algorithms such as AES Key Wrap and AES GCM are also >>> present there. >>> >>> I'll let others who are experts in PBKDF2 and password-based encryption >>> respond to Yaron's specific comment. >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com >>> ] >>> Sent: Friday, March 15, 2013 8:16 AM >>> To: cfrg@irtf.org ; Mike Jones >>> Subject: Re: Draft describing encrypting JWK key representations, with JWE >>> >>> Hi Mike, >>> >>> I'm probably missing something, but I'm worried about the security of >>> this scheme (though I do appreciate the usability/convenience of >> passwords). >>> >>> PBKDF2 is meant to make dictionary attacks on stored passwords harder, >>> as a second line defense, once the server has been breached. Using it to >>> encrypt data and then sending the data on the wire, makes the data >>> vulnerable to this same dictionary attack (in this case the effort comes >>> to the space of all possible passwords - say 1 million - times 1000). >>> Moreover, this also puts the password itself in danger. >>> >>> Thanks, >>> Yaron >>> >>> > >>> > ------------------------------ >>> > >>> > Message: 5 >>> > Date: Fri, 15 Mar 2013 14:10:32 +0000 >>> > From: Mike Jones >> > >>> > To: "cfrg@irtf.org " >> > >>> > Subject: [Cfrg] Draft describing encrypting JWK key representations >>> > with JWE >>> > Message-ID: >>> > >>> > >> <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmon >> d.corp. >>> >> > edmond.corp.%0b>> >>> microsoft.com > >>> > >>> > Content-Type: text/plain; charset="us-ascii" >>> > >>> > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 >>> > >>> > This also adds password-based encryption to the algorithm registry. >>> > >>> > -- Mike >>> > >>> > -------------- next part -------------- An HTML attachment was >>> > scrubbed... >>> > URL: >>> > > archive/web/cfrg/attachments/20130315/02e36b >>> > 24/attachment.htm> >>> > >>> > ------------------------------ >>> > >>> > _______________________________________________ >>> > Cfrg mailing list >>> > Cfrg@irtf.org >>> > http://www.irtf.org/mailman/listinfo/cfrg >>> > >>> > >>> > End of Cfrg Digest, Vol 95, Issue 3 >>> > *********************************** >>> > >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> From ietf@augustcellars.com Fri Mar 15 11:36:46 2013 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 330FC21F89EE for ; Fri, 15 Mar 2013 11:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.373 X-Spam-Level: X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tw69aBC1rIt for ; Fri, 15 Mar 2013 11:36:42 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id B461A21F898B for ; Fri, 15 Mar 2013 11:36:42 -0700 (PDT) Received: from Philemon (dhcp-1431.meeting.ietf.org [130.129.20.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 3CD662CA0B; Fri, 15 Mar 2013 11:36:41 -0700 (PDT) From: "Jim Schaad" To: "'Peck, Michael A'" , "'Richard Barnes'" , "'Mike Jones'" References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> Date: Fri, 15 Mar 2013 14:36:07 -0400 Message-ID: <07c801ce21ab$f63d74b0$e2b85e10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C9_01CE218A.6F30DDC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWSvveXif1uBJMdQIlAIR3tfOciwIBGSONAb2I7vQB2Zw5NAJhN+hpAaclu5ICD9JAc5g5Pjfw Content-Language: en-us Cc: 'Yaron Sheffer' , cfrg@irtf.org, jose@ietf.org Subject: Re: [Cfrg] [jose] Draft describing encrypting JWK key representations, with JWE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 18:36:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07C9_01CE218A.6F30DDC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Use PBKDF2 as a general key wrap mechanism seems to be a bad idea. Take the key and use it as a key wrap key for randomly generated content encryption key. Thus alg should be "AES128KW" rather than direct. Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Peck, Michael A Sent: Friday, March 15, 2013 12:59 PM To: Richard Barnes; Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE +1 NIST Special Publication 800-132 provides recommendations for the parameters that the group may find useful. http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf It may also be worth thinking about using PBKDF2 instead of the "dir" (Direct Encryption with a Shared Symmetric Key) mechanism described in draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared symmetric key would be used as the PBKDF2 "password", and this would force a new key to be used for each encryption, rather than the current "dir" approach of using the same encryption key repeatedly. Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Friday, March 15, 2013 12:53 PM To: Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE Do I count as an expert? :) As I understand it, PBDKF2 is completely fine for key protection. PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., having a high number of iterations. We might want to make some recommendations as to how you set those parameters. And the actual key wrapping is done with something like AES-KW, so that step is fine. So I would be completely fine with adding this to JWE / JWA. We should do this. --Richard On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones wrote: That's up to the working group. I'm actually hoping that experts on the lists will respond to Yaron's comments before we make a decision on whether PBKDF2 as specified is an appropriate key wrapping algorithm or not. Assuming that the content in Matt's draft eventually becomes an RFC or part of one, the PBKDF2 definition would end up in the algorithms registry either way, even if it's not part of the JWA spec itself. Cheers, -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Friday, March 15, 2013 9:43 AM To: Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key wrapping algorithm? --Richard On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones wrote: [Adding JOSE mailing list to the thread] For clarification, PBKDF2 is not the only algorithm that could be used to wrap keys in this scheme. This draft *adds* PBKDF2 to the set of algorithms already specified for use with encryption in the JSON Web Algorithms (JWA) specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). In particular, other algorithms such as AES Key Wrap and AES GCM are also present there. I'll let others who are experts in PBKDF2 and password-based encryption respond to Yaron's specific comment. -- Mike -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Friday, March 15, 2013 8:16 AM To: cfrg@irtf.org; Mike Jones Subject: Re: Draft describing encrypting JWK key representations, with JWE Hi Mike, I'm probably missing something, but I'm worried about the security of this scheme (though I do appreciate the usability/convenience of passwords). PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a second line defense, once the server has been breached. Using it to encrypt data and then sending the data on the wire, makes the data vulnerable to this same dictionary attack (in this case the effort comes to the space of all possible passwords - say 1 million - times 1000). Moreover, this also puts the password itself in danger. Thanks, Yaron > > ------------------------------ > > Message: 5 > Date: Fri, 15 Mar 2013 14:10:32 +0000 > From: Mike Jones > To: "cfrg@irtf.org" > Subject: [Cfrg] Draft describing encrypting JWK key representations > with JWE > Message-ID: > > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > microsoft.com> > > Content-Type: text/plain; charset="us-ascii" > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > This also adds password-based encryption to the algorithm registry. > > -- Mike > > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > 24/attachment.htm> > > ------------------------------ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > End of Cfrg Digest, Vol 95, Issue 3 > *********************************** > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ------=_NextPart_000_07C9_01CE218A.6F30DDC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Use PBKDF2 as a general key wrap mechanism seems to be a bad = idea.  Take the key and use it as a key wrap key for randomly = generated content encryption key.  Thus alg should be = “AES128KW” rather than direct.

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Peck, Michael A
Sent: Friday, March 15, 2013 12:59 = PM
To: Richard Barnes; Mike Jones
Cc: Yaron Sheffer; = cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft = describing encrypting JWK key representations, with = JWE

 

+1

 

NIST Special Publication 800-132 provides recommendations for the = parameters that the group may find useful.

http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.p= df

 

It may also be worth thinking about using PBKDF2 instead of the = “dir” (Direct Encryption with a Shared Symmetric Key) = mechanism described in draft-ietf-jose-json-web-algorithms-08 section = 4.6.  The shared symmetric key would be used as the PBKDF2 = “password”, and this would force a new key to be used for = each encryption, rather than the current “dir” approach of = using the same encryption key repeatedly.

 

Mike

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Richard Barnes
Sent: Friday, March 15, = 2013 12:53 PM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: = [jose] Draft describing encrypting JWK key representations, with = JWE

 

Do I count = as an expert?  :)

 

As I understand it, PBDKF2 is completely fine for key = protection.  PBKDF2 has mechanisms to mitigate the dictionary = attack risks, e.g., having a high number of iterations. We might want to = make some recommendations as to how you set those parameters. And the = actual key wrapping is done with something like AES-KW, so that step is = fine.

 

So I would be completely fine with adding this to JWE = / JWA.  We should do this.

 

--Richard

 

 

On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

That’s up to the working group.  I’m actually hoping = that experts on the lists will respond to Yaron’s comments before = we make a decision on whether PBKDF2 as specified is an appropriate key = wrapping algorithm or not.

 

Assuming that the content in Matt’s draft eventually becomes an = RFC or part of one, the PBKDF2 definition would end up in the algorithms = registry either way, even if it’s not part of the JWA spec = itself.

 

           &nbs= p;            = ;            =             &= nbsp;           = Cheers,

           &nbs= p;            = ;            =             &= nbsp;           -- = Mike

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Friday, March 15, 2013 9:43 AM
To: Mike = Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft = describing encrypting JWK key representations, with = JWE

 <= /o:p>

So, Mike, = would you be OK with adding PBE to JWE / JWA, as a new key wrapping = algorithm?

 <= /o:p>

--Richard

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Fri, Mar = 15, 2013 at 12:14 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

[Adding = JOSE mailing list to the thread]

For clarification, PBKDF2 is not = the only algorithm that could be used to wrap keys in this scheme. =  This draft *adds* PBKDF2 to the set of algorithms already = specified for use with encryption in the JSON Web Algorithms (JWA) = specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-alg= orithms-08).  In particular, other algorithms such as AES Key = Wrap and AES GCM are also present there.

I'll let others who are = experts in PBKDF2 and password-based encryption respond to Yaron's = specific comment.

            =                     -- = Mike

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Friday, March 15, = 2013 8:16 AM
To: cfrg@irtf.org; Mike Jones
Subject: Re: Draft = describing encrypting JWK key representations, with JWE

Hi = Mike,

I'm probably missing something, but I'm worried about the = security of this scheme (though I do appreciate the = usability/convenience of passwords).

PBKDF2 is meant to make = dictionary attacks on stored passwords harder, as a second line defense, = once the server has been breached. Using it to encrypt data and then = sending the data on the wire, makes the data vulnerable to this same = dictionary attack (in this case the effort comes to the space of all = possible passwords - say 1 million - times 1000).
Moreover, this also = puts the password itself in danger.

Thanks,
    =     Yaron

>
> = ------------------------------
>
> Message: 5
> Date: = Fri, 15 Mar 2013 14:10:32 +0000
> From: Mike Jones <Michael.Jones@microsoft.com>
> To: = "cfrg@irtf.org" <cfrg@irtf.org>
> Subject: [Cfrg] Draft = describing encrypting JWK key representations
>     =   with JWE
> Message-ID:
>
> <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284= .redmond.corp.
> microsoft.com>
>
> Content-Type: = text/plain; charset=3D"us-ascii"
>
> http://tools.ietf.org/html/draft-miller-jose-jwe-protec= ted-jwk-01
>
> This also adds password-based encryption = to the algorithm registry.
>
>         =                     =                     =              -- Mike
>
> = -------------- next part -------------- An HTML attachment was
> = scrubbed...
> URL:
> <http://www.irtf.org/mail-archive/web/cfrg/attachments/2= 0130315/02e36b
> 24/attachment.htm>
>
> = ------------------------------
>
> = _______________________________________________
> Cfrg mailing = list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>>
> End of Cfrg Digest, Vol 95, Issue 3
> = ***********************************
>
__________________________= _____________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 <= /o:p>

 

------=_NextPart_000_07C9_01CE218A.6F30DDC0-- From housley@vigilsec.com Fri Mar 15 11:42:39 2013 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 4709511E80D1; Fri, 15 Mar 2013 11:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j485-DC6dAs9; Fri, 15 Mar 2013 11:42:38 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id EAF1811E80A3; Fri, 15 Mar 2013 11:42:37 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 9EADC9A4095; Fri, 15 Mar 2013 14:42:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 2k4oZdOcieb9; Fri, 15 Mar 2013 14:41:52 -0400 (EDT) Received: from dhcp-5419.meeting.ietf.org (dhcp-5419.meeting.ietf.org [130.129.84.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 110439A4094; Fri, 15 Mar 2013 14:42:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Russ Housley In-Reply-To: <31556AB6-899F-4D81-9FBC-40708864EA55@cisco.com> Date: Fri, 15 Mar 2013 14:42:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31556AB6-899F-4D81-9FBC-40708864EA55@cisco.com> To: Brian Weis X-Mailer: Apple Mail (2.1085) Cc: cfrg@ietf.org, jose@ietf.org Subject: Re: [Cfrg] [jose] Use of authenticated encryption for key wrapping X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 18:42:39 -0000 There are some system design issues to be considered. The use of = different modes for encryption of user data and keying material makes it = easier to prevent the decryption of keying material outside of the = crypto module. Russ =20 On Mar 15, 2013, at 11:42 AM, Brian Weis wrote: > Jim Schaad gave a presentation on JOSE to CFRG today = (). The = question came up as to whether AES key wrap was necessarily the only = method that was safe for key wrapping in JOSE. The other algorithm under = consideration is AES-GCM.=20 >=20 > Section 3.1 of NIST 800-38F (Methods for Key Wrapping) says: >=20 > "Previously approved authenticated-encryption modes=97as well as = combinations of an approved encryption mode with an approved = authentication method=97are approved for the protection of cryptographic = keys, in addition to general data." >=20 > So if one considers that to be good enough advice, AES-GCM would = indeed be an acceptable method of key wrapping. The chairs asked me to = cross-post this for discussion. >=20 > Brian From yaronf.ietf@gmail.com Fri Mar 15 12:45:43 2013 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 0BBDD21F88F1 for ; Fri, 15 Mar 2013 12:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.392 X-Spam-Level: X-Spam-Status: No, score=-100.392 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BEFORE=1.272, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o0FBXGg9yZ4 for ; Fri, 15 Mar 2013 12:45:40 -0700 (PDT) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 073BD21F8873 for ; Fri, 15 Mar 2013 12:45:38 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b47so1728772eek.1 for ; Fri, 15 Mar 2013 12:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:in-reply-to:references:mime-version :content-type:subject:from:date:to:cc:message-id; bh=P1Bd9our7zTj/hOvsHafWdzKPRuc3DF4S+nopcVBMz8=; b=V7KEVt4gIgAhSS8h5AiFPSfPdHQEFE3o3hGXUpw9VlxtbUU+1Mn3BNwJqlpCVA9rGF ldF6PC5MuXyq3R8qsF9XtXftYM8N5EVhp4aanldp3o9w/i1FZsTpp47SCwLY8oYcADa/ W7vHrXWsFqgtKpdKN3qd2kTEwIorFCRJH/LswRjnHRm1Xq+LcFCvRm4uYTeBZ2jI5gzW 4POvChkzh2bVip6Us2QcQ5AxkQ9+X0OaC5pqoTyucxnb4seitza25Jf91sZoxGmT38Uj TN5oXha0poPL5BkoJvbxFzc7AyIqCtpOfXUdr5Xnc/Oxt6K7YSjftQ28vfYusMgoBP3T 7SWA== X-Received: by 10.14.209.131 with SMTP id s3mr21318713eeo.26.1363376737965; Fri, 15 Mar 2013 12:45:37 -0700 (PDT) Received: from [10.209.190.56] ([95.35.60.56]) by mx.google.com with ESMTPS id a1sm12019630eep.2.2013.03.15.12.45.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 12:45:37 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <07c801ce21ab$f63d74b0$e2b85e10$@augustcellars.com> References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> <07c801ce21ab$f63d74b0$e2b85e10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----YXTMSIONN0BDIJ4N2082HKWH1H2BKB" From: Yaron Sheffer Date: Fri, 15 Mar 2013 21:45:30 +0200 To: Jim Schaad , "'Peck, Michael A'" , 'Richard Barnes' , 'Mike Jones' Message-ID: <6769e08f-8bae-41de-a723-409f7bfae4f2@email.android.com> Cc: cfrg@irtf.org, jose@ietf.org Subject: Re: [Cfrg] [jose] Draft describing encrypting JWK key representations, with JWE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 19:45:43 -0000 ------YXTMSIONN0BDIJ4N2082HKWH1H2BKB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit no way to generate a strong key in JavaScript. So you also need a way to use a key directly. But I'm by no means a JOSE expert, they may have different assumptions. Thanks, Yaron Jim Schaad wrote: >Use PBKDF2 as a general key wrap mechanism seems to be a bad idea. >Take the >key and use it as a key wrap key for randomly generated content >encryption >key. Thus alg should be "AES128KW" rather than direct. > > > >Jim > > > > > >From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >Peck, Michael A >Sent: Friday, March 15, 2013 12:59 PM >To: Richard Barnes; Mike Jones >Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >Subject: Re: [jose] Draft describing encrypting JWK key >representations, >with JWE > > > >+1 > > > >NIST Special Publication 800-132 provides recommendations for the >parameters >that the group may find useful. > >http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf > > > >It may also be worth thinking about using PBKDF2 instead of the "dir" >(Direct Encryption with a Shared Symmetric Key) mechanism described in >draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared >symmetric >key would be used as the PBKDF2 "password", and this would force a new >key >to be used for each encryption, rather than the current "dir" approach >of >using the same encryption key repeatedly. > > > >Mike > > > > > >From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >Richard Barnes >Sent: Friday, March 15, 2013 12:53 PM >To: Mike Jones >Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >Subject: Re: [jose] Draft describing encrypting JWK key >representations, >with JWE > > > >Do I count as an expert? :) > > > >As I understand it, PBDKF2 is completely fine for key protection. >PBKDF2 >has mechanisms to mitigate the dictionary attack risks, e.g., having a >high >number of iterations. We might want to make some recommendations as to >how >you set those parameters. And the actual key wrapping is done with >something >like AES-KW, so that step is fine. > > > >So I would be completely fine with adding this to JWE / JWA. We should >do >this. > > > >--Richard > > > > > >On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones > >wrote: > >That's up to the working group. I'm actually hoping that experts on >the >lists will respond to Yaron's comments before we make a decision on >whether >PBKDF2 as specified is an appropriate key wrapping algorithm or not. > > > >Assuming that the content in Matt's draft eventually becomes an RFC or >part >of one, the PBKDF2 definition would end up in the algorithms registry >either >way, even if it's not part of the JWA spec itself. > > > > Cheers, > > -- Mike > > > >From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >Richard Barnes >Sent: Friday, March 15, 2013 9:43 AM >To: Mike Jones >Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >Subject: Re: [jose] Draft describing encrypting JWK key >representations, >with JWE > > > >So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key >wrapping algorithm? > > > >--Richard > > > > > > > >On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones > >wrote: > >[Adding JOSE mailing list to the thread] > >For clarification, PBKDF2 is not the only algorithm that could be used >to >wrap keys in this scheme. This draft *adds* PBKDF2 to the set of >algorithms >already specified for use with encryption in the JSON Web Algorithms >(JWA) >specification >(http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). >In >particular, other algorithms such as AES Key Wrap and AES GCM are also >present there. > >I'll let others who are experts in PBKDF2 and password-based encryption >respond to Yaron's specific comment. > > -- Mike > >-----Original Message----- >From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >Sent: Friday, March 15, 2013 8:16 AM >To: cfrg@irtf.org; Mike Jones >Subject: Re: Draft describing encrypting JWK key representations, with >JWE > >Hi Mike, > >I'm probably missing something, but I'm worried about the security of >this >scheme (though I do appreciate the usability/convenience of passwords). > >PBKDF2 is meant to make dictionary attacks on stored passwords harder, >as a >second line defense, once the server has been breached. Using it to >encrypt >data and then sending the data on the wire, makes the data vulnerable >to >this same dictionary attack (in this case the effort comes to the space >of >all possible passwords - say 1 million - times 1000). >Moreover, this also puts the password itself in danger. > >Thanks, > Yaron > >> >> ------------------------------ >> >> Message: 5 >> Date: Fri, 15 Mar 2013 14:10:32 +0000 >> From: Mike Jones >> To: "cfrg@irtf.org" >> Subject: [Cfrg] Draft describing encrypting JWK key representations >> with JWE >> Message-ID: >> >> ><4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. >.%0b> >> microsoft.com> >> >> Content-Type: text/plain; charset="us-ascii" >> >> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 >> >> This also adds password-based encryption to the algorithm registry. >> >> -- Mike >> >> -------------- next part -------------- An HTML attachment was >> scrubbed... >> URL: >> >> 24/attachment.htm> >> >> ------------------------------ >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >> >> >> End of Cfrg Digest, Vol 95, Issue 3 >> *********************************** >> >_______________________________________________ >jose mailing list >jose@ietf.org >https://www.ietf.org/mailman/listinfo/jose > > > > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------YXTMSIONN0BDIJ4N2082HKWH1H2BKB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Jim, prior to the new Webcrypto API there'sno way to generate a strong key in JavaScript. So you also need a way to use a key directly. But I'm by no means a JOSE expert, they may have different assumptions.

Thanks, Yaron

Jim Schaad <ietf@augus



tcellars.com> wrote:

Use PBKDF2 as a general key wrap mechanism seems to be a bad idea.  Take the key and use it as a key wrap key for randomly generated content encryption key.  Thus alg should be “AES128KW” rather than direct.

 

Jim

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Peck, Michael A
Sent: Friday, March 15, 2013 12:59 PM
To: Richard Barnes; Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE

 

+1

 

NIST Special Publication 800-132 provides recommendations for the parameters that the group may find useful.

http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf

 

It may also be worth thinking about using PBKDF2 instead of the “dir” (Direct Encryption with a Shared Symmetric Key) mechanism described in draft-ietf-jose-json-web-algorithms-08 section 4.6.  The shared symmetric key would be used as the PBKDF2 “password”, and this would force a new key to be used for each encryption, rather than the current “dir” approach of using the same encryption key repeatedly.

 

Mike

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 12:53 PM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE

 

Do I count as an expert?  :)

 

As I understand it, PBDKF2 is completely fine for key protection.  PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., having a high number of iterations. We might want to make some recommendations as to how you set those para meters. And the actual key wrapping is done with something like AES-KW, so that step is fine.

 

So I would be completely fine with adding this to JWE / JWA.  We should do this.

 

--Richard

 

 

On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

That’s up to the working group.  I’m actually hoping that experts on the lists will respond to Yaron’s comments b efore we make a decision on whether PBKDF2 as specified is an appropriate key wrapping algorithm or not.

 

Assuming that the content in Matt’s draft eventually becomes an RFC or part of one, the PBKDF2 definition would end up in the algorithms registry either way, even if it’s not part of the JWA spec itself.

 

                                                            Cheers,

                                                            -- Mike

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 9:43 AM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE

 

So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key wrapping algorithm?

 

--Richard

 

 

 

On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

[Adding JOSE mailing list to the thread]

For clarification, PBKDF2 is not the only algorithm that could be used to wrap keys in this scheme.  This draft *adds* PBKDF2 to the set of algorithms already specified for use with encryption in the JSON Web Algorithms (JWA) specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08).  In particular, other algorithms such as AES Key Wrap and AES GCM are also present there.

I'll let others who are experts in PBKDF2 and password-based encryption respond to Yaron's specific comment.

                                -- Mike

-----Original Message- ----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Friday, March 15, 2013 8:16 AM
To: cfrg@irtf.org; Mike Jones
Subject: Re: Draft describing encrypting JWK key representations, with JWE

Hi Mike,

I'm probably missing something, but I'm worried about the security of this scheme (though I do appreciate the usability/convenience of passwords).

PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a second line defense, once the server has been breached. Using it to encrypt data and then sending the data on the wire, makes the data vulnerable to this same dictionary attack (in this case the effort comes to the space of all possible passwords - say 1 million - times 1000).
Moreover, this also puts the password itself in danger.

Thanks,
        Yaron

>
> ------------------------------
>
> Message: 5
> Date: Fri, 15 Mar 2013 14:10:32 +0000
> From: Mike Jones <Michael.Jones@microsoft.com>
> To: "cfrg@irtf.org" <cfrg@irtf.org>
> Subject: [Cfrg] Draft describing encrypting JWK key representations
>       with JWE
> Message-ID:
>
> <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp.
> microsoft.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01
>
> This also adds password-based encryption to the algorithm registry.
>
>                                                              -- Mike
>
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> <http://www.irtf.org/mail-archive/web/cfrg/attachments/20130315/02e36b
> 24/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>
>
> End of Cfrg Digest, Vol 95, Issue 3
> ***********************************
>
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 

 


--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------YXTMSIONN0BDIJ4N2082HKWH1H2BKB-- From yaronf.ietf@gmail.com Sat Mar 16 05:25:12 2013 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 6DE2E21F8B4A for ; Sat, 16 Mar 2013 05:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.229 X-Spam-Level: X-Spam-Status: No, score=-100.229 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_14=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQosReNe2neT for ; Sat, 16 Mar 2013 05:25:11 -0700 (PDT) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 756EB21F8AB8 for ; Sat, 16 Mar 2013 05:25:05 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id q10so1949422eaj.33 for ; Sat, 16 Mar 2013 05:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5qngBkUYommavs4HYAFjDOre0oN3Gs4uuoEmygRYB5w=; b=hMDdoy7PSdhD7nVp7cze3VrKQbezfnHT7qKDEN2tK/EhYBt/+GoeO9dDvPUDMJw+Cv sJNeyGaO4hGfYfEBgLh+lyZ5EqKHXsEaTFtJLrGkY3dL3O05tB1+DD8DQme0InFW3PJ8 Pu7rM1wXrbsO+jGvCT5G07bU70drwNecaN2c9U6razWQTLSOn+scwfdmEnQ/Cd8/sIRg KcYtq4D+njmbNJUu/po+ZyttPISsj0SU+v89TWZ6atlVsAFMg53wV+thPqrnYGvx8fJF tggs0OvYcwCXFMVSA0fID+S4SrecPJ1U1oqPxJyf7jUNHAea+LbJpvta6oIDBKZyOjOH XtEA== X-Received: by 10.14.183.198 with SMTP id q46mr28693752eem.1.1363436704555; Sat, 16 Mar 2013 05:25:04 -0700 (PDT) Received: from [10.0.0.2] (bzq-109-66-120-100.red.bezeqint.net. [109.66.120.100]) by mx.google.com with ESMTPS id a1sm15742380eep.2.2013.03.16.05.24.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Mar 2013 05:25:03 -0700 (PDT) Message-ID: <51446495.8020708@gmail.com> Date: Sat, 16 Mar 2013 14:24:53 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> <51435D7A.7050800@gmail.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5FBC@IMCMBX04.MITRE.ORG> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Richard Barnes , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] [jose] Draft describing encrypting JWK key representations, with JWE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 12:25:12 -0000 Well I guess that's for me. So here goes: Despite the protections afforded by PBKDF2 and PBES2, password-protected data is still subject to off-line dictionary attacks, when using human-generated passwords. The same applies to machine generated passwords, if they need to be memorable to humans. Such dictionary attacks reveal both the data and the password to an eavesdropper. Therefore: - Password-based encryption should not be used for high value data. - Password-based encryption should not be used with high-value passwords, e.g. with a user's long-term password. Thanks, Yaron On 03/15/2013 09:47 PM, Matt Miller (mamille2) wrote: > My intent for introducing PBES2 key wrapping algorithms was for those times when the key exchange is at the human-level. I think there are probably better mechanisms when the input in appropriately random to start with, although I personally don't see a tremendous amount of harm using a PBES2-based algorithm with stronger "passwords". > > I tried to address some concerns around the use of passwords, but did rely on what RFC2898 already says about specific values for iteration counts and salts. I'd be happy to incorporate more direction there, if someone could help provide some text. I'd also be happy to help incorporate this into whatever other document we'd rather have it in. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > On Mar 15, 2013, at 1:55 PM, "Peck, Michael A" > wrote: > >> I'll try to clarify (and hopefully not dig a deeper hole). >> >> JWE currently provides a "dir" mechanism allowing a symmetric key previously agreed to out of band to be used for content encryption. >> All of the other JWE mechanisms use a fresh symmetric key for each encryption. >> >> My suggestion was that instead of directly using the pre-shared symmetric key to encrypt content, if JWE makes the PBKDF2 mechanism available the symmetric key could be used as the PBKDF2 "password", resulting in a fresh key generated for each content encryption. In this particular case the password input to PBKDF2 would hopefully be very random - I would think there would be no more risk than using the pre-shared key directly, rather less risk. >> >> General password considerations are a different matter. Passwords have lots of issues but if we're stuck with them we should at least advise how to do the best we can. >> >> Mike >> >>> -----Original Message----- >>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>> Sent: Friday, March 15, 2013 1:42 PM >>> To: Peck, Michael A >>> Cc: Richard Barnes; Mike Jones; cfrg@irtf.org; jose@ietf.org >>> Subject: Re: [jose] Draft describing encrypting JWK key representations, with >>> JWE >>> >>> Hi Mike and Mike, >>> >>> The NIST SP is about using PBKDF2 for storage encryption (which I'm not >>> thrilled with, either). Not for sending the encrypted blob over the >>> wire, for an attacker to intercept and decrypt off-line. And if we read >>> the NIST document, let's adopt the whole thing - quoting from sec. A.1: >>> "Passwords shorter than 10 characters are usually considered to be >>> weak." Are we going to make this recommendation too? Well I guess not. >>> >>> *Please* do not mix passwords with cryptographic keys. If the WG goes >>> through the risk vs. benefit analysis and decides to have a >>> password-based mechanism, fine. But please leave the shared-key >>> mechanism as-is. It's important that readers of JOSE specs are very >>> clear about the difference between randomly generated keys and >>> user-memorable (or even -generated) passwords. >>> >>> Let's be clear: even a single use of a user-generated password for >>> on-the-wire encryption is risky. So-called key rotation of actual >>> cryptographic keys is a whole different matter. >>> >>> Thanks, >>> Yaron >>> >>> >>> On 03/15/2013 06:58 PM, Peck, Michael A wrote: >>>> +1 >>>> >>>> NIST Special Publication 800-132 provides recommendations for the >>>> parameters that the group may find useful. >>>> >>>> http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf >>>> >>>> It may also be worth thinking about using PBKDF2 instead of the "dir" >>>> (Direct Encryption with a Shared Symmetric Key) mechanism described in >>>> draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared >>>> symmetric key would be used as the PBKDF2 "password", and this would >>>> force a new key to be used for each encryption, rather than the current >>>> "dir" approach of using the same encryption key repeatedly. >>>> >>>> Mike >>>> >>>> *From:*jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >>>> Of *Richard Barnes >>>> *Sent:* Friday, March 15, 2013 12:53 PM >>>> *To:* Mike Jones >>>> *Cc:* Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >>>> *Subject:* Re: [jose] Draft describing encrypting JWK key >>>> representations, with JWE >>>> >>>> Do I count as an expert? :) >>>> >>>> As I understand it, PBDKF2 is completely fine for key protection. >>>> PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., >>>> having a high number of iterations. We might want to make some >>>> recommendations as to how you set those parameters. And the actual key >>>> wrapping is done with something like AES-KW, so that step is fine. >>>> >>>> So I would be completely fine with adding this to JWE / JWA. We should >>>> do this. >>>> >>>> --Richard >>>> >>>> On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones >>>> > >>> wrote: >>>> >>>> That's up to the working group. I'm actually hoping that experts on the >>>> lists will respond to Yaron's comments before we make a decision on >>>> whether PBKDF2 as specified is an appropriate key wrapping algorithm or >>> not. >>>> >>>> Assuming that the content in Matt's draft eventually becomes an RFC or >>>> part of one, the PBKDF2 definition would end up in the algorithms >>>> registry either way, even if it's not part of the JWA spec itself. >>>> >>>> Cheers, >>>> >>>> -- Mike >>>> >>>> *From:*jose-bounces@ietf.org >>>> [mailto:jose-bounces@ietf.org ] *On >>> Behalf >>>> Of *Richard Barnes >>>> *Sent:* Friday, March 15, 2013 9:43 AM >>>> *To:* Mike Jones >>>> *Cc:* Yaron Sheffer; cfrg@irtf.org ; jose@ietf.org >>>> >>>> *Subject:* Re: [jose] Draft describing encrypting JWK key >>>> representations, with JWE >>>> >>>> So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key >>>> wrapping algorithm? >>>> >>>> --Richard >>>> >>>> On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones >>>> > >>> wrote: >>>> >>>> [Adding JOSE mailing list to the thread] >>>> >>>> For clarification, PBKDF2 is not the only algorithm that could be used >>>> to wrap keys in this scheme. This draft *adds* PBKDF2 to the set of >>>> algorithms already specified for use with encryption in the JSON Web >>>> Algorithms (JWA) specification >>>> (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). In >>>> particular, other algorithms such as AES Key Wrap and AES GCM are also >>>> present there. >>>> >>>> I'll let others who are experts in PBKDF2 and password-based encryption >>>> respond to Yaron's specific comment. >>>> >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com >>>> ] >>>> Sent: Friday, March 15, 2013 8:16 AM >>>> To: cfrg@irtf.org ; Mike Jones >>>> Subject: Re: Draft describing encrypting JWK key representations, with JWE >>>> >>>> Hi Mike, >>>> >>>> I'm probably missing something, but I'm worried about the security of >>>> this scheme (though I do appreciate the usability/convenience of >>> passwords). >>>> >>>> PBKDF2 is meant to make dictionary attacks on stored passwords harder, >>>> as a second line defense, once the server has been breached. Using it to >>>> encrypt data and then sending the data on the wire, makes the data >>>> vulnerable to this same dictionary attack (in this case the effort comes >>>> to the space of all possible passwords - say 1 million - times 1000). >>>> Moreover, this also puts the password itself in danger. >>>> >>>> Thanks, >>>> Yaron >>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 5 >>>>> Date: Fri, 15 Mar 2013 14:10:32 +0000 >>>>> From: Mike Jones >>> > >>>>> To: "cfrg@irtf.org " >>> > >>>>> Subject: [Cfrg] Draft describing encrypting JWK key representations >>>>> with JWE >>>>> Message-ID: >>>>> >>>>> >>> <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmon >>> d.corp. >>>> >>> >> edmond.corp.%0b>> >>>> microsoft.com > >>>>> >>>>> Content-Type: text/plain; charset="us-ascii" >>>>> >>>>> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 >>>>> >>>>> This also adds password-based encryption to the algorithm registry. >>>>> >>>>> -- Mike >>>>> >>>>> -------------- next part -------------- An HTML attachment was >>>>> scrubbed... >>>>> URL: >>>>> >> archive/web/cfrg/attachments/20130315/02e36b >>>>> 24/attachment.htm> >>>>> >>>>> ------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Cfrg mailing list >>>>> Cfrg@irtf.org >>>>> http://www.irtf.org/mailman/listinfo/cfrg >>>>> >>>>> >>>>> End of Cfrg Digest, Vol 95, Issue 3 >>>>> *********************************** >>>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > From turners@ieca.com Sat Mar 16 07:48:21 2013 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 1269321F8A05 for ; Sat, 16 Mar 2013 07:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.537 X-Spam-Level: X-Spam-Status: No, score=-101.537 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvdZKm-LBMsT for ; Sat, 16 Mar 2013 07:48:20 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.52.14]) by ietfa.amsl.com (Postfix) with ESMTP id A23A221F89B2 for ; Sat, 16 Mar 2013 07:48:20 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 2D89FB61D70EC; Sat, 16 Mar 2013 09:48:20 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 209A3B61D70C8 for ; Sat, 16 Mar 2013 09:48:20 -0500 (CDT) Received: from [198.180.150.142] (port=51011 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UGsPD-0006Vf-Tl; Sat, 16 Mar 2013 09:48:20 -0500 Message-ID: <51448633.2060303@ieca.com> Date: Sat, 16 Mar 2013 10:48:19 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: saag@ietf.org, cfrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [198.180.150.142]:51011 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [Cfrg] Looking for an HOTP expert X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 14:48:21 -0000 I'd like some help resolving three errata on RFC 4226. If you think you can help please send me a private email. spt From yaronf.ietf@gmail.com Sat Mar 16 13:56:56 2013 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 7E94821F8463 for ; Sat, 16 Mar 2013 13:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.214 X-Spam-Level: X-Spam-Status: No, score=-102.214 tagged_above=-999 required=5 tests=[AWL=1.385, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUH0C7ov0ilx for ; Sat, 16 Mar 2013 13:56:56 -0700 (PDT) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id B403721F8464 for ; Sat, 16 Mar 2013 13:56:55 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id d41so2029428eek.36 for ; Sat, 16 Mar 2013 13:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CMtQu0tENXF9xpabmz19N/4fxqz/DT4VC4w3xD5W3eo=; b=oHGIGWZU2zk7RHkjqAfho8Z6QXQo/kXAq/vko2f1CnAWEazC8s832S0bI1Q94R3Qcm j534895QgMsocTm+4GqFdikR23ak9m0qvcJJkFKxM0fiYSCsEn4Zm77w5Y7t8XumbH+n Nm29YYyo7q0XG9VNocSqN2E5KtbQqFUdRVO8xeJflWEqerzQlAEZw+Kyn68WLFjf889u zpohcyy1jU/AFAxcUvWmkoVLi1ZmLL2BBvoZRbShJVz4LH7BLZN6K6lSHc0pvtPXhHxd CrgGJXl77bHLTScMbRWxTZR12RkwudPvdNqeyd8iiQLDcsqSbxWbXy1rp2P4weQw2OpK OVXw== X-Received: by 10.14.173.196 with SMTP id v44mr31898602eel.29.1363467414763; Sat, 16 Mar 2013 13:56:54 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-181-130-250.red.bezeqint.net. [79.181.130.250]) by mx.google.com with ESMTPS id 3sm17955019eej.6.2013.03.16.13.56.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Mar 2013 13:56:53 -0700 (PDT) Message-ID: <5144DC8B.9020403@gmail.com> Date: Sat, 16 Mar 2013 22:56:43 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ryan-ietf@sleevi.com References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> <07c801ce21ab$f63d74b0$e2b85e10$@augustcellars.com> <6769e08f-8bae-41de-a723-409f7bfae4f2@email.android.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Richard Barnes' , cfrg@irtf.org, jose@ietf.org Subject: Re: [Cfrg] [jose] Draft describing encrypting JWK key representations, with JWE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 20:56:56 -0000 Hi Ryan, Yes, the complete first sentence in my mail (which the listserv gobbled) was: "prior to the new Webcrypto API there's no way to generate a strong key in JavaScript." Do the JOSE specs assume this API is always available? Thanks, Yaron On 16.3.2013 22:14, Ryan Sleevi wrote: > On Fri, March 15, 2013 12:45 pm, Yaron Sheffer wrote: >> no way to generate a strong key in JavaScript. So you also need a way to >> use a key directly. But I'm by no means a JOSE expert, they may have >> different assumptions. >> >> Thanks, Yaron > window.crypto.getRandomValues() ? > > Already implemented today by WebKit and Firefox, as part of the W3C Web > Cryptography API - > https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html > From ietf@augustcellars.com Sun Mar 17 10:01:34 2013 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 B3E9421F8BF8 for ; Sun, 17 Mar 2013 10:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbzsywMBnric for ; Sun, 17 Mar 2013 10:01:34 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id B268D21F8BE7 for ; Sun, 17 Mar 2013 10:01:31 -0700 (PDT) Received: from Philemon (ip-64-134-191-81.public.wayport.net [64.134.191.81]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id B18492C9BC; Sun, 17 Mar 2013 10:01:30 -0700 (PDT) From: "Jim Schaad" To: "David McGrew" Date: Sun, 17 Mar 2013 13:00:53 -0400 Message-ID: <088401ce2330$fef84950$fce8dbf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0885_01CE230F.77E808E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4jLkgMuq37lVAvRXCo2xsqoYEAgg== Content-Language: en-us Cc: cfrg@irtf.org Subject: [Cfrg] Use of draft-mgcrew-aead-aes-cbc-hmac-sha2 with CMS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 17:01:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0885_01CE230F.77E808E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David, If I were to assume that I wanted to use your draft rather than RFC 6476 (Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)) in a CMS context with the AEAD structures defined in RFC 5038, I believe that I would have a problem. Specifically, the current CMS structure assumes that the IV and the authentication tag are kept separate I have no objects to the fact that a long key is used and the fact that the MAC cannot be truncated. However the fact that the IV and the tag MUST be part of the encryption stream is difficult. I do however 100% agree that the IV MUST be included in the tag computation. Jim ------=_NextPart_000_0885_01CE230F.77E808E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David,

 

If I were to = assume that I wanted to use your draft rather than RFC 6476 (Using = Message Authentication Code (MAC) Encryption in the Cryptographic = Message Syntax (CMS)) in a CMS context with the AEAD structures defined = in RFC 5038, I believe that I would have a problem.  Specifically, = the current CMS structure assumes that the IV and the authentication tag = are kept separate

 

I have no = objects to the fact that a long key is used and the fact that the MAC = cannot be truncated.  However the fact that the IV and the tag MUST = be part of the encryption stream is difficult.

 

I do however = 100% agree that the IV MUST be included in the tag = computation.

 

Jim

 

------=_NextPart_000_0885_01CE230F.77E808E0-- From Michael.Jones@microsoft.com Sun Mar 17 11:57:07 2013 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 459E721F8A43 for ; Sun, 17 Mar 2013 11:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS9FtayWHdO4 for ; Sun, 17 Mar 2013 11:57:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id A0FA521F8A68 for ; Sun, 17 Mar 2013 11:57:05 -0700 (PDT) Received: from BL2FFO11FD013.protection.gbl (10.173.161.202) by BL2FFO11HUB028.protection.gbl (10.173.161.52) with Microsoft SMTP Server (TLS) id 15.0.641.9; Sun, 17 Mar 2013 18:56:52 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Sun, 17 Mar 2013 18:56:52 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Sun, 17 Mar 2013 18:56:49 +0000 From: Mike Jones To: Jim Schaad , David McGrew Thread-Topic: [Cfrg] Use of draft-mgcrew-aead-aes-cbc-hmac-sha2 with CMS Thread-Index: Ac4jLkgMuq37lVAvRXCo2xsqoYEAggAElXXQ Date: Sun, 17 Mar 2013 18:56:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436753BCBC@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <088401ce2330$fef84950$fce8dbf0$@augustcellars.com> In-Reply-To: <088401ce2330$fef84950$fce8dbf0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436753BCBCTK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(52314002)(377454001)(51856001)(47736001)(33656001)(56776001)(56816002)(49866001)(47976001)(50986001)(54356001)(55846006)(59766001)(53806001)(4396001)(16406001)(512954001)(79102001)(5343655001)(5343635001)(63696002)(74502001)(47446002)(54316002)(44976002)(31966008)(66066001)(77982001)(69226001)(80022001)(46102001)(76482001)(65816001)(20776003)(74662001)(15202345001)(16236675001)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB028; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07880C4932 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Use of draft-mgcrew-aead-aes-cbc-hmac-sha2 with CMS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 18:57:07 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436753BCBCTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a private thread with David, there's a discussion about how the algorith= m description in draft-mgcrew-aead-aes-cbc-hmac-sha2 could be refactored in= to: 1) Requirements about the content of the key value. 2) Requirements about the content of the initialization vector value. 3) A deterministic function generating the ciphertext and integrity value = from the plaintext, additional authenticated data, initialization vector, a= nd key. 4) A RFC 5116 encoding for the results of 1-3. I believe, Jim, that you're saying that CMS would use 1-3, but a different = encoding of the results than 4. I believe that JSON Web Encryption (JWE) w= ould also want to use 1-3 but not 4. Anyway, I think this is a really useful discussion and one that could resul= t in the algorithm being used in more contexts. Thanks for your thoughts, = Jim. -- Mike From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Jim= Schaad Sent: Sunday, March 17, 2013 10:01 AM To: David McGrew Cc: cfrg@irtf.org Subject: [Cfrg] Use of draft-mgcrew-aead-aes-cbc-hmac-sha2 with CMS David, If I were to assume that I wanted to use your draft rather than RFC 6476 (U= sing Message Authentication Code (MAC) Encryption in the Cryptographic Mess= age Syntax (CMS)) in a CMS context with the AEAD structures defined in RFC = 5038, I believe that I would have a problem. Specifically, the current CMS= structure assumes that the IV and the authentication tag are kept separate I have no objects to the fact that a long key is used and the fact that the= MAC cannot be truncated. However the fact that the IV and the tag MUST be= part of the encryption stream is difficult. I do however 100% agree that the IV MUST be included in the tag computation= . Jim --_000_4E1F6AAD24975D4BA5B16804296739436753BCBCTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In a private thread wi= th David, there’s a discussion about how the algorithm description in= draft-mgcrew-aead-aes-cbc-hmac-sha2 could be refactored into:

 

1)  Requirements = about the content of the key value.

2)  Requirements = about the content of the initialization vector value.

3)  A determinist= ic function generating the ciphertext and integrity value from the plaintex= t, additional authenticated data, initialization vector, and key.

4)  A RFC 5116 en= coding for the results of 1-3.

 

I believe, Jim, that y= ou’re saying that CMS would use 1-3, but a different encoding of the = results than 4.  I believe that JSON Web Encryption (JWE) would also w= ant to use 1-3 but not 4.

 

Anyway, I think this i= s a really useful discussion and one that could result in the algorithm bei= ng used in more contexts.  Thanks for your thoughts, Jim.

 

   &nbs= p;             =             &nb= sp;            =             &nb= sp;     -- Mike

 

From: cfrg-bou= nces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Jim Schaad
Sent: Sunday, March 17, 2013 10:01 AM
To: David McGrew
Cc: cfrg@irtf.org
Subject: [Cfrg] Use of draft-mgcrew-aead-aes-cbc-hmac-sha2 with CMS<= o:p>

 

David,

 

If I were to assume that I wanted to use your draft = rather than RFC 6476 (Using Message Authentication Code (MAC) Encryption in= the Cryptographic Message Syntax (CMS)) in a CMS context with the AEAD str= uctures defined in RFC 5038, I believe that I would have a problem.  Specifically, the current CMS structure= assumes that the IV and the authentication tag are kept separate

 

I have no objects to the fact that a long key is use= d and the fact that the MAC cannot be truncated.  However the fact tha= t the IV and the tag MUST be part of the encryption stream is difficult.

 

I do however 100% agree that the IV MUST be included= in the tag computation.

 

Jim

 

--_000_4E1F6AAD24975D4BA5B16804296739436753BCBCTK5EX14MBXC284r_-- From ve7jtb@ve7jtb.com Sun Mar 17 15:40:33 2013 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 A77C721F8A43 for ; Sun, 17 Mar 2013 15:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=-1.064, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, J_CHICKENPOX_43=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw10WV7cr7Vy for ; Sun, 17 Mar 2013 15:40:33 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id E41DC21F8A3F for ; Sun, 17 Mar 2013 15:40:32 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id t2so2496449qcq.28 for ; Sun, 17 Mar 2013 15:40:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=f6go32YwU6Q9PQ+LmP7MNc4K/CgNXhtns4lvRozu9U0=; b=J5ElAgy4xp/OBWu+xxjKqJScxR4gXcCyYjPdXfEXEMWjMfEYmr7cx5EWoZGbOCi5lA YHJYmjBy+2e/+/g4pclXywnX13hl+Z2yujIwvAkcmVCHZPXS/5TboG8xlnJbzcN38ogY voyoUTNlaszxMzCzEJIozclvbVm3JET0BpVDQ5aaf3SjL+uVy5LTdJwL3Han85Ec6G0p TDABh7t6XXsjwV0ar9xG7Pju7CwC1uFeesarD6dwpS4sCcPRZRPpO0QRNP5bWoMihum+ I4SKOePut+DhtIo1X3KOz0fW8EUPHltV2zOI/mMlH0HExpaW8g6y1E+tDc0AzJe7iTSS R2KQ== X-Received: by 10.229.106.162 with SMTP id x34mr3893112qco.90.1363560032210; Sun, 17 Mar 2013 15:40:32 -0700 (PDT) Received: from [192.168.1.37] (190-20-39-218.baf.movistar.cl. [190.20.39.218]) by mx.google.com with ESMTPS id u4sm22763678qao.13.2013.03.17.15.40.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Mar 2013 15:40:30 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3B564EEC-78E5-4225-96DB-21DD142282BB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Sun, 17 Mar 2013 18:40:21 -0400 Message-Id: <0A3D2079-279F-4D6C-AEE9-2B4BBF97B609@ve7jtb.com> References: <31556AB6-899F-4D81-9FBC-40708864EA55@cisco.com> To: Russ Housley X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnGau9lphlKY65QOIrHztmpL4sJiYn8jjrwbvDXwlxzzH5LEY9GWSLusdpVzzIYoTKBNs5S Cc: Brian Weis , cfrg@ietf.org, jose@ietf.org Subject: Re: [Cfrg] [jose] Use of authenticated encryption for key wrapping X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 22:40:33 -0000 --Apple-Mail=_3B564EEC-78E5-4225-96DB-21DD142282BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 That is true. However the main reason AES-GWC would be used is to allow transport of = keys (RSA, EC and Symmetric) that are intended for use outside the = crypto module. Where I agree, is that it is probably not such a good idea to start = using AESKW on the message body just because that body contains a JWK = with a private key. I think that is where this particular question started. Some people = thought that only AES-KW was appropriate for encrypting keys. My preference is to keep AES-KW for wrapping session keys,and not change = to the newer version that would allow us to encrypt arbitrary length = messages. That at least still provides some additional protection for session keys = in that the KW alg remains internal, so can not be used to expose = session keys accidentally if that is what you are getting at. Regards, John B. On 2013-03-15, at 2:42 PM, Russ Housley wrote: > There are some system design issues to be considered. The use of = different modes for encryption of user data and keying material makes it = easier to prevent the decryption of keying material outside of the = crypto module. >=20 > Russ >=20 >=20 > On Mar 15, 2013, at 11:42 AM, Brian Weis wrote: >=20 >> Jim Schaad gave a presentation on JOSE to CFRG today = (). The = question came up as to whether AES key wrap was necessarily the only = method that was safe for key wrapping in JOSE. The other algorithm under = consideration is AES-GCM.=20 >>=20 >> Section 3.1 of NIST 800-38F (Methods for Key Wrapping) says: >>=20 >> "Previously approved authenticated-encryption modes=97as well as = combinations of an approved encryption mode with an approved = authentication method=97are approved for the protection of cryptographic = keys, in addition to general data." >>=20 >> So if one considers that to be good enough advice, AES-GCM would = indeed be an acceptable method of key wrapping. The chairs asked me to = cross-post this for discussion. >>=20 >> Brian >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_3B564EEC-78E5-4225-96DB-21DD142282BB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE3MjI0MDIyWjAjBgkqhkiG9w0BCQQxFgQUwTFCo4UV mud2IP5vt9hIEUOFvgQwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAl0u7KxAeN2BS/zVyz4TwiHzxTYwL7mIHX+Lz59i1 6gND/uEQaFTdyk1LFuwcJl+TDgExpk8z99sjokc8sS6oyJ3n8ZxnVw19ltDtXElGtbNEInfA4Gr1 Cvv/tvW3BikUNLZ/LGzsP6lfIlkN7/0JQaeZ/649mBM8r4+ej08xBYog5v/x+qh9t8WJy2Fa+wtK 1oe6JaHA7Z0fEXWWxNdMBVg1NMirn1FyH5JHuCC7UXbs0lbHN4fO9NhOwlaFuhUCDffJvsKz6MLc v6tW65pLzrIUuc4sp9rSwei1FknYyf3dhYEPbtQUnAo3OlpHtwjhcxmZiHgMmMZi1woXn5IP3wAA AAAAAA== --Apple-Mail=_3B564EEC-78E5-4225-96DB-21DD142282BB-- From mcgrew@cisco.com Mon Mar 18 06:24:16 2013 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 02F3121F8DD0; Mon, 18 Mar 2013 06:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uFoCyJJGNJA; Mon, 18 Mar 2013 06:24:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C44D621F8CE8; Mon, 18 Mar 2013 06:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1873; q=dns/txt; s=iport; t=1363613055; x=1364822655; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=KGe8stE/M5PRG8Wkdq/B09mY6soyai8GFNw5PByWE1o=; b=E6ECOW4EBl0NfJv9YN01yeAdloRAw18GN2pSX8ZfuTVdMRBwxY0mNmS0 kbJ4gYnVnjncxbCRGIUdp6Q7i0bvEp8mspxeL1zUpoG6o2KzHfTp88yA9 AJPx5kGfbNAQmhGDkpLWAS1WNV8S1zgMPh85Ty0U3+Z+o/ryfzjV/9HPV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC4VR1GtJXG+/2dsb2JhbABDxSCBVBZ0giYBAgIBAQFrHQEIIksLJQIEARIIAYgLDMFfjEKCIjiCX2EDp2CDCoFsJBg X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="188405890" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 18 Mar 2013 13:24:14 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2IDOEBX011993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 13:24:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 08:24:14 -0500 From: "David McGrew (mcgrew)" To: "Brian Weis (bew)" , "jose@ietf.org" , "cfrg@ietf.org" Thread-Topic: [Cfrg] Use of authenticated encryption for key wrapping Thread-Index: AQHOIZaIOO+Qa/7kdEmBaYbXVhCe2pirhVeA Date: Mon, 18 Mar 2013 13:24:13 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EB276@xmb-rcd-x04.cisco.com> In-Reply-To: <31556AB6-899F-4D81-9FBC-40708864EA55@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4127D9F8DE8BF543BAF395AA9E9B13BF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Cfrg] Use of authenticated encryption for key wrapping X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 13:24:16 -0000 Hi Brian, On 3/15/13 11:42 AM, "Brian Weis (bew)" wrote: >Jim Schaad gave a presentation on JOSE to CFRG today >(). The >question came up as to whether AES key wrap was necessarily the only >method that was safe for key wrapping in JOSE. The other algorithm under >consideration is AES-GCM. > >Section 3.1 of NIST 800-38F (Methods for Key Wrapping) says: > >"Previously approved authenticated-encryption modes=8Bas well as >combinations of an approved encryption mode with an approved >authentication method=8Bare approved for the protection of cryptographic >keys, in addition to general data." > >So if one considers that to be good enough advice, AES-GCM would indeed >be an acceptable method of key wrapping. The chairs asked me to >cross-post this for discussion. Thanks for sending out the pointer. I think the biggest negative with using AES-GCM for key wrapping is that GCM is not designed to be misuse-resistant. In contrast, the AES-KW algorithm does provide some misuse resistance: the AES-KW encryption algorithm does not require that the caller provide a distinct nonce for each invocation. =20 The biggest negative with requiring the use of AES-KW for key wrapping is that, it requires the implementation of the AES decryption operation (unlike GCM), it is yet another algorithm to implement/test/validate, and it takes up space that is precious in a constrained environment. NIST is right to allow other authenticated encryption methods than AES-KW to be used for key wrapping. But if AES-KW is available for JOSE, then it makes sense to use it for key wrapping. My $0.02. David > >Brian=20 >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg From mcgrew@cisco.com Mon Mar 18 12:25:26 2013 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 9BA5721F8606 for ; Mon, 18 Mar 2013 12:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03QcTbVLPdMG for ; Mon, 18 Mar 2013 12:25:09 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2168E21F86C1 for ; Mon, 18 Mar 2013 12:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2652; q=dns/txt; s=iport; t=1363634630; x=1364844230; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8vehR51qWhLI+badoKnlpXr05HUhctN0m30MFDYIVLc=; b=R62FaZ29XH2yLiJn/MJJdaVkDMkhpXhdCiVM0HTId6oMCYOogjqwCCZM rgdBVr6mvwF8f20tpsRlBamNREhkDaOqFEIvzmKCWbBqHoJ9TGosFP6cB 0mH1UAaOe+CpBYU2O8T1LCdRfTpuLaRkNaMD+WBE0JvV163H9MEDtwCrZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABFpR1GtJXG+/2dsb2JhbABDxSGBVhZ0giYBBAEBATc0CxIBCCIUNwslAgQOBQgMiAAMwhaOZDEHgl9hA5d9j2ODCoIo X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="188805962" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 18 Mar 2013 19:23:42 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2IJNg9u029822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 19:23:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 14:23:42 -0500 From: "David McGrew (mcgrew)" To: Simon Josefsson Thread-Topic: [TLS] Salsa20 stream cipher in TLS Thread-Index: AQHOI2IRfwT9uKfaFUuf1DQlms1pvpir5i+A Date: Mon, 18 Mar 2013 19:23:41 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> In-Reply-To: <87ppyxhc6y.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [Cfrg] [TLS] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 19:25:26 -0000 Hi Simon, On 3/17/13 6:51 PM, "Simon Josefsson" wrote: >All, > >FYI, we have published -00 of a draft that describes how the Salsa20 >stream cipher can be added to TLS and DTLS, see: > >http://tools.ietf.org/html/draft-josefsson-salsa20-tls > >While we are not asking for WG adoption of this draft now, we are at a >point where we would like to invite external review and solicit >feedback. =20 Some early feedback; copied CFRG. It would be good to have review from that community. It is not exactly clear what problem is being addressed by this work. Would be good to add a problem statement section. In addition, it would be good to provide the currently-unmet requirements to CAESAR (Competition for Authenticated Encryption: Security, Applicability, and Robustness) http://competitions.cr.yp.to/ Some more detailed comments, quoting from the draft: Recent attacks has indicated problems with CBC-mode cipher suites in TLS/DTLS and problems with the only supported stream cipher (RC4) in TLS has been known for a long time. While AEAD cipher suites address these issues, concerns about performance are sometimes raised. What are the performance concerns? I suggest citing some relevant performance data. Because the GenericStreamCipher definition in TLS does not provide any way to transport the Salsa20 nonce that is required for functionality and needed to provide the random access property, we let the output from the stream cipher operation be the concatenation of the IV and the encrypted data. Please, define a Salsa20-based AEAD mechanism instead of a new TLS format! =20 >Some elements of the draft is still in flux. For example, >initial performance benchmarks suggests HMAC-SHA256 was a poor choice >for the MAC so we are looking into UMAC and HMAC-SHA1 as alternatives. >Still, all comments are appreciated. If anything other than HMAC-SHA1 is used, that would underscore the value of defining an AEAD algorithm. If the main motivation for this work is encryption that is computationally cheap, then it makes sense to pair the algorithm with an authentication method with the same characteristics. For security considerations, I suggest citing the analysis of Salsa20, and adding a sentence or paragraph summarizing the best-known attacks. Something like "Salsa20 has been analyzed by X independent teams, and the best known attack breaks 8 of 20 rounds." David > >/Simon >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From simon@josefsson.org Mon Mar 18 13:42:33 2013 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 F3C1C11E80CC; Mon, 18 Mar 2013 13:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXsO-wceCunr; Mon, 18 Mar 2013 13:42:32 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id EF48E11E80BA; Mon, 18 Mar 2013 13:42:30 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2IKgIXx008663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Mar 2013 21:42:21 +0100 From: Simon Josefsson To: "David McGrew \(mcgrew\)" References: <87ppyxhc6y.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130318:joachim@secworks.se::gtcs30S7ApbT29ps:1XE5 X-Hashcash: 1:22:130318:cfrg@irtf.org::aYH0KGdGpFBKoqaG:9He X-Hashcash: 1:22:130318:mcgrew@cisco.com::McJDm8ulb7NLZpDl:Ole7 X-Hashcash: 1:22:130318:tls@ietf.org::Ce9zQZZ6LXhKXWtE:gpfN Date: Mon, 18 Mar 2013 21:42:13 +0100 In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> (David McGrew's message of "Mon, 18 Mar 2013 19:23:41 +0000") Message-ID: <87ehfc784a.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [Cfrg] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 20:42:33 -0000 "David McGrew (mcgrew)" writes: > Hi Simon, Hi David. Thanks for quick review. > It is not exactly clear what problem is being addressed by this work. > Would be good to add a problem statement section. Good idea, the document now contains this paragraph: The purpose of this document is to provide an alternative stream cipher for both TLS and DTLS that is comparable to RC4 in speed on a wide range of platforms. There are other soft factors too. In general the goal is to offer something that can replace use of RC4 in TLS. I'm guessing speed is one reason people use RC4 in TLS today. > Some more detailed comments, quoting from the draft: > > Recent attacks has indicated problems with CBC-mode cipher suites in > TLS/DTLS and problems with the only supported stream cipher (RC4) in > TLS has been known for a long time. While AEAD cipher suites address > these issues, concerns about performance are sometimes raised. > > > What are the performance concerns? I suggest citing some relevant > performance data. If there are implementations of this, we can benchmark them and compare them against other cipher suites and include some numbers or pointers to comparisons. I believe Salsa20 is faster than for example AES GCM on most platforms. > Because the GenericStreamCipher definition in TLS does not provide > any way to transport the Salsa20 nonce that is required for > functionality and needed to provide the random access property, we > let the output from the stream cipher operation be the concatenation > of the IV and the encrypted data. > > > Please, define a Salsa20-based AEAD mechanism instead of a new TLS format! That paragraph has been removed from the current work in progress, it was incorrect (the record sequence number will be used as nonce instead). I don't believe the AEAD mechanism works: there is no field to put the MAC in it. >>Some elements of the draft is still in flux. For example, >>initial performance benchmarks suggests HMAC-SHA256 was a poor choice >>for the MAC so we are looking into UMAC and HMAC-SHA1 as alternatives. >>Still, all comments are appreciated. > > If anything other than HMAC-SHA1 is used, that would underscore the value > of defining an AEAD algorithm. If the main motivation for this work is > encryption that is computationally cheap, then it makes sense to pair the > algorithm with an authentication method with the same characteristics. Yes -- only specifying HMAC-SHA256 was a mistake, and we have included a HMAC-SHA1 variant in the working copy. It is not clear to me whether keeping HMAC-SHA256 is useful. > For security considerations, I suggest citing the analysis of Salsa20, and > adding a sentence or paragraph summarizing the best-known attacks. > Something like "Salsa20 has been analyzed by X independent teams, and the > best known attack breaks 8 of 20 rounds." Good idea, the first paragraph of the security considerations is now: The security of Salsa20 is discussed in the Salsa20 security [SALSA20-SECURITY] paper. The reader must consult cryptographic research to find out the current security status of Salsa20. At the time of writing this document, there are no known significant security problems with Salsa20/12 or Salsa20/20. As of early 2013, the best cryptanalysis breaks 8 out of 20 rounds to recover the 256- bit secret key in 2^251 operations, using 2^31 keystream pairs (see [SALSA20-ATTACK]). For more background, see the eSTREAM report [ESTREAM]. /Simon From simon@josefsson.org Mon Mar 18 13:55:54 2013 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 8398D21F916C; Mon, 18 Mar 2013 13:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMK4lbi3Z+4x; Mon, 18 Mar 2013 13:55:54 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id A29D121F914F; Mon, 18 Mar 2013 13:55:53 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2IKthCd009249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Mar 2013 21:55:45 +0100 From: Simon Josefsson To: Wan-Teh Chang References: <87ppyxhc6y.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130318:tls@ietf.org::K8nk1fUrLw1piW/7:3bnc X-Hashcash: 1:22:130318:cfrg@irtf.org::+Ps6paRixAR8yNrV:Bek3 X-Hashcash: 1:22:130318:wtc@google.com::gE+KLXI0W4qEv3OR:GDSS X-Hashcash: 1:22:130318:joachim@secworks.se::f3lrVB5nPrZ37699:IqUe X-Hashcash: 1:22:130318:mcgrew@cisco.com::Ua0cWHXJYLWnHsCl:UOB+ Date: Mon, 18 Mar 2013 21:55:38 +0100 In-Reply-To: (Wan-Teh Chang's message of "Mon, 18 Mar 2013 12:48:51 -0700") Message-ID: <87620o77hx.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "David McGrew \(mcgrew\)" , "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [Cfrg] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 20:55:54 -0000 Wan-Teh Chang writes: > On Sun, Mar 17, 2013 at 3:51 PM, Simon Josefsson wrote: >> All, >> >> FYI, we have published -00 of a draft that describes how the Salsa20 >> stream cipher can be added to TLS and DTLS, see: >> >> http://tools.ietf.org/html/draft-josefsson-salsa20-tls > > Hi Simon, > > I am interested in this work. I am especially interested in your plan > to allow the salsa20 cipher suites to be used in TLS 1.0 and TLS > 1.1, which you stated in the first paragraph of the Introduction > section. > > Since all of the new cipher suite names end in _SHA256, I > infer the MAC algorithm is hmac_sha256. (The fact is > not explicitly stated in the -00 draft.) Hi Wan-Teh and thank you for the review. Good catch, I have added a paragraph explaining what the MAC algorithm should be. > It is important to clarify how hmac_sha256 can be used in TLS 1.0 and > TLS 1.1, because a naive implementor would see the old definition of > MACAlgorithm in TLS 1.0 and 1.1: > > enum { null, md5, sha } MACAlgorithm; > > and conclude that hmac_sha256 can't be used in TLS > 1.0 and 1.1. Right. Would adding a set of cipher suites that use HMAC-SHA1 resolve this? We have added them already in our working copy for performance reasons. It is not clear whether there is any point in also having HMAC-SHA256, it destroys the performance properties. > I'm also interested in figuring out if these cipher suites > can be used in SSL 3.0. The only difficulty I see is > extending the SSL 3.0 MAC algorithm to hash=sha256 > (see the definition of the SSL 3.0 MAC in Section 5.2.3.1 > of RFC 6101) -- it is not clear what should be the size of > pad_1 and pad_2 for hash=sha256. I'm hoping that using HMAC-SHA1 here would solve this too, right? > The reason I'm interested in SSL 3.0 is that web browsers, > when talking to Google servers, which implement TLS/SSL > version negotiation correctly, are still downgraded to SSL 3.0 > by network errors injected by certain network devices. Having compability with SSL 3.0 would be nice. The next version will mention SSL 3.0 compatibility too. /Simon From mcgrew@cisco.com Mon Mar 18 14:12:04 2013 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 A81AB21F914C for ; Mon, 18 Mar 2013 14:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnKsNNiigq9a for ; Mon, 18 Mar 2013 14:12:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A880221F9146 for ; Mon, 18 Mar 2013 14:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4226; q=dns/txt; s=iport; t=1363641123; x=1364850723; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YHFhIrKFdBhAXh/7aHgA1Pr31JADzxXnkwFK6nSfbxg=; b=D7UxWsI+WkcEkdFmERdv0xZn/gVhBfaQKY0lav+oA8QesmajbLmQ+R4b c/gtl47/yquy7ZvmdxqV2QVkzLHy8If7niIe8YMfgCqbTrFiYwGguuvUw m6NRu2dfaenHJpH8GOK7LzjrXOGXQbO07wzLSRM0zrf35GO7exPGziVAi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIeAR1GtJXG8/2dsb2JhbABDxS6BVhZ0giQBAQEDATo/EgEIIhRCJQIEDgUIiAYGwieOXzEHgl9hA4t6kVOKE4MKgig X-IronPort-AV: E=Sophos;i="4.84,867,1355097600"; d="scan'208";a="188840993" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 18 Mar 2013 21:11:58 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2ILBwih014374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 21:11:58 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 16:11:57 -0500 From: "David McGrew (mcgrew)" To: Simon Josefsson Thread-Topic: Salsa20 stream cipher in TLS Thread-Index: AQHOJBkcOgV0xxTq40yuP+6jbt08QpisAv8A Date: Mon, 18 Mar 2013 21:11:57 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EB9C5@xmb-rcd-x04.cisco.com> In-Reply-To: <87ehfc784a.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [Cfrg] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:12:04 -0000 Hi Simon, On 3/18/13 4:42 PM, "Simon Josefsson" wrote: >"David McGrew (mcgrew)" writes: > >> Hi Simon, > >Hi David. Thanks for quick review. Thanks for the quick response, more inline: > >> It is not exactly clear what problem is being addressed by this work. >> Would be good to add a problem statement section. > >Good idea, the document now contains this paragraph: > > The purpose of this document is to provide an alternative stream > cipher for both TLS and DTLS that is comparable to RC4 in speed on a > wide range of platforms. > >There are other soft factors too. In general the goal is to offer >something that can replace use of RC4 in TLS. I'm guessing speed is one >reason people use RC4 in TLS today. > >> Some more detailed comments, quoting from the draft: >> >> Recent attacks has indicated problems with CBC-mode cipher suites in >> TLS/DTLS and problems with the only supported stream cipher (RC4) in >> TLS has been known for a long time. While AEAD cipher suites address >> these issues, concerns about performance are sometimes raised. >> >> >> What are the performance concerns? I suggest citing some relevant >> performance data. > >If there are implementations of this, we can benchmark them and compare >them against other cipher suites and include some numbers or pointers to >comparisons. I believe Salsa20 is faster than for example AES GCM on >most platforms. > >> Because the GenericStreamCipher definition in TLS does not provide >> any way to transport the Salsa20 nonce that is required for >> functionality and needed to provide the random access property, we >> let the output from the stream cipher operation be the concatenation >> of the IV and the encrypted data. >> >> >> Please, define a Salsa20-based AEAD mechanism instead of a new TLS >>format! > >That paragraph has been removed from the current work in progress, it >was incorrect (the record sequence number will be used as nonce >instead). I don't believe the AEAD mechanism works: there is no field >to put the MAC in it. I'm not sure what you mean about the lack of a MAC field. It would not be hard to define an AEAD algorithm based on Salsa20; I would be surprised if there is not a submission to CAESAR using that cipher. And using the AEAD in TLSv1.2 is straightforward. (Is the issue a desire to use Salsa20 in older versions?) > >>>Some elements of the draft is still in flux. For example, >>>initial performance benchmarks suggests HMAC-SHA256 was a poor choice >>>for the MAC so we are looking into UMAC and HMAC-SHA1 as alternatives. >>>Still, all comments are appreciated. >> >> If anything other than HMAC-SHA1 is used, that would underscore the >>value >> of defining an AEAD algorithm. If the main motivation for this work is >> encryption that is computationally cheap, then it makes sense to pair >>the >> algorithm with an authentication method with the same characteristics. > >Yes -- only specifying HMAC-SHA256 was a mistake, and we have included a >HMAC-SHA1 variant in the working copy. It is not clear to me whether >keeping HMAC-SHA256 is useful. > >> For security considerations, I suggest citing the analysis of Salsa20, >>and >> adding a sentence or paragraph summarizing the best-known attacks. >> Something like "Salsa20 has been analyzed by X independent teams, and >>the >> best known attack breaks 8 of 20 rounds." > >Good idea, the first paragraph of the security considerations is now: > > The security of Salsa20 is discussed in the Salsa20 security > [SALSA20-SECURITY] paper. The reader must consult cryptographic > research to find out the current security status of Salsa20. At the > time of writing this document, there are no known significant > security problems with Salsa20/12 or Salsa20/20. As of early 2013, > the best cryptanalysis breaks 8 out of 20 rounds to recover the 256- > bit secret key in 2^251 operations, using 2^31 keystream pairs (see > [SALSA20-ATTACK]). For more background, see the eSTREAM report > [ESTREAM]. Looks good. David > >/Simon From simon@josefsson.org Mon Mar 18 14:17:25 2013 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 E36A321F8FFD; Mon, 18 Mar 2013 14:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-OU-zyTgi-2; Mon, 18 Mar 2013 14:17:25 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id BE7C421F897A; Mon, 18 Mar 2013 14:17:24 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2ILHIBr010090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Mar 2013 22:17:20 +0100 From: Simon Josefsson To: Adam Langley References: <87ppyxhc6y.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB8AD@xmb-rcd-x04.cisco.com> <87ehfc784a.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130318:agl@google.com::xSV2JNAmIvHd9ZVy:04e4 X-Hashcash: 1:22:130318:tls@ietf.org::GTrw17Fe8VdYV7+F:3GPG X-Hashcash: 1:22:130318:joachim@secworks.se::IYmT3Ten/6vcIFhL:6Q7u X-Hashcash: 1:22:130318:cfrg@irtf.org::fbVVFNdpH4psAGGb:INax Date: Mon, 18 Mar 2013 22:17:12 +0100 In-Reply-To: (Adam Langley's message of "Mon, 18 Mar 2013 16:45:51 -0400") Message-ID: <87r4jc5rxj.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [Cfrg] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:17:26 -0000 Adam Langley writes: > On Mon, Mar 18, 2013 at 4:42 PM, Simon Josefsson wrote: >> instead). I don't believe the AEAD mechanism works: there is no field >> to put the MAC in it. > > There's no field for the GHASH tag for AES-GCM either: the > construction of the authentication is opaque to the user of the AEAD > algorithm. If you were to define an AEAD for this then you could > decide where you would like the MAC to know, but it's a property of > the AEAD, not of TLS. Right, agreed. Equally, the content of the ciphertext for a GenericStreamCipher is opaque to TLS, so we could put a nonce in there if that was necessary (but we don't need to). Having stream ciphers expand data is a bit unorthodox, but from a TLS protocol point of view it may work. Some implementation assume there is no message expansion for stream ciphers, but I haven't seen anything in the specification that assumes or require that. >> Yes -- only specifying HMAC-SHA256 was a mistake, and we have included a >> HMAC-SHA1 variant in the working copy. It is not clear to me whether >> keeping HMAC-SHA256 is useful. > > I'm curious why you wouldn't pair Salsa20 with Poly1305, which is the > typical combination. That could be another option. The only reason is that I haven't worked with any implementation of Poly1305, so I'm not that familiar with it. /Simon From mcgrew@cisco.com Mon Mar 18 14:23:57 2013 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 9F67621F85D6 for ; Mon, 18 Mar 2013 14:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UiXjjf3nZg0 for ; Mon, 18 Mar 2013 14:23:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D7BDE21F85C6 for ; Mon, 18 Mar 2013 14:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2379; q=dns/txt; s=iport; t=1363641835; x=1364851435; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=78zxLcE7EmVZ3fRwkyZGFsGvor0zwiDRbXmd2OD+xsw=; b=NSOm089OPByomFByyJW7JzM4Dj3SILTVPVQndbxU6dlTMTj/ICgw7e1x MLULpWIV6y2G9kKnJre09NokgZdFFh/XJohsDgZETq9I2mSb1N0LL2DZ6 CQZIgSTw4egeXDDG8TvLi//U9h9gFWSl4fld+mDcypeMVKD9tpgcmWVMD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHOFR1GtJV2b/2dsb2JhbABDxTSBWxZ0giQBAQEDATo/EgEIGAoUQiUCBA4FCAyHegYMwiWOXzECBYJfYQOXfY9jgwqCKA X-IronPort-AV: E=Sophos;i="4.84,867,1355097600"; d="scan'208";a="188811719" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 18 Mar 2013 21:23:55 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2ILNtug021336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 21:23:55 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 16:23:55 -0500 From: "David McGrew (mcgrew)" To: Nikos Mavrogiannopoulos Thread-Topic: [TLS] Salsa20 stream cipher in TLS Thread-Index: AQHOI2IRfwT9uKfaFUuf1DQlms1pvpir5i+AgABN3wD//9O3AA== Date: Mon, 18 Mar 2013 21:23:54 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EB9F6@xmb-rcd-x04.cisco.com> In-Reply-To: <514772CE.4060300@gnutls.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: <49DA04091F6369498BEF1352C3192BA4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Josefsson , "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [Cfrg] [TLS] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:23:57 -0000 Hi Nikos, On 3/18/13 4:02 PM, "Nikos Mavrogiannopoulos" wrote: >On 03/18/2013 08:23 PM, David McGrew (mcgrew) wrote: > >> Hi Simon, >>=20 >> On 3/17/13 6:51 PM, "Simon Josefsson" wrote: >>=20 >>> All, >>> >>> FYI, we have published -00 of a draft that describes how the Salsa20 >>> stream cipher can be added to TLS and DTLS, see: >>> >>> http://tools.ietf.org/html/draft-josefsson-salsa20-tls >>> >>> While we are not asking for WG adoption of this draft now, we are at a >>> point where we would like to invite external review and solicit >>> feedback. =20 >>=20 >> Some early feedback; copied CFRG. It would be good to have review from >> that community. >> It is not exactly clear what problem is being addressed by this work. > > >As I understand, the requirement, is a fast stream cipher that can be >used for TLS and DTLS, and doesn't have the issues RC4 has [0]. > >[0]. http://home.hiroshima-u.ac.jp/ohigashi/rc4/index.html Yes, I'm well aware of the RC4 issues and I support its deprecation. > >> Some more detailed comments, quoting from the draft: > >> What are the performance concerns? I suggest citing some relevant >> performance data. > > >The GCM mode does require special instructions to achieve performance >close (but often not better) to RC4 in general purpose CPUs. The stream >ciphers from the eStream competition outperform RC4 without any hw >assistance. The appropriate comparison would include both authentication and encryption, so comparisons to "naked" stream ciphers are misleading. And I strongly encourage actual performance comparisons on target platforms. > >> Because the GenericStreamCipher definition in TLS does not provide >> any way to transport the Salsa20 nonce that is required for >> functionality and needed to provide the random access property, we >> let the output from the stream cipher operation be the concatenation >> of the IV and the encrypted data. >> Please, define a Salsa20-based AEAD mechanism instead of a new TLS >>format! > > >The GenericStreamCipher mode is sufficient for this mode. It just >requires to define how to set the nonce. I think using the AEAD would >complicate things rather than provide any practical advantage. I respectfully disagree. David > >regards, >Nikos From simon@josefsson.org Mon Mar 18 14:47:52 2013 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 D7AB621F85DF; Mon, 18 Mar 2013 14:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGQGfux+dIBC; Mon, 18 Mar 2013 14:47:52 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 118B021F8A09; Mon, 18 Mar 2013 14:47:51 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2ILliI7011347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Mar 2013 22:47:47 +0100 From: Simon Josefsson To: "David McGrew \(mcgrew\)" References: <87ehfc784a.fsf@latte.josefsson.org> <747787E65E3FBD4E93F0EB2F14DB556B183EB9C5@xmb-rcd-x04.cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130318:tls@ietf.org::yfSRUt/OfKmL9Tdb:4my2 X-Hashcash: 1:22:130318:cfrg@irtf.org::xeQWpLRwOeKJ09rB:7Kla X-Hashcash: 1:22:130318:mcgrew@cisco.com::nrEdyeYix5MZ7Jmu:3i40 X-Hashcash: 1:22:130318:joachim@secworks.se::5GPrf/oDr6ZRN7S7:JQ7k Date: Mon, 18 Mar 2013 22:47:39 +0100 In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183EB9C5@xmb-rcd-x04.cisco.com> (David McGrew's message of "Mon, 18 Mar 2013 21:11:57 +0000") Message-ID: <87ip4o5qis.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "cfrg@irtf.org" , "joachim@secworks.se" , "tls@ietf.org" Subject: Re: [Cfrg] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:47:53 -0000 "David McGrew (mcgrew)" writes: > I'm not sure what you mean about the lack of a MAC field. It would not be > hard to define an AEAD algorithm based on Salsa20; I would be surprised if > there is not a submission to CAESAR using that cipher. And using the AEAD > in TLSv1.2 is straightforward. (Is the issue a desire to use Salsa20 in > older versions?) Yes. If it is not possible to implement Salsa20 as a GenericStreamCipher we'll reconsider. Right now to me it seems Salsa20 is more similar to RC4 than to AES-GCM or other AEAD ciphers and there is no advantage in specifying it as a GenericAEADCipher while the advantage for GenericStreamCipher is potential compatibility with older TLS versions. /Simon From mcgrew@cisco.com Tue Mar 19 06:36:08 2013 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 D860821F8AC8 for ; Tue, 19 Mar 2013 06:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOPClAEbChl9 for ; Tue, 19 Mar 2013 06:36:08 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DCC7021F8A38 for ; Tue, 19 Mar 2013 06:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2494; q=dns/txt; s=iport; t=1363700168; x=1364909768; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jijjCFzkWEvgUJ1ArkwuLuvh/hoCLM7YDvmm6QNb7og=; b=A9IH+22WYiAFBu9WdkV4E1sJ7gefdI7OrjGcDmnsO/tL5+v99bRqtQGG nhqQgUa6k6Lfu+iixc0xmPFYNaB6oLpjQB+7Mxbg2DHQ2nUwDgi9bIoKL KHY9BU9Dssixn8w920OacdTnEHTR/VWu4SUHj1IbCGUHKrA42xGDQDPod 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOBoSFGtJV2a/2dsb2JhbABDxSCBXhZ0giQBAQEEeRIBCBgKViUCBAENBQiIDLI9kB2NX3wCMQeCX2EDiD+PP49jgwqCKA X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="scan'208";a="188845794" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 19 Mar 2013 13:36:07 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2JDa7fN004556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 13:36:07 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 08:36:07 -0500 From: "David McGrew (mcgrew)" To: "joachim@secworks.se" , Adam Langley Thread-Topic: [TLS] Salsa20 stream cipher in TLS Thread-Index: AQHOJBkcOgV0xxTq40yuP+6jbt08QpisPsaAgAER6wD//8VGgA== Date: Tue, 19 Mar 2013 13:36:06 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EBFA6@xmb-rcd-x04.cisco.com> In-Reply-To: <514862C6.4070809@secworks.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Josefsson , "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [Cfrg] [TLS] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 13:36:09 -0000 Hi Joachim, On 3/19/13 9:06 AM, "Joachim Str=F6mbergson" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Aloha! > >On 2013-03-18 21:45 , Adam Langley wrote: >> I'm curious why you wouldn't pair Salsa20 with Poly1305, which is >> the typical combination. > >Is poly1305 widely used? I think that's the wrong question to ask when considering a MAC based on universal hashing, since the security of such constructs is well understood. =20 >Would it be advantageous for adoption and >approval of Salsa20 in TLS to also introduce poly1305? If one of the motivations for adopting Salsa20 is that it is computationally cheap (fast in software, small circuit, low power consumption) then it definitely makes sense to pair it with an authenticator with the same properties. It will be important to make sure that the performance is adequate on all of the processors under consideration. Many universal hash functions have a performance that is closely linked to that of the 32,64, or 128-bit multiplication operation, which varies widely across CPUs. > >My gut feeling is/was that trying to just provide a really good >alternative to RC4 would be easiest to do and get adoption for. Well, AES-GCM is certainly a good alternative to RC4 and CBC. It is security-conservative, already specified in TLSv1.2 and implemented in many places, performs very well on dedicated hardware and performs adequately otherwise, and is approved for use in FIPS-140. David > >- --=20 >Med v=E4nlig h=E4lsning, Yours > >Joachim Str=F6mbergson - Alltid i harmonisk sv=E4ngning. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Joachim Str=F6mbergson Secworks AB joachim@secworks.se >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >-----BEGIN PGP SIGNATURE----- >Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >Comment: GPGTools - http://gpgtools.org >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iEYEARECAAYFAlFIYsYACgkQZoPr8HT30QEavwCg04uHLG2XSgTRHt2fL9NZdMft >FM4AoIlRvzHPPzwnjHe4yKkYOjm9q6Bo >=3DddOd >-----END PGP SIGNATURE----- From simon@josefsson.org Tue Mar 19 13:41:40 2013 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 3A7FD21F8F29; Tue, 19 Mar 2013 13:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1GqV0Pf7P86; Tue, 19 Mar 2013 13:41:39 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 30FF221F8F35; Tue, 19 Mar 2013 13:41:38 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2JKfMM7009797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Mar 2013 21:41:24 +0100 From: Simon Josefsson To: Wan-Teh Chang References: <514862C6.4070809@secworks.se> <747787E65E3FBD4E93F0EB2F14DB556B183EBFA6@xmb-rcd-x04.cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130319:joachim@secworks.se::dxc0gSCGfbu+z/Zk:0VfY X-Hashcash: 1:22:130319:cfrg@irtf.org::C0oV06b/PWJtk+mu:2lj X-Hashcash: 1:22:130319:tls@ietf.org::jQ6n40INzvdPyq9Q:35oy X-Hashcash: 1:22:130319:agl@google.com::mSitBaG3KYHSk7bU:HxoV X-Hashcash: 1:22:130319:wtc@google.com::fW1tmDJk5QKNqjFy:Jl6J Date: Tue, 19 Mar 2013 21:41:16 +0100 In-Reply-To: (Wan-Teh Chang's message of "Tue, 19 Mar 2013 11:23:39 -0700") Message-ID: <87fvzrktqr.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "cfrg@irtf.org" , "joachim@secworks.se" , Adam Langley , "tls@ietf.org" Subject: Re: [Cfrg] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 20:41:40 -0000 Wan-Teh Chang writes: > Although it may be possible to retrofit GenericAEADCipher into TLS 1.0 and > 1.1, the existing implementations of the AES-GCM cipher suites restrict them > to TLS 1.2, so there will still be interoperability problems. Implementations could be fixed here, if we want to. There may still be interop problems, but there will always be interop problems so implementations need to handle them anyway. > Assuming we can solve the problems of using GenericAEADCipher and > updating key expansion in TLS 1.0 and 1.1, new AEAD cipher suites can > describe how they will be used in older versions of TLS from day one. > So it still seems worthwhile to solve the problem of using AEAD cipher > suites in TLS 1.0 and 1.1. That may be useful, and would likely have helped adoption of AEAD ciphers in TLS if it was done from the start. I'm not sure why TLS 1.2 isn't negotiated more often by browsers. If it is an implementation issue, I'm not convinced specifying AEAD ciphers for TLS 1.0 and TLS 1.1 will help: they just get another implementation issue to implement that instead. Admittedly, it is a different implementation task, so it may be fixed earlier than the other issue, but that is difficult to predict. Generally, it might be better to push browsers vendors to switch to TLS 1.2 more quickly, then the problem is also solved. /Simon From jon@callas.org Tue Mar 19 16:31:00 2013 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 EF1DE21F8DB7 for ; Tue, 19 Mar 2013 16:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSTLkNj7HcyM for ; Tue, 19 Mar 2013 16:30:59 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8295B21F8DBB for ; Tue, 19 Mar 2013 16:30:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id BD49224C3679 for ; Tue, 19 Mar 2013 16:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yd03Rkt-fQv7 for ; Tue, 19 Mar 2013 16:30:49 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 6FE5F24C365B for ; Tue, 19 Mar 2013 16:30:49 -0700 (PDT) Received: from [192.168.66.100] ([207.239.114.206]) by keys.merrymeet.com (PGP Universal service); Tue, 19 Mar 2013 16:30:49 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 19 Mar 2013 16:30:49 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jon Callas In-Reply-To: <87fvzrktqr.fsf@latte.josefsson.org> Date: Tue, 19 Mar 2013 16:30:16 -0700 Message-Id: References: <514862C6.4070809@secworks.se> <747787E65E3FBD4E93F0EB2F14DB556B183EBFA6@xmb-rcd-x04.cisco.com> <87fvzrktqr.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1503) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jon Callas , "cfrg@irtf.org" , "joachim@secworks.se" , Adam Langley , "tls@ietf.org" , Wan-Teh Chang Subject: Re: [Cfrg] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 23:31:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 19, 2013, at 1:41 PM, Simon Josefsson wrote: > I'm not sure why TLS 1.2 isn't negotiated more often by browsers. If it > is an implementation issue, I'm not convinced specifying AEAD ciphers > for TLS 1.0 and TLS 1.1 will help: they just get another implementation > issue to implement that instead. Admittedly, it is a different > implementation task, so it may be fixed earlier than the other issue, > but that is difficult to predict. Generally, it might be better to push > browsers vendors to switch to TLS 1.2 more quickly, then the problem is > also solved. There are two reasons. Uncertainty about ECC, and uncertainty about GCM. We can debate how much the ECC uncertainty is warranted, but lots of people= have it. We can also debate the GCM issues, but GCM is tetchy to use prope= rly. And yes, you could always use CCM instead. But most people don't know = that CCM is part of TLS 1.2. I didn't know it I discovered it while writing= this note. The general opinion about TLS 1.2 is that that's the version for Suite B. T= hat's not precisely true. I had that opinion for a while until I learned I = was mistaken. However, if you have concerns about either ECC or GCM, then y= ou have concerns about TLS 1.2. I don't know if you can do 1.2 without ECC = or GCM. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFRSPUpsTedWZOD3gYRAimEAJ0V1eXYxUqRHxWWNaX1GzZJIIz0ZgCfRBXF 48rWFyQymJ1znyyvWCKO4MY=3D =3DJh5v -----END PGP SIGNATURE----- From James.H.Manger@team.telstra.com Tue Mar 19 22:57:43 2013 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 2DDFD21F8D65 for ; Tue, 19 Mar 2013 22:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0PKgxIWRxBe for ; Tue, 19 Mar 2013 22:57:42 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7069B21F8D55 for ; Tue, 19 Mar 2013 22:57:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,876,1355058000"; d="scan'208";a="124788656" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 20 Mar 2013 16:57:40 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7019"; a="172241032" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcavi.tcif.telstra.com.au with ESMTP; 20 Mar 2013 16:57:40 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Wed, 20 Mar 2013 16:57:40 +1100 From: "Manger, James H" To: 'IRTF CFRG' Date: Wed, 20 Mar 2013 16:57:38 +1100 Thread-Topic: AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm Thread-Index: Ac4lL9NyQFK/uhfsRx+HrnkfaTBDmQ== Message-ID: <255B9BB34FB7D647A506DC292726F6E1150BBD8DFD@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Cfrg] AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 05:57:43 -0000 SWYgeW91IHBhc3MgYWRkaXRpb25hbCBkYXRhIChBQUQpLCBidXQgbm8gcGxhaW50ZXh0LCB0byB0 aGUgR0NNIEFFQUQgYWxnb3JpdGhtIHlvdSBlZmZlY3RpdmVseSBnZXQgYSBNQUMgYWxnb3JpdGht LiBJdCBldmVuIGhhcyBhIG5hbWU6IEdNQUMuDQoNClByZXN1bWFibHkgaXQgaXMgZXF1YWxseSB0 cml2aWFsIHRvIGNyZWF0ZSBhIE1BQyBhbGdvcml0aG0gZnJvbSBhbnkgQUVBRCBhbGdvcml0aG0u DQoNCllvdSBjYW4gZG8gdGhpcyB3aXRoIHRoZSBBRUFEX0FFU194X0NCQ19ITUFDX1NIQV95IGFs Z29yaXRobXMgaW4gZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTItMDEuIEhvd2V2 ZXIsIHRoZSBvdXRwdXQgaXMgYSAxNi1ieXRlIElWLCAxNi1ieXRlIGNpcGhlcnRleHQgKGVuY3J5 cHRpbmcgYSBibG9jayBvZiBwYWRkaW5nKSwgYW5kIHRoZSB0cnVuY2F0ZWQgSE1BQyBvdXRwdXQu IFRoaXMgaXMgMzIgYnl0ZXMgbW9yZSB0aGFuIGEgc3RyYWlnaHQgSE1BQyBvZiB0aGUgQUFELg0K DQpRdWVzdGlvbiAxOiBJcyBITUFDIG92ZXIgQUFELXBsdXMtcmFuZG9tLUlWIGJldHRlciBjcnlw dG9ncmFwaGljYWxseSB0aGFuIEhNQUMgb3ZlciBqdXN0IHRoZSBBQUQ/DQoNCg0KV2hlbiBkZWZp bmluZyBhIHNlY3VyZSBtZXNzYWdlIGZvcm1hdCBhIHRlbXB0aW5nIHNpbXBsaWZpY2F0aW9uIGlz IHRvIG9ubHkgZGVmaW5lIGhvdyB0byB1c2UgYW4gQUVBRCBhbGdvcml0aG0uIFRoZW4gaWYgYSBw YXJ0aWN1bGFyIG1lc3NhZ2UgZG9lc24ndCBuZWVkIGNvbmZpZGVudGlhbGl0eSBqdXN0IHB1dCB0 aGUgY29udGVudCBpbnRvIHRoZSBBQUQgZmllbGQgYW5kIGxlYXZlIHRoZSBwbGFpbnRleHQgZW1w dHkuIFRoaXMgYXBwcm9hY2ggaXMgbGVzcyBhdHRyYWN0aXZlIGlmIHVzaW5nIGFuIEFFQUQgYWxn b3JpdGhtIGluICJNQUMgbW9kZSIgaW5jdXJzIGFuIHVubmVjZXNzYXJ5IDMyLWJ5dGUgb3Zlcmhl YWQgb3ZlciBhIGRlZGljYXRlZCBNQUMgbW9kZS4NCg0KUXVlc3Rpb24gMjogU2hvdWxkIGRyYWZ0 LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyIGFkZCBhIHNwZWNpYWwgY2FzZSBmb3Igd2hl biB0aGUgcGxhaW50ZXh0IGlzIGVtcHR5Pw0KSWYgdGhlIGFuc3dlciB0byBRMSBpcyAiTm8iLCB0 aGUgc3BlY2lhbCBjYXNlIG1pZ2h0IGJlICJ3aGVuIHRoZSBwbGFpbnRleHQgaXMgZW1wdHk6IHNl dCB0aGUgSVYgdG8gYWxsIHplcm9zOyBhbmQgdGhlIG91dHB1dCBpcyBqdXN0IHRoZSB0cnVuY2F0 ZWQgaGFzaCAoQyA9IFQpLCBvbWl0dGluZyB0aGUgSVYgYW5kIGNpcGhlcnRleHQiLiBBbHRlcm5h dGl2ZWx5LCB0aGUgc3BlY2lhbCBjYXNlIG1pZ2h0IGp1c3QgaW52b2x2ZSBITUFDLCB3aXRoIG5v IEFFUyBvcGVyYXRpb25zLg0KSWYgdGhlIGFuc3dlciB0byBRMSBpcyAiWWVzIiwgdGhlIHNwZWNp YWwgY2FzZSBtaWdodCBiZSAid2hlbiB0aGUgcGxhaW50ZXh0IGlzIGVtcHR5OiB0aGUgb3V0cHV0 IGlzIEMgPSBJViB8fCBULCBvbWl0dGluZyB0aGUgZW5jcnlwdGVkIHBhZGRpbmciLg0KDQoNCi0t DQpKYW1lcyBNYW5nZXINCg0KDQo= From mcgrew@cisco.com Wed Mar 20 02:55:51 2013 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 DCA1E21F8A41 for ; Wed, 20 Mar 2013 02:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEu7kHOrZU24 for ; Wed, 20 Mar 2013 02:55:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 073D721F8A64 for ; Wed, 20 Mar 2013 02:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2952; q=dns/txt; s=iport; t=1363773351; x=1364982951; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=m5Nr3Z/zGLgaPY+jnDMdm0bpXh4VW79Nn6qE5aBkRkc=; b=I4+vcYKoEgsXis0l5emvcwwUCeYAv+veDS8qPEPoyxZorertpqpjkLcl ioWrKrA+nU/01/TqjhgKyKd2PyjOta6WTIsyW5bZJXrie9UWgnHQDKU8B D+mee1866UBgYV4h1QdrkL4qePjcY9aJHmTLIFbN2r4aFYLcsYfRb/Fej E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGCHSVGtJXG+/2dsb2JhbABDxRKBSBZ0giQBAQEDAQEBATc0CxIBCBgKFDcLJQIEAQ0FCAGIBQYMwhAXjDyCIjEHgl9hA6digwqCKA X-IronPort-AV: E=Sophos;i="4.84,876,1355097600"; d="scan'208";a="186440167" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 20 Mar 2013 09:55:28 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2K9tRAZ008319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 09:55:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 04:55:27 -0500 From: "David McGrew (mcgrew)" To: Jon Callas , Simon Josefsson Thread-Topic: [Cfrg] Salsa20 stream cipher in TLS Thread-Index: AQHOJOIar3FapCbYoEGyY4Iqyk/e/pit/XkAgABrnQA= Date: Wed, 20 Mar 2013 09:55:26 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EC751@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Wan-Teh Chang , "cfrg@irtf.org" , "joachim@secworks.se" , Adam Langley , "tls@ietf.org" Subject: Re: [Cfrg] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 09:55:52 -0000 Hi Jon, On 3/19/13 7:30 PM, "Jon Callas" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Mar 19, 2013, at 1:41 PM, Simon Josefsson wrote: > >> I'm not sure why TLS 1.2 isn't negotiated more often by browsers. If it >> is an implementation issue, I'm not convinced specifying AEAD ciphers >> for TLS 1.0 and TLS 1.1 will help: they just get another implementation >> issue to implement that instead. Admittedly, it is a different >> implementation task, so it may be fixed earlier than the other issue, >> but that is difficult to predict. Generally, it might be better to push >> browsers vendors to switch to TLS 1.2 more quickly, then the problem is >> also solved. > >There are two reasons. Uncertainty about ECC, and uncertainty about GCM. > >We can debate how much the ECC uncertainty is warranted, but lots of >people have it. We can also debate the GCM issues, but GCM is tetchy to >use properly. >And yes, you could always use CCM instead. But most people don't know >that CCM is part of TLS 1.2. I didn't know it I discovered it while >writing this note. > >The general opinion about TLS 1.2 is that that's the version for Suite B. >That's not precisely true. I had that opinion for a while until I learned >I was mistaken. However, if you have concerns about either ECC or GCM, >then you have concerns about TLS 1.2. I don't know if you can do 1.2 >without ECC or GCM. TLSv1.2 barely mentions either GCM or ECC, much less requires their use. RFC 5246 says: in the absence of an application profile standard specifying otherwise, a TLSv1.2-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. No ECC or GCM ciphersuites are mentioned in that RFC. On the flip side, there are benefits in using that version; v1.2 allows to use SHA256 in key derivation (PRF) and message authentication (HMAC), allows the use of AEAD, and adds other fixes. GCM does require a distinct nonce for each encryption operation, which makes it vulnerable to "nonce misuse", or makes it tetchy as you say. However, this property is a non-issue in TLS, since it is easy to use a sequence number as a nonce, and session keys don't persist between sessions. For comparison, Salsa20 and UMAC, both recently mentioned on this thread, would also have exactly the same distinct-nonce requirement, and essentially RC4 does as well (in the sense that an application that mis-manages the RC4 state would likely cause a loss of confidentiality). David > > Jon > > >-----BEGIN PGP SIGNATURE----- >Version: PGP Universal 3.2.0 (Build 1672) >Charset: us-ascii > >wj8DBQFRSPUpsTedWZOD3gYRAimEAJ0V1eXYxUqRHxWWNaX1GzZJIIz0ZgCfRBXF >48rWFyQymJ1znyyvWCKO4MY=3D >=3DJh5v >-----END PGP SIGNATURE----- >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg From Kenny.Paterson@rhul.ac.uk Wed Mar 20 05:36:20 2013 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 D3A6321F88E5 for ; Wed, 20 Mar 2013 05:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVdorEzhdKBV for ; Wed, 20 Mar 2013 05:36:20 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 3501821F8788 for ; Wed, 20 Mar 2013 05:36:20 -0700 (PDT) Received: from mail211-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Mar 2013 12:36:19 +0000 Received: from mail211-ch1 (localhost [127.0.0.1]) by mail211-ch1-R.bigfish.com (Postfix) with ESMTP id 2E5BAE00C1; Wed, 20 Mar 2013 12:36:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:134.219.208.197; KIP:(null); UIP:(null); IPV:NLI; H:EXCH-HUB03.cc.rhul.local; RD:exch-hub03.rhul.ac.uk; EFVD:NLI X-SpamScore: 24 X-BigFish: VPS24(zz98dI1432Idb82hzz1f42h1ee6h1de0h1d18h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1aa3ir1155h) Received: from mail211-ch1 (localhost.localdomain [127.0.0.1]) by mail211-ch1 (MessageSwitch) id 1363782977860165_22221; Wed, 20 Mar 2013 12:36:17 +0000 (UTC) Received: from CH1EHSMHS036.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail211-ch1.bigfish.com (Postfix) with ESMTP id C64793A004B; Wed, 20 Mar 2013 12:36:17 +0000 (UTC) Received: from EXCH-HUB03.cc.rhul.local (134.219.208.197) by CH1EHSMHS036.bigfish.com (10.43.69.245) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Mar 2013 12:36:14 +0000 Received: from EXCH-MB01.cc.rhul.local ([169.254.3.31]) by EXCH-HUB03.cc.rhul.local ([2002:86db:d0c5::86db:d0c5]) with mapi id 14.02.0328.009; Wed, 20 Mar 2013 12:36:12 +0000 From: "Paterson, Kenny" To: "Manger, James H" Thread-Topic: [Cfrg] AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm Thread-Index: Ac4lL9NyQFK/uhfsRx+HrnkfaTBDmQAN60qA Date: Wed, 20 Mar 2013 12:36:10 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E1150BBD8DFD@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150BBD8DFD@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [78.147.242.69] Content-Type: text/plain; charset="us-ascii" Content-ID: <52A50704CC78664191D7FE71EC71FF7A@rhul.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Cc: IRTF CFRG Subject: Re: [Cfrg] AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 12:36:21 -0000 Hi James, Good questions. My personal view in-line. I'll be interested in hearing Dav= id's viewpoint. On 20 Mar 2013, at 05:57, Manger, James H wrote: > If you pass additional data (AAD), but no plaintext, to the GCM AEAD algo= rithm you effectively get a MAC algorithm. It even has a name: GMAC. Indeed, and it's even standardised in various places :-) >=20 > Presumably it is equally trivial to create a MAC algorithm from any AEAD = algorithm. >=20 > You can do this with the AEAD_AES_x_CBC_HMAC_SHA_y algorithms in draft-mc= grew-aead-aes-cbc-hmac-sha2-01. However, the output is a 16-byte IV, 16-byt= e ciphertext (encrypting a block of padding), and the truncated HMAC output= . This is 32 bytes more than a straight HMAC of the AAD. >=20 > Question 1: Is HMAC over AAD-plus-random-IV better cryptographically than= HMAC over just the AAD? >=20 No, there's no security advantage (that I know of) to having HMAC over "AAD= plus random IV" compared to HMAC over just the AAD.=20 >=20 > When defining a secure message format a tempting simplification is to onl= y define how to use an AEAD algorithm. Then if a particular message doesn't= need confidentiality just put the content into the AAD field and leave the= plaintext empty. This approach is less attractive if using an AEAD algorit= hm in "MAC mode" incurs an unnecessary 32-byte overhead over a dedicated MA= C mode. >=20 > Question 2: Should draft-mcgrew-aead-aes-cbc-hmac-sha2 add a special case= for when the plaintext is empty? > If the answer to Q1 is "No", the special case might be "when the plaintex= t is empty: set the IV to all zeros; and the output is just the truncated h= ash (C =3D T), omitting the IV and ciphertext". Alternatively, the special = case might just involve HMAC, with no AES operations. > If the answer to Q1 is "Yes", the special case might be "when the plainte= xt is empty: the output is C =3D IV || T, omitting the encrypted padding". I see the rationale of reducing overhead. Your proposal would also reduce t= he randomness requirements of the scheme for this "MAC only" mode.=20 But even so I'd prefer not to go down this route because of the potential f= or confusion and mis-impementation. A single, clean design without too many= options feels better in that respect.=20 While I don't see any security issues immediately, I'd also be concerned ab= out having a special case that might somehow interact badly with the genera= l case. Do you see anything troubling there?=20 Cheers, Kenny= From mcgrew@cisco.com Wed Mar 20 11:18:12 2013 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 19F7611E80D1 for ; Wed, 20 Mar 2013 11:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K17MPoi9kzdU for ; Wed, 20 Mar 2013 11:18:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BD78311E80A6 for ; Wed, 20 Mar 2013 11:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4162; q=dns/txt; s=iport; t=1363803490; x=1365013090; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pJlxGq/Y550qd2poji1klRVljKU7otSczFZFp4id30Y=; b=RfpQzgIsFD0l0bogy7YovvHgByUPWiH4roBE7rrD6fbJJ8rF6iMDf/Y9 orAajyJ8nO4woQrmUtOSPywhkndqdy8hrIdijWRJLNcoc/4pkz+Dw7qjv kGMWdWLoK+mLNqx2u+SFw71m/GdtnH82hndPMwDI74BZSjE/rUsdbMSAe 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACP8SVGtJV2b/2dsb2JhbABEDsUTgVIWdIIkAQEBBAEBATc0CxIBCBgKFDcLJQEBBA4FCAGICwzCTIw8giIGKweCX2EDoEyHFoJLP4Io X-IronPort-AV: E=Sophos;i="4.84,880,1355097600"; d="scan'208";a="189683125" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 20 Mar 2013 18:18:09 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2KII9ju026431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 18:18:09 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 13:18:08 -0500 From: "David McGrew (mcgrew)" To: "Paterson, Kenny" , "Manger, James H" Thread-Topic: [Cfrg] AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm Thread-Index: Ac4lL9NyQFK/uhfsRx+HrnkfaTBDmQAN60qAAA4JRYA= Date: Wed, 20 Mar 2013 18:18:08 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183ECBC3@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: <50EEA2CC5A824C458163FCA697A157A2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IRTF CFRG Subject: Re: [Cfrg] AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:18:12 -0000 Hi James and Kenny, On 3/20/13 8:36 AM, "Paterson, Kenny" wrote: >Hi James, > >Good questions. My personal view in-line. I'll be interested in hearing >David's viewpoint. > >On 20 Mar 2013, at 05:57, Manger, James H wrote: > >> If you pass additional data (AAD), but no plaintext, to the GCM AEAD >>algorithm you effectively get a MAC algorithm. It even has a name: GMAC. > >Indeed, and it's even standardised in various places :-) > >>=20 >> Presumably it is equally trivial to create a MAC algorithm from any >>AEAD algorithm. Agreed. =20 >>=20 >> You can do this with the AEAD_AES_x_CBC_HMAC_SHA_y algorithms in >>draft-mcgrew-aead-aes-cbc-hmac-sha2-01. However, the output is a 16-byte >>IV, 16-byte ciphertext (encrypting a block of padding), and the >>truncated HMAC output. This is 32 bytes more than a straight HMAC of the >>AAD. Yes, good observation. >>=20 >> Question 1: Is HMAC over AAD-plus-random-IV better cryptographically >>than HMAC over just the AAD? >>=20 > >No, there's no security advantage (that I know of) to having HMAC over >"AAD plus random IV" compared to HMAC over just the AAD. Agreed. >=20 > >>=20 >> When defining a secure message format a tempting simplification is to >>only define how to use an AEAD algorithm. Then if a particular message >>doesn't need confidentiality just put the content into the AAD field and >>leave the plaintext empty. This approach is less attractive if using an >>AEAD algorithm in "MAC mode" incurs an unnecessary 32-byte overhead over >>a dedicated MAC mode. >>=20 >> Question 2: Should draft-mcgrew-aead-aes-cbc-hmac-sha2 add a special >>case for when the plaintext is empty? >> If the answer to Q1 is "No", the special case might be "when the >>plaintext is empty: set the IV to all zeros; and the output is just the >>truncated hash (C =3D T), omitting the IV and ciphertext". Alternatively, >>the special case might just involve HMAC, with no AES operations. >> If the answer to Q1 is "Yes", the special case might be "when the >>plaintext is empty: the output is C =3D IV || T, omitting the encrypted >>padding". > >I see the rationale of reducing overhead. Your proposal would also reduce >the randomness requirements of the scheme for this "MAC only" mode. > >But even so I'd prefer not to go down this route because of the potential >for confusion and mis-impementation. A single, clean design without too >many options feels better in that respect. > >While I don't see any security issues immediately, I'd also be concerned >about having a special case that might somehow interact badly with the >general case. Do you see anything troubling there? I recognize both the motivation for reducing bandwidth and the concern about special cases that might inadvertently cause trouble. If there are implementations that would use AEAD_CBC_HMAC as a MAC, then I think it makes sense to do the bandwidth optimization, *if* we can convince ourselves that there is no potential for badness on the decryption side. It seems as though the change would come in Steps 2 and 4 of Section 2.2 "Decryption", which would change to something like: 2. If C contains exactly T_LEN octets, then S is the zero-length String. Otherwise, ... ... 4. If S is the zero-length string, then P is set to the zero-length string. Otherwise, ... At Step 2 of Section 2.1 "Encryption", we would need to say "If P contains exactly zero octets, then S is the zero-length string; skip to step 5." It looks innocuous, but deserves more analysis I think. My inclination is that we should only add this if there are plans to use the algorithm as a MAC. Are there scenarios in which AEAD_CBC_HMAC would be available, but the underlying HMAC would not? I can see value in minimizing the number of entry points to a crypto implementation, but on the other hand, HMAC is already broadly available. David > >Cheers, > >Kenny >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg From mcgrew@cisco.com Wed Mar 20 11:43:36 2013 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 F290D21F904D for ; Wed, 20 Mar 2013 11:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hoEppX2Q-UV for ; Wed, 20 Mar 2013 11:43:35 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 531AC21F903C for ; Wed, 20 Mar 2013 11:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1393; q=dns/txt; s=iport; t=1363805015; x=1365014615; h=from:to:subject:date:message-id:mime-version; bh=aMi9SjPqnwTNtFoxbYyqEKxjNAxnfcvOuLb3DK2m1LU=; b=NHMD39A8maUFbgXI1P9WvrISow7N12mq5lRMcBdH0iQ1C1e6Q2MYvTSn Qo51zLLF7QBmOCYgyg2wkNPwTAcUs+SndocosJp+v/dAhmdSZLZbyftxO f4latm9Z7LKNX5WZ/OUeRsdHDEtbrAybapZ+2pogZxayEJPNPw678hyAH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEMABwDSlGtJV2d/2dsb2JhbABEh1G9TQECAYFSFm0HgiYBBIELAQsBHlYnBBsBiAsMoS6hIY4nIxSDF2EDp2KDCoIo X-IronPort-AV: E=Sophos;i="4.84,880,1355097600"; d="scan'208,217";a="189648007" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 20 Mar 2013 18:43:23 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2KIhNYv024342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 20 Mar 2013 18:43:23 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 13:43:22 -0500 From: "David McGrew (mcgrew)" To: "cfrg@irtf.org" Thread-Topic: minutes from IETF 86 meeting Thread-Index: AQHOJZrMgDdAD02sIkCI5YA3XDk6cg== Date: Wed, 20 Mar 2013 18:43:22 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183ECCCA@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B183ECCCAxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [Cfrg] minutes from IETF 86 meeting X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:43:36 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B183ECCCAxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minutes are now posted. Thanks to Paul Hoffman for being the scribe. David http://www.ietf.org/proceedings/86/minutes/minutes-86-cfrg --_000_747787E65E3FBD4E93F0EB2F14DB556B183ECCCAxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <505B8C14051274409D042D8C1603EABD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Minutes a= re now posted.   Thanks to Paul Hoffman for being the scribe.

David

http://ww= w.ietf.org/proceedings/86/minutes/minutes-86-cfrg
--_000_747787E65E3FBD4E93F0EB2F14DB556B183ECCCAxmbrcdx04ciscoc_-- From benlaurie@gmail.com Wed Mar 20 13:36:49 2013 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 C62B91F0D10 for ; Wed, 20 Mar 2013 13:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUHkqyCiilYF for ; Wed, 20 Mar 2013 13:36:49 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 52D381F0D0F for ; Wed, 20 Mar 2013 13:36:49 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id z24so1042555qcq.5 for ; Wed, 20 Mar 2013 13:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/em8qfc+RjvM4agQLsQ06OmLOPW4aEAKuiKCmjb9UTk=; b=qZYJ+VW9rTatoWjpW/qCdJ2OXStZIdUi+/sdLbmZdv5E1N5Nmi1Dg7hG72bG0+jdfw Y0TtbBxJieqSWHqB5rMGeXtsI1eKsJsLuC2NTYLg1kXvo7TrJG1bd+FDRbitiAumJLyY gbqtP3ZxKXThcbP/rgUQu49KcBA8QWyFXhwy/2sw4DXztQyKrypfGkDX884e6cMBOT2Q Eef9CACzcLq7TdSrgNo54n3DWiMrIJSpIThbgR3v8PhoEmjimlpA9XGNxWeMAI+OiN+G LXKn95OPzr1iU0jqP9WCac3WEWNHu/09gVzL+o91/k057dDvrn+Sl0qTZf2J/Eyk61pl h2DQ== MIME-Version: 1.0 X-Received: by 10.49.28.229 with SMTP id e5mr8524978qeh.14.1363811808696; Wed, 20 Mar 2013 13:36:48 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.121.233 with HTTP; Wed, 20 Mar 2013 13:36:48 -0700 (PDT) In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183ECCCA@xmb-rcd-x04.cisco.com> References: <747787E65E3FBD4E93F0EB2F14DB556B183ECCCA@xmb-rcd-x04.cisco.com> Date: Wed, 20 Mar 2013 20:36:48 +0000 X-Google-Sender-Auth: VdMFlgEDt16FWDH4gauJQ6UBIj4 Message-ID: From: Ben Laurie To: "David McGrew (mcgrew)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] minutes from IETF 86 meeting X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 20:36:49 -0000 On 20 March 2013 18:43, David McGrew (mcgrew) wrote: > Minutes are now posted. Thanks to Paul Hoffman for being the scribe. > > David > > http://www.ietf.org/proceedings/86/minutes/minutes-86-cfrg I just want to observe that arguments of the form "we should not use X because X is not widely used" are not worth the paper they are written on. From pgut001@cs.auckland.ac.nz Wed Mar 20 14:58:05 2013 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 9E45A21F8E47 for ; Wed, 20 Mar 2013 14:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbGnDg8OOUm2 for ; Wed, 20 Mar 2013 14:58:04 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9C67B21F8E2C for ; Wed, 20 Mar 2013 14:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363816685; x=1395352685; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=d6SWbnhEdwvyQbgEagCqtrMSQ3T0NrW4BNTU5SDS/HE=; b=edL8X8rUir0Lev+KahuHzoFzydKEdjXksRdF2f2Uy9N2aTF7FI1sVmnD ezrTVuYctI7i9akHF9GyGy9i9p6McgHwG4HWl0QWECFu/c7TcrriqeUEF bnWTYddUvMWgsrsC0r69i+XZ+NXBAGDbtjkyUUlxD8HLUj/HQb/4ExWtC w=; X-IronPort-AV: E=Sophos;i="4.84,881,1355050800"; d="scan'208";a="176825904" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Mar 2013 10:58:03 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Mar 2013 10:58:03 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.115]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 10:58:03 +1300 From: Peter Gutmann To: "cfrg@irtf.org" Thread-Topic: [Cfrg] minutes from IETF 86 meeting Thread-Index: Ac4ltfqPkp9C33CpSpCkXTgNu6JjIQ== Date: Wed, 20 Mar 2013 21:57:56 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D2239B@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Cfrg] minutes from IETF 86 meeting X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 21:58:05 -0000 Ben Laurie writes:=0A= >On 20 March 2013 18:43, David McGrew (mcgrew) wrote:=0A= >> Minutes are now posted. Thanks to Paul Hoffman for being the scribe.= =0A= >>=0A= >> http://www.ietf.org/proceedings/86/minutes/minutes-86-cfrg=0A= >=0A= >I just want to observe that arguments of the form "we should not use X=0A= >because X is not widely used" are not worth the paper they are written on.= =0A= =0A= I assume you mean the "Survey showed that GCM is not universally provided, = so=0A= can also do CBC plus HMAC", which sounds perfectly reasonable to me. What= =0A= you're proposing seems to be "X is rarely used, so we should require it in = our=0A= spec", which in effect is saying "We don't want our spec to be used".=0A= =0A= Peter.=0A= From James.H.Manger@team.telstra.com Wed Mar 20 16:20:12 2013 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 7F76111E80F5 for ; Wed, 20 Mar 2013 16:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.507 X-Spam-Level: X-Spam-Status: No, score=-1.507 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKLbG6wf2n0Q for ; Wed, 20 Mar 2013 16:20:11 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3E72711E80F4 for ; Wed, 20 Mar 2013 16:20:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,880,1355058000"; d="scan'208";a="124428719" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 21 Mar 2013 10:20:09 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7020"; a="120153702" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdvi.tcif.telstra.com.au with ESMTP; 21 Mar 2013 10:20:09 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Thu, 21 Mar 2013 10:20:08 +1100 From: "Manger, James H" To: "David McGrew (mcgrew)" , "Paterson, Kenny" Date: Thu, 21 Mar 2013 10:20:07 +1100 Thread-Topic: [Cfrg] AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm Thread-Index: Ac4lL9NyQFK/uhfsRx+HrnkfaTBDmQAN60qAAA4JRYAABlT2MA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1150BBD92CD@WSMSG3153V.srv.dir.telstra.com> References: <747787E65E3FBD4E93F0EB2F14DB556B183ECBC3@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183ECBC3@xmb-rcd-x04.cisco.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IRTF CFRG Subject: Re: [Cfrg] AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 23:20:12 -0000 PiA+PiBRdWVzdGlvbiAxOiBJcyBITUFDIG92ZXIgQUFELXBsdXMtcmFuZG9tLUlWIGJldHRlciBj cnlwdG9ncmFwaGljYWxseQ0KPiA+PnRoYW4gSE1BQyBvdmVyIGp1c3QgdGhlIEFBRD8NCj4gPg0K PiA+Tm8sIHRoZXJlJ3Mgbm8gc2VjdXJpdHkgYWR2YW50YWdlICh0aGF0IEkga25vdyBvZikgdG8g aGF2aW5nIEhNQUMgb3Zlcg0KPiA+IkFBRCBwbHVzIHJhbmRvbSBJViIgY29tcGFyZWQgdG8gSE1B QyBvdmVyIGp1c3QgdGhlIEFBRC4NCj4gDQo+IEFncmVlZC4NCg0KPiA+PiBRdWVzdGlvbiAyOiBT aG91bGQgZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTIgYWRkIGEgc3BlY2lhbA0K PiA+PmNhc2UgZm9yIHdoZW4gdGhlIHBsYWludGV4dCBpcyBlbXB0eT8NCj4gPg0KPiA+SSBzZWUg dGhlIHJhdGlvbmFsZSBvZiByZWR1Y2luZyBvdmVyaGVhZC4gWW91ciBwcm9wb3NhbCB3b3VsZCBh bHNvDQo+IHJlZHVjZQ0KPiA+dGhlIHJhbmRvbW5lc3MgcmVxdWlyZW1lbnRzIG9mIHRoZSBzY2hl bWUgZm9yIHRoaXMgIk1BQyBvbmx5IiBtb2RlLg0KPiA+DQo+ID5CdXQgZXZlbiBzbyBJJ2QgcHJl ZmVyIG5vdCB0byBnbyBkb3duIHRoaXMgcm91dGUgYmVjYXVzZSBvZiB0aGUNCj4gcG90ZW50aWFs DQo+ID5mb3IgY29uZnVzaW9uIGFuZCBtaXMtaW1wZW1lbnRhdGlvbi4gQSBzaW5nbGUsIGNsZWFu IGRlc2lnbiB3aXRob3V0DQo+IHRvbw0KPiA+bWFueSBvcHRpb25zIGZlZWxzIGJldHRlciBpbiB0 aGF0IHJlc3BlY3QuDQo+ID4NCj4gPldoaWxlIEkgZG9uJ3Qgc2VlIGFueSBzZWN1cml0eSBpc3N1 ZXMgaW1tZWRpYXRlbHksIEknZCBhbHNvIGJlDQo+IGNvbmNlcm5lZA0KPiA+YWJvdXQgaGF2aW5n IGEgc3BlY2lhbCBjYXNlIHRoYXQgbWlnaHQgc29tZWhvdyBpbnRlcmFjdCBiYWRseSB3aXRoIHRo ZQ0KPiA+Z2VuZXJhbCBjYXNlLiBEbyB5b3Ugc2VlIGFueXRoaW5nIHRyb3VibGluZyB0aGVyZT8N Cj4gDQo+IEkgcmVjb2duaXplIGJvdGggdGhlIG1vdGl2YXRpb24gZm9yIHJlZHVjaW5nIGJhbmR3 aWR0aCBhbmQgdGhlIGNvbmNlcm4NCj4gYWJvdXQgc3BlY2lhbCBjYXNlcyB0aGF0IG1pZ2h0IGlu YWR2ZXJ0ZW50bHkgY2F1c2UgdHJvdWJsZS4NCj4gDQo+IElmIHRoZXJlIGFyZSBpbXBsZW1lbnRh dGlvbnMgdGhhdCB3b3VsZCB1c2UgQUVBRF9DQkNfSE1BQyBhcyBhIE1BQywNCj4gdGhlbiBJDQo+ IHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRvIGRvIHRoZSBiYW5kd2lkdGggb3B0aW1pemF0aW9uLCAq aWYqIHdlIGNhbg0KPiBjb252aW5jZSBvdXJzZWx2ZXMgdGhhdCB0aGVyZSBpcyBubyBwb3RlbnRp YWwgZm9yIGJhZG5lc3Mgb24gdGhlDQo+IGRlY3J5cHRpb24gc2lkZS4gIEl0IHNlZW1zIGFzIHRo b3VnaCB0aGUgY2hhbmdlIHdvdWxkIGNvbWUgaW4gU3RlcHMgMg0KPiBhbmQNCj4gNCBvZiBTZWN0 aW9uIDIuMiAiRGVjcnlwdGlvbiIsIHdoaWNoIHdvdWxkIGNoYW5nZSB0byBzb21ldGhpbmcgbGlr ZToNCj4gDQo+ICAgIDIuIElmIEMgY29udGFpbnMgZXhhY3RseSBUX0xFTiBvY3RldHMsIHRoZW4g UyBpcyB0aGUgemVyby1sZW5ndGgNCj4gICAgICAgU3RyaW5nLiAgT3RoZXJ3aXNlLCAuLi4NCj4g DQo+IC4uLg0KPiANCj4gICAgNC4gSWYgUyBpcyB0aGUgemVyby1sZW5ndGggc3RyaW5nLCB0aGVu IFAgaXMgc2V0IHRvIHRoZSB6ZXJvLWxlbmd0aA0KPiBzdHJpbmcuDQo+ICAgICAgIE90aGVyd2lz ZSwgLi4uDQo+IA0KPiANCj4gQXQgU3RlcCAyIG9mIFNlY3Rpb24gMi4xICJFbmNyeXB0aW9uIiwg d2Ugd291bGQgbmVlZCB0byBzYXkgIklmIFANCj4gY29udGFpbnMNCj4gZXhhY3RseSB6ZXJvIG9j dGV0cywgdGhlbiBTIGlzIHRoZSB6ZXJvLWxlbmd0aCBzdHJpbmc7IHNraXAgdG8gc3RlcCA1LiIN Cj4gDQo+IA0KPiBJdCBsb29rcyBpbm5vY3VvdXMsIGJ1dCBkZXNlcnZlcyBtb3JlIGFuYWx5c2lz IEkgdGhpbmsuICBNeSBpbmNsaW5hdGlvbg0KPiBpcyB0aGF0IHdlIHNob3VsZCBvbmx5IGFkZCB0 aGlzIGlmIHRoZXJlIGFyZSBwbGFucyB0byB1c2UgdGhlIGFsZ29yaXRobSBhcw0KPiBhIE1BQy4g IEFyZSB0aGVyZSBzY2VuYXJpb3MgaW4gd2hpY2ggQUVBRF9DQkNfSE1BQyB3b3VsZCBiZSBhdmFp bGFibGUsDQo+IGJ1dCB0aGUgdW5kZXJseWluZyBITUFDIHdvdWxkIG5vdD8gSSBjYW4gc2VlIHZh bHVlIGluIG1pbmltaXppbmcgdGhlIG51bWJlcg0KPiBvZiBlbnRyeSBwb2ludHMgdG8gYSBjcnlw dG8gaW1wbGVtZW50YXRpb24sIGJ1dCBvbiB0aGUgb3RoZXIgaGFuZCwgSE1BQyBpcw0KPiBhbHJl YWR5IGJyb2FkbHkgYXZhaWxhYmxlLg0KPiANCj4gRGF2aWQNCg0KSSBzdXNwZWN0IEhNQUMgd291 bGQgYWx3YXlzIGJlIGF2YWlsYWJsZSB3aGVuIEFFQURfQ0JDX0hNQUMgaXMuIExhY2sgb2YgZGly ZWN0IGFjY2VzcyB0byBITUFDIGNhbm5vdCBtb3RpdmF0ZSB0aGlzIGNoYW5nZS4NCg0KSSBoYWQg YmVlbiB0aGlua2luZyBhYm91dCB0aGUgc3RydWN0dXJlcyBpbiBKT1NFIChjcnlwdG8gaW4gYSB3 ZWItZnJpZW5kbHkgZm9ybWF0LCB1c2luZyBKU09OLCBub3QgQVNOLjEpLiBKT1NFIHN1cHBvcnRz IEFFQUQgb3BlcmF0aW9ucyB3aXRoIGEgcGVyLW1lc3NhZ2Uga2V5IGZyb20gYSBrZXkgYWdyZWVt ZW50L2V4Y2hhbmdlL3dyYXAgb3BlcmF0aW9uLiBKT1NFIGFsc28gc3VwcG9ydHMgTUFDcyB3aXRo IGEgcHJlLWVzdGFibGlzaGVkIHNlY3JldCBrZXksIGJ1dCBub3Qgd2l0aCBhIHBlci1tZXNzYWdl IGtleS4gSk9TRSBwYWNrYWdlcyBNQUMgZnVuY3Rpb25hbGl0eSB0b2dldGhlciB3aXRoIGFzeW1t ZXRyaWMgZGlnaXRhbCBzaWduYXR1cmVzLiBBbiBhbHRlcm5hdGl2ZSBhcHByb2FjaCB3b3VsZCBi ZSB0byBwYWNrYWdlIE1BQyBmdW5jdGlvbmFsaXR5IGFzIGEgc3Vic2V0IG9mIEFFQUQgZnVuY3Rp b25hbGl0eSwgaW4gd2hpY2ggY2FzZSBBRUFEX0NCQ19ITUFDIHdvcmtpbmcgZWZmaWNpZW50bHkg YXMgYSBNQUMgd291bGQgYmUgdXNlZnVsLiANCg0KW1AuUy4gQW5vdGhlciBwb3NzaWJpbGl0eSB3 b3VsZCBiZSB0byBkZWZpbmUgSE1BQyBhcyBhIHBzZXVkby1BRUFEIGFsZ29yaXRobSB0aGF0IG9u bHkgd29ya2VkIHdoZW4gdGhlcmUgd2FzIG5vIHBsYWludGV4dCwgb25seSBBQUQgKGllIFBfTUFY ID0gMCkuIFJGQzQ1NDMgIkdNQUMgaW4gSVBzZWMgRVNQIGFuZCBBSCIgZG9lcyBhIHZhZ3VlbHkg c2ltaWxhciB0cmljayB3aGVuIGRlZmluaW5nIEVOQ1JfTlVMTF9BVVRIX0FFU19HTUFDLl0NCg0K RGF2aWTigJlzIGNoYW5nZXMgZG8gbG9vayBzbWFsbCBhbmQgaW5ub2N1b3VzIHNvIEkgYW0gdmVy eSB0ZW1wdGVkIHRvIHNheSAieWVzIHBsZWFzZSwgbGV04oCZcyBtYWtlIHRob3NlIGNoYW5nZXMi LiBJIHN1c3BlY3QgdGhlIHJpZ2h0IHNvbHV0aW9uIGZvciBKT1NFLCB0aG91Z2gsIGlzIHRvIGhh dmUgQUVBRCBhbmQgTUFDIG9wZXJhdGlvbnMgYXMgc2VwYXJhdGUgZXhwbGljaXRseS1zdXBwb3J0 ZWQgImZpcnN0LWNsYXNzIGNpdGl6ZW5zIjogc2VwYXJhdGUgZnJvbSBhc3ltbWV0cmljIHNpZ25h dHVyZXM7IGFuZCBzZXBhcmF0ZSBmcm9tIGEga2V5IGFncmVlbWVudC9leGNoYW5nZS93cmFwIHN0 ZXAuIE15IGluY2xpbmF0aW9uIG5vdyBpcyBub3QgdG8gdGhlIGNoYW5nZSBkcmFmdC1tY2dyZXct YWVhZC1hZXMtY2JjLWhtYWMtc2hhMi4gVGhhbmt5b3UgZm9yIHRoZSBjb25zaWRlcmluZyB0aGUg aWRlYS4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From jon@callas.org Wed Mar 20 16:54:18 2013 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 DCE7421F8CA3 for ; Wed, 20 Mar 2013 16:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2s5QoHNvjOr for ; Wed, 20 Mar 2013 16:54:13 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3901621F8620 for ; Wed, 20 Mar 2013 16:54:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 8211024EDA69 for ; Wed, 20 Mar 2013 16:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCFxZRuD-SPG for ; Wed, 20 Mar 2013 16:54:12 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 8D61224EDA4B for ; Wed, 20 Mar 2013 16:54:05 -0700 (PDT) Received: from mab.hardwired ([66.241.70.254]) by keys.merrymeet.com (PGP Universal service); Wed, 20 Mar 2013 16:54:05 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 20 Mar 2013 16:54:05 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jon Callas In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183EC751@xmb-rcd-x04.cisco.com> Date: Wed, 20 Mar 2013 16:53:55 -0700 Message-Id: References: <747787E65E3FBD4E93F0EB2F14DB556B183EC751@xmb-rcd-x04.cisco.com> To: David McGrew (mcgrew) X-Mailer: Apple Mail (2.1503) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Simon Josefsson , Jon Callas , "cfrg@irtf.org" , "joachim@secworks.se" , Adam Langley , "tls@ietf.org" , Wan-Teh Chang Subject: Re: [Cfrg] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 23:54:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 20, 2013, at 2:55 AM, David McGrew (mcgrew) wrote: > TLSv1.2 barely mentions either GCM or ECC, much less requires their use. > RFC 5246 says: in the absence of an application profile standard > specifying otherwise, a TLSv1.2-compliant application MUST implement the > cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. No ECC or GCM ciphersuites are > mentioned in that RFC. On the flip side, there are benefits in using that > version; v1.2 allows to use SHA256 in key derivation (PRF) and message > authentication (HMAC), allows the use of AEAD, and adds other fixes. >=20 > GCM does require a distinct nonce for each encryption operation, which > makes it vulnerable to "nonce misuse", or makes it tetchy as you say. > However, this property is a non-issue in TLS, since it is easy to use a > sequence number as a nonce, and session keys don't persist between > sessions. For comparison, Salsa20 and UMAC, both recently mentioned on > this thread, would also have exactly the same distinct-nonce requirement, > and essentially RC4 does as well (in the sense that an application that > mis-manages the RC4 state would likely cause a loss of confidentiality). I apologize for note being organized in my typing. Let me try again. Rightly or wrongly, there's a perception both on the implementation end and= the deployment end that TLS 1.2 is the "Suite B" version of TLS, that it's= mandatory to implement and mandatory to deploy. That this is a mispercepti= on is in fact what part of the problem is. I've held many of these misperce= ptions myself, and if someone as expert as I doesn't grok TLS 1.2, then how= is the average developer or sysadmin going to understand? TLS 1.2 needs some marketing that explains why people want it, and that nee= ds to include reassurance that it doesn't require you to commit to ECC and = GCM. Many people out there believe precisely this. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFRSkwdsTedWZOD3gYRAkWSAKCxRRMWVhNq2NF1ihkX17sFU4hqGACgjo/9 RJSto/qI8hZe5T6wz9YBrNQ=3D =3D6tCp -----END PGP SIGNATURE----- From pgut001@cs.auckland.ac.nz Wed Mar 20 21:49:57 2013 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 67F4D21F8D67 for ; Wed, 20 Mar 2013 21:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PC-OqF0J2Qm for ; Wed, 20 Mar 2013 21:49:55 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 8772821F8D62 for ; Wed, 20 Mar 2013 21:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363841395; x=1395377395; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=wkZh4t/qPcRXenaABR0IebEVphdl/qvVVl9qXjs66z8=; b=byVF16zZxbanlPIA7GA1mM/52grUOQRlpdqajwmvQqLCYCo8ZxTZqrOW BlO6BqS7+iqmWmQGdZBNfGAj+7XTTF9xVfl1UCEoJis+qoZXimTyzOS3s 3RIgCi1wjqA/k8M22ZWt5qVmIoI5BfZKw7dcfACkF0diA4vLKaOYU6H2y w=; X-IronPort-AV: E=Sophos;i="4.84,883,1355050800"; d="scan'208";a="176957505" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Mar 2013 17:49:54 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe1.UoA.auckland.ac.nz (130.216.4.112) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Mar 2013 17:49:53 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.115]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 17:49:53 +1300 From: Peter Gutmann To: "cfrg@irtf.org" , "tls@ietf.org" Thread-Topic: [TLS] [Cfrg] Salsa20 stream cipher in TLS Thread-Index: Ac4l74bCx0Msako7Rh2/1VlfqG02AA== Date: Thu, 21 Mar 2013 04:49:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D245C7@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Cfrg] [TLS] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 04:49:57 -0000 Adam Langley writes:=0A= >On Wed, Mar 20, 2013 at 7:53 PM, Jon Callas wrote:=0A= > TLS 1.2 needs some marketing that explains why people want it, and that= =0A= > needs to include reassurance that it doesn't require you to commit to ECC= =0A= > and GCM. Many people out there believe precisely this.=0A= >=0A= >I believe that the reason that TLS 1.2 hasn't seen wider deployment is tha= t=0A= >it causes compatibility issues and the motivation hasn't previously been= =0A= >strong enough.=0A= =0A= Exactly. Getting back to Jon's point that "it needs some marketing that=0A= explains why people want it", I can't think of any reason why you'd want it= .=0A= It causes compatibility problems, but I can't think of any pressing issue t= hat=0A= it solves apart from "we need to do Suite B". This is why it's seen as "TL= S=0A= with Suite B", because that's it's sole marketing point.=0A= =0A= Look at OCSP pinning as a counterexample. Virtually every major site deplo= yed=0A= this as quickly as they could, because the site owners recognised that if t= hey=0A= didn't do it, they'd take a significant performace hit or even complete OCS= P-=0A= induced site outages (on hard fail).=0A= =0A= If you don't deploy TLS 1.2 OTOH, nothing happens. You're no slower, no le= ss=0A= available, no less secure... the only thing you don't have is Suite B. I= =0A= implemented it some time ago and so far the sole users have been (a) a smal= l=0A= number of users who wanted Suite B and (b) an even smaller number of users,= =0A= mostly in Europe, who insisted on having the largest version number of TLS= =0A= they could get. Most of the latter went back to 1.1 when they started runn= ing=0A= into problems with interoperability.=0A= =0A= Peter.= From pgut001@cs.auckland.ac.nz Wed Mar 20 22:36:32 2013 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 D793721F8FA3 for ; Wed, 20 Mar 2013 22:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48u9ZzPh4E8L for ; Wed, 20 Mar 2013 22:36:31 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 2589921F8FED for ; Wed, 20 Mar 2013 22:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1363844191; x=1395380191; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yL3K2zCGuCVNgX4B36InR2hI3vfUey74JCNmHghsabk=; b=opH7Ggu40EYJ9iXNC5T8NZ7ujkV6KobpleX52ljBLnINMXa/dJJSjqeY /ALgxIVC45FQMIVoc0bQQ1F23tqeyFc+dXod7gfIYkRr26LykEJhg/1Hg Q2uwFpk+JagDxcM+WrSiS8ifkZbq8IEY6MwOXI7bnwYOufvfKt37fIdfy g=; X-IronPort-AV: E=Sophos;i="4.84,883,1355050800"; d="scan'208";a="176963893" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Mar 2013 18:36:25 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.115]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 18:36:25 +1300 From: Peter Gutmann To: "cfrg@irtf.org" , "tls@ietf.org" Thread-Topic: [Cfrg] Salsa20 stream cipher in TLS Thread-Index: Ac4l9gauvD7G5gucTheQ1FuELorOyg== Date: Thu, 21 Mar 2013 05:36:24 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D25628@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Cfrg] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 05:36:33 -0000 Geoffrey Keating =0A= =0A= >It also lets you do GCM, which has performance benefits over AES+SHA1.=0A= =0A= It does? GMAC is kind of a pig unless you've got hardware assist... and=0A= speaking of hardware, if you're using an ASIC for it you don't have much=0A= choice, it's mostly HMAC-SHA1 only. Even with that aside, anyone who's rea= lly=0A= worried about performance seems to be using RC4.=0A= =0A= >So are we now in a catch-22 where no-one will upgrade because they don't n= eed=0A= >to because all the fixes are shoehorned into the current version because n= o-=0A= >one will upgrade?=0A= =0A= I'm not sure I'd characterise it as "shoehorned", a better view would be th= at=0A= the existing versions fix pretty much everything that needs fixing except t= he=0A= MAC-then-encrypt problem, and given that 1.2 is such a huge change that it'= s=0A= almost a new protocol in parts (the change from 1.1 to 1.2 is much bigger t= han=0A= the change from SSL to TLS), it's not surprising that there's no great rush= to=0A= move to it.=0A= =0A= It's also a killer roadblock to any new changes in 1.3. Since even the mos= t=0A= trivial change (to get to 1.3) will involve implementing and deploying all = of=0A= 1.2, people will keep adding stuff to 1.1 rather than have to go through th= e=0A= pain of 1.2 in order to add new features. So in that sense you're right,= =0A= we're going to keep seeing changes to 1.1 rather than having them added in= =0A= 1.3. 1.2 is too big a hurdle for too small a gain.=0A= =0A= Kinda scary when you look at it like that...=0A= =0A= Peter.= From simon@josefsson.org Thu Mar 21 03:27:17 2013 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 D7BF321F8DE5; Thu, 21 Mar 2013 03:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHS2cYP-hdFw; Thu, 21 Mar 2013 03:27:17 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6892221F883E; Thu, 21 Mar 2013 03:27:15 -0700 (PDT) Received: from latte.josefsson.org (host-95-192-103-177.mobileonline.telia.com [95.192.103.177]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r2LAQalv018265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 11:26:42 +0100 From: Simon Josefsson To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C7343D25628@uxcn10-2.UoA.auckland.ac.nz> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130321:cfrg@irtf.org::AXEYTUj7t32Jh4bg:HU7E X-Hashcash: 1:22:130321:tls@ietf.org::zxMPnT91mWG2m9Xz:PrUv X-Hashcash: 1:22:130321:pgut001@cs.auckland.ac.nz::dvlkWYeuAD6jsyyj:K/Jt Date: Thu, 21 Mar 2013 11:26:31 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D25628@uxcn10-2.UoA.auckland.ac.nz> (Peter Gutmann's message of "Thu, 21 Mar 2013 05:36:24 +0000") Message-ID: <87ppytqca0.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [Cfrg] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 10:27:18 -0000 Peter Gutmann writes: > It's also a killer roadblock to any new changes in 1.3. Since even the most > trivial change (to get to 1.3) will involve implementing and deploying all of > 1.2, people will keep adding stuff to 1.1 rather than have to go through the > pain of 1.2 in order to add new features. So in that sense you're right, > we're going to keep seeing changes to 1.1 rather than having them added in > 1.3. 1.2 is too big a hurdle for too small a gain. Are people adding stuff to 1.1? My impression is that all serious problems (including renegotiation and the explicit IV problem) are solved in TLS 1.0 too. The problems are solved through specification (think renegotiation) or through implementation fixes (think empty fragments to mimic explicit IVs). For TLS 1.0 and SSL 3.0 to go away, there needs to be a serious enough security problem that is not fixable in TLS 1.0 implementations. I'm not convinced that will happen. We have seen that people will try hard to resolve protocol security problems within TLS 1.0. Thinking about this, perhaps we need a document explaining how to implement TLS 1.0 securely. TLS 1.0 as implemented by RFC 2246 is not secure. The document could say that you need to send bad_record_mac in case of MAC verification failures, and to send empty fragments to combat CBC attacks, and implement renegotiation, and discuss how to combat CBC timing attacks, and something about RC4. And other things I may have forgotten. Right now it seems the knowledge about fixing TLS 1.0 are found in TLS implementations and not discussed in IETF documents. /Simon From ynir@checkpoint.com Thu Mar 21 05:10:09 2013 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 C3FAE21F8E1D; Thu, 21 Mar 2013 05:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.418 X-Spam-Level: X-Spam-Status: No, score=-10.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZVdPnKby3TL; Thu, 21 Mar 2013 05:10:09 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 83BBE21F86CB; Thu, 21 Mar 2013 05:09:54 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2LC9PbZ023958; Thu, 21 Mar 2013 14:09:29 +0200 X-CheckPoint: {514AF733-1-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 14:09:25 +0200 From: Yoav Nir To: Peter Gutmann Thread-Topic: [TLS] [Cfrg] Salsa20 stream cipher in TLS Thread-Index: Ac4l74bCPkc5tmAbHkmmrTIC4WvxcwALKVEA Date: Thu, 21 Mar 2013 12:09:25 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C7343D245C7@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D245C7@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.171] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <5B1650FD24FEE74E8D627E91ABDB4656@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [Cfrg] [TLS] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 12:10:10 -0000 On Mar 21, 2013, at 12:49 AM, Peter Gutmann wro= te: > If you don't deploy TLS 1.2 OTOH, nothing happens. You're no slower, no = less > available, no less secure... the only thing you don't have is Suite B. I > implemented it some time ago and so far the sole users have been (a) a sm= all > number of users who wanted Suite B and (b) an even smaller number of user= s, > mostly in Europe, who insisted on having the largest version number of TL= S > they could get. Most of the latter went back to 1.1 when they started ru= nning > into problems with interoperability. Actually, we turned on TLS 1.2 by default for the speed advantage. iOS begi= ns a TLS handshake with version 1.2, both in ClientHello and in the record = layer. Only when the (shocked and flabbergasted) server closes the connecti= on, does the iPhone try with something more sane like 1.0, and then even ca= ches this for a short while. This takes two extra round-trips. The bug report said "iPhone x is slow to connect" (I don't remember if at t= he time x was 5 or 6. Yoav From ynir@checkpoint.com Thu Mar 21 13:26:43 2013 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 6E70021F8C04; Thu, 21 Mar 2013 13:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.428 X-Spam-Level: X-Spam-Status: No, score=-10.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ik3BoivcIYZ; Thu, 21 Mar 2013 13:26:43 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 81E5D21F8C00; Thu, 21 Mar 2013 13:26:39 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2LKQMrY013187; Thu, 21 Mar 2013 22:26:22 +0200 X-CheckPoint: {514B6BA7-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 22:26:22 +0200 From: Yoav Nir To: Adam Langley Thread-Topic: [TLS] [Cfrg] Salsa20 stream cipher in TLS Thread-Index: Ac4l74bCPkc5tmAbHkmmrTIC4WvxcwALKVEAAABN74AAEQ1ygA== Date: Thu, 21 Mar 2013 20:26:21 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C7343D245C7@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.41] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <3828286181568D44A23D649A5DADC6EB@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "tls@ietf.org" , Peter Gutmann Subject: Re: [Cfrg] [TLS] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 20:26:43 -0000 On Mar 21, 2013, at 8:18 AM, Adam Langley wrote: > On Thu, Mar 21, 2013 at 8:09 AM, Yoav Nir wrote: >> Actually, we turned on TLS 1.2 by default for the speed advantage. iOS b= egins a TLS handshake with version 1.2, both in ClientHello and in the reco= rd layer. Only when the (shocked and flabbergasted) server closes the conne= ction, does the iPhone try with something more sane like 1.0, and then even= caches this for a short while. >=20 > But you don't need to switch on TLS 1.2 to fix this, right? The server > just needs to implement version negotiation correctly. We consider the record layer version to be the minimum version supported by= the client, and the version in the ClientHello to be the maximum version s= upported by the client. Since both were 1.2, our code concludes that TLS 1.= 2 is the only supported version. We tried replying in TLS 1.0, and we got a= TCP reset or an alert (I forget which). So without TLS 1.2 support, the fi= rst connection would always fail. In practice this wouldn't be a problem, b= ecause the phone would get the penalty once, and then cache the information= that our server doesn't support 1.2. Still, we preferred to add support fo= r TLS 1.2 (which I wanted to do anyway) > (On the flip side, this /is/ a problem for clients since the > incentives are aligned for clients to stop trying TLS 1.2 since they > can't (directly) fix the server.) >=20 >=20 > Cheers >=20 > AGL >=20 > Email secured by Check Point From ynir@checkpoint.com Thu Mar 21 23:06:50 2013 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 C7BDE21F8AB2; Thu, 21 Mar 2013 23:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.438 X-Spam-Level: X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTey7ZyY3NTY; Thu, 21 Mar 2013 23:06:50 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8201221F8AA8; Thu, 21 Mar 2013 23:06:49 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2M66j7a021418; Fri, 22 Mar 2013 08:06:45 +0200 X-CheckPoint: {514BF3A9-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Fri, 22 Mar 2013 08:06:45 +0200 From: Yoav Nir To: "" Thread-Topic: [TLS] [Cfrg] Salsa20 stream cipher in TLS Thread-Index: Ac4l74bCPkc5tmAbHkmmrTIC4WvxcwALKVEAAABN74AAI8xdAAABhmkA Date: Fri, 22 Mar 2013 06:06:44 +0000 Message-ID: References: <20130322052312.1ADD51A65B@ld9781.wdf.sap.corp> In-Reply-To: <20130322052312.1ADD51A65B@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.114] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <08E8563364190C43B399CE274F5E21E5@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "tls@ietf.org" , Adam Langley Subject: Re: [Cfrg] [TLS] Salsa20 stream cipher in TLS X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 06:06:50 -0000 On Mar 22, 2013, at 1:23 AM, Martin Rex wrote: > Adam Langley wrote: >> On Thu, Mar 21, 2013 at 8:09 AM, Yoav Nir wrote: >>>=20 >>> Actually, we turned on TLS 1.2 by default for the speed advantage. >>> iOS begins a TLS handshake with version 1.2, both in ClientHello >>> and in the record layer. Only when the (shocked and flabbergasted) >>> server closes the connection, does the iPhone try with something >>> more sane like 1.0, and then even caches this for a short while. >=20 > Are you sure? >=20 > It would clearly be stupid behaviour on part of iPhone to send an > initial ClientHello with { 0x03, 0x03 } at the record layer. It would be, and it was. This was long ago, so it may have been fixed in iO= S 6. >=20 > It should be sending this version in ClientHello.client_version alone. >=20 >>=20 >> But you don't need to switch on TLS 1.2 to fix this, right? The server >> just needs to implement version negotiation correctly. >=20 > The servers typically implement it correctly. If iPhone is willing > to talk a protocol version < TLSv1.2, then using TLSv1.2 on the > Record Layer on the first ClientHello is a stupid bug.=20 >=20 > Only(!!) TLSv1.2 servers will ignore the record layer PDU version > on the initial ClientHello (but for them this is currently entirely > irrelevant, since there is no TLSv1.3 and no borked TLSv1.3 clients > that tag PDUs incorrectly). >=20 >=20 > -Martin >=20 > Email secured by Check Point From lhitt@21ct.com Fri Mar 22 10:27:13 2013 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 A8BE121F84D4 for ; Fri, 22 Mar 2013 10:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsCa7oc5cNGi for ; Fri, 22 Mar 2013 10:27:12 -0700 (PDT) Received: from 21ct-exg07.21technologies.com (21ct-exg07.21technologies.com [173.226.154.197]) by ietfa.amsl.com (Postfix) with ESMTP id A36AB21F8496 for ; Fri, 22 Mar 2013 10:27:12 -0700 (PDT) Received: from 21ct-exg07.21technologies.com ([10.0.10.16]) by 21ct-exg07.21technologies.com ([10.0.10.16]) with mapi; Fri, 22 Mar 2013 12:26:59 -0500 From: Laura Hitt To: "cfrg@irtf.org" Date: Fri, 22 Mar 2013 12:27:00 -0500 Thread-Topic: request for comments: ZSS Short Signature Scheme for SS and BN Curves Thread-Index: Ac4lkatAl+acAzUUTfqTMjf28qdPGABju82w Message-ID: <04920BD67C651C469D0387704CD7692A74B0844B94@21ct-exg07.21technologies.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_04920BD67C651C469D0387704CD7692A74B0844B9421ctexg0721te_" MIME-Version: 1.0 Subject: [Cfrg] request for comments: ZSS Short Signature Scheme for SS and BN Curves X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:27:13 -0000 --_000_04920BD67C651C469D0387704CD7692A74B0844B9421ctexg0721te_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have recently submitted (as an Individual) two I-Ds and would greatly app= reciate any comments you are able to offer. They pertain to the ZSS short = signature scheme from bilinear pairings on supersingular elliptic curves an= d on Barreto-Naerhig elliptic curves. http://www.ietf.org/internet-drafts/draft-irtf-cfrg-zss-00.txt http://www.ietf.org/internet-drafts/draft-irtf-cfrg-zssbn-00.txt Thank you! Laura Hitt --_000_04920BD67C651C469D0387704CD7692A74B0844B9421ctexg0721te_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<my apo= logies if this was sent twice, I saw strange behavior on my end, so thought= I’d try again.>

 

I ha= ve recently submitted (as an Individual) two I-Ds and would greatly appreci= ate any comments you are able to offer.  They pertain to the ZSS short= signature scheme from bilinear pairings on supersingular elliptic curves a= nd on Barreto-Naerhig elliptic curves.

<= o:p> 

http://www.ietf.org/internet-draft= s/draft-irtf-cfrg-zss-00.txt

http:= //www.ietf.org/internet-drafts/draft-irtf-cfrg-zssbn-00.txt<= /p>

 

Thank you= !
Laura Hitt

 

 

 

= --_000_04920BD67C651C469D0387704CD7692A74B0844B9421ctexg0721te_-- From mcgrew@cisco.com Thu Mar 28 04:14:55 2013 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 DACED21F861F for ; Thu, 28 Mar 2013 04:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPCV641JqCCr for ; Thu, 28 Mar 2013 04:14:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id CA0E921F84F5 for ; Thu, 28 Mar 2013 04:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8056; q=dns/txt; s=iport; t=1364469295; x=1365678895; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ByqF1rQmP0NY9rDkf5x4SvKuyhy0u5glFhNc9s7dTfE=; b=hmipPx7BYoh0xojNiJZAFuRODlXe5GXjLzyqrd3xrKMsl9UbkCGGmMef LSaA9ZdTPFE02lnBvc7yMdk+FJfD4lqpG7v0E0LUXXd+tuYQQLvFcfyfG jRmGt16juIpMniGI9aYC8cba2FDAh0/tO/TKfCbLZMB5EJkmsMu1sDNJK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAFAI8kVFGtJV2b/2dsb2JhbABDgkN3tjoBiCqBAxZ0gh8BAQEELUwSAQgRAwECCx05FAkIAQEEDgUIiAwMvmGJBYViIAYLB4JfYQOYBo9ogwuCKA X-IronPort-AV: E=Sophos;i="4.84,925,1355097600"; d="scan'208,217";a="192450707" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 28 Mar 2013 11:14:52 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2SBEpwY028783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Mar 2013 11:14:51 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 28 Mar 2013 06:14:51 -0500 From: "David McGrew (mcgrew)" To: Jim Schaad Thread-Topic: GCM nonce reuse question Thread-Index: Ac4rPAw7MkpmLDvlR4e6aC3llihwKgAccr0A Date: Thu, 28 Mar 2013 11:14:50 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> In-Reply-To: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B183EF2E3xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] GCM nonce reuse question X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 11:14:56 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B183EF2E3xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, From: Jim Schaad = > Date: Wednesday, March 27, 2013 6:43 PM To: David McGrew > Cc: "cfrg@irtf.org" > Subject: GCM nonce reuse question David, In doing a write up I became worried about a security property of the GCM e= ncryption mode in the way that the JOSE group is currently using it. There are known problems with not having a unique set of values for IVs and= Key pairings. Do these problems apply to having a different set of auxili= ary data as well as the plain text? Yes. The security issues are summarized in http://tools.ietf.org/html/rfc5= 116#section-5.1.1 but apparently they are not described generally enough. = They should read "plaintext or associated data values". Specifically the current way that GCM mode is being used in JOSE is Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, nonce, plai= n text) Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, nonce, plai= n text) As the key, nonce and plain text are fixed it would produce the same encryp= ted text value but different authentication tags. Can't do that. Each invocation of the encryption operation needs a distin= ct nonce, unless all of the encryption operation inputs are identical. Many thanks for calling this out, Jim. David Jim --_000_747787E65E3FBD4E93F0EB2F14DB556B183EF2E3xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <1EB03C6ED5EEF14493B5F1C1A8C38806@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Jim,

From: Jim Schaad <jimsch@augustcellars.com>
Date: Wednesday, March 27, 2013 6:4= 3 PM
To: David McGrew <mcgrew@cisco.com>
Cc: "cfrg@irtf.org" <cfrg@i= rtf.org>
Subject: GCM nonce reuse question

David,

 

In doing a write up I became worried about a securit= y property of the GCM encryption mode in the way that the JOSE group is cur= rently using it.

 

There are known problems with not having a unique se= t of values for IVs and Key pairings.  Do these problems apply to havi= ng a different set of auxiliary data as well as the plain text?<= /p>

 

Yes.  The security issues are summarized in http://tools.ietf.org/html/rfc= 5116#section-5.1.1  but apparently they are not described generall= y enough.   They should read "plaintext or associated data values".

Specifically the current way that GCM mode is being = used in JOSE is

 

Recipient #1 authentication tag =3D GCM(Key, Recipie= nt #1 data, nonce, plain text)

Recipient #2 authentication tag =3D GCM(Key, Recipie= nt #2 data, nonce, plain text)

 

As the key, nonce and plain text are fixed it would = produce the same encrypted text value but different authentication tags.

 

Can't do that.   Each invocation of the encryption operation need= s a distinct nonce, unless all of the encryption operation inputs are ident= ical.

Many thanks for calling this out, Jim.

David

Jim

 

 --_000_747787E65E3FBD4E93F0EB2F14DB556B183EF2E3xmbrcdx04ciscoc_-- From Michael.Jones@microsoft.com Thu Mar 28 19:06:53 2013 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 2AF9421F890D for ; Thu, 28 Mar 2013 19:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRkLeRWdS0Pn for ; Thu, 28 Mar 2013 19:06:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 889DF21F89C3 for ; Thu, 28 Mar 2013 19:06:51 -0700 (PDT) Received: from BL2FFO11FD021.protection.gbl (10.1.15.200) by BY2FFO11HUB024.protection.gbl (10.1.14.138) with Microsoft SMTP Server (TLS) id 15.0.651.3; Fri, 29 Mar 2013 02:06:48 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD021.mail.protection.outlook.com (10.173.161.100) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Fri, 29 Mar 2013 02:06:49 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Fri, 29 Mar 2013 02:06:45 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] FW: GCM nonce reuse question Thread-Index: Ac4rPAw7MkpmLDvlR4e6aC3llihwKgAccr0AABzjcgAAACgWkA== Date: Fri, 29 Mar 2013 02:06:44 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436759736A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> <006701ce2c21$65accf10$31066d30$@augustcellars.com> In-Reply-To: <006701ce2c21$65accf10$31066d30$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436759736ATK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(66654001)(199002)(52604002)(377454001)(79102001)(512954001)(15202345001)(55846006)(49866001)(51856001)(74662001)(50986001)(4396001)(54316002)(76482001)(16406001)(47976001)(56816002)(16236675001)(81342001)(66066001)(65816001)(77982001)(56776001)(71186001)(59766001)(33656001)(54356001)(53806001)(80022001)(5343655001)(46102001)(5343635001)(63696002)(47446002)(69226001)(74502001)(20776003)(44976002)(47736001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB024; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0800C0C167 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] [jose] FW: GCM nonce reuse question X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 02:06:53 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436759736ATK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll plan to add text to the GCM section of JWA during the current round of= edits pointing this out. David McGrew was also going to get me some text = about constraints on GCM initialization vector values. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Thursday, March 28, 2013 7:02 PM To: jose@ietf.org Subject: [jose] FW: GCM nonce reuse question For those people not on the CFRG list - Jim From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com] Sent: Thursday, March 28, 2013 4:15 AM To: Jim Schaad Cc: cfrg@irtf.org Subject: Re: GCM nonce reuse question Hi Jim, From: Jim Schaad = > Date: Wednesday, March 27, 2013 6:43 PM To: David McGrew > Cc: "cfrg@irtf.org" > Subject: GCM nonce reuse question David, In doing a write up I became worried about a security property of the GCM e= ncryption mode in the way that the JOSE group is currently using it. There are known problems with not having a unique set of values for IVs and= Key pairings. Do these problems apply to having a different set of auxili= ary data as well as the plain text? Yes. The security issues are summarized in http://tools.ietf.org/html/rfc5= 116#section-5.1.1 but apparently they are not described generally enough. = They should read "plaintext or associated data values". Specifically the current way that GCM mode is being used in JOSE is Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, nonce, plai= n text) Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, nonce, plai= n text) As the key, nonce and plain text are fixed it would produce the same encryp= ted text value but different authentication tags. Can't do that. Each invocation of the encryption operation needs a distin= ct nonce, unless all of the encryption operation inputs are identical. Many thanks for calling this out, Jim. David Jim --_000_4E1F6AAD24975D4BA5B16804296739436759736ATK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll plan to add= text to the GCM section of JWA during the current round of edits pointing = this out.  David McGrew was also going to get me some text about const= raints on GCM initialization vector values.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      -- Mike

 

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, March 28, 2013 7:02 PM
To: jose@ietf.org
Subject: [jose] FW: GCM nonce reuse question

 

For those people not o= n the CFRG list –

 

Jim<= /p>

 

 

From: David Mc= Grew (mcgrew) [mailto:mcgrew@cisco.com<= /a>]
Sent: Thursday, March 28, 2013 4:15 AM
To: Jim Schaad
Cc: cfrg@irtf.org
Subject: Re: GCM nonce reuse question

 

Hi Jim,=

&n= bsp;

From: Jim Schaad <jimsch@augustcellars.com>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <mcgrew@cisc= o.com>
Cc: "cfrg@irtf.org" &= lt;cfrg@irtf.org>
Subject: GCM nonce reuse question

&n= bsp;

David,=

 =

In doing a write up I be= came worried about a security property of the GCM encryption mode in the wa= y that the JOSE group is currently using it.

 =

There are known problems= with not having a unique set of values for IVs and Key pairings.  Do = these problems apply to having a different set of auxiliary data as well as= the plain text?

 =

&n= bsp;

Yes. &n= bsp;The security issues are summarized in http://tools.ietf.org/html/rfc5116#section= -5.1.1  but apparently they are not described generally enough.   They should read "plaintext or associated da= ta values".

&n= bsp;

Specifically the current= way that GCM mode is being used in JOSE is

 =

Recipient #1 authenticat= ion tag =3D GCM(Key, Recipient #1 data, nonce, plain text)

Recipient #2 authenticat= ion tag =3D GCM(Key, Recipient #2 data, nonce, plain text)

 =

As the key, nonce and pl= ain text are fixed it would produce the same encrypted text value but diffe= rent authentication tags.

 =

&n= bsp;

Can't d= o that.   Each invocation of the encryption operation needs a distinct= nonce, unless all of the encryption operation inputs are identical.

&n= bsp;

Many th= anks for calling this out, Jim.

&n= bsp;

David

&n= bsp;

Jim

 =

--_000_4E1F6AAD24975D4BA5B16804296739436759736ATK5EX14MBXC283r_-- From stephen.farrell@cs.tcd.ie Sat Mar 30 04:40:15 2013 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 C52D121F84BD for ; Sat, 30 Mar 2013 04:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da+0gQI3FjI9 for ; Sat, 30 Mar 2013 04:40:15 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 58D1E21F84BC for ; Sat, 30 Mar 2013 04:40:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4B319BE4C; Sat, 30 Mar 2013 11:39:46 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WT7pW39zl3hh; Sat, 30 Mar 2013 11:39:42 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.45.54.41]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 24263BE35; Sat, 30 Mar 2013 11:39:42 +0000 (GMT) Message-ID: <5156CEFC.3010007@cs.tcd.ie> Date: Sat, 30 Mar 2013 11:39:40 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "saag@ietf.org" , "cfrg@irtf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Mark Nottingham Subject: [Cfrg] Fwd: Fwd: Choosing a header compression algorithm X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 11:40:16 -0000 The httpbis wg are trying to figure out how to do compression in HTTP/2.0 in a way that's not so vulnerable to the CRIME attack. They'd like additional security eyeballs on what is quite a tricky problem. If you're willing and able to help then that'd be best done on the httpbis wg list. Any other questions feel free to ask me or Mark (httpbis wg chair, cc'd) offlist. S. -------- Original Message -------- Subject: Fwd: Choosing a header compression algorithm Date: Sat, 30 Mar 2013 16:50:32 +1100 From: Mark Nottingham To: Stephen Farrell , Sean Turner Any input from Security would be most welcome here… Cheers, Begin forwarded message: > Resent-From: ietf-http-wg@w3.org > From: James M Snell > Subject: Re: Choosing a header compression algorithm > Date: 30 March 2013 8:09:56 AM AEDT > To: Roberto Peon > Cc: RUELLAN Herve , "agl@google.com" , Mark Nottingham , "ietf-http-wg@w3.org Group" > Archived-At: > > +1 ... I have explored this a bit on this end also (and discussed it > with some security folks) and definitely align with Roberto's point of > view. At this point, any prefix matching proposal needs to be backed > with clear evidence as to it's safety. > > On Fri, Mar 29, 2013 at 11:39 AM, Roberto Peon wrote: >> Herve-- >> >> With the way you've implemented prefix matching, there are no guarantees on >> security whatsoever. >> In order to provide a guarantee of at least a minimum amount of effort on >> the part of the attacker, you MUST provide guarantees on the minimum >> subsequence sizes, as this relates directly to the amount of tries... >> As an example, >> foo.com/a/b/c >> will be exceptionally easy to figure out, as each subsequence will be >> guessed in a very small amount of time. >> >> There are many caveats and gotchas in this space, and I feel uncomfortable >> that you're making assertions about safety unless you've got some security >> folks looking at it critically. >> I've done that for the delta compressor, and I suggest you do the same. If >> it turns out that we do get consensus from security folks that some kind of >> prefix matching is safe, I'm happy to add it back into delta. Until then, I >> don't want to go down the rabbit hole! >> -=R >> >> >> On Fri, Mar 29, 2013 at 8:26 AM, RUELLAN Herve >> wrote: >>> >>> >>> >>>> -----Original Message----- >>>> From: Roberto Peon [mailto:grmocg@gmail.com] >>>> Sent: jeudi 28 mars 2013 20:17 >>>> To: RUELLAN Herve >>>> Cc: agl@google.com; Mark Nottingham; ietf-http-wg@w3.org Group >>>> Subject: Re: Choosing a header compression algorithm >>>> >>>> The net effect of the character-delimited prefix match you propose is >>>> that an >>>> attacker must only brute force each subsequence which matches [^/&=, >>>> ]*([^/&=, ]|$) , >>>> >>>> Running the numbers, that is: >>>> >>>> k^s * m >>>> >>>> where: >>>> >>>> k = possible characters >>>> s = subsequence length or characters not ending in [^/&= ,] or >>>> end- >>>> of-line >>>> m = number of subsequences >>>> >>>> >>>> >>>> instead of full atom matching, which is (is a good special case of above >>>> where >>>> m is always 1 and s is always n): >>>> >>>> k^n >>>> >>>> >>>> where: >>>> >>>> >>>> k = possible characters >>>> n = length of field >>>> >>>> >>>> >>>> In other words, full atom matching is *exponentially* more difficult (a >>>> desirable trait)! >>>> >>>> In the example above, assuming 27 commonly used characters per entry, >>>> I'm >>>> very likely to completely discover that data in: >>>> >>>> http://www.example.com/path/first/myfile >>>> >>>> in: >>>> >>>> 27^4 + 27^5 + 27^6 tries >>> >>> This is roughly 400 million tries. And this figure is obtained using >>> several assumptions that may not hold: >>> - The number of possible characters is only 27. >>> - The length of each chunk is known. >>> >>>> Note that it is likely that an attacker would be able to do >>>> substantially better >>>> than above if they know the letter frequency (very likely) or have >>>> similar >>>> data: >>>> In the case of a whole atom match, I'd discover the data in: >>>> >>>> >>>> 27^(17) tries >>>> >>>> >>>> So, full atom matching is ~ 5 quadrillion (5,353,441,417,462,320) times >>>> more >>>> difficult... that is a lot. >>> >>> True full atom matching is much harder, but limited prefix matching is >>> already very hard. >>> >>> We must also keep in mind that each try correspond to a request that the >>> attacker for the client to do. Such a huge number of requests should be >>> detected somewhere, just in order to prevent DoS attacks. >>> >>>> When I originally considered prefix matching in the past, this was the >>>> math >>>> that I did, and I decided that I was not confident that compressor >>>> implementors would ensure that their encoder prevents prefix matching >>>> when the subsequence lengths are too small (and thus easily attacked). >>>> The >>>> same consideration applies to dynamic huffman coding. It *CAN* be safe, >>>> but it requires complexity and computation, and I think there is >>>> significant >>>> risk that implementors may knowing or unknowingly sacrifice security. It >>>> is >>>> actually more safe to ignore delimiters and allow for a match of a >>>> prefix so >>>> long as it is greater than a certain length. At least in that case there >>>> is >>>> guarantee of the number of times that it must be brute forced... >>>> >>>> Full-atom matching is simply much more difficult to get wrong from a >>>> security >>>> perspective, and it results in pretty decent compression... >>> >>> I think that prefix matching with constrained ending is fairly secure: it >>> compels an attacker to used brute force to break it. In addition, it >>> provides very interesting results regarding compression. >> >> >>> >>> >>> Hervé. >>> >>>> -=R >>> >> > -- Mark Nottingham http://www.mnot.net/