Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt

Martin Thomson <mt@lowentropy.net> Fri, 27 May 2022 06:21 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0045C15791C for <uta@ietfa.amsl.com>; Thu, 26 May 2022 23:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.1
X-Spam-Level:
X-Spam-Status: No, score=-7.1 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, RCVD_IN_DNSWL_HI=-5, 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=lowentropy.net header.b=lT6x7Bm1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qLrmwF8B
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 ul5aLw1EZ2hd for <uta@ietfa.amsl.com>; Thu, 26 May 2022 23:21:54 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164D4C157901 for <uta@ietf.org>; Thu, 26 May 2022 23:21:53 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 0F78B5C00D8; Fri, 27 May 2022 02:21:53 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Fri, 27 May 2022 02:21:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1653632513; x= 1653718913; bh=lOXNTaOcvFJ7YQXD1jFf+Hz/fy6d+itS9dazmGb3KzU=; b=l T6x7Bm1a7coxQX+n+5kthGpSTUlIjHouQAa3YKLonAd59o0iOfm7WWDF9Lla/s4b P9SF+oYtjPZVWCaPFu+PjdGLNBtQQT8inrmDWOWRT7RZ7JtWjH/r26893aeJoahV 8cMbw5sla+zz/c/1qP/60W9rOjLXRW/gzfQZaa+U89UTms+ZbTci8VCayP4sAZPp 29LqI7LacY/xw93AvkbsY9mxCl1SbJgZa5TQp3rfzt2Yf6vrNJ06vREmApNpt1NK emHpgbQy3Qp6NsST28SQ2+HpgtZJ8gjQ1dEbQbkJLXsBTJxglJUOVnBjei3LdfKG yl0t3zLFmpOF3IqIp63OQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1653632513; x=1653718913; bh=l OXNTaOcvFJ7YQXD1jFf+Hz/fy6d+itS9dazmGb3KzU=; b=qLrmwF8BT90j4C7qx 24fIa23eQP0D5rDkQfwedt2sZ2gtZOBp0S+QAPX4ve4ftOALEarqHK8+8k+29Zh0 i/8hzf5QRMTS8IYwRhFXsS+0LUNk+v8RLL8Faspr48g6HFpve2r0sl9X2qtJ0s8M U5lrFG1+Q0lYR+FpmkEh1/rSaJkSFpjAYriGhZ4Vy4Ce71mZgy/Z4Fas8nliRlWx 5nsZdGxRlW5MdLdmXVNLPiC5NCjmWeR5Xrhtk75A/8cllgtMLDMLF1Vu44q2eXqT Y+rQipFhkxqGK9ETQX6O0Tz3zL9sIB/Fo0xJZRDuvI3ZuKyXqtWXYbN2iUx2iRkf DbiQw==
X-ME-Sender: <xms:AG6QYk6s6UHxZ7YMBnlVN2qbCew-eY1Owq-N88zUtKaE8a_E1qZBnw> <xme:AG6QYl6NKsW0ugNJJe3LYvjL2VH_W7k8INP3FxmF3EMYvcXNeQzV09doE3JIJFd0Q X09gKmq7JkJfESzwio>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrjeekgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepheehvdfhheevgfegje dtgeejudevteeljedvkeejjefhkeeikeduleffvddufeffnecuffhomhgrihhnpehgihht hhhusgdrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:AG6QYjf9KPy5X8bIu8YC4KEUJrxBmCxO26o0mM0KVTJLYpnUn_0GhQ> <xmx:AG6QYpKmipYtB_-f-KQ609Swut44qBUG_mTQE7mTpe-stjSo3WaivQ> <xmx:AG6QYoLcixGlfSSdQdjaQhmqn6DLP-6ktDH_oBuVoqdC84wzMlpRFg> <xmx:AW6QYvnNoxgVhFLvWw8ytadcz6s-rCqlA6kp1Me-ZxvT430rXKr7mg>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C7EF52340076; Fri, 27 May 2022 02:21:52 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27
Mime-Version: 1.0
Message-Id: <02b1cdfa-02f2-43cd-8066-fb36f9e30164@beta.fastmail.com>
In-Reply-To: <CC2019E7-BD6A-4F65-A59F-42B9E79468B0@gmail.com>
References: <165360014937.7348.791812490092301727@ietfa.amsl.com> <CC2019E7-BD6A-4F65-A59F-42B9E79468B0@gmail.com>
Date: Fri, 27 May 2022 16:21:32 +1000
From: Martin Thomson <mt@lowentropy.net>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, uta@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/7FRisi71XDHH99kIA5iw_C4v_iQ>
Subject: Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 May 2022 06:21:59 -0000

I made some comments in discussion of 6125bis that I think this document should address.

Basically, the document would benefit from a discussion on multi-server deployments in a few arrangements:

* deployments where multiple servers speak for the same names, but with different protocols.  ALPACA showed us that cross-protocol confusion, particularly for protocols that do not define the use of ALPN, can be exploited by directing protocols toward endpoints that use different protocols

* deployments where multiple servers and services with overlapping names that have different TLS configurations.  DROWN showed us that the security of these servers depends on the *weakest* server configuration.  If the weak instance can be attacked, that affects all services that share the same name.  This depends a little on the nature of the attack. An attack like this can render ALPN protections useless.

See also https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/43

On Fri, May 27, 2022, at 07:26, Yaron Sheffer wrote:
> This version addresses numerous comments, mostly (but not always) 
> editorial, by Francesca and Paul W.
>
> As a reminder, the document is in IETF LC until May 30.
>
> Thanks,
> 	Yaron
>
>
> On 5/27/22, 00:22, "uta-bounces@ietf.org on behalf of 
> internet-drafts@ietf.org" <uta-bounces@ietf.org on behalf of 
> internet-drafts@ietf.org> wrote:
>
>
>     A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>     This draft is a work item of the Using TLS in Applications WG of 
> the IETF.
>
>             Title           : Recommendations for Secure Use of 
> Transport Layer Security (TLS) and Datagram Transport Layer Security 
> (DTLS)
>             Authors         : Yaron Sheffer
>                               Peter Saint-Andre
>                               Thomas Fossati
>     	Filename        : draft-ietf-uta-rfc7525bis-07.txt
>     	Pages           : 39
>     	Date            : 2022-05-26
>
>     Abstract:
>        Transport Layer Security (TLS) and Datagram Transport Layer Security
>        (DTLS) are widely used to protect data exchanged over application
>        protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the
>        years, the industry has witnessed several serious attacks on TLS and
>        DTLS, including attacks on the most commonly used cipher suites and
>        their modes of operation.  This document provides the latest
>        recommendations for ensuring the security of deployed services that
>        use TLS and DTLS.  These recommendations are applicable to the
>        majority of use cases.
>
>        An earlier version of this document was published as RFC 7525 when
>        the industry was in the midst of its transition to TLS 1.2.  Years
>        later this transition is largely complete and TLS 1.3 is widely
>        available.  This document updates the guidance given the new
>        environment and obsoletes RFC 7525.  In addition, the document
>        updates RFC 5288 and RFC 6066 in view of recent attacks.
>
>
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/
>
>     There is also an HTML version available at:
>     https://www.ietf.org/archive/id/draft-ietf-uta-rfc7525bis-07.html
>
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-rfc7525bis-07
>
>
>     Internet-Drafts are also available by rsync at 
> rsync.ietf.org::internet-drafts
>
>
>     _______________________________________________
>     Uta mailing list
>     Uta@ietf.org
>     https://www.ietf.org/mailman/listinfo/uta
>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta