[DNSOP] Fwd: [TLS] Authenticating incompatible protocols
Martin Thomson <mt@lowentropy.net> Tue, 14 July 2020 02:07 UTC
Return-Path: <mt@lowentropy.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF043A0E67 for <dnsop@ietfa.amsl.com>; Mon, 13 Jul 2020 19:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=OiaMXfX5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qGIHnicU
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 eM-aLPRfpBO8 for <dnsop@ietfa.amsl.com>; Mon, 13 Jul 2020 19:07:27 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2463A0E3F for <dnsop@ietf.org>; Mon, 13 Jul 2020 19:07:27 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6CCBE5C0117 for <dnsop@ietf.org>; Mon, 13 Jul 2020 22:07:25 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 13 Jul 2020 22:07:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=eZnUI7wYnTBKnBNLh9DTvesvHllwyfktD9LvLuFHmB8=; b=OiaMXfX5 pEetTz8Ue63BMJ1K/QqF8DikRusaXKfKHyCaBHK06cgTCF5uLWoPUr9sVhlKRSy1 +1hCcv2BO7OlkuzVGdmxLnW205hROGgqksJLUkzT0ZOMAfJFY+TmQ/CpL43cH/UR m8oXOGtkcxk7LGSViqi6UejN0KlPwspt4EUEyJU2+a6TMUERTD4cKGFM36PuiLa0 9YJd+RxdVYehp/qx1OVceRR3xD43AapSy1ua4t3dWVty5H3dfMB3I0P6vuESjchU lAGUaeXDIdFalrFoTgTtzG0EuigfFrFoDNIhKRtOcEo6ttGjEAX3u0/J+aXJwiaP SRFKpKF6CbSu2g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=eZnUI7wYnTBKnBNLh9DTvesvHllwy fktD9LvLuFHmB8=; b=qGIHnicU8zyIYSq6hee6d8Q4GOhzDvpEeFaq+W6wQ7vVC Ddy+1lRIWXF+MCCjAXCsK8wYMFkvhNhPlRdpXk3EvnPiCPMYmeLTX9vS+HGH0jJ4 XQPa4d+bd+6fY5aUUEWiPyi05ZCb5oHQaOYTnXSKaRrC6FPkv/zoHVwrdew6IGml /mbSu8wDqvPOEhj50o7KiEPLFF03m4X+vWGRo+tbcIHJngCg41yUopSxDLvARJqk Vy+epOY4XGt0snV4fJVMVxfgbODK9+8URrIm2MmHdgXOaPzsS1d7VzyokYThH1EB lTk5zwvw+61YlOOwS9DNeOituxqqS0284NruXwiyw==
X-ME-Sender: <xms:XRMNX_2KGmDp_GLk1qtzYoj1wHn9tkM5TAdrsDitaD80vD_jyRRbug>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdelgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenuc fjughrpefofgggkfffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhhtihhn ucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtffrrg htthgvrhhnpeffgeegfeeutdegleehgfdtieffieefteevheelieeliedtgeeuleevuedt teduvdenucffohhmrghinhepihgvthhfrdhorhhgpdhgihhthhhusgdrihhonecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghn thhrohhphidrnhgvth
X-ME-Proxy: <xmx:XRMNX-GXXpOpJ_kIBLHVJ8tEz-WZ4EA85K3yJklTvwIdApf0V_wo4w> <xmx:XRMNX_4oh9TVQjF_0RLbDGK0R3JDS3MtWwNaixiucEziG93kfgFr4Q> <xmx:XRMNX00UbD_Dn6Vvk4TSl2hOlVWLnV-rxof7CaAYADwKnkykF6Aetw> <xmx:XRMNX-GWHqUN2GBZtyJwXzLJDhhv9ZI7sugfUkQQS20ESEXaYFeGiw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id F2FA6E00CE; Mon, 13 Jul 2020 22:07:24 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e
Mime-Version: 1.0
x-forwarded-message-id: <60bc7458-c054-4715-aba2-8c4c9393f74d@www.fastmail.com>
Message-Id: <8f4cf639-0f2d-4117-a59d-3a488bbc7284@www.fastmail.com>
Date: Tue, 14 Jul 2020 12:07:06 +1000
From: Martin Thomson <mt@lowentropy.net>
To: dnsop@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6Gs3w7Q_jfXFGyyziWsLjswMXMs>
Subject: [DNSOP] Fwd: [TLS] Authenticating incompatible protocols
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2020 02:07:29 -0000
FYI, in particular for those who are following the SVCB work. The lack of authentication for the results of SVCB discovery were a concern for me. I am not entirely comfortable with the idea that we are shipping a protocol without any real protection against downgrade attack. So I wrote up a rough draft. My initial thinking was that this was general enough that TLS is the right venue, but I can also see reasons for having some discussion here. ----- Original message ----- From: Martin Thomson <mt@lowentropy.net> To: tls@ietf.org Subject: [TLS] Authenticating incompatible protocols Date: Tuesday, July 14, 2020 11:21 The work in DNSOP on the SVCB record raised a few awkward questions about the potential for downgrade attacks. Where protocols aren't compatible -- that is, A is not compatible with B if you can't attempt A and negotiate B -- you don't get downgrade protection. ALPN only really protects against downgrades with compatible protocols. With QUIC, and increasing diversity of protocol usage across TLS and DTLS, there are more opportunities for incompatible protocols to be used. I've done a quick writeup of something that might work: https://datatracker.ietf.org/doc/draft-thomson-tls-snip/ https://martinthomson.github.io/snip/draft-thomson-tls-snip.html Thoughts would be appreciated. As a footnote: this makes some assumptions about the way that ALPN is used. That is, this relies on the same ALPN not being used in incompatible protocols. The ALPN registry already lists one counterexample in stun.turn [RFC7443] which can be used over both DTLS and TLS. I personally think that was a mistake, but I know that others disagree. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- [DNSOP] Fwd: [TLS] Authenticating incompatible pr… Martin Thomson