Re: [TLS] Choice of Additional Data Computation

chris - <chrispatton@gmail.com> Fri, 24 April 2020 15:57 UTC

Return-Path: <chrispatton@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0993A0A22 for <tls@ietfa.amsl.com>; Fri, 24 Apr 2020 08:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3xXsEXidBq-u for <tls@ietfa.amsl.com>; Fri, 24 Apr 2020 08:57:11 -0700 (PDT)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 714A03A0DF8 for <tls@ietf.org>; Fri, 24 Apr 2020 08:57:06 -0700 (PDT)
Received: by mail-ot1-x32b.google.com with SMTP id e26so13224157otr.2 for <tls@ietf.org>; Fri, 24 Apr 2020 08:57:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=urjY7VHsv9QYCLvY61L9Oka0E3d3b0NrWrqzwOETjCM=; b=qqaEficYRI367U5wS17eHdVg65Vmj49KB+7PNp8PUSVWn+UCu+jJN7WDpAtI7Lypgx dMJiN+IjacoC8glDkMkprDZuRHEMGzyqoga9XaXrd3UQHyQF1EpCUgOUzOxppPUaiLSB DtRM4BYAKovg/t+n1DH2bV0WXg1uYQBAanz6FdapuJ4/A7mUAcxulTBTIkMeg9JBVA63 6OsupeHIBgWY5L8g5dsVviQJrAIJHvLLEDkd8J/UTYrrmWUtdqx80YiRLlsyS7GOKKuQ yd4mFeSIlQyuEN25dgdSXuo3XUeVWuz56Gp4IddQlrjAk22uzdLw+eU5WXMy9N+qXP0X rIXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=urjY7VHsv9QYCLvY61L9Oka0E3d3b0NrWrqzwOETjCM=; b=KCH2zoURt8e5fRE6OP+J7cSIOtjqqAI+X2iZ+zBVIrpSL2IaAtgG27DT8vi3fKLIPU UI7OQus22D0wgImEtGU2cbpDZ55UoqkskkyOKNTafdpjs0LdJnart/Yads7a9qXaq88/ kA25Qj1hErqHcaL73wTYUfD1KavFqfemq0Utq5Iv953stKWv7LBQOd4Op0YGjcGntE0O H6Z4BjirMHhn0kUjqKSXKW3HRlPDFZMD8rpmDJSdlcVr3PZ1WQacHGZx4Q516K1TENPD EVtUMPqU0apr60k39L37ZzXRPznZErk7bEJC2vP4u1pTC+agaufRhv7sPK1D1MaG0kRl Pdjw==
X-Gm-Message-State: AGi0PuZTp+Z1dSHT8id1yh5N/FyGvW/RsqQJzkG0EknuIe2Xbt8xH81x Q+6l+FwXNyfWe0EGc4IOZROLe7dmH92MH3pPPpw=
X-Google-Smtp-Source: APiQypIeZzG9DPanYwSPdyw213Pu7yjQwzMZT/dCebqkyQ/PUaTpQvQG6/2/5JPPD8B7wLLbeLvBKxzMk3wG9WmE6B8=
X-Received: by 2002:aca:57d6:: with SMTP id l205mr7304295oib.20.1587743825638; Fri, 24 Apr 2020 08:57:05 -0700 (PDT)
MIME-Version: 1.0
References: <AM0PR08MB371694E826FA10D25F2BA53EFAD00@AM0PR08MB3716.eurprd08.prod.outlook.com> <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> <AM0PR08MB3716541F4825F8D43DC3D308FAD00@AM0PR08MB3716.eurprd08.prod.outlook.com>
In-Reply-To: <AM0PR08MB3716541F4825F8D43DC3D308FAD00@AM0PR08MB3716.eurprd08.prod.outlook.com>
From: chris - <chrispatton@gmail.com>
Date: Fri, 24 Apr 2020 11:56:54 -0400
Message-ID: <CACLV2m4-Qcx-xKWP201VCY73HVyjCzHVCb6PrntnBWhA8fBQYg@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Achim Kraus <achimkraus@gmx.net>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b8bb5205a40b6a20"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TNHy4EGBYhrnrgzdWN0rSk-HOKM>
Subject: Re: [TLS] Choice of Additional Data Computation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2020 15:57:13 -0000

Hi all,


>  1. Generic question: Should the construction of the additional data be
>     dependent on what is transmitted over the wire or should it be based
>     on a "pseudo header"? DTLS 1.2 uses a pseudo header and DTLS 1.3 the
>     data transmitted over the wire in the additional data calculation.

I'd like to point to some related work that could shed light on this
question. The decision for TLS 1.3 was to authenticate all data that is
written to the wire, as this allows for proving the record layer secure [1]
in a strong model for secure channels [2]. However, the formal models of
[1,2] assume reliable transport (i.e., TCP): failure to deliver packets in
order is deemed an attack. Therefore, the definitions would need to be
changed in order to account for the case of DTLS. (I'm not sure if this has
been studied.) My hunch is that the same design pattern (i.e.,
"authenticate everything on the wire") would be called for, but I've not
seen formal evidence either way.


>  2. Specific question: Should the CID be included in the additional data
>     calculation, particularly for the case where it is only implicitly
>     sent? Asked differently, are there attacks possible?

Unfortunately I'm unfamiliar with the specific problem at hand, as I've not
been following DTLS' development. (I'm in the middle of writing my thesis.)
That said, I don't see a problem with having the AAD include *both* the
record heard  *and*  something else, like the CID. And it may very well
prevent an attack.


Chris P.

[1] https://eprint.iacr.org/2018/634.pdf
[2] https://eprint.iacr.org/2017/1191.pdf