Re: [COSE] Authentication tag

Justin Richer <jricher@mit.edu> Mon, 20 March 2017 20:10 UTC

Return-Path: <jricher@mit.edu>
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 8285C12762F for <cose@ietfa.amsl.com>; Mon, 20 Mar 2017 13:10:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SamIc24Gjp9 for <cose@ietfa.amsl.com>; Mon, 20 Mar 2017 13:10:01 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178EF1274D2 for <cose@ietf.org>; Mon, 20 Mar 2017 13:10:00 -0700 (PDT)
X-AuditID: 1209190d-5ffff70000001c9e-0f-58d037164e64
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 27.31.07326.61730D85; Mon, 20 Mar 2017 16:09:59 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v2KK9wil029615; Mon, 20 Mar 2017 16:09:58 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v2KK9sEn005856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Mar 2017 16:09:56 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <44DF8A98-2191-4E9F-811F-E000D7FB7092@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_54D4904F-DDB1-4C7C-AA1F-9AEA4A849024"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Mon, 20 Mar 2017 16:09:54 -0400
In-Reply-To: <CAF2hCbboTj+v9GgVxeP+r2aRjwDT3qhyjTuVHBO-f2MeK-Zqbw@mail.gmail.com>
Cc: Jim Schaad <ietf@augustcellars.com>, cose <cose@ietf.org>
To: Samuel Erdtman <samuel@erdtman.se>
References: <CAF2hCbYALonNaZ6BrmEhYosCrNsJqLmHs3YMupjOCeRxav2X9A@mail.gmail.com> <00f701d29f43$c278fd60$476af820$@augustcellars.com> <CAF2hCbbsEm7YNpPmQj_e2b-zfKyZ9B9E1BjLUPyZjbd44jtcNw@mail.gmail.com> <016501d2a02b$ecd2edd0$c678c970$@augustcellars.com> <CAF2hCbZB_QtDHWexdzWWzhe4iWfF38JMBJf6CLwnPtL_KuESCA@mail.gmail.com> <CAF2hCbboTj+v9GgVxeP+r2aRjwDT3qhyjTuVHBO-f2MeK-Zqbw@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixG6nritufiHC4PhWK4tpW6eyWqye/p3N 4v/SU0wOzB4b50xn83jxbw+jx5IlP5kCmKO4bFJSczLLUov07RK4Mi43bGcpWDmFsaLj8gK2 BsY9jYxdjJwcEgImEi/Xz2MFsYUE2pgkXt127GLkArI3MkocWz+HEcJ5yCSx5cgCsCo2AVWJ 6WtamEBsXgEriYbJF8BsZoEkifsNV1gg4voSs89cArOFBdQkDrQfAdvGAtTb3fWPGcTmFAiU mPPjGDNEr63EhB8fwWwRoPq7Bx+xQiyeyCzx7fsbNohTZSXe/lrCPIGRfxaSfbOQ7IOIa0ss W/iaGcLWlNjfvRyLuIZE57eJrAsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGunlZpbopaaU bmIEhTynJO8Oxn93vQ4xCnAwKvHwrrhyPkKINbGsuDL3EKMkB5OSKO/T20AhvqT8lMqMxOKM +KLSnNTiQ4wSHMxKIrwfFS9ECPGmJFZWpRblw6SkOViUxHnFNRojhATSE0tSs1NTC1KLYLIy HBxKEryXTYEaBYtS01Mr0jJzShDSTBycIMN5gIa/A6nhLS5IzC3OTIfIn2JUlBLn3QaSEABJ ZJTmwfWCUlLC28OmrxjFgV4R5l0GUsUDTGdw3a+ABjMBDV524wzI4JJEhJRUA+OSfVXKXPFX tGKVjqs35k7ftP8E+1xWrpeBzZ15a2x07Db3x308rB9pXlrH/knkXYnAW5ODu+UMp6kInmjb G+CSf37Whyj/qwrMPmncf9fVbynLDOI/93n3NL2agrwf5oIndVqM3jw8u2R2Vcr37Q/CbSIl zubaz+vmU1IUCLPaeY3nwpOVNUosxRmJhlrMRcWJAEzzBUYkAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/vT29C21cLWG4mh_ySEZe6PpDoaM>
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: Mon, 20 Mar 2017 20:10:03 -0000

Well you weren’t necessarily *wrong* the first time.

 — Justin, not as chair


> On Mar 20, 2017, at 3:58 PM, Samuel Erdtman <samuel@erdtman.se> wrote:
> 
> *implementers 
> 
> On Mon, Mar 20, 2017 at 8:57 PM, Samuel Erdtman <samuel@erdtman.se <mailto:samuel@erdtman.se>> wrote:
> Thanks again!
> 
> I think this will add some clarity for tormentors.
> 
> //Samuel
> 
> On Sat, Mar 18, 2017 at 10:09 PM, Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com>> wrote:
> 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 <mailto:samuel@erdtman.se>] 
> Sent: Saturday, March 18, 2017 1:08 PM
> To: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com>>; ilariliusvaara@welho.com <mailto:ilariliusvaara@welho.com>
> Cc: cose <cose@ietf.org <mailto: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
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose