Re: [TLS] Authenticating incompatible protocols

Ben Schwartz <> Tue, 14 July 2020 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 405583A09AD for <>; Tue, 14 Jul 2020 15:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D4OjseHAy_OV for <>; Tue, 14 Jul 2020 15:53:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C97A73A09AC for <>; Tue, 14 Jul 2020 15:53:53 -0700 (PDT)
Received: by with SMTP id 17so1542134wmo.1 for <>; Tue, 14 Jul 2020 15:53:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/VrXbUgWZd6sRHoC9CDFQQ4yK6kaIe7p1PMRCT8Z5Dg=; b=LTuyNUG+8h3mSNMuNl3dS0GqROozgjlOPZUnYWmhsjD+Jjyn/7o2LSgGlzPzFF9I6O 1q79lteejH7bThjW6HtkHv07OSMl2d4FzuHIKaUTwj2Fn9PHvHkRVoFoeU0CCjgIsB1b cZV8ha2nYMd7B/V1UbxNQBCFrZwb8+2l/iOqrSza9iE6ak9i8m7/3il9xZpcqvD8hPF1 LsySqf3twdZ0rSocqqUraOLSVYnQthKqsRHqiGQ1jfwUmhIHfbuUa1ke5VqiTZ2SzHqS GpsAf2TJ7KZN4jrIyl6ILZ3ZA4HH5IQzyzaj63GxrIm+peRTSaI7xUsty5tLcMd2mA1O ii0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/VrXbUgWZd6sRHoC9CDFQQ4yK6kaIe7p1PMRCT8Z5Dg=; b=ggB+cjxwKAmwpv8DSJDJXxCGa3zgJctghZtXVY2+LCxaLAJpwBNhsRZ175mtuqGsOF Qf+2KeqEXE7cuj6TB9Y4cjStW6OoDTgxAPW/rx/ToWjNdoaOjNcg+NiJarYE62JBnZcB Em2tNtRAmXH29yQE8N+ShhyQtc6vrCh8ISHMXQIctC/uYGaluO1ESXJeRpPQG4PnNQPe ERzWNMShpk/9TY9gEL+2uJkQlldHsFAt2syvaLhCy2BIsInvNTZZdijo2isJpafNjQF4 VQ093LeQJPN7M8RAps0HlC5G1TzCmy7G74DftYfo5wIUFrDl+kmymeZETE7DzTyj/Nyb K27w==
X-Gm-Message-State: AOAM531jOoe4YDZDxqVBg9NEsRWd5UUH+NsVeo0wv4GTej5eifuyG6S4 kvUTiAeagl58aSx4macS69SzYvIQCdQ20kPoHcrbjJqF
X-Google-Smtp-Source: ABdhPJxyllz3cGIOmEct0sjc+S0tpb7z80BjYpAD+RkmhI4yhHRnP6t0VOvh+Sny3oy0teBmBoAu/X4SeBFJ3hgOm0g=
X-Received: by 2002:a1c:6246:: with SMTP id w67mr5715410wmb.42.1594767231919; Tue, 14 Jul 2020 15:53:51 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 14 Jul 2020 18:53:40 -0400
Message-ID: <>
To: Martin Thomson <>
Cc: "<>" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000006300c305aa6eaecb"
Archived-At: <>
Subject: Re: [TLS] Authenticating incompatible protocols
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Jul 2020 22:53:56 -0000

I am supportive of this draft.  I don't think it's needed now, but
eventually I would like to live in a world where we don't have to tolerate
these kinds of downgrades, and I don't think it's too early to be drawing
up the mechanism to prevent them.

For ease of deployment, I wonder whether the concept of a "scope" needs to
be pinned down a bit more precisely.  In 00 here, the scope is entirely
implicit; servers are required to know how users might have found them, and
what other servers they also might have found at the same time.  That seems
like it could be a management headache, especially if clients reach your
server in more than one way.  Could the scope be made more explicit
instead? For example, it might be helpful if the server could say "this IP
(and port number?) can also do FOO and BAR, and the whole SVCB pool can do
FOO (but I don't know if they can all do BAR)".

On Mon, Jul 13, 2020 at 9:22 PM Martin Thomson <> wrote:

> 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:
> 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