IETF Logo Mail Archive

Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-kitten-tls-channel-bindings-for-tls13-09.txt> (Channel Bindings for TLS 1.3) to Proposed Standard

Simon Josefsson <simon@josefsson.org> Mon, 08 November 2021 22:48 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03213A0DC4; Mon, 8 Nov 2021 14:48:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=josefsson.org header.b=iDmrsiae; dkim=pass (2736-bit key) header.d=josefsson.org header.b=v7Per6/F
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 Ho5-mdbmS243; Mon, 8 Nov 2021 14:48:09 -0800 (PST)
Received: from uggla.sjd.se (uggla.sjd.se [IPv6:2001:9b1:8633::107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76423A0D3F; Mon, 8 Nov 2021 14:48:08 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed2110; h=Content-Type:MIME-Version:Message-ID:In-Reply-To :Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description; bh=1HNxkVstp/EPcxNtQv3huDYrNfil/+7BTNgq5OVCLm8=; t=1636411689; x=1637621289; b=iDmrsiaemT9fpSMQlBs/LKXsMt36UT/15qIP7KSsABaIIjNcFwfXq8MjqyFHaTjDCMvjsRWgPlC 92K+5/ScaBA==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa2110; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=1HNxkVstp/EPcxNtQv3huDYrNfil/+7BTNgq5OVCLm8=; t=1636411689; x=1637621289; b=v7Per6/Fex9Ub5segQoIqerK8wUy3uwf06QI6nD5pGa5tKrKP7qUZc2rSBE1EqHDDcl5I6ucWGj yG29g9SojxupJrEnK4FC+IcgVlrbxcm3cU4EMYTKGEY3Xax4is5DLnrCiVD245a13n7dMb8cDWEBs xsM05fFypI0ECS/gHKFfhwKJKZv+5pw4ucZpOh1uB4d2tc5bp1deuqsBbFlb9rNxMsDJPc+nn8HYb rOV7cKRSe20CwE8A8R/J9GidxiKqk6oChuLpdD7ZlvW1sFwtDlgIVai/KeT8qwom2Kv182KRX5MQl NopaMcm4ZHd3xeV3KwxhvAKk0d2w8KLHH1yfRnln/DYtAqGn9GXxgjX/wURCtuifmhOHva/Z4wo45 rs5DTPOjILzYli/g/a8uzBhHRkj5swmNuc4Oj0LRy0FU2kDq8QIA3cD6wNCvcCk9g8NuZr22z;
Received: from [2001:9b1:41ac:ff00:50fc:c7e5:7e78:6f99] (port=43334 helo=latte) by uggla.sjd.se with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <simon@josefsson.org>) id 1mkDQp-00FDVY-U5; Mon, 08 Nov 2021 23:48:03 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Cc: "Ruslan N. Marchenko" <rufferson@gmail.com>, KITTEN Working Group <kitten@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
References: <163311243544.13917.11736165165419008870@ietfa.amsl.com> <20211001190002.GC98042@kduck.mit.edu> <CABcZeBPQG82xJdwMrmj4-=9aJymo1xts=D6VZedBW5X9k+34cQ@mail.gmail.com> <92ed26c1-bfde-43c1-93f4-2bbdbd4f6ec1@www.fastmail.com> <CAChr6Sw6Rs42DfS8KgD3qasPcWM_gGZhWN5C4b7W7JsPy0wDzw@mail.gmail.com> <8796f867-12b8-41f8-b124-82b3ab0e2d32@www.fastmail.com> <CAChr6SyKAnBcE9t68coGGXFt9WPLuDuWtVKoCXrK+QrwAVtPXw@mail.gmail.com> <f1bcd676-13ad-49b3-a8e8-8a272e0124e3@www.fastmail.com> <CABcZeBNo0gKjNZOKPYJYraioaw6G=z5ibTqh-o9GkWsDkfDmSQ@mail.gmail.com> <c4d6f2e5-0712-42a6-aef5-0cbada7e149e@www.fastmail.com> <CABcZeBM6y-6ZqaLGZ=8qr+uBnWOOgczhcx=ruy5S=n-YrHweKg@mail.gmail.com> <ca676a77-b2c9-4926-9842-d1d6587206ed@www.fastmail.com> <CACykbs11rHUweXmR1NSU0N2rRjcQ8Sf1S+DY2LO7T+e6cLt+5w@mail.gmail.com> <e9570c02c4f703780a4e317b26607ac124a3b595.camel@ruff.mobi> <CACykbs3v0FC50WQHNqq-oXwKDE=Jha-o0P=Mgr92OgyeKPS6Ug@mail.gmail.com> <7e862904cee5f86e4b77fce23c451c2abe0dc720.camel@ruff.mobi> <CACykbs2V0mgxDz_MK2EiqSDBGWWfvq0TAX+UpLSEZKwOoFc8HQ@mail.gmail.com>
OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt
X-Hashcash: 1:22:211108:kitten@ietf.org::ndZeFjUcyPlAP9Rx:3b3u
X-Hashcash: 1:22:211108:jonathan.hoyland@gmail.com::WSeeKnMrwZldRcgo:6mET
X-Hashcash: 1:22:211108:tls@ietf.org::UfNUWPAR0F9DIm1Y:VbR1
X-Hashcash: 1:22:211108:rufferson@gmail.com::SlWHBWzSd7CPHPLA:QJZ7
Date: Mon, 08 Nov 2021 23:47:59 +0100
In-Reply-To: <CACykbs2V0mgxDz_MK2EiqSDBGWWfvq0TAX+UpLSEZKwOoFc8HQ@mail.gmail.com> (Jonathan Hoyland's message of "Thu, 28 Oct 2021 18:46:26 +0100")
Message-ID: <87zgqei7s0.fsf@latte.josefsson.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/3jQfgyFi8251Z3D9uBtZV3ohx70>
Subject: Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-kitten-tls-channel-bindings-for-tls13-09.txt> (Channel Bindings for TLS 1.3) to Proposed Standard
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2021 22:48:16 -0000

Jonathan Hoyland <jonathan.hoyland@gmail.com> writes:

> When someone tries to copy a message from a SCRAM handshake into some
> GSS-API run on a single TLS connection I want to be sure that it will be
> rejected, without having to understand exactly how every version of SCRAM
> and GSS-API ever (including ones that will be drafted in the future) works
> (not to mention every other protocol past, present, and future that uses
> the same string.)

If I understand you correctly, this behaviour was a design choice of
SCRAM (and indirectly GS2) -- it was designed so that SCRAM native in
SASL would produce the same tokens as SCRAM used via GSS-API, for the
same TLS session.  Whether that was a wise decision remains to be seen,
but I don't think it will come as a surprise for anyone, nor is there
any publicly documented attack based on this property that I am aware
of.

/Simon

v2.23.0 | Report a Bug | By Email