Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer

Jonathan Hoyland <jonathan.hoyland@gmail.com> Mon, 24 February 2020 21:33 UTC

Return-Path: <jonathan.hoyland@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559763A13A6 for <tls@ietfa.amsl.com>; Mon, 24 Feb 2020 13:33:46 -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 MaAf0DqzGhah for <tls@ietfa.amsl.com>; Mon, 24 Feb 2020 13:33:44 -0800 (PST)
Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 84C163A13A5 for <tls@ietf.org>; Mon, 24 Feb 2020 13:33:44 -0800 (PST)
Received: by mail-ua1-x92e.google.com with SMTP id h32so3779752uah.4 for <tls@ietf.org>; Mon, 24 Feb 2020 13:33:44 -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=EuUkruvgyQf6yQoAJurDmhJIjSkuJnYmW/1kWaR7vmk=; b=K0lcRRTDe6IRPTBnZkbGGHx5eeEuBhDBayImBqD/w+9Anzrsq7RR4v+boevFF11Gxu r8lKnseaHGvKVMo6N/WqWBBeAp5B82u9/HPJLrdj4pIYBjoM6ula2XI8+vohr7yhqExM 8584Lw776x3dFvx4I5toyHq9B7OWwr8MnTsKo1YuFudpbGF9n8vq+qzZu1SsmAFhPmIe +pBN+oQ5pQqYIyPaKEefNns8hO4JXWvyby4ZPL4NXKZ/xf4Moc+Y1ZUQm+lbAWvjLdQd NqeC+6jmqfeiTZRwP2mzXhXr7IwrJlcPMyzJ3s71cMZDBkn74R1wKKPzW9ntvTfGEJ49 QXww==
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=EuUkruvgyQf6yQoAJurDmhJIjSkuJnYmW/1kWaR7vmk=; b=qK/XKskPTFU9wPnCVhOUvMliA0ddVHelsoMKhkuhcVUFeVyK4GeuGW2bsgwryhIt9I xE4Xe1e7+cYSFbQa22CkobgoKuN44ITTMXr9GHLezRofVQJh9WO5olixsrrewlCSNzul cUfJ2shZNfN+93/bAdOuJmxV9kkYcLrZ9vsnyqXKuIVzirVcomjWCYfa4VlPZzmq6ygX LAuAQlrliKEg7Q2Tgv3IifCTpOzw2I695KgTKR2p5m7LtGNBH9mcejtNysWR6kuIUYDK c0Bkbx6fASClFHT6sWz1hKqmx9cgk89K7bTU+Mj2dDeiJu+uSRC98fSNdUL+JezaoSEc VHuw==
X-Gm-Message-State: APjAAAUOMFXzSAN0UaQJWhnz6UlD/YBZ7YIAumQvXxqMt2oLAPXbaHHP lRJjzEr5oOkOwytAgh8rDhtBerZagZDECl462MHcPJxjjow=
X-Google-Smtp-Source: APXvYqzRoReuzZaj7KOU1xu1ggUbWCqDofnySrBdfAcM38t2gN/H7YS9EHM//8pnguoCSK7HoUHrKZoa2hSPz6HGANU=
X-Received: by 2002:ab0:2a93:: with SMTP id h19mr25365386uar.27.1582580023098; Mon, 24 Feb 2020 13:33:43 -0800 (PST)
MIME-Version: 1.0
References: <CAOgPGoBnSsDDaWWRHjkdjVRWw_DtxFYSQS7G-NyeSUfTzmYbAw@mail.gmail.com> <CAChr6SyA05VTB1n5Dcc2WNP6rrpsvDGXuPQxDxM9-=3JiYYPLQ@mail.gmail.com> <CABcZeBOPaGZ1ZKWpXkhC05v3HcbSLNuXYD_Lzw0S6iaBQY0a9A@mail.gmail.com> <CAChr6Sz7EqMbHNzcvbwdXkWB1JbQQig3RXCrzG6zascJL__t2Q@mail.gmail.com> <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com>
In-Reply-To: <8887946c-8509-483c-9c62-de5393fb9eaf@www.fastmail.com>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Mon, 24 Feb 2020 21:33:32 +0000
Message-ID: <CACykbs3LjPXPyvXGthCxYPK_Kv_+3TCV8VmkYab6gkfOfNmYuA@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001aff1c059f592048"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tpHQ8LrTI1L4_iedNuQa5lSXLW8>
Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2020 21:33:46 -0000

Just looking at this again, it might be better to make a slightly different
tweak to the key schedule.
Instead of:

                0
                |
                v
      PSK ->  HKDF-Extract = Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp binder", "")
                |                     = binder_key

                v



We should do:

                0
                |
                v
      PSK ->  HKDF-Extract = Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp e binder"

                |                      | "imp r binder", "")
                |                     = binder_key

                v


or at least:

                0
                |
                v
      PSK ->  HKDF-Extract = Early Secret
                |
                +-----> Derive-Secret(., "ext binder"
                |                      | "res binder"
                |                      | "imp e binder", "")
                |                     = binder_key

                v




Just so that we can distinguish between external imported binders and
resumed imported binders, should we at some point decide to do both.

Regards,

Jonathan



On Mon, 24 Feb 2020 at 20:50, Christopher Wood <caw@heapingbits.net> wrote:

> On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote:
> >
> >
> > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > >
> > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre <sayrer@gmail.com> wrote:
> > >> Hi,
> > >>
> > >> I'm not sure how violations of these requirements would result in
> poor interoperability:
> > >>
> > >>  Clients which import external keys TLS MUST NOT use these keys for
> > >>  any other purpose. Moreover, each external PSK MUST be associated
> > >>  with at most one hash function.
> > >>
> > >> These seem like aspirational security goals. It would be better to
> describe the consequences of violating these conditions.
> > >
> > > I don't agree. They are requirements in order to be able to make the
> assertions we want to make about the security of the protocol.
> > >
> > > This is consistent with the following text of RFC 2119 S 6
> > > ".. or to limit behavior which has potential for causing harm (e.g.,
> limiting retransmisssions) "
> > >
> > > I don't think it would be unreasonable.to explain the reason for
> these, though this is already a requirement of 8446 S 4.2.11 (though
> without justification).
> >
> > I think that interpretation of 2119 is a stretch, but your idea to add
> > an explanation while keeping the 2119 terms addresses my concern. At
> > the very least, the draft should note this is already a requirement of
> > 8446.
>
> That seems perfectly reasonable! We can point to the security
> considerations to clarify the "single hash function" requirement, and we
> can note cross protocol attack deterrence for the other claim. Would that
> suffice? If not, can you please recommend text?
>
> Thanks,
> Chris
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>