[secdir] Secdir review of draft-ietf-quic-tls-48
Radia Perlman <radiaperlman@gmail.com> Sun, 01 November 2020 02:41 UTC
Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009EB3A0E0D; Sat, 31 Oct 2020 19:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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] 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 tcNhATDXu1MZ; Sat, 31 Oct 2020 19:41:05 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 046343A0E0A; Sat, 31 Oct 2020 19:41:01 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id dg9so10596256edb.12; Sat, 31 Oct 2020 19:41:01 -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=uiaO9GgYwYFDs0xmCcvMenIF7Kkl7w1d0tFze+uxrL8=; b=Lc4LdvBV5C/mvsXA+zjr8M5Su70hyoovF+ApoBu8B6OAx2zvZtiOHM28qDjvx1Ge6K t5vJnDx0trAdLLz0B8Xv4qNJ4OcZU7sEjcxonEQT4GaSZugXJj0xG36peUflAmZBFAi7 KqDFK2LxQ7hIaMR2BvKfe5tJtsb1iMzJXhdvSh3LsiH8xI11RuvU/JVrIGuNChZP+2rk plbUo2aOFzNE9kKApABrprrQAi1FAH2JbLaMWLKGRXOjQr8sDbiNpD/rOtgsWb3jzLOK PKzgEHjM148PqOJXfX5OVb+TLDeRgInCV6B/19dqele1V3k+v4VeTnGGs7rPVRJk9L3k 6VSw==
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=uiaO9GgYwYFDs0xmCcvMenIF7Kkl7w1d0tFze+uxrL8=; b=OY0RAz0N4KM8nYnON/C9rl2xltfWOECRsu1E7U5jerNFqMl1J6Er/9kj0Tzq8FV/Ct u60MzmXFq/eo/Y0UYgLH6mAOgO0rUTKF/Y8oEebyRGoS6Ti59Fs8rqgivKBHEzVHe/a8 8sgfAL0H4JeJheOVL7ytPSxrf1imImOvXR7Ojdjd1EUdjSlhms3ZdMKKuYRO6fpN8lwf 2CbiHWz9uCZIm26AXu1EMy7RfG62VNLMl2xHXPmJJddPJhCeOyQVlf5ztcdEA/l9lKFe hogE7axPyjuKe9QwdihptE1xVtV17fppt7jUqb0+QbRxoklT+hX3rsywxtXB1PDjLFMv dUXg==
X-Gm-Message-State: AOAM533ihkqnjiWUFZoVhI6mGYdn57Pj1wrq2AkU4MFLbHnwziceqHs/ caDl4i7tvFWPcGrr9KCnksrFfxL1Dz0zMLeCRXnzF4mAX4Y=
X-Google-Smtp-Source: ABdhPJzPmEyl1jgG6Uc12bls/wWWCdEdwHBngOSsGv1X/bX9UStqARLTTnR2XyKiKyQ3VG61PGRaJkX5JU/M6b5eFTQ=
X-Received: by 2002:a05:6402:b45:: with SMTP id bx5mr9781836edb.193.1604198459907; Sat, 31 Oct 2020 19:40:59 -0700 (PDT)
MIME-Version: 1.0
From: Radia Perlman <radiaperlman@gmail.com>
Date: Sat, 31 Oct 2020 19:40:47 -0700
Message-ID: <CAFOuuo4hcHoDjzCJzyxfU8Oq1cZzBXz9TAmUXuKPUE-PVNzQUQ@mail.gmail.com>
To: secdir@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-quic-tls.all@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005a221705b3028f05"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/PUhfV7mlqywzISwEErxP8WzcNmU>
Subject: [secdir] Secdir review of draft-ietf-quic-tls-48
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Nov 2020 02:41:07 -0000
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies the cryptographic exchanges and formats associated with the QUIC protocol, which in turn is an ambitious protocol that could over time replace TCP. quic-transport, quic-tls, and quic-recovery represent a triple of I-Ds that are always used together and could be combined into a single spec, though the length of the existing specs is already daunting. In many cases, it is impossible to evaluate them independently. As an interested outsider, I see these protocols as exceptionally well designed and the specs exceptionally well written. I could not find even any nits in a very long spec. It is misleading to regard this as a specification of running QUIC over TLS. It is related to TLS in the same way that DTLS is related to TLS: it imports much of the syntax, but there are many differences and its security must be evaluated largely independently. My initial reaction to this spec was to wonder why it did not simply run QUIC over DTLS . I believe the answer is that careful integration improves the performance and is necessary for some of the address agility/transition design. Given its potential importance, this deserves a thorough review by our best security people. Fortunately, from the acknowledgements list, it appears it has gotten that. There are a few aspects of the design that might raise eyebrows. For example: 1) TLS exchanges start out in cleartext until a key can be negotiated. QUIC data is always encrypted. The initial packets are encrypted with fixed keys whose derivation is specified in the I-D until fresh keys are negotiated. This isn't a security problem...it will just surprise people. 2) Applications using TLS can usually be configured to run over TCP in contexts where cryptographic protection is not needed. (e.g., use HTTP instead of HTTPS). Applications using QUIC cannot. That is likely to mean in practice that it will more frequently be the case that applications using QUIC will need to connect to servers without certificates signed by a CA trusted by the client (because that's the substitute when connecting to a server without a certificate). It's not clear what the spec should say about that, but perhaps the problem should be acknowledged. Radia
- [secdir] Secdir review of draft-ietf-quic-tls-48 Radia Perlman
- Re: [secdir] Secdir review of draft-ietf-quic-tls… Lars Eggert
- Re: [secdir] Secdir review of draft-ietf-quic-tls… Lucas Pardue