IETF Logo Mail Archive

Re: [kitten] [TLS] last call: draft-ietf-kitten-tls-channel-bindings-for-tls13-02

Jonathan Hoyland <jonathan.hoyland@gmail.com> Wed, 10 March 2021 23:57 UTC

Return-Path: <jonathan.hoyland@gmail.com>
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 695283A105A; Wed, 10 Mar 2021 15:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.com
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 ibBfU-D5VaTU; Wed, 10 Mar 2021 15:57:46 -0800 (PST)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50343A105B; Wed, 10 Mar 2021 15:57:46 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id w60so48411qte.0; Wed, 10 Mar 2021 15:57:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IbRYWFHTe3ziaGz/UgyNqK8d7kxLoSKjkFkO8GJigNU=; b=mPd3npP5jGHYU6Wq6puBAjhuKCt364//aXl4wXzW9zRvujKJnILBzs6xOthDdUW9Or 4qgUnCUR4oVimfmap5MLmwMuvFNbK0TSZ2+jFJ65I/v1/eLF5XWOqY6urbwCwGHp7W4+ xVyN7iD/tEe1JicCLX6KMKtTDmVIWqR83KesDO8Oa3X2QTZ8kIZlQfxPFk77wQuTzZJG m3OffG9ww64dVivNZ+rEOYD+lYQxdTQWutiRTihP7toWSvWTSgjsuU2NSfbvDrVUyJQX ppSH3Buec6Tbx/7E4Nf4fS3AievANKcVU/j5WJIdb4vH+XbUNxcSP4da2yMvQPMERu1z V54Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IbRYWFHTe3ziaGz/UgyNqK8d7kxLoSKjkFkO8GJigNU=; b=ZLY1ImlkSlXD64VCzA5CF9CwQ7sIq8B7md8kXdDIOKv+z81UA9nROOBCbENQHkaiar EAHS5jA5W8a3r1mVZO27stvFfRdiOcY4XhF3R8rvA7UUWrFjmpMhOQDZAGENjdfobyWw iCxvE4YvePSvFuS/vXEt6hI6bAwmIII2kLyEzCcMS2I2tp/fSls43gqjIYzYZEO+f3mN dJ5p7J3F8f6Wrq4paTfakzTIVIKIcMlAV3FCkswcWup847wydmxiqU/JGJCweHH/nO4d z3CIoQgPTm61/pLmpcfGoynOCNef0YJ/PdiRzgbC9N2zjjFAljetm4MS/5/07Tjp9f3H tQVw==
X-Gm-Message-State: AOAM530NJ+6/wFSRO4sf5LhIZoDoA9HwUHUTEKQb3UUEmdgkY4DB+2Th bCaLf0sUQFxvijDM6RtZSFYof6n0vNTrCdTi7G8=
X-Google-Smtp-Source: ABdhPJyAjoQdaBes5FY26lbJ68kX+EwjuBItp0JHlo6hIxN5/kf1rx+RI1vdtl0umIdz0XBY/J938cwWAJlKACYtrIg=
X-Received: by 2002:ac8:1301:: with SMTP id e1mr5221314qtj.96.1615420661628; Wed, 10 Mar 2021 15:57:41 -0800 (PST)
MIME-Version: 1.0
References: <jlgy2eu3j6s.fsf@redhat.com> <CACsn0c=Z5bNcpYGNEQi5RhzvV9LaKckH230Un2Oqp6ot457VNQ@mail.gmail.com> <20210310193630.GJ30153@localhost>
In-Reply-To: <20210310193630.GJ30153@localhost>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Wed, 10 Mar 2021 23:57:30 +0000
Message-ID: <CACykbs1PAhVCRD3GmjkAESox_jPBH9LqLLdtGZ7AWBrnZDzLGg@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Watson Ladd <watsonbladd@gmail.com>, KITTEN Working Group <kitten@ietf.org>, TLS List <tls@ietf.org>, Robbie Harwood <rharwood@redhat.com>
Content-Type: multipart/alternative; boundary="000000000000b301d905bd376edc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/iu_8ugoOxQQUdv9LAX0v9hGJM0w>
Subject: Re: [kitten] [TLS] last call: draft-ietf-kitten-tls-channel-bindings-for-tls13-02
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: Wed, 10 Mar 2021 23:57:49 -0000

IIUC a channel binding (in this context) provides a unique "name" for a
channel.
In the case where two distinct protocols running over the top of TLS use
this definition, they will both get the same channel binding.
It might be useful to pull out in the security considerations one
consideration from RFC 5056 that might be forgotten.

```
 o The integrity of a secure channel MUST NOT be weakened should
      their channel bindings be revealed to an attacker.  That is, the
      construction of the channel bindings for any type of secure
      channel MUST NOT leak secret information about the channel. [...]
```

This means that a perfectly valid (even if currently undefined) use of a
channel binding might involve posting it to Twitter.
I don't follow kitten, but if there are multiple places that use this
binding then this might be a useful warning.
You cannot assume the channel binding of a channel is secret.

Alternatively using context strings allows for independent channel bindings
to be used by each over-the-top protocol, so perhaps requiring some unique
context string per usage type might be appropriate.

Perhaps these concerns are too out there, but just thought they warranted
at least a mention.


Regards,


Jonathan



On Wed, 10 Mar 2021 at 19:37, Nico Williams <nico@cryptonector.com> wrote:
>
> +1
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.8.7 | Report a Bug | By Email