Re: [COSE] Authentication tag

Jim Schaad <ietf@augustcellars.com> Sat, 18 March 2017 21:09 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDA4129444 for <cose@ietfa.amsl.com>; Sat, 18 Mar 2017 14:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_v83KHzfXGA for <cose@ietfa.amsl.com>; Sat, 18 Mar 2017 14:09:33 -0700 (PDT)
Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC53129442 for <cose@ietf.org>; Sat, 18 Mar 2017 14:09:33 -0700 (PDT)
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0166_01D29FF1.40783480"
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1489871372; h=from:subject:to:date:message-id; bh=V5zDegy6KmmyRUhTWfY9IDfsPPpwrYElDI1fvgWHzXE=; b=J9QWX7Fn1fbDLNY8LIcnr7+v5JYschsO2ySjWpeeWNmIZzAs+u7vUvT7yqmK6ZVVimf2wmvyy1r fkDl15LQ/2gQggMQZx8EdrypZ65k9XyrnEsBVpaW8mi0/6dTTtf7tkHMCxJxnvVl9aYiEatPXlhCo 7+fHjyYuY89H0sQzIJVrQhsaH7wgEs67ult0cHcplwXmSWPHw8sDhXgamk0YE3Ypcs3Es83lralHx xj10UQPPJJSyfwI6qI3ZK6hXA8/3woqXi/2wwpctKNMniRRL4pGN5esQkP06SfqGPT3JLG+ol3RyF WmH8pGeRmgowkNgf4W6/gfckokMJLA59GIPg==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 18 Mar 2017 14:09:31 -0700
Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 18 Mar 2017 14:06:56 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Samuel Erdtman' <samuel@erdtman.se>
CC: 'cose' <cose@ietf.org>
References: <CAF2hCbYALonNaZ6BrmEhYosCrNsJqLmHs3YMupjOCeRxav2X9A@mail.gmail.com> <00f701d29f43$c278fd60$476af820$@augustcellars.com> <CAF2hCbbsEm7YNpPmQj_e2b-zfKyZ9B9E1BjLUPyZjbd44jtcNw@mail.gmail.com>
In-Reply-To: <CAF2hCbbsEm7YNpPmQj_e2b-zfKyZ9B9E1BjLUPyZjbd44jtcNw@mail.gmail.com>
Date: Sat, 18 Mar 2017 14:09:23 -0700
Message-ID: <016501d2a02b$ecd2edd0$c678c970$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHJyY/ZCPv2uIyenJalNKBf3teWxAH2xgvQAiEsI4qhi/9SEA==
X-Originating-IP: [173.8.216.38]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/yliwBspfSlj_vYnXeRe-pm7BHEI>
Subject: Re: [COSE] Authentication tag
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Mar 2017 21:09:39 -0000

There are two different schools of thought about where to put the authentication tag.  RFC 5116 was designed so that it is part of the standard set of parameters rather than separate.  Thus, for GCM, it is included as part of the cipher text.  For SIV mode it is the IV and there is no extra authentication tag.

 

Other encodings have made the fields be separate, JOSE and CMS keep the tag and the cipher text as separate items and, for some systems, you then get the opposite world of needed to combined them when doing decryption operation.   The decision of where and how authentication tags are placed is always going to be an encoding decision and not part of the encryption algorithm.

 

The decision was made to combine them for COSE because it saved an additional field, and thus one or more bytes are removed from the encoding.  This followed the guidance of trying for very short encodings.  

 

I have filed an issue to remember this at the next revision.

 

Jim

 

 

 

From: Samuel Erdtman [mailto:samuel@erdtman.se] 
Sent: Saturday, March 18, 2017 1:08 PM
To: Jim Schaad <ietf@augustcellars.com>; ilariliusvaara@welho.com
Cc: cose <cose@ietf.org>
Subject: Re: Authentication tag

 

Thanks Jim and Ilari for the quick replies.

So if I understand it correctly RFC 5116 defines AE and AEAD with the requirement to bundle the tag with the ciphertext, so it would not be allowed to put the tag in the COSE headers.

Section 10 Content Encryption Algorithms, gives a hint of where to find the tag, 'normally' appended. Forgive me my ignorance, but does GCM have a more normative requirement on the location of the tag in a ciphertext?

If GCM does not mandate the location of the tag in the ciphertext and we cannot put it in a header attribute then I would like more explicit language about where to find/put the tag.

Once again thanks for the quick and enlightening reply.

Cheers

//Samuel

 

 

On Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> > wrote:

>From Section 10:

 

COSE restricts the set of legal content encryption algorithms to those that support authentication both of the content and additional data. The encryption process will generate some type of authentication value, but that value may be either explicit or implicit in terms of the algorithm definition. For simplicity sake, the authentication code will normally be defined as being appended to the cipher text stream. The encryption functions are:

 

 

From: Samuel Erdtman [mailto:samuel@erdtman.se <mailto:samuel@erdtman.se> ] 
Sent: Friday, March 17, 2017 9:50 AM
To: cose <cose@ietf.org <mailto:cose@ietf.org> >; Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> >
Subject: Authentication tag

 

Hi 

I´m working on a JavaScript implementation of the COSE msg specification, currently working on the GCM encryption.

In the nodejs crypto environment the authentication tag is set separately i.e. a specific setAuthTag call. I looked into openssl and could see that that was the case there too.

In the examples provided with the COSE specification I could find out that the auth tag is appends to the end of the ciphertext.

I tried to find this described in the COSE specification but could not find it. It might be described in some refereed specification but it was not obvious to me at least.

If it is not to late I would suggest that authentication tag is lifted out from the ciphertext and into the unprotected header similar to IV. Or that it is explicitly described that the authentication tag should be appended to the ciphertext.

Cheers

Samuel Erdtman