[TLS] Review of draft-ietf-tls-external-psk-guidance

Watson Ladd <watsonbladd@gmail.com> Mon, 06 July 2020 19:47 UTC

Return-Path: <watsonbladd@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 433183A09DF for <tls@ietfa.amsl.com>; Mon, 6 Jul 2020 12:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 7jnbfwhVdERE for <tls@ietfa.amsl.com>; Mon, 6 Jul 2020 12:47:43 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 D7D4A3A09DE for <tls@ietf.org>; Mon, 6 Jul 2020 12:47:42 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id o4so23337342lfi.7 for <tls@ietf.org>; Mon, 06 Jul 2020 12:47:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=AJ09914+ZVVoxABPZm06grn8fpB5p+PpCwfQyIeJ7Vs=; b=TbaWMIICdTdPFv16/jvh5uh6eYWcaVdJwJiGH2hhhkRyTdXZcZxl5+FP+PEFaz3N6t nwgkKgkFABJz5pnRNPBrB9oiO1vXCncqq+jRDW0OdC5IuliJf+F00qI5OOKpi6g7O1ir cMW/PIL3eFIdfIQkO7f5B264V70LwVy79W2kbkBHHNBP5cuHRR4Dt+TL/lZC83i8aHYL tBGWti+hVwUrrRn24RqhDHPxOM1BNX4/rCmmskAjVRjsnx3Gq0YfUuJCtPYZBvdTIKf6 VN6ZXzWN2oqFfftcPS7HMXtuSwC6DHwEioeuKxITSct+tOHBLOpiZIJNHimXeUdjTCr/ L3Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AJ09914+ZVVoxABPZm06grn8fpB5p+PpCwfQyIeJ7Vs=; b=VFeaZVi1inyxOqfMnRIxLp8pnBGgu3qA/BSdAHOGthb+84h9+N6bV0F1K2V0Z/91b3 /bvtKGv1rhsSDzmKo6MNTjrqSNeWjcgugFjhbMP2w3axIZ3/yu6fj7qOZhJ9sSsiKJP3 nsIS0mzMoCVjFRg+ihuaAhMx0BEW3m/CFqqruXBlw07hOBlPSUw0qBXAevma9oDDoAJ4 U8GLRvYtP5m4lfNVjk22GuD0S/D6Bt7hwmU4gO7jv9+HAOnrUxNBp5L6MZpCW8z28vTr 6r4c2nUJDRY5fZGTtrm/Ai2Zl5aOQbVfQZXOVegBdvs6Y/xrjzTKPEGmOL3N5O5pA1m8 71rg==
X-Gm-Message-State: AOAM530JVDBMauhiZv3HEijhspuhNryKoPwxUmX229OLO/ByHIDVUR2/ uRVGCJ4MoMhr3flZ6oJ3+yBTQA07dO2r5dWelivCFEadtaY=
X-Google-Smtp-Source: ABdhPJwwv50LAe8MRGw/MydGNGn6NxNve8t3sGzg5K63+NMOG4mStzJRfcUGsAhqNZ18Trij4M1Wvrfun2Cj35jaB68=
X-Received: by 2002:ac2:5691:: with SMTP id 17mr31403282lfr.209.1594064860562; Mon, 06 Jul 2020 12:47:40 -0700 (PDT)
MIME-Version: 1.0
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 6 Jul 2020 15:47:29 -0400
Message-ID: <CACsn0cnutp3LJokruYaCSteZiNdMOe8het-2p1jvmLUYGimKqg@mail.gmail.com>
To: TLS List <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MKBcycX3Qbz-_XSTNfPFobWTxV0>
Subject: [TLS] Review of draft-ietf-tls-external-psk-guidance
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, 06 Jul 2020 19:47:44 -0000

Dear WG,

I've taken a look at the draft and I think while its discussion of the
properties and limitations of the external PSKs are good, I think the
recommendations in section 7 could use some minor editorial work.

In particular  "SHOULD be combined with a DH exchange for forward
secrecy." I would like to see rephrased to make clear that this is
about the TLS PSK Key Exchange Mode. It wasn't immediately clear to me
on first read, especially given the next sentence is (maybe) about key
establishment outside of TLS.

"If only low-entropy keys are available, then key establishment
mechanisms such as Password Authenticated Key Exchange (PAKE) that
mitigate the risk of offline dictionary attacks SHOULD be employed".
I have some questions about the meaning of this sentence. If it's
about potential future additions to TLS ciphersuites, then it should
be more clear that this doesn't currently exist and will in the
future.  If it's about designing an ad-hoc key distribution mechanism
to be run one time ahead of PSK TLS, then I think we should say so
more clearly and provide guidance on how to do this and think through
the implications.

Section 7.1.1. While it's a good idea to compare byte by byte, humans
entering PSK identifiers may run into trouble due to all the ways
visually identical strings may not actually be identical. It might be
worth calling this out as a consideration.

Sincerely,
Watson Ladd