[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, 06 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
- [TLS] Review of draft-ietf-tls-external-psk-guida… Watson Ladd
- Re: [TLS] Review of draft-ietf-tls-external-psk-g… Christopher Wood