IETF Logo Mail Archive

Re: [TLS] Choice of Additional Data Computation

chris - <chrispatton@gmail.com> Fri, 24 April 2020 18:51 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 8021B3A081E for <tls@ietfa.amsl.com>; Fri, 24 Apr 2020 11:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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] 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 e7xvcN7RExQ3 for <tls@ietfa.amsl.com>; Fri, 24 Apr 2020 11:51:45 -0700 (PDT)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 982FA3A082B for <tls@ietf.org>; Fri, 24 Apr 2020 11:51:45 -0700 (PDT)
Received: by mail-ot1-x32a.google.com with SMTP id e26so14236487otr.2 for <tls@ietf.org>; Fri, 24 Apr 2020 11:51:45 -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=q6QKV0xr5rMObTKfcRhWbg/7OkBubnv3bTdQ2Ap6Cb0=; b=m5OVxiChtlV+GKsasGXgROZODDMx3lDXzwVGSbE0G5Jj6bBd02JhqyIpq+UuXXLwLz qkncCTf+2Jj3P1DeXb0jl2MSyXsfG3xLiXYhaYLA/BGqXvaOdLW0Ql/fGjuJe7bR5UXA UgWp3EiwXnMK44d4I3ZFyPXn4DvstvTWhQjK45Ht9D5iBAhXtkKl0/8uqN8uxtyj+JZ9 Tn08/RhbMiq+S+ttZqWQRqD/uXNUjQm/8Wed/micG/cjd++h98VJrWILBLLpawvHkSfC y0JXU+jtovYUMaQhV8QK4mk3iBbD1/5wa15BhAjIv+UeksIJ1ib643hU7C+QRqZUwS3C GAZw==
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=q6QKV0xr5rMObTKfcRhWbg/7OkBubnv3bTdQ2Ap6Cb0=; b=K0vDRg83+kKWTpgoq3Vk33cgrFl1vmzR3jDqf8CSv0g435pbJ9doo6utBbOQOoNfcf 8tHbMT7d1RoKkgtDHe/8d183T4xqLuOouC2Vpjx5C+ZVeRtxmRv+sadwWs4/yOnh9mIm TnqIx5Wt7hHBnne67/Mgi6aZvKS7rqtLvQt9oZ3NlwfERcyFoaGfAfa2u55EkrSGgylX fMF+TDAwzoDW0O1MTKkKnBkUGLx3Jwe81b1Z1gRbPfQ34y7EM5QC425jyEcao8IFYaUN RnsGwrMJl2vekwh+UoBqqNLC0cJas+27YJgAVygncTBWZe+FrXhoAywyeOdJlrTxBvxa gHkA==
X-Gm-Message-State: AGi0PuaYB2B8bKET8PenSmtbUly1pcwEmFW0dBk9SZzjXecYqp/EatcG q5dEYJ/L0wYiBLn0YqGH08YCKN+GyszGumJbgLQ=
X-Google-Smtp-Source: APiQypLqocjNYZWYttTyDvjDqbxNYK/7c6XJJcfeHtdrTJIDtLJNGSf9n0/HhRcsCMdaLp3Yisv8znDssLVm6nNKwxQ=
X-Received: by 2002:a9d:1eaa:: with SMTP id n39mr9307275otn.238.1587754304809; Fri, 24 Apr 2020 11:51:44 -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> <AM6PR08MB3318B6ABD411C8C476C3D10B9BD00@AM6PR08MB3318.eurprd08.prod.outlook.com> <CABcZeBOwK7m465LsbY3U+bHv0XA2rcGOTEBStTtTNkwAYvWeQA@mail.gmail.com> <CACLV2m5Md2+Ffc978ZJ+BeZwRgcXTV3xE0vXzmvNgnot_c71xQ@mail.gmail.com> <AM6PR08MB331862B6F143652F4B4C10EE9BD00@AM6PR08MB3318.eurprd08.prod.outlook.com> <CABcZeBMKoVrcN-=aTvy6py5bhOwOVrhgVLmtX2tthc=Oa54b_Q@mail.gmail.com>
In-Reply-To: <CABcZeBMKoVrcN-=aTvy6py5bhOwOVrhgVLmtX2tthc=Oa54b_Q@mail.gmail.com>
From: chris - <chrispatton@gmail.com>
Date: Fri, 24 Apr 2020 14:51:33 -0400
Message-ID: <CACLV2m7knyt-gQoQq2v1Kz-J62DPjCpb6faJFfDgJ-8mprHwxQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Hanno Becker <Hanno.Becker@arm.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000054325205a40ddb43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/j4nf2g2obsZlxYbfzaJXjvoQ52k>
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 18:51:57 -0000

> I don't think that's at all obvious. Again, the problem with the
> pseudo-header is you are authenticating some abstract information, *not*
> what is actually on the wire, and that allows the attacker to manipulate
> what's on the wire undetected. We have no analysis for the impact of that.
>

Yes, this is the way I see it. I think you can get by with implicitly
authenticating things, but when you start doing this, the details of how to
decode the data on the wire begin to really matter for the proof (and
potentially for an attacker). This can get complicated if, as you say, the
header's content is highly variable. So, I would recommend authenticating
what's on the wire. I don't think it would hurt to authenticate more than
this, e.g., other fields that the sender and receiver need to agree on.

Chris P.

v2.23.0 | Report a Bug | By Email