IETF Logo Mail Archive

[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 20 July 2024 13:24 UTC

Return-Path: <ilariliusvaara@welho.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 29790C14F6A5 for <tls@ietfa.amsl.com>; Sat, 20 Jul 2024 06:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjScpHtwt_Av for <tls@ietfa.amsl.com>; Sat, 20 Jul 2024 06:24:21 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3b.welho.com [83.102.41.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A74BC14F698 for <tls@ietf.org>; Sat, 20 Jul 2024 06:24:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 9B5E014FDD for <tls@ietf.org>; Sat, 20 Jul 2024 16:24:18 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 6SiKRvy6DdZ0 for <tls@ietf.org>; Sat, 20 Jul 2024 16:24:18 +0300 (EEST)
Received: from LK-Perkele-VII2 (78-27-96-203.bb.dnainternet.fi [78.27.96.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 350AC287 for <tls@ietf.org>; Sat, 20 Jul 2024 16:24:17 +0300 (EEST)
Date: Sat, 20 Jul 2024 16:24:16 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "tls@ietf.org" <tls@ietf.org>
Message-ID: <Zpu6gA-yfmehBVND@LK-Perkele-VII2.locald>
References: <CAD2nvsT4qWqudiv1C1wZn6rB4_s-9EDENq5TXEbxr_ygcMFjDQ@mail.gmail.com> <CAChr6Sw+gxK3dO29F9bsLTQReJz6LzT2hZb5O7LAXmKzQbKTSw@mail.gmail.com> <CACf5n7_29CNXLf+SmpKKOWkc_3Oi2BZqZ8irU+z=3btJns_1-Q@mail.gmail.com> <CAChr6SxJ3r88a4Aehv_5fsSWb1JApV6Lg4hfwdm0Oh5x04_shQ@mail.gmail.com> <479BA457-9001-4EBC-A84F-9E3EB71E809F@akamai.com> <CACcvr=kQM4XASQv0jj9Xy3he_E_uqN4MV-_Hy=MndqdALfb5pw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACcvr=kQM4XASQv0jj9Xy3he_E_uqN4MV-_Hy=MndqdALfb5pw@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Message-ID-Hash: TEWBN7VN5TIOLRLFPTLJEF6KANZV3TSG
X-Message-ID-Hash: TEWBN7VN5TIOLRLFPTLJEF6KANZV3TSG
X-MailFrom: ilariliusvaara@welho.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UsLVA9Oermp5-U9q5t2TEjmTcxw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

On Fri, Jul 19, 2024 at 09:11:34PM -0700, Nick Harper wrote:
> On Fri, Jul 19, 2024 at 8:58 PM Salz, Rich <rsalz=
> 40akamai.com@dmarc.ietf.org> wrote:
> 
> > Can we simplify things and solve just one problem?
> >
> 
> >From my perspective, this draft does solve just one problem: how a server
> chooses a certificate to use that it knows the client will trust.
> 
> I had a similar reaction the first time I read the Trust Expressions draft.
> Trust Anchor IDs (
> https://www.ietf.org/archive/id/draft-beck-tls-trust-anchor-ids-00.html) is
> a simpler to understand mechanism that solves the same problem in a
> different way.

I would not say that Trust Anchor IDs is simpler than Trust Expressions.

Trust Anchor IDs introduces things like retries and DNS latency, which
are anything but simple. Or the security considerations.




-Ilari

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