Re: [COSE] Authentication tag

Samuel Erdtman <samuel@erdtman.se> Sat, 18 March 2017 20:08 UTC

Return-Path: <samuel@erdtman.se>
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 512F012709D for <cose@ietfa.amsl.com>; Sat, 18 Mar 2017 13:08:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAE92KPIQCUL for <cose@ietfa.amsl.com>; Sat, 18 Mar 2017 13:08:10 -0700 (PDT)
Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E575129434 for <cose@ietf.org>; Sat, 18 Mar 2017 13:08:10 -0700 (PDT)
Received: by mail-ot0-x233.google.com with SMTP id x37so113946714ota.2 for <cose@ietf.org>; Sat, 18 Mar 2017 13:08:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PtZO2ZLw8k49ORWq3v1ZArLENfjsZV1cuUZ+wmjvXCM=; b=fSfAkLPm54C3RnitsYWt2JxUTUaA3WM+oOw/FLz2aObXxzXX7FXpQcgVXebNQrmTEz W2uASKgFSccxLtjp0VyuxDMN9sSvdxjFjV4CAAOfTbfKq9wwn33Vk4re6/8vdzEujxNw cUaQeURG258p+UFmfsx7Y1w9W2qzkg84brnOwggfBSgI0iKQjG6Hu/aZOSqw+JUMKaJC yiNB8ifOYkmcXegEcG3hNM5hfmSjzSlYyWl5Fvne4mAwDwW+iRvhRevdgDRhVAC2TjDQ ZmVmxhdZVoBpKHxFSYk7D/kDKxIt4vnBYwZ6XhowpboA9ZML6nzd3DYGbXXhJdNw4W6N jmlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PtZO2ZLw8k49ORWq3v1ZArLENfjsZV1cuUZ+wmjvXCM=; b=ngcBx1URP2Gxxoolqz3qvA5JUO/hCMsfwzKq5JfsPozurq+zAzyXBwTfNkWlr6f03v XsNM4eRb3oxiGAoPVxOTLT8lvIjzOZqESj3acMLU8l1bLo4AlBoun9Y8wKDkOpZXn/zZ F4D7JwSDsZuxFcsdN7DsKRQB5XL4PW1dk9ERuJFQSFxjnYcf4izgf645ZLJdgkufCiLQ cJDB1djEuWShgf12+vAYoE+6F8WT8Hrdwmy9XRneF3sTt/dYdO/HyNFAHCa3/OQX+FJr DMucW8bh1ZhmJR13P97RwROvolX0t9iBVJbGE3QSx2WrIGElLWhX/sg2vHCN/jq5bkgV X5tA==
X-Gm-Message-State: AFeK/H1cD6b9+Xr21AMW2Aek6MBKoytwk3cjvYtJ5A/GFeF9RB0n/qmcDzlAO58KUDp3I8H4y6L0p7qZ2U9LWQ==
X-Received: by 10.157.66.14 with SMTP id q14mr10409014ote.210.1489867689707; Sat, 18 Mar 2017 13:08:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.125.40 with HTTP; Sat, 18 Mar 2017 13:08:09 -0700 (PDT)
In-Reply-To: <00f701d29f43$c278fd60$476af820$@augustcellars.com>
References: <CAF2hCbYALonNaZ6BrmEhYosCrNsJqLmHs3YMupjOCeRxav2X9A@mail.gmail.com> <00f701d29f43$c278fd60$476af820$@augustcellars.com>
From: Samuel Erdtman <samuel@erdtman.se>
Date: Sat, 18 Mar 2017 21:08:09 +0100
Message-ID: <CAF2hCbbsEm7YNpPmQj_e2b-zfKyZ9B9E1BjLUPyZjbd44jtcNw@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>, ilariliusvaara@welho.com
Cc: cose <cose@ietf.org>
Content-Type: multipart/alternative; boundary="f4030437951c686245054b06da90"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/X871u1sEiAzzj0qsFBEJ-eoSqu8>
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 20:08:13 -0000

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> 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]
> *Sent:* Friday, March 17, 2017 9:50 AM
> *To:* cose <cose@ietf.org>; Jim Schaad <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
>
>
>