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

Jonathan Hoyland <jonathan.hoyland@gmail.com> Mon, 24 February 2020 22:58 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 7CA6D3A14F7 for <tls@ietfa.amsl.com>; Mon, 24 Feb 2020 14:58:24 -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 QiImWqxvPFz6 for <tls@ietfa.amsl.com>; Mon, 24 Feb 2020 14:58:18 -0800 (PST)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 799D43A14F5 for <tls@ietf.org>; Mon, 24 Feb 2020 14:58:07 -0800 (PST)
Received: by mail-vs1-xe36.google.com with SMTP id b79so6784729vsd.9 for <tls@ietf.org>; Mon, 24 Feb 2020 14:58:07 -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=VPJl8aU33+cye/2C8xj56FUzDY3E5MdXrVH+mH4ZlZE=; b=qc0X6bAsSFNT01deGQsTo7KCLd2t7ssRSIeJAO60mg+VOLXq43DQNOYFQWN7bCQ4KQ F7Nzri3jFt7gQ/0cvwNFMQAPtzqiXOxNhi/PFZMbbqvs777mKNN7FFUIKTNgDhHW01Se fEHAiDP/G1iXeCv8FIpr/uJNJYdKbyHMh+41X2NTHHbgIux2UUcHjc/8GrrhykR3bAoh d+HlZ6C9QvXCelFx167PFDvazhrNXD6pyBHt8wnTY9ko8uHrAvNPfDUQv92VIzSjPTjF HRDjdgawG43CiC+FKX8AjZ8pXPgGzGonS/DhgiWUOY0LetixCe5kj//qOU9Wv21O0jKu n5uQ==
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=VPJl8aU33+cye/2C8xj56FUzDY3E5MdXrVH+mH4ZlZE=; b=iE7GdYQAulEYwc5efuFhW9JoiqvhUTql998i8dKXteNGfSew8FnC9ExQbkjEHCE9l1 XUmIkIBMrLae1cZ79NX2gVSm134ioTVmCEoceHT2iDI320sFFgR24diIDPBbdDu3LVun lQUhnDakbueCdaFtokApZjfxARV8g3fHzdy6qqjWrI0zoo0a2L3pUfVOlPJhXsZPrcaM 1+TY9hw8N2btH9cGEE7+rsclK+rmAaUJ3NIvlUZ85nSk9k7t0IUmh3eDuCXaU1KSgaXO kziUesC+Jv+EV/sJCxO7BiI2OgzskXHSPCAFzxo7A/x+5fP0bvWlM5ZCWlZuFlSNJWJd V12Q==
X-Gm-Message-State: APjAAAXy26CVGYvsgUeXKLruUjN5CBcBexiZ1Q2O3tgBy/yPRKPLQH0Y qkhFGexjMlTLVSgP3ShbWGnlHPxmIf0XQPkLmo17mJLt
X-Google-Smtp-Source: APXvYqzpI4bSlzJtnw66SoSfPyqdoGUYv8bZIbUNbmUYKezTTXstTnWFd9iFlVU0xHfOLv7Kpru/2NJJfct2y2576CI=
X-Received: by 2002:a67:eac5:: with SMTP id s5mr27899568vso.148.1582585081388; Mon, 24 Feb 2020 14:58:01 -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> <CACykbs3LjPXPyvXGthCxYPK_Kv_+3TCV8VmkYab6gkfOfNmYuA@mail.gmail.com> <CAF8qwaCPbQfXWvTm7VgS7G6XAfzEY_=rTfD2CzRWsSod+MpC2Q@mail.gmail.com>
In-Reply-To: <CAF8qwaCPbQfXWvTm7VgS7G6XAfzEY_=rTfD2CzRWsSod+MpC2Q@mail.gmail.com>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Mon, 24 Feb 2020 22:57:50 +0000
Message-ID: <CACykbs08ico3WVDK-E=sqTSVPD=gYQdJ8eiQzyxhKqY=q_EPUQ@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: Christopher Wood <caw@heapingbits.net>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009a6dc9059f5a4dcf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xS0_dmcCZZMfxeWAej878dx3U48>
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 22:58:25 -0000

This would be for cases where we want to inject extra context into a
resumption.
That would be anything that changes an authentication property, so
for example if you wanted to include some agreement on the status of a
post-handshake auth or Exported Authenticator.

So for example imagine I had a session during which I received an EA and
when I came to resume that session I wished to indicate that I was still
willing to accept the EA.
I would offer a special PSK and inject some extra material into the
handshake*, and if the server was able / willing to agree to this it would
select the PSK.
I could also offer a PSK with no extra injected material, as a fallback,
and request the EA again.

* This would only affect the binder for the PSK in the ClientHello.

Another potential use would be the binding for ECHO, although I don't have
a clear enough picture of the precise mechanics of that to know if it would
be helpful.

Something that would allow for a consistent naming in the future would be
my preference, because just as "imp binder" doesn't preclude "imp r
binder", using "imp e binder" doesn't preclude us never adopting "imp r
binder".
I vaguely remember discussing whether the longer name would tip us into an
extra hash invocation at the last IETF,  and concluding that it didn't,
although I'd have to double check that.

Regards,

Jonathan

On Mon, 24 Feb 2020, 22:23 David Benjamin, <davidben@chromium.org> wrote:

> On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland <
> jonathan.hoyland@gmail.com> wrote:
>
>> 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.
>>
>
> I may just be confused, but what would a resumed imported binder mean? I
> see this mechanism as largely a bugfix for TLS 1.3 external PSKs, rather
> than a new kind of adjective describing PSKs.
>
> ("imp binder" also doesn't preclude "imp r binder" later if we later
> define something which needs it, but I'm confused what the concept even
> would be.)
>
> David
>
>
>> 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
>>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>