From rbarnes@bbn.com Mon Jul 2 11:00:12 2012 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 2F7EA11E80FD for ; Mon, 2 Jul 2012 11:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 sYMBzp2ZJPIu for ; Mon, 2 Jul 2012 11:00:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA3711E80FA for ; Mon, 2 Jul 2012 11:00:07 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:62982) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Slkuy-0005ue-Ai for cfrg@irtf.org; Mon, 02 Jul 2012 14:00:12 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jul 2012 14:00:11 -0400 Message-Id: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> To: cfrg@irtf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Cfrg] Question from JOSE working group 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, 02 Jul 2012 18:00:12 -0000 Dear CFRG, This is a request for input on a crypto question that has come up in the = JOSE working group. The question is whether there is any benefit to applying integrity = protection to cryptographic parameters attached to a = signed/authenticated/encrypted object. By "cryptographic parameters" = here, I mean public keys, wrapped symmetric keys, algorithm identifiers, = etc. For historical background: CMS does not provide parameter protection [RFC5652]. The content that = is signed / authenticated / encrypted is precisely the protected content = (eContent). Optionally, an application may add signed attributes. In = the case of SignedData and AuthenticatedData, if signed attributes are = present, then they must include the message digest that was signed or = authenticated; not a parameter, but an intermediate result. IKE and TLS does not provide integrity protection for parameters = [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key = agreement in the initial phase of IKEv2 Algorithm negotiation in TLS = is done in the ClientHello / ServerHello messages, which are sent before = the secure channel is established. When TLS client certificates are = used, the client demonstrates its possession of the relevant private key = by signing the handshake messages, which provides an integrity check on = cryptographic parameters as a side-effect. However, the parameters for = this signature (the public key and signature/hash algorithms) are not = protected. PKIX is an intermediate case. The signature algorithm used to sign / = verify the certificate is included in the certificate body (under the = signature) as well as ouside the signature. Back to today: The current draft specifications for JOSE [JWS][JWE] require integrity = protection for parameters. The creator of an object constructs a = "header" value including the cryptographic parameters used to generate = the object. This header value is prepended to the protected content = before the content is signed / authenticated (JWS), or attached as = "Associated Data" to the encrypted content (JWE). (JWE only allows AEAD = algorithms.) So the questions for this group are the following:=20 -- Does applying integrity protection to cryptographic parameters result = in a meaningful increase the security of an secure object format? =20 -- What are the classes of attack that this integrity protection would = address? -- Does parameter protection create any additional security = vulnerabilities? Any input would be very helpful for the group to decide on a way = forward. Thanks a lot, --Richard [RFC5652] [RFC4306] [RFC5246] [RFC5280] [JWS] [JWE] From Michael.Jones@microsoft.com Mon Jul 2 11:33:58 2012 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 AF4D111E80D1 for ; Mon, 2 Jul 2012 11:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.783 X-Spam-Level: X-Spam-Status: No, score=-3.783 tagged_above=-999 required=5 tests=[AWL=-0.184, 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 tDwoO+ZP0Ume for ; Mon, 2 Jul 2012 11:33:58 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 98F1F11E80EF for ; Mon, 2 Jul 2012 11:33:57 -0700 (PDT) Received: from mail88-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Jul 2012 18:32:05 +0000 Received: from mail88-db3 (localhost [127.0.0.1]) by mail88-db3-R.bigfish.com (Postfix) with ESMTP id 4F4CE4E05CE; Mon, 2 Jul 2012 18:32:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VS-32(zz9371I1b0bM542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail88-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail88-db3 (localhost.localdomain [127.0.0.1]) by mail88-db3 (MessageSwitch) id 1341253919606124_15011; Mon, 2 Jul 2012 18:31:59 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.249]) by mail88-db3.bigfish.com (Postfix) with ESMTP id 900AC240137; Mon, 2 Jul 2012 18:31:59 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Jul 2012 18:31:58 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Mon, 2 Jul 2012 18:33:32 +0000 From: Mike Jones To: "cfrg@irtf.org" Thread-Topic: [Cfrg] Question from JOSE working group Thread-Index: Ac1YgS4wo9tuM20zQ029ZMkY7eroAQ== Date: Mon, 2 Jul 2012 18:33:31 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366572E8A@TK5EX14MBXC283.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.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [Cfrg] Question from JOSE working group 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, 02 Jul 2012 18:33:58 -0000 Dear cfrg, Since Richard is providing examples of choices made by other systems, I'll = add that XML DSIG http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/ does= integrity protect the algorithm and other parameters. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L. Barnes Sent: Monday, July 02, 2012 11:07 AM To: jose@ietf.org Subject: [jose] Fwd: [Cfrg] Question from JOSE working group FYI, trying to recruit some additional crypto expertise on this question. --Richard Begin forwarded message: > From: "Richard L. Barnes" > Subject: [Cfrg] Question from JOSE working group > Date: July 2, 2012 2:00:11 PM EDT > To: cfrg@irtf.org >=20 > Dear CFRG, >=20 > This is a request for input on a crypto question that has come up in the = JOSE working group. >=20 > The question is whether there is any benefit to applying integrity protec= tion to cryptographic parameters attached to a signed/authenticated/encrypt= ed object. By "cryptographic parameters" here, I mean public keys, wrapped= symmetric keys, algorithm identifiers, etc. >=20 > For historical background: >=20 > CMS does not provide parameter protection [RFC5652]. The content that is= signed / authenticated / encrypted is precisely the protected content (eCo= ntent). Optionally, an application may add signed attributes. In the case= of SignedData and AuthenticatedData, if signed attributes are present, the= n they must include the message digest that was signed or authenticated; no= t a parameter, but an intermediate result. >=20 > IKE and TLS does not provide integrity protection for parameters [RFC4306= ][RFC5246]. Algorithm negotiation is done in parallel with key agreement i= n the initial phase of IKEv2 Algorithm negotiation in TLS is done in the = ClientHello / ServerHello messages, which are sent before the secure channe= l is established. When TLS client certificates are used, the client demons= trates its possession of the relevant private key by signing the handshake = messages, which provides an integrity check on cryptographic parameters as = a side-effect. However, the parameters for this signature (the public key = and signature/hash algorithms) are not protected. >=20 > PKIX is an intermediate case. The signature algorithm used to sign / ver= ify the certificate is included in the certificate body (under the signatur= e) as well as ouside the signature. >=20 > Back to today: >=20 > The current draft specifications for JOSE [JWS][JWE] require integrity pr= otection for parameters. The creator of an object constructs a "header" va= lue including the cryptographic parameters used to generate the object. Th= is header value is prepended to the protected content before the content is= signed / authenticated (JWS), or attached as "Associated Data" to the encr= ypted content (JWE). (JWE only allows AEAD algorithms.) >=20 > So the questions for this group are the following:=20 > -- Does applying integrity protection to cryptographic parameters result = in a meaningful increase the security of an secure object format? =20 > -- What are the classes of attack that this integrity protection would ad= dress? > -- Does parameter protection create any additional security vulnerabiliti= es? >=20 > Any input would be very helpful for the group to decide on a way forward. >=20 > Thanks a lot, > --Richard >=20 >=20 > [RFC5652] > [RFC4306] > [RFC5246] > [RFC5280] > [JWS] > [JWE] >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Mon Jul 2 11:34:35 2012 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 1426911E80D1 for ; Mon, 2 Jul 2012 11:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 U70tIKdM7viM for ; Mon, 2 Jul 2012 11:34:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4792911E80F1 for ; Mon, 2 Jul 2012 11:34:34 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:63231) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SllSI-0006eV-QY; Mon, 02 Jul 2012 14:34:38 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4FF1E6A0.3060606@adida.net> Date: Mon, 2 Jul 2012 14:34:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6419EDFA-B62C-41F3-8E88-CB0BA1D2168D@bbn.com> References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> <140C6B2D-8BE8-4202-91F4-65D6693D3D79@bbn.com> <4FF1E6A0.3060606@adida.net> To: Ben Adida X-Mailer: Apple Mail (2.1278) Cc: cfrg@irtf.org Subject: Re: [Cfrg] [jose] Fwd: Question from JOSE working group 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, 02 Jul 2012 18:34:35 -0000 [Redirecting this back to CFRG] I appreciate what you're trying to do, but I'm not sure it's really = possible, and in any case, integrity-protecting parameter values doesn't = accomplish it. =20 Even with parameter integrity protection, the recipient of the object = has to use the parameters before he knows whether they're valid. So an = attacker can still cause the recipient to go down an alternate code = path, it's just that at the end, the recipient will realize he's gone = down the wrong path. In other words, getting to your "(1) error" case = already involves going down the wrong processing path. --Richard On Jul 2, 2012, at 2:21 PM, Ben Adida wrote: >=20 > My take: yes, there is value. The crypto parameters will trigger = different processing on the payload, and that *might* be usable, by some = crafty cryptanalyst, as an oracle. >=20 > It would be more conservative (and thus safer) to follow one rule: = there are only two execution paths that can be triggered by the = recipient of a crypto blob. (1) error, or (2) processing of payload = according to authenticated sender's specifications. >=20 > -Ben >=20 > On 7/2/12 11:07 AM, Richard L. Barnes wrote: >> FYI, trying to recruit some additional crypto expertise on this = question. >>=20 >> --Richard >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: "Richard L. Barnes" >>> Subject: [Cfrg] Question from JOSE working group >>> Date: July 2, 2012 2:00:11 PM EDT >>> To: cfrg@irtf.org >>>=20 >>> Dear CFRG, >>>=20 >>> This is a request for input on a crypto question that has come up in = the JOSE working group. >>>=20 >>> The question is whether there is any benefit to applying integrity = protection to cryptographic parameters attached to a = signed/authenticated/encrypted object. By "cryptographic parameters" = here, I mean public keys, wrapped symmetric keys, algorithm identifiers, = etc. >>>=20 >>> For historical background: >>>=20 >>> CMS does not provide parameter protection [RFC5652]. The content = that is signed / authenticated / encrypted is precisely the protected = content (eContent). Optionally, an application may add signed = attributes. In the case of SignedData and AuthenticatedData, if signed = attributes are present, then they must include the message digest that = was signed or authenticated; not a parameter, but an intermediate = result. >>>=20 >>> IKE and TLS does not provide integrity protection for parameters = [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key = agreement in the initial phase of IKEv2 Algorithm negotiation in TLS = is done in the ClientHello / ServerHello messages, which are sent before = the secure channel is established. When TLS client certificates are = used, the client demonstrates its possession of the relevant private key = by signing the handshake messages, which provides an integrity check on = cryptographic parameters as a side-effect. However, the parameters for = this signature (the public key and signature/hash algorithms) are not = protected. >>>=20 >>> PKIX is an intermediate case. The signature algorithm used to sign = / verify the certificate is included in the certificate body (under the = signature) as well as ouside the signature. >>>=20 >>> Back to today: >>>=20 >>> The current draft specifications for JOSE [JWS][JWE] require = integrity protection for parameters. The creator of an object = constructs a "header" value including the cryptographic parameters used = to generate the object. This header value is prepended to the protected = content before the content is signed / authenticated (JWS), or attached = as "Associated Data" to the encrypted content (JWE). (JWE only allows = AEAD algorithms.) >>>=20 >>> So the questions for this group are the following: >>> -- Does applying integrity protection to cryptographic parameters = result in a meaningful increase the security of an secure object format? >>> -- What are the classes of attack that this integrity protection = would address? >>> -- Does parameter protection create any additional security = vulnerabilities? >>>=20 >>> Any input would be very helpful for the group to decide on a way = forward. >>>=20 >>> Thanks a lot, >>> --Richard >>>=20 >>>=20 >>> [RFC5652] >>> [RFC4306] >>> [RFC5246] >>> [RFC5280] >>> [JWS] >>> = [JWE] >>>=20 >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/cfrg >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From housley@vigilsec.com Mon Jul 2 12:43:17 2012 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 9923521F8707 for ; Mon, 2 Jul 2012 12:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[AWL=0.761, 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 HEkCRvDyqFFI for ; Mon, 2 Jul 2012 12:43:16 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id A140321F847C for ; Mon, 2 Jul 2012 12:43:16 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 9415BF24047; Mon, 2 Jul 2012 15:43:32 -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 v9HIBgaxHh9Q; Mon, 2 Jul 2012 15:43:13 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-10-63.washdc.fios.verizon.net [96.255.10.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7F04DF24040; Mon, 2 Jul 2012 15:43:31 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jul 2012 15:43:20 -0400 Message-Id: To: "cfrg@irtf.org" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: "jose@ietf.org" Subject: Re: [Cfrg] Question from JOSE working group 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, 02 Jul 2012 19:43:17 -0000 In the CMS signature processing, the hash algorithm is covered by the = signature. The hash algorithm is a signed attribute, and the collection = of signed attributes is hashed as part of the signature process. Other parameters of the signature algorithm, if any, are not integrity = protected. The thinking is that the signature algorithm is seriously = flawed is a change to the parameters will make an invalid signature seem = valid. Russ Begin forwarded message: > From: "Richard L. Barnes" > Subject: [Cfrg] Question from JOSE working group > Date: July 2, 2012 2:00:11 PM EDT > To: cfrg@irtf.org >=20 > Dear CFRG, >=20 > This is a request for input on a crypto question that has come up in = the JOSE working group. >=20 > The question is whether there is any benefit to applying integrity = protection to cryptographic parameters attached to a = signed/authenticated/encrypted object. By "cryptographic parameters" = here, I mean public keys, wrapped symmetric keys, algorithm identifiers, = etc. >=20 > For historical background: >=20 > CMS does not provide parameter protection [RFC5652]. The content that = is signed / authenticated / encrypted is precisely the protected content = (eContent). Optionally, an application may add signed attributes. In = the case of SignedData and AuthenticatedData, if signed attributes are = present, then they must include the message digest that was signed or = authenticated; not a parameter, but an intermediate result. >=20 > IKE and TLS does not provide integrity protection for parameters = [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key = agreement in the initial phase of IKEv2 Algorithm negotiation in TLS = is done in the ClientHello / ServerHello messages, which are sent before = the secure channel is established. When TLS client certificates are = used, the client demonstrates its possession of the relevant private key = by signing the handshake messages, which provides an integrity check on = cryptographic parameters as a side-effect. However, the parameters for = this signature (the public key and signature/hash algorithms) are not = protected. >=20 > PKIX is an intermediate case. The signature algorithm used to sign / = verify the certificate is included in the certificate body (under the = signature) as well as ouside the signature. >=20 > Back to today: >=20 > The current draft specifications for JOSE [JWS][JWE] require integrity = protection for parameters. The creator of an object constructs a = "header" value including the cryptographic parameters used to generate = the object. This header value is prepended to the protected content = before the content is signed / authenticated (JWS), or attached as = "Associated Data" to the encrypted content (JWE). (JWE only allows AEAD = algorithms.) >=20 > So the questions for this group are the following:=20 > -- Does applying integrity protection to cryptographic parameters = result in a meaningful increase the security of an secure object format? = =20 > -- What are the classes of attack that this integrity protection would = address? > -- Does parameter protection create any additional security = vulnerabilities? >=20 > Any input would be very helpful for the group to decide on a way = forward. >=20 > Thanks a lot, > --Richard >=20 >=20 > [RFC5652] > [RFC4306] > [RFC5246] > [RFC5280] > [JWS] > [JWE] >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg From rbarnes@bbn.com Mon Jul 2 13:02:10 2012 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 6CE4211E80A3; Mon, 2 Jul 2012 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 EUFRYLspSw3C; Mon, 2 Jul 2012 13:02:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 55A8D11E8083; Mon, 2 Jul 2012 13:02:09 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:63483) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Slmoy-0008Oa-Rl; Mon, 02 Jul 2012 16:02:08 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 2 Jul 2012 16:02:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <41F795C1-BD4F-4732-8F1A-62F909E9AA07@bbn.com> References: To: Russ Housley X-Mailer: Apple Mail (2.1278) Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] Question from JOSE working group 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, 02 Jul 2012 20:02:10 -0000 Actually, the inclusion of the hash algorithm under the signature is = optional: " signedAttrs is a collection of attributes that are signed. The field is optional, but it MUST be present if the content type of the EncapsulatedContentInfo value being signed is not id-data. [...] If the field is present, it MUST contain, at a minimum, the following two attributes: ... A message-digest attribute, having as its value the message digest of the content. Section 11.2 defines the message-digest attribute. " Since "id-data" means "no more ASN.1 structure", for JOSE, the content = type is effectively always "id-data". --Richard On Jul 2, 2012, at 3:43 PM, Russ Housley wrote: > In the CMS signature processing, the hash algorithm is covered by the = signature. The hash algorithm is a signed attribute, and the collection = of signed attributes is hashed as part of the signature process. >=20 > Other parameters of the signature algorithm, if any, are not integrity = protected. The thinking is that the signature algorithm is seriously = flawed is a change to the parameters will make an invalid signature seem = valid. >=20 > Russ >=20 >=20 > Begin forwarded message: >=20 >> From: "Richard L. Barnes" >> Subject: [Cfrg] Question from JOSE working group >> Date: July 2, 2012 2:00:11 PM EDT >> To: cfrg@irtf.org >>=20 >> Dear CFRG, >>=20 >> This is a request for input on a crypto question that has come up in = the JOSE working group. >>=20 >> The question is whether there is any benefit to applying integrity = protection to cryptographic parameters attached to a = signed/authenticated/encrypted object. By "cryptographic parameters" = here, I mean public keys, wrapped symmetric keys, algorithm identifiers, = etc. >>=20 >> For historical background: >>=20 >> CMS does not provide parameter protection [RFC5652]. The content = that is signed / authenticated / encrypted is precisely the protected = content (eContent). Optionally, an application may add signed = attributes. In the case of SignedData and AuthenticatedData, if signed = attributes are present, then they must include the message digest that = was signed or authenticated; not a parameter, but an intermediate = result. >>=20 >> IKE and TLS does not provide integrity protection for parameters = [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key = agreement in the initial phase of IKEv2 Algorithm negotiation in TLS = is done in the ClientHello / ServerHello messages, which are sent before = the secure channel is established. When TLS client certificates are = used, the client demonstrates its possession of the relevant private key = by signing the handshake messages, which provides an integrity check on = cryptographic parameters as a side-effect. However, the parameters for = this signature (the public key and signature/hash algorithms) are not = protected. >>=20 >> PKIX is an intermediate case. The signature algorithm used to sign / = verify the certificate is included in the certificate body (under the = signature) as well as ouside the signature. >>=20 >> Back to today: >>=20 >> The current draft specifications for JOSE [JWS][JWE] require = integrity protection for parameters. The creator of an object = constructs a "header" value including the cryptographic parameters used = to generate the object. This header value is prepended to the protected = content before the content is signed / authenticated (JWS), or attached = as "Associated Data" to the encrypted content (JWE). (JWE only allows = AEAD algorithms.) >>=20 >> So the questions for this group are the following:=20 >> -- Does applying integrity protection to cryptographic parameters = result in a meaningful increase the security of an secure object format? = =20 >> -- What are the classes of attack that this integrity protection = would address? >> -- Does parameter protection create any additional security = vulnerabilities? >>=20 >> Any input would be very helpful for the group to decide on a way = forward. >>=20 >> Thanks a lot, >> --Richard >>=20 >>=20 >> [RFC5652] >> [RFC4306] >> [RFC5246] >> [RFC5280] >> [JWS] >> [JWE] = >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From rbarnes@bbn.com Mon Jul 2 13:05:01 2012 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 3CEFC11E80A3; Mon, 2 Jul 2012 13:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 DUczTBbxY51O; Mon, 2 Jul 2012 13:04:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE8411E80B3; Mon, 2 Jul 2012 13:04:59 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:63493) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Slmrm-000CY1-FH; Mon, 02 Jul 2012 16:05:02 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> Date: Mon, 2 Jul 2012 16:05:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <76A75405-ACBB-474F-AE9A-845F1AA65E54@bbn.com> References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> To: cfrg@irtf.org X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [Cfrg] Question from JOSE working group 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, 02 Jul 2012 20:05:01 -0000 Here's my analysis of the question, as it stands right now. =46rom what I can tell, parameter protection is at best a marginal = improvement, and at worst actively harmful: 1. The possible benefits are a corner case 2. The JW* syntax increases vulnerability to chosen-prefix attacks 3. The JWE syntax creates operational risks in multiple-recipient = scenarios 1. The possible benefits are a corner case A JOSE object is defined by three main things: The algorithm A = (including associated parameters), the key K, and the message M. An = attack on the integrity of a JOSE object is a transformation of these = parameters and the integrity check value A(K,M) such that the attacker = can create another valid integrity check value A'(K',M'), causing the = recipient to accept a bogus integrity check value. Obviously, An attack = is only relevant if either the key or the message changes, since the = algorithm holds no inherent meaning. For example, in the attack (A,K,M)-->(A,K,M'), the recipient would accept a bogus message under the correct key. Under = the attack (A,K,M)-->(A,K',M) the recipient would accept a correct message, but under the wrong key. = There are obviously seven different attacks in this model (excluding the = trivial "attack").=20 There is value in parameter protection only in cases where an attacker = can mount a successful attack against an object with unprotected = parameters, but cannot attack an object with protected parameters. So = we should examine each of the seven different types of attacker = capabilities here and see whether they extend to protected objects. =46rom the perspective of this model, the impact of adding integrity = protection on the parameters is to add them to the message M. So we can = immediately note that parameter protection is useless against the four = attacks in which the message M is modified. If the attacker can change = the protected content, then he can also change the protected parameter = values, since they are, aftera all, just more content octets. We can also ignore the two attacks where neither the key K nor the = message M changes, since these don't represent a meaningful attack. So the only possible benefit is from the two remaining cases where the = key changes, but the message does not. That is, parameter protection = has value only if one of the following implications is *false*: (1) (A,K,M)-->(A,K',M) =3D=3D> (A,K,M)-->(A,K',M') (2) (A,K,M)-->(A',K',M) =3D=3D> (A,K,M)-->(A',K',M') In these cases, in order to overcome the parameter integrity protection, = the attacker would need to be able to modify the part of the message = containing the parameters. Only if the attacker is unable to make this = modification does the protection have value.=20 I don't know whether these implications are true or false in general, = but there are at least some cases in which they are true. For example: -- Implication (1) is true for HMAC: If you can change the key, then you = have effectively broken the hash function, so you should be able to = change the content as well. -- Implication (1) is true for RSA-PSS, because the security of RSA-PSS = is equivalent to the factoring problem [RSAPSS] The change of algorithm question in implication (2) is an exotic one, = and AFAICT, there's not much literature on it. ISTM most likely to = arise in the context of related algorithms, e.g., elliptic curves of the = same size with different parameters. (This could, of course, be = mitigated by requiring named curves, one per field size!) Other than = that, it seems like the differences in mathematics would make it = unlikely that a valid key for one algorithm would collide. Of course, = the assumption here is=20 Summing up all of the above: Parameter protection seems to only be = useful under highly constrained assumptions on attacker capabilities. 2. The JWS syntax increases vulnerability to chosen-prefix attacks There has been a lot of press lately about Flame's use of a = chosen-prefix attack against MD5 to generate bogus code-signing = certificates [Flame-MD5]. In general, chosen-prefix attacks have been a = fairly fruitful avenue of attack against hash functions, with MD5 = clearly broken, and significant progress having been made against SHA-1 = [SHA1Prefix]. In the JWS signing process, the header value is prepended to the content = before the whole thing is digested and signed/authenticated. In = practice, for a given signer, the JWS header is likely to be predictable = to an attacker. So JWS has a built-in predictable prefix that can be = exploited for chosen-prefix attacks. JWS also defeats efforts that applications might make to mitigate = chosen-prefix attacks. In PKIX, for example, the recommended mitigation = to MD5's weaknesses is to randomize the fields that come early in the = certificate, so that the length of the available prefix is minimized = [RFC4270]. In JWS, however, even if an application put unpredictable = things early in the content body, the JWS signing process prepends = something predictable, so the efforts of the application are for naught. = =20 Thus, if the JOSE format ultimately does protect parameters, then it = will need to include a mandatory random element at the beginning of the = protected header. 3. The JWE syntax creates operational risks in multiple-recipient = scenarios One of the major use-cases for JOSE is for encrypting messages to be = received by multiple entities holding different private keys. In this = context, integrity-protecting parameters causes a couple of operational = concerns, arising from the fact that the wrapped key is included under = the integrity check. First, if there is any delay between the sending of the original object = and the transmission of wrapped keys, then the sender needs to cache the = entire object and re-process it to compute a new integrity check value = whenever a new recipient is added. Moreover, the object needs to be = cached in plaintext, exposing it to risks of being stolen on the = originating host while it resides in cache. By contrast, without parameter protection, only the encryption key needs = to be cached; the content itself can be deleted. So even though there = is a risk that the cached key will leak, it can at least be separated = from the protected content, to reduce the ultimate risk that the content = will be exposed. Reference: [RSAPSS] [Flame-MD5] = [SHA1Prefix] [RFC4270] On Jul 2, 2012, at 2:00 PM, Richard L. Barnes wrote: > Dear CFRG, >=20 > This is a request for input on a crypto question that has come up in = the JOSE working group. >=20 > The question is whether there is any benefit to applying integrity = protection to cryptographic parameters attached to a = signed/authenticated/encrypted object. By "cryptographic parameters" = here, I mean public keys, wrapped symmetric keys, algorithm identifiers, = etc. >=20 > For historical background: >=20 > CMS does not provide parameter protection [RFC5652]. The content that = is signed / authenticated / encrypted is precisely the protected content = (eContent). Optionally, an application may add signed attributes. In = the case of SignedData and AuthenticatedData, if signed attributes are = present, then they must include the message digest that was signed or = authenticated; not a parameter, but an intermediate result. >=20 > IKE and TLS does not provide integrity protection for parameters = [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key = agreement in the initial phase of IKEv2 Algorithm negotiation in TLS = is done in the ClientHello / ServerHello messages, which are sent before = the secure channel is established. When TLS client certificates are = used, the client demonstrates its possession of the relevant private key = by signing the handshake messages, which provides an integrity check on = cryptographic parameters as a side-effect. However, the parameters for = this signature (the public key and signature/hash algorithms) are not = protected. >=20 > PKIX is an intermediate case. The signature algorithm used to sign / = verify the certificate is included in the certificate body (under the = signature) as well as ouside the signature. >=20 > Back to today: >=20 > The current draft specifications for JOSE [JWS][JWE] require integrity = protection for parameters. The creator of an object constructs a = "header" value including the cryptographic parameters used to generate = the object. This header value is prepended to the protected content = before the content is signed / authenticated (JWS), or attached as = "Associated Data" to the encrypted content (JWE). (JWE only allows AEAD = algorithms.) >=20 > So the questions for this group are the following:=20 > -- Does applying integrity protection to cryptographic parameters = result in a meaningful increase the security of an secure object format? = =20 > -- What are the classes of attack that this integrity protection would = address? > -- Does parameter protection create any additional security = vulnerabilities? >=20 > Any input would be very helpful for the group to decide on a way = forward. >=20 > Thanks a lot, > --Richard >=20 >=20 > [RFC5652] > [RFC4306] > [RFC5246] > [RFC5280] > [JWS] > [JWE] >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From ve7jtb@ve7jtb.com Mon Jul 2 14:00:50 2012 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 BF1C611E8126 for ; Mon, 2 Jul 2012 14:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 JPcYWlLQwBn1 for ; Mon, 2 Jul 2012 14:00:49 -0700 (PDT) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5702011E8125 for ; Mon, 2 Jul 2012 14:00:49 -0700 (PDT) Received: by ggnm2 with SMTP id m2so5420474ggn.13 for ; Mon, 02 Jul 2012 14:00:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=fzwH74rjM6ItPpQlPsp/w3h7yB88b5FwALlmXFB2Z0Q=; b=ZK7Zm2E9xc9yFPLm0u4v+AglY1a1EHcEeOo6hANkem/V8kN3UZ2IDiviO/h3jrWwc4 4/s1bAQjBIdaI8EMIRZGcOWPTruJtjtfJ0/mBHSx0Hy4yTyxMVxKFvCip+7B3Jsx+c1f a6ztnaEZZ8kW0eDv0R50OL5wkLPTyS+pMnkE7Jq0KiY5F/Zd10sEMTAAOKMl6SjobgNK faImzJ5rYBgB5MyRACktZp+oPTt0qjBOCT7C1U/8VWaRVF3VYkEZn1GQeYPbyWW9ZKYJ qBsKT3v3dMIXOXrARO7esHOX6km/u/jNjCTTwCNpGWm/CNHSC6ZhSkS8kSoOJHZeoh/K ZpNQ== Received: by 10.236.181.71 with SMTP id k47mr11483069yhm.69.1341262854613; Mon, 02 Jul 2012 14:00:54 -0700 (PDT) Received: from [192.168.1.211] (190-20-50-6.baf.movistar.cl. [190.20.50.6]) by mx.google.com with ESMTPS id p14sm12672864ani.8.2012.07.02.14.00.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2012 14:00:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_0EFAC52B-FD4E-418E-89B3-6A239AD3520A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <76A75405-ACBB-474F-AE9A-845F1AA65E54@bbn.com> Date: Mon, 2 Jul 2012 17:00:43 -0400 Message-Id: References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> <76A75405-ACBB-474F-AE9A-845F1AA65E54@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlexyYdN7hdokAiMlXPsTy5XddPCgz2mCVDFerPX3DYhCAUC/mqO2lM1HxTXGgG6oYFsHZJ Cc: cfrg@irtf.org, jose@ietf.org Subject: Re: [Cfrg] [jose] Question from JOSE working group 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, 02 Jul 2012 21:00:50 -0000 --Apple-Mail=_0EFAC52B-FD4E-418E-89B3-6A239AD3520A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Richard, Chosen-prefix attacks require the text of both messages to be the same = up to the point where the attacker can insert the collision function = blocks. If the header is not integrity protected the attacker is able to insert = collision function blocks at the start of the plan text. I have a hard = time seeing the attacker controlling the entire plaintext as "better" in = any way. If anything JWS and JWE should be including a nonce or timestamp in the = header to prevent this attack. That requires integrity protecting the = header with the nonce. JOSE was constructed to make no assumptions about the plaintext. Saying = the protocol using JOSE should deal with it in the plaintext is not all = that useful if arbitrary bodes are allowed for signing and encrypting. That is one reason CMS allows for the integrity protect of additional = attributes. Regards John Bradley On 2012-07-02, at 4:05 PM, Richard L. Barnes wrote: > Here's my analysis of the question, as it stands right now. >=20 > =46rom what I can tell, parameter protection is at best a marginal = improvement, and at worst actively harmful: > 1. The possible benefits are a corner case > 2. The JW* syntax increases vulnerability to chosen-prefix attacks > 3. The JWE syntax creates operational risks in multiple-recipient = scenarios >=20 >=20 > 1. The possible benefits are a corner case >=20 > A JOSE object is defined by three main things: The algorithm A = (including associated parameters), the key K, and the message M. An = attack on the integrity of a JOSE object is a transformation of these = parameters and the integrity check value A(K,M) such that the attacker = can create another valid integrity check value A'(K',M'), causing the = recipient to accept a bogus integrity check value. Obviously, An attack = is only relevant if either the key or the message changes, since the = algorithm holds no inherent meaning. For example, in the attack > (A,K,M)-->(A,K,M'), > the recipient would accept a bogus message under the correct key. = Under the attack > (A,K,M)-->(A,K',M) > the recipient would accept a correct message, but under the wrong key. = There are obviously seven different attacks in this model (excluding = the trivial "attack").=20 >=20 > There is value in parameter protection only in cases where an attacker = can mount a successful attack against an object with unprotected = parameters, but cannot attack an object with protected parameters. So = we should examine each of the seven different types of attacker = capabilities here and see whether they extend to protected objects. >=20 > =46rom the perspective of this model, the impact of adding integrity = protection on the parameters is to add them to the message M. So we can = immediately note that parameter protection is useless against the four = attacks in which the message M is modified. If the attacker can change = the protected content, then he can also change the protected parameter = values, since they are, aftera all, just more content octets. >=20 > We can also ignore the two attacks where neither the key K nor the = message M changes, since these don't represent a meaningful attack. >=20 > So the only possible benefit is from the two remaining cases where the = key changes, but the message does not. That is, parameter protection = has value only if one of the following implications is *false*: > (1) (A,K,M)-->(A,K',M) =3D=3D> (A,K,M)-->(A,K',M') > (2) (A,K,M)-->(A',K',M) =3D=3D> (A,K,M)-->(A',K',M') > In these cases, in order to overcome the parameter integrity = protection, the attacker would need to be able to modify the part of the = message containing the parameters. Only if the attacker is unable to = make this modification does the protection have value.=20 >=20 > I don't know whether these implications are true or false in general, = but there are at least some cases in which they are true. For example: > -- Implication (1) is true for HMAC: If you can change the key, then = you have effectively broken the hash function, so you should be able to = change the content as well. > -- Implication (1) is true for RSA-PSS, because the security of = RSA-PSS is equivalent to the factoring problem [RSAPSS] >=20 > The change of algorithm question in implication (2) is an exotic one, = and AFAICT, there's not much literature on it. ISTM most likely to = arise in the context of related algorithms, e.g., elliptic curves of the = same size with different parameters. (This could, of course, be = mitigated by requiring named curves, one per field size!) Other than = that, it seems like the differences in mathematics would make it = unlikely that a valid key for one algorithm would collide. Of course, = the assumption here is=20 >=20 > Summing up all of the above: Parameter protection seems to only be = useful under highly constrained assumptions on attacker capabilities. >=20 >=20 >=20 > 2. The JWS syntax increases vulnerability to chosen-prefix attacks >=20 > There has been a lot of press lately about Flame's use of a = chosen-prefix attack against MD5 to generate bogus code-signing = certificates [Flame-MD5]. In general, chosen-prefix attacks have been a = fairly fruitful avenue of attack against hash functions, with MD5 = clearly broken, and significant progress having been made against SHA-1 = [SHA1Prefix]. >=20 > In the JWS signing process, the header value is prepended to the = content before the whole thing is digested and signed/authenticated. In = practice, for a given signer, the JWS header is likely to be predictable = to an attacker. So JWS has a built-in predictable prefix that can be = exploited for chosen-prefix attacks. >=20 > JWS also defeats efforts that applications might make to mitigate = chosen-prefix attacks. In PKIX, for example, the recommended mitigation = to MD5's weaknesses is to randomize the fields that come early in the = certificate, so that the length of the available prefix is minimized = [RFC4270]. In JWS, however, even if an application put unpredictable = things early in the content body, the JWS signing process prepends = something predictable, so the efforts of the application are for naught. = =20 >=20 > Thus, if the JOSE format ultimately does protect parameters, then it = will need to include a mandatory random element at the beginning of the = protected header. >=20 >=20 >=20 > 3. The JWE syntax creates operational risks in multiple-recipient = scenarios >=20 > One of the major use-cases for JOSE is for encrypting messages to be = received by multiple entities holding different private keys. In this = context, integrity-protecting parameters causes a couple of operational = concerns, arising from the fact that the wrapped key is included under = the integrity check. >=20 > First, if there is any delay between the sending of the original = object and the transmission of wrapped keys, then the sender needs to = cache the entire object and re-process it to compute a new integrity = check value whenever a new recipient is added. Moreover, the object = needs to be cached in plaintext, exposing it to risks of being stolen on = the originating host while it resides in cache. >=20 > By contrast, without parameter protection, only the encryption key = needs to be cached; the content itself can be deleted. So even though = there is a risk that the cached key will leak, it can at least be = separated from the protected content, to reduce the ultimate risk that = the content will be exposed. >=20 >=20 >=20 > Reference: > [RSAPSS] > [Flame-MD5] = > [SHA1Prefix] = > [RFC4270] >=20 >=20 > On Jul 2, 2012, at 2:00 PM, Richard L. Barnes wrote: >=20 >> Dear CFRG, >>=20 >> This is a request for input on a crypto question that has come up in = the JOSE working group. >>=20 >> The question is whether there is any benefit to applying integrity = protection to cryptographic parameters attached to a = signed/authenticated/encrypted object. By "cryptographic parameters" = here, I mean public keys, wrapped symmetric keys, algorithm identifiers, = etc. >>=20 >> For historical background: >>=20 >> CMS does not provide parameter protection [RFC5652]. The content = that is signed / authenticated / encrypted is precisely the protected = content (eContent). Optionally, an application may add signed = attributes. In the case of SignedData and AuthenticatedData, if signed = attributes are present, then they must include the message digest that = was signed or authenticated; not a parameter, but an intermediate = result. >>=20 >> IKE and TLS does not provide integrity protection for parameters = [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key = agreement in the initial phase of IKEv2 Algorithm negotiation in TLS = is done in the ClientHello / ServerHello messages, which are sent before = the secure channel is established. When TLS client certificates are = used, the client demonstrates its possession of the relevant private key = by signing the handshake messages, which provides an integrity check on = cryptographic parameters as a side-effect. However, the parameters for = this signature (the public key and signature/hash algorithms) are not = protected. >>=20 >> PKIX is an intermediate case. The signature algorithm used to sign / = verify the certificate is included in the certificate body (under the = signature) as well as ouside the signature. >>=20 >> Back to today: >>=20 >> The current draft specifications for JOSE [JWS][JWE] require = integrity protection for parameters. The creator of an object = constructs a "header" value including the cryptographic parameters used = to generate the object. This header value is prepended to the protected = content before the content is signed / authenticated (JWS), or attached = as "Associated Data" to the encrypted content (JWE). (JWE only allows = AEAD algorithms.) >>=20 >> So the questions for this group are the following:=20 >> -- Does applying integrity protection to cryptographic parameters = result in a meaningful increase the security of an secure object format? = =20 >> -- What are the classes of attack that this integrity protection = would address? >> -- Does parameter protection create any additional security = vulnerabilities? >>=20 >> Any input would be very helpful for the group to decide on a way = forward. >>=20 >> Thanks a lot, >> --Richard >>=20 >>=20 >> [RFC5652] >> [RFC4306] >> [RFC5246] >> [RFC5280] >> [JWS] >> [JWE] = >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_0EFAC52B-FD4E-418E-89B3-6A239AD3520A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw MjIxMDA0NFowIwYJKoZIhvcNAQkEMRYEFIlu0dssk7OSCNMRXB5C3EBu2WVoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AHhFUYdIiIBuBdCE7dfvFXMFtbioMV4f0wtfqxb9OA1mfcGcbYXkTrr0n+O9gSG+KDInVHVZXdUk jZqqhc5iHHy5MibfofwVK6d17zfyv5lDHw/EwCzLYp+wkqEuIT1JIc7NvMRCyAhQaMo/3kvtYwTx LKS/OhL4xVKat+rcfOv/WhOB9DA4+kQqttx5gWjMuHcnFOKiwToEU9xVTOgYuYBYIdFZ3g+5KGi9 O/8KqYP72ZMSOi8YR5ka+8DmDNQRhTnd4eLJN43rDQVq1wgK3sJWX73h6CtglwMJ1Sohul3hlddw 9ZNTpbe7IGMWqcFnWwVReJ/qCR9qtmuK0UWt93wAAAAAAAA= --Apple-Mail=_0EFAC52B-FD4E-418E-89B3-6A239AD3520A-- From b.m.m.d.weger@TUE.nl Mon Jul 2 15:19:18 2012 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 6A94521F85AF for ; Mon, 2 Jul 2012 15:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 FWyCz-KeRFSE for ; Mon, 2 Jul 2012 15:19:18 -0700 (PDT) Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.3.8]) by ietfa.amsl.com (Postfix) with ESMTP id CE90B21F85AC for ; Mon, 2 Jul 2012 15:19:17 -0700 (PDT) Received: from kweetal.tue.nl (localhost [127.0.0.1]) by mailhost.tue.nl (Postfix) with ESMTP id 9E8CC287CD; Tue, 3 Jul 2012 00:19:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at tue.nl Received: from mailhost.tue.nl ([131.155.3.8]) by kweetal.tue.nl (kweetal.tue.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8YbOYJk52Cg; Tue, 3 Jul 2012 00:19:21 +0200 (CEST) Received: from webmail10.campus.tue.nl (Webmail10.campus.tue.nl [131.155.6.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailhost.tue.nl (Postfix) with ESMTPS id 767F8287CC; Tue, 3 Jul 2012 00:19:21 +0200 (CEST) Received: from EXCHANGE11.campus.tue.nl ([131.155.6.31]) by webmail10.campus.tue.nl ([131.155.6.46]) with mapi; Tue, 3 Jul 2012 00:19:21 +0200 From: "Weger, B.M.M. de" To: John Bradley , "Richard L. Barnes" Date: Tue, 3 Jul 2012 00:19:20 +0200 Thread-Topic: [Cfrg] [jose] Question from JOSE working group Thread-Index: Ac1Ylc9XRxClBkD6TOaghE+skesfSgACSsqw Message-ID: <7DF2365FF07C0E4E89419D65CCC93C9E018FF3683736@EXCHANGE11.campus.tue.nl> References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> <76A75405-ACBB-474F-AE9A-845F1AA65E54@bbn.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] [jose] Question from JOSE working group 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, 02 Jul 2012 22:19:18 -0000 Hi John, > Chosen-prefix attacks require the text of both messages to be the same up > to the point where the attacker can insert the collision function blocks. Correction:=20 It's identical-prefix attacks that require the text of both messages to be= =20 the same up to the point where the attacker can insert the collision blocks= . That's exactly why these attacks are called "identical-prefix". Chosen-prefix attacks allow the attacker to choose whatever he wants in each of the two messages up to the point where ... etc. Chosen-prefix attacks fail if the attacker has no sufficient control over /= =20 cannot sufficiently predict this part of the messages. Grtz, Benne de Weger From ve7jtb@ve7jtb.com Mon Jul 2 15:40:18 2012 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 86A6A11E80C5 for ; Mon, 2 Jul 2012 15:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 l8BIuD8fos9g for ; Mon, 2 Jul 2012 15:40:18 -0700 (PDT) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by ietfa.amsl.com (Postfix) with ESMTP id E36DF11E8080 for ; Mon, 2 Jul 2012 15:40:17 -0700 (PDT) Received: by ghbz22 with SMTP id z22so5531819ghb.13 for ; Mon, 02 Jul 2012 15:40:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=FuPEUNz0RGOQrNcWpZg0OOUvqTMZEbrFDMuLSYRDCSs=; b=YmwCtl7V013b4QhLBDQ1WVdIaBBLtJHFWEmr5BD9YJPRTT4YaTGciVJg2cyMuJ8cCW yqaE0Po1ULeFrlVKrHSLAxb9Ni1qDY9ASYt99Hbdnp/ficXA1ggt1vg0ot4aAfaKeEy7 y+lIFYD0/Mm31ErEQjJGaSqiK/lbTeTqzXjVPFtKqJdBBngAlJSTnO7VQ2NuzUMUJv5G jCZYIcHQ3D5EKBi09CiFhmN/K4uI2FCVjMxCp96bdYyPDHk9hWpWy3MglOiR1R1932Sa 2TLyU8FtHkydSapYjJb7x1hxI368NtlRff4gHsTofvOizn6VXVMH255I/3k1QYDnGQih 0Cgg== Received: by 10.236.165.74 with SMTP id d50mr17236527yhl.118.1341268823767; Mon, 02 Jul 2012 15:40:23 -0700 (PDT) Received: from [192.168.1.211] (190-20-50-6.baf.movistar.cl. [190.20.50.6]) by mx.google.com with ESMTPS id k67sm27822393yhj.18.2012.07.02.15.40.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2012 15:40:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_303FD340-641E-4FAF-A220-52B7E32A1446"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <7DF2365FF07C0E4E89419D65CCC93C9E018FF3683736@EXCHANGE11.campus.tue.nl> Date: Mon, 2 Jul 2012 18:40:03 -0400 Message-Id: <58091EAC-6E16-48FD-A698-A4BF64C60DEB@ve7jtb.com> References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> <76A75405-ACBB-474F-AE9A-845F1AA65E54@bbn.com> <7DF2365FF07C0E4E89419D65CCC93C9E018FF3683736@EXCHANGE11.campus.tue.nl> To: "Weger, B.M.M. de" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlmokt7kgudjTyAJpCwosiIAceY+7jT2rfJbHDlJZY6ILKcyWKGXOyTqhE+vYCTLwSAninn Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] [jose] Question from JOSE working group 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, 02 Jul 2012 22:40:18 -0000 --Apple-Mail=_303FD340-641E-4FAF-A220-52B7E32A1446 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes sorry JOSE would not be susceptible to chosen prefix unless we allow = the attacker to control the entire plaintext. As it is now the header is controlled by the signer. I think Richard was referring to an identical prefix attack being = possible due to the header without a nonce or date stamp being = relatively deterministic. In ether event integrity protecting the header is not increasing the = vulnerability. Thanks few the correction. Regards John Bradley On 2012-07-02, at 6:19 PM, Weger, B.M.M. de wrote: > Hi John, >=20 >> Chosen-prefix attacks require the text of both messages to be the = same up >> to the point where the attacker can insert the collision function = blocks. >=20 > Correction:=20 > It's identical-prefix attacks that require the text of both messages = to be=20 > the same up to the point where the attacker can insert the collision = blocks. > That's exactly why these attacks are called "identical-prefix". >=20 > Chosen-prefix attacks allow the attacker to choose whatever he wants = in > each of the two messages up to the point where ... etc. >=20 > Chosen-prefix attacks fail if the attacker has no sufficient control = over /=20 > cannot sufficiently predict this part of the messages. >=20 > Grtz, > Benne de Weger --Apple-Mail=_303FD340-641E-4FAF-A220-52B7E32A1446 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw MjIyNDAwNFowIwYJKoZIhvcNAQkEMRYEFFdYaQHhBYLl3i25wurn8OWIVWtZMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AFqvB2U0cHbFa9cEsolUQuiyHnytCgZNpRaxYKYVHlyFydKfgEMdNOdFDsvgHL1spxgDy4FIo6/5 KtZwi4gPeBxQkrsyAzYP+fNiJ8oNst1eKPs0wbgdU9LLnIuPAS1Zh09D/Y1EGRxH1biWYVkA4wME 39K+f56HHWoQMhAxLC9wszRx0m3wdtSsyStnkXI4IjLgIuJb3P8gE+SUkzmB5DGYOTornIBr9hSi g1X5h9oSKIJ+/hMYeptqffUoQhhYkhhRkg9W/oJfriSt+c6LBZvWAj04JRvWOVxRXeAJookJuYty EEbZPAuQ00Ov4XSFEEMVlyL0C5+pJ5NgK4htJocAAAAAAAA= --Apple-Mail=_303FD340-641E-4FAF-A220-52B7E32A1446-- From housley@vigilsec.com Tue Jul 3 08:01:44 2012 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 C541511E8154 for ; Tue, 3 Jul 2012 08:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=0.480, 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 J9ebSHh1NPsm for ; Tue, 3 Jul 2012 08:01:43 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id B177111E8151 for ; Tue, 3 Jul 2012 08:01:43 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B7722F24046; Tue, 3 Jul 2012 11:02: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 H3o0moNMwZka; Tue, 3 Jul 2012 11:01:33 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-10-63.washdc.fios.verizon.net [96.255.10.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E144FF2403D; Tue, 3 Jul 2012 11:02:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <41F795C1-BD4F-4732-8F1A-62F909E9AA07@bbn.com> Date: Tue, 3 Jul 2012 11:01:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1499CA50-2239-4102-BA1A-04104EAC57DF@vigilsec.com> References: <41F795C1-BD4F-4732-8F1A-62F909E9AA07@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] Question from JOSE working group 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, 03 Jul 2012 15:01:45 -0000 Richard: > Actually, the inclusion of the hash algorithm under the signature is = optional: > " > signedAttrs is a collection of attributes that are signed. The > field is optional, but it MUST be present if the content type of > the EncapsulatedContentInfo value being signed is not id-data. > [...] If the field is present, it MUST > contain, at a minimum, the following two attributes: >=20 > ... >=20 > A message-digest attribute, having as its value the message > digest of the content. Section 11.2 defines the = message-digest > attribute. > " >=20 > Since "id-data" means "no more ASN.1 structure", for JOSE, the content = type is effectively always "id-data". In practice, there are other attributes that one wants signed, such as = signing-time, so the algorithm identifier gets included. Russ From ietf@augustcellars.com Tue Jul 3 10:45:08 2012 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 F1CCB11E8185 for ; Tue, 3 Jul 2012 10:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 5h9OIYaIUg27 for ; Tue, 3 Jul 2012 10:45:05 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id C52D411E80A4 for ; Tue, 3 Jul 2012 10:45:05 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 984CF2CA0E; Tue, 3 Jul 2012 10:45:13 -0700 (PDT) From: "Jim Schaad" To: "'Russ Housley'" , "'Richard L.Barnes'" References: <41F795C1-BD4F-4732-8F1A-62F909E9AA07@bbn.com> <1499CA50-2239-4102-BA1A-04104EAC57DF@vigilsec.com> In-Reply-To: <1499CA50-2239-4102-BA1A-04104EAC57DF@vigilsec.com> Date: Tue, 3 Jul 2012 10:43:51 -0700 Message-ID: <03b301cd5943$693f2800$3bbd7800$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDe91NbMO1Nq06fh8taxrYdt/CHCALpPHJBAWJNYUmY0jtbkA== Content-Language: en-us Cc: cfrg@irtf.org, jose@ietf.org Subject: Re: [Cfrg] Question from JOSE working group 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, 03 Jul 2012 17:45:08 -0000 I would also note that when PKCS#7 was designed, the hash algorithm was always protected independent the presence of signed attributes. Either the hash algorithm was in the signed attributes or it was in the RSA signature block encoding. It was only with the introduction of other algorithms that this was no longer true. Jim > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Russ Housley > Sent: Tuesday, July 03, 2012 8:02 AM > To: Richard L.Barnes > Cc: cfrg@irtf.org; jose@ietf.org > Subject: Re: [Cfrg] Question from JOSE working group > > Richard: > > > Actually, the inclusion of the hash algorithm under the signature is optional: > > " > > signedAttrs is a collection of attributes that are signed. The > > field is optional, but it MUST be present if the content type of > > the EncapsulatedContentInfo value being signed is not id-data. > > [...] If the field is present, it MUST > > contain, at a minimum, the following two attributes: > > > > ... > > > > A message-digest attribute, having as its value the message > > digest of the content. Section 11.2 defines the message-digest > > attribute. > > " > > > > Since "id-data" means "no more ASN.1 structure", for JOSE, the content > type is effectively always "id-data". > > In practice, there are other attributes that one wants signed, such as signing- > time, so the algorithm identifier gets included. > > Russ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From rbarnes@bbn.com Tue Jul 3 12:58:27 2012 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 2D9A521F86D5; Tue, 3 Jul 2012 12:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 45E5ZNi-Ei77; Tue, 3 Jul 2012 12:58:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 57A7421F854E; Tue, 3 Jul 2012 12:58:26 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:52297) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sm9F1-000LaW-UK; Tue, 03 Jul 2012 15:58:31 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <03b301cd5943$693f2800$3bbd7800$@augustcellars.com> Date: Tue, 3 Jul 2012 15:58:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7C1A94EE-8633-4FA7-A936-E82FDA6A5FB9@bbn.com> References: <41F795C1-BD4F-4732-8F1A-62F909E9AA07@bbn.com> <1499CA50-2239-4102-BA1A-04104EAC57DF@vigilsec.com> <03b301cd5943$693f2800$3bbd7800$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1278) Cc: cfrg@irtf.org, 'Russ Housley' , jose@ietf.org Subject: Re: [Cfrg] Question from JOSE working group 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, 03 Jul 2012 19:58:27 -0000 More precisely: RSASSA-PKCS1-v1_5 includes the hash algorithm under the signature RSASSA-PSS (introduced in PKCS#1 v2.1) does not include the hash = algorithm Doesn't this seem to argue against the need to protect parameters, since = the security of RSASSA-PSS is tightly related to the RSA problem itself? = =20 On Jul 3, 2012, at 1:43 PM, Jim Schaad wrote: > I would also note that when PKCS#7 was designed, the hash algorithm = was > always protected independent the presence of signed attributes. = Either the > hash algorithm was in the signed attributes or it was in the RSA = signature > block encoding. It was only with the introduction of other = algorithms that > this was no longer true. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf = Of >> Russ Housley >> Sent: Tuesday, July 03, 2012 8:02 AM >> To: Richard L.Barnes >> Cc: cfrg@irtf.org; jose@ietf.org >> Subject: Re: [Cfrg] Question from JOSE working group >>=20 >> Richard: >>=20 >>> Actually, the inclusion of the hash algorithm under the signature is > optional: >>> " >>> signedAttrs is a collection of attributes that are signed. The >>> field is optional, but it MUST be present if the content type of >>> the EncapsulatedContentInfo value being signed is not id-data. >>> [...] If the field is present, it MUST >>> contain, at a minimum, the following two attributes: >>>=20 >>> ... >>>=20 >>> A message-digest attribute, having as its value the message >>> digest of the content. Section 11.2 defines the = message-digest >>> attribute. >>> " >>>=20 >>> Since "id-data" means "no more ASN.1 structure", for JOSE, the = content >> type is effectively always "id-data". >>=20 >> In practice, there are other attributes that one wants signed, such = as > signing- >> time, so the algorithm identifier gets included. >>=20 >> Russ >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >=20 From ietf@augustcellars.com Tue Jul 3 14:29:31 2012 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 3C32921F86B3 for ; Tue, 3 Jul 2012 14:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 hHd5p6DiN55z for ; Tue, 3 Jul 2012 14:29:30 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5359921F86B5 for ; Tue, 3 Jul 2012 14:29:30 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 1EE362CA15; Tue, 3 Jul 2012 14:29:39 -0700 (PDT) From: "Jim Schaad" To: "'Richard L. Barnes'" References: <41F795C1-BD4F-4732-8F1A-62F909E9AA07@bbn.com> <1499CA50-2239-4102-BA1A-04104EAC57DF@vigilsec.com> <03b301cd5943$693f2800$3bbd7800$@augustcellars.com> <7C1A94EE-8633-4FA7-A936-E82FDA6A5FB9@bbn.com> In-Reply-To: <7C1A94EE-8633-4FA7-A936-E82FDA6A5FB9@bbn.com> Date: Tue, 3 Jul 2012 14:28:16 -0700 Message-ID: <03c801cd5962$c3182920$49487b60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDe91NbMO1Nq06fh8taxrYdt/CHCALpPHJBAWJNYUkCIgYT+gJ3iACymK2qUNA= Content-Language: en-us Cc: cfrg@irtf.org, jose@ietf.org Subject: Re: [Cfrg] Question from JOSE working group 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, 03 Jul 2012 21:29:31 -0000 As I said - with the introduction of new signature algorithms led to the fact that the hash algorithm was no longer protected. If you are looking at breaking an RSA signature, you have two ways of going about it. You can either break the hash in some way - or you can factor the RSA keys. The RSA problem is related to the factoring of the keys and has little to do with attacking the hash algorithm. If I could get you to substitute my hash algorithm for the actual hash algorithm used, and they had the same hash value for different messages then the RSA problem is not relevant for the purposes of the attack. The PKCS#1.5 RSA defended against this by placing the hash algorithm identifier in as part of the "to be signed" value. This was both good - the hash algorithm was defended and bad - there were lots of known bits fixed bits in the signature block for lots of signatures. There can be operational/convention steps that deal with this - for example there is a suggested practice that the hash algorithm used in the RSA-PSS signature operation and the one computing the hash of the message should be the same. But there is no current requirement that these steps be followed. (Oops - need to file an erratum on RFC 4056 about what to do for a hash algorithm if signed attributes are not used.) The reason for writing RFC 6211 was precisely the issue of protecting the hash algorithm used in the signature operation in those cases where it was not completely obvious (i.e DSA which only permitted one signature algorithm) or it was not included in the cryptographic block (RSA v1.5). Jim > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, July 03, 2012 12:59 PM > To: Jim Schaad > Cc: 'Russ Housley'; cfrg@irtf.org; jose@ietf.org > Subject: Re: [Cfrg] Question from JOSE working group > > More precisely: > RSASSA-PKCS1-v1_5 includes the hash algorithm under the signature > RSASSA-PSS (introduced in PKCS#1 v2.1) does not include the hash algorithm > > Doesn't this seem to argue against the need to protect parameters, since the > security of RSASSA-PSS is tightly related to the RSA problem itself? > > > On Jul 3, 2012, at 1:43 PM, Jim Schaad wrote: > > > I would also note that when PKCS#7 was designed, the hash algorithm > > was always protected independent the presence of signed attributes. > > Either the hash algorithm was in the signed attributes or it was in the RSA > signature > > block encoding. It was only with the introduction of other algorithms that > > this was no longer true. > > > > Jim > > > > > >> -----Original Message----- > >> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf > >> Of Russ Housley > >> Sent: Tuesday, July 03, 2012 8:02 AM > >> To: Richard L.Barnes > >> Cc: cfrg@irtf.org; jose@ietf.org > >> Subject: Re: [Cfrg] Question from JOSE working group > >> > >> Richard: > >> > >>> Actually, the inclusion of the hash algorithm under the signature is > > optional: > >>> " > >>> signedAttrs is a collection of attributes that are signed. The > >>> field is optional, but it MUST be present if the content type of > >>> the EncapsulatedContentInfo value being signed is not id-data. > >>> [...] If the field is present, it MUST > >>> contain, at a minimum, the following two attributes: > >>> > >>> ... > >>> > >>> A message-digest attribute, having as its value the message > >>> digest of the content. Section 11.2 defines the message-digest > >>> attribute. > >>> " > >>> > >>> Since "id-data" means "no more ASN.1 structure", for JOSE, the > >>> content > >> type is effectively always "id-data". > >> > >> In practice, there are other attributes that one wants signed, such > >> as > > signing- > >> time, so the algorithm identifier gets included. > >> > >> Russ > >> > >> _______________________________________________ > >> Cfrg mailing list > >> Cfrg@irtf.org > >> http://www.irtf.org/mailman/listinfo/cfrg > > From lars@netapp.com Mon Jul 9 07:55:46 2012 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 8397221F864B for ; Mon, 9 Jul 2012 07:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.029 X-Spam-Level: X-Spam-Status: No, score=-10.029 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, 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 qQXWYMEwaZUI for ; Mon, 9 Jul 2012 07:55:45 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id B031C21F8649 for ; Mon, 9 Jul 2012 07:55:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,552,1336374000"; d="p7s'?scan'208";a="660852665" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 09 Jul 2012 07:56:10 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q69EuA8l001927 for ; Mon, 9 Jul 2012 07:56:10 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.13]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 07:56:10 -0700 From: "Eggert, Lars" To: "cfrg@irtf.org" Thread-Topic: minor suggestion for draft-irtf-cfrg-cipher-catalog Thread-Index: AQHNXeL5JrXzf/Kr0kewozS1DSqRog== Date: Mon, 9 Jul 2012 14:56:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_B7AE5BA6-E18F-49F1-B924-E5E4AD3DE3BA"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Cfrg] minor suggestion for draft-irtf-cfrg-cipher-catalog 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, 09 Jul 2012 14:55:46 -0000 --Apple-Mail=_B7AE5BA6-E18F-49F1-B924-E5E4AD3DE3BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I took a quick look at draft-irtf-cfrg-cipher-catalog and have some = minor suggestions: - When you say "Intellectual Property Rights have been claimed" on a = given cipher, what exactly does that mean? Does that mean that an IPR = disclosure has been filed with the IETF, or did you do a broader patent = search beyond what is in the IETF IPR disclosure database? Likewise, = when you say that IPR "has not been claimed", does that mean there is no = IETF disclosure, or did you do any further search? - Related to that, when you state "The owner of those rights is XYZ", = I'm wondering if what you mean is "the IPR disclosure to the IETF has = been filed by XYZ". Or have you done any further research into who = actually owns the IPR? (IPR gets bought and sold, for example.) For both of these, I think it would be good to be very clear what you = mean. Then, there is a third unrelated suggestion: - When you say that a cipher is used by IETF IDs or RRCs, I wonder if it = would be useful to actually cite the relevant documents, or if this = would make your already very long bibliography explode. Lars= --Apple-Mail=_B7AE5BA6-E18F-49F1-B924-E5E4AD3DE3BA Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcwOTE0NTYwNVowIwYJKoZIhvcNAQkEMRYEFGn9 ev+VgM82qhBRiItiha82VSdiMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAA8lOjjh VunBzv+DyqXN/CYwjdBoLR+71QbCAzM5E4ffbzY3jtLBR9ut8Glh6GOQxuNGLOGNUMlbLaCdHZg8 THZP/Ft3auu+WB/0ZHCgY60z6/HFLC3C+Mp92JMwjXT8p+yVSNndKWEMKBagt8TqmqbzFsW6/mkP 0EWuxtRWCj0c3neLThRaYgn3Fg2xHOR2Ou+MxJVj19cb8oUmmycvqFmwdx1Llx0uLNHJMeCjMe/c unePi393xDkBIRvVVVHqMNS10aIaaljPigKo9KfJU/xjC77LteBNDuJW8iX0qfuW3bjh7+mkzh2e R7YNY65OscxLwdDbiqKnqQFabfHybGwAAAAAAAA= --Apple-Mail=_B7AE5BA6-E18F-49F1-B924-E5E4AD3DE3BA-- From ted@krovetz.net Mon Jul 16 13:25:39 2012 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 1705C11E8137 for ; Mon, 16 Jul 2012 13:25:39 -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 4isnYaOzwNwv for ; Mon, 16 Jul 2012 13:25:38 -0700 (PDT) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2356311E8120 for ; Mon, 16 Jul 2012 13:25:38 -0700 (PDT) Received: by ggnm2 with SMTP id m2so6320830ggn.13 for ; Mon, 16 Jul 2012 13:26:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=nmE1senMY3i3hpD562lB7FZ0FAB+Y9d/u6YNHTK4EJU=; b=itl5gu3J6VZxdwuusHZdV5HomDNsIvJ0JBO58OrKntpXbK8jckY5/mAFRw09B7S6t1 1TZkmXVymhDNyW668592gXWG+c+LA1K9HXw1/q9uwdlJ2rr5dcazf9udA7GxkvPwVgzj ziJO5G+sXVH5ebu7l5FBGcSEQWJeFqopIWPdTAUJF86QyClMESeSeHtgO/lLkWcR2ykE 6G8ybzGwlGZTYAT3w2G/pxoTH1F5N5bXpHSXVDgHxe18DjqYxyF8P7YCn7C8Z+cF0oc0 EUzC1ml7H4GbTya/BdvC3fuuktgrR+h22Bv8G4sASyHyzdBczmz3NxlJzwu2J+Q9b1Q4 cTtA== Received: by 10.66.90.67 with SMTP id bu3mr25208613pab.47.1342470383073; Mon, 16 Jul 2012 13:26:23 -0700 (PDT) Received: from [192.168.1.73] (99-113-68-43.lightspeed.frokca.sbcglobal.net. [99.113.68.43]) by mx.google.com with ESMTPS id qr3sm2303663pbc.69.2012.07.16.13.26.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jul 2012 13:26:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Ted Krovetz In-Reply-To: <20120716201641.16081.681.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 13:26:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <21FF2C2E-873A-4EC8-BBDA-453225865776@krovetz.net> References: <20120716201641.16081.681.idtracker@ietfa.amsl.com> To: cfrg@irtf.org X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnS5uSPYIat+xzwdxAPsJzZJvjQEDAF23V6numFugXh4qOjKRYZWd1jwh5C5nyMyA7iOGZ+ Subject: [Cfrg] New Version Notification for draft-krovetz-ocb-04.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: Mon, 16 Jul 2012 20:25:39 -0000 The OCB Internet-Draft was about to expire, so I resubmitted it to the = IETF. There are no significant changes. The draft will soon be submitted to the IETF with a request that it be = made an RFC. If there are any last comments before this process begins, = please let me know. Thank you, Ted Krovetz On Jul 16, 2012, at 1:16 PM, internet-drafts@ietf.org wrote: >=20 > A new version of I-D, draft-krovetz-ocb-04.txt > has been successfully submitted by Ted Krovetz and posted to the > IETF repository. >=20 > Filename: draft-krovetz-ocb > Revision: 04 > Title: The OCB Authenticated-Encryption Algorithm > Creation date: 2012-07-16 > WG ID: Individual Submission > Number of pages: 17 > URL: = http://www.ietf.org/internet-drafts/draft-krovetz-ocb-04.txt > Status: http://datatracker.ietf.org/doc/draft-krovetz-ocb > Htmlized: http://tools.ietf.org/html/draft-krovetz-ocb-04 > Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-krovetz-ocb-04 >=20 > Abstract: > This document specifies OCB, a shared-key blockcipher-based > encryption scheme that provides privacy and authenticity for > plaintexts and authenticity for associated data. >=20 >=20 >=20 >=20 > The IETF Secretariat