IETF Logo Mail Archive

Re: [TLS] Choice of Additional Data Computation

Eric Rescorla <ekr@rtfm.com> Fri, 15 May 2020 20:05 UTC

Return-Path: <ekr@rtfm.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 5DF543A08B5 for <tls@ietfa.amsl.com>; Fri, 15 May 2020 13:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.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 qgcDW-rseHCF for <tls@ietfa.amsl.com>; Fri, 15 May 2020 13:05:15 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 4D8F43A08B3 for <tls@ietf.org>; Fri, 15 May 2020 13:05:15 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id h26so2850988lfg.6 for <tls@ietf.org>; Fri, 15 May 2020 13:05:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jQmcoFEr5R2PpwpUJU3Ql4Hq3T41+xZleLW1XtzesTI=; b=kJIBEHVnYViWYzu3AdoaIO2oAOZfqcuJVZIawPCXHSgiFTYjRsN4qXECID7cIlqkEu b8B916JgNV3g75wxrMVytvSfrQKqjtaNQ3pE2E4i0oy3MwX4mJoIOhHKKVUNm8i6rwl9 2ymKG1TuVhQq57JXBNls+2qd4GJrPYX5MqneYWOwnyJxkq7zwvLYxQ2F12qtpux3MRhH yAT2OLq5kzKxS0Rc9GlkGwR/cUVpFNDAw4C3lWqhizFQWNeKzp0WNCI3ub6cF4VlmMZD cvto8e0C+hcgW631labD13BeiGe90HNU+LWmV453RWJ/i2qtqn0OJpxthHIXNXJqHCSA k4Qg==
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=jQmcoFEr5R2PpwpUJU3Ql4Hq3T41+xZleLW1XtzesTI=; b=JZXB5Z6/SM+DqLbt8Wt0fwRlVXmTPZ3OGKJ0Qjbn7pDGGiF5lbvmPMcohT1kqS4lBd XeuNk/frux+VXmfudDlCau4ojCML8LRv5fSoL4ZzZuyPN5ShHiKjqdOGWySJAmA1m9N3 ykA4PvJuLW4uXJRbrqlBFxIbAZxIFNBb5ss8QCZPx+S0hrNPYLI285pZH0smj0wFz++g XNKJRQY8TBDaJDNEBH1iWeolRgrWQOKMjpfh1wOjbpOsjyerlJQO7oj6JkeNLpefKfd7 QGBFS+XkZTfxIVcZ1goxx+pAFM8ITdHUrHTqc7rBzNGAvvDRLaPdBmF6XD4EHDjzXq0W xjcg==
X-Gm-Message-State: AOAM533GH9jttRegBgRf+ZQXZDr/ZigAoonJiH5Nh/PKAiDvRdgt51VN 30ZSqJzKOY03ecIfz1x7n3bW3MoELmhycrgNCgvtHeOw7A/tNg==
X-Google-Smtp-Source: ABdhPJwUYX+j6KYJ0hh7sJVPdRR/40/V/Ji9UOIjPFqh3MePG+AmESeB6F0Ee5AuYHyxedYktw+ElOQ1JDQDS1WXu3s=
X-Received: by 2002:a19:e213:: with SMTP id z19mr3271840lfg.201.1589573113623; Fri, 15 May 2020 13:05:13 -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> <CACLV2m4-Qcx-xKWP201VCY73HVyjCzHVCb6PrntnBWhA8fBQYg@mail.gmail.com> <a18b8223-ca9e-4a06-97fc-448865023376@www.fastmail.com> <6b074b76-2977-fbc1-99d7-f9acb79466e3@felixguenther.info>
In-Reply-To: <6b074b76-2977-fbc1-99d7-f9acb79466e3@felixguenther.info>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 15 May 2020 13:04:37 -0700
Message-ID: <CABcZeBNzGr+R5BivpyBXRnO8y+Hnr2RTWeyifw9gFZrgG1C8ZQ@mail.gmail.com>
To: Felix Günther <mail@felixguenther.info>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c85b9505a5b554e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_81a_-yDte8-JCaUAQBs-EWhy9E>
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, 15 May 2020 20:05:17 -0000

On Tue, May 5, 2020 at 10:55 AM Felix Günther <mail@felixguenther.info>
wrote:

>   4) I slightly disagree with "epochs determine the key" (true) as, what
> I understand is, an argument that "the full epoch is implicitly
> authenticated by using the right key", at least in its absoluteness. My
> *guess* would be that, due to the key schedule, this argument comes down
> to the probability of keys colliding (which is anyway to be avoided, so
> probably fine). Still, from a security analysis point of view, showing
> security with key updates might be easier if the (full) epoch was
> authenticated as part of the AAD.
>

Actually, the full epoch is included in the overall sequence number and
hence used to generate the nonce.

https://tools.ietf.org/html/draft-ietf-tls-dtls13-37#section-4

Does that help?

-Ekr

v2.35.0 | Report a Bug | By Email | System Status