[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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

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

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.