Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

Eric Rescorla <> Tue, 12 November 2019 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 776C912082E for <>; Tue, 12 Nov 2019 07:55:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rmCX-8TG9LVo for <>; Tue, 12 Nov 2019 07:55:37 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5742212004F for <>; Tue, 12 Nov 2019 07:55:37 -0800 (PST)
Received: by with SMTP id d22so6853540lji.8 for <>; Tue, 12 Nov 2019 07:55:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EPZNeg+JV3mFIqz2COEoeHPNE1NMOngYfazcZI04m1o=; b=omTyp6sB1q8Ebn3Nzb2iFk8zqmWbZSWc/DW25AKwv0ERvf7erq5R+gOIB8wQBskP9F 8vUz0teIovsivInW6XSkoo2YSoguhISXMzJ3aTfQ9GQFwpQE+mgzqpuPg0Ray3phoJ1b BOC618qcd4OYVLsgq1AMjFBUuCcLAEJvBrYCACC/zYyLMUQxmDno+ZwjF8UY3Lh7p4d1 WewuU6Vc0fHqDQMMK4lKnyoTYqM3Ehg8QF0NM+Aem2DuucgmGVoeGZvCL2sWxpZm3Kst +PdfQC/LDHFQYn9YUwmFVCvZ2jktuGwFMLEmAOXC5WOSX4JTsCnJ5hFgf0uJyMNXX8C8 uTFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EPZNeg+JV3mFIqz2COEoeHPNE1NMOngYfazcZI04m1o=; b=EVVIzIJkNGnQEsxVdr/y/PFlRahLOCvqHzy68gVzG/rO2eOh8bwxrIyakDcBgaBzMX eA2JAElPdC5mysIqxH3gLUFccTgJI/+QFZBfYFpdWg2RUBK/oTaUE4s6oXlLdu8+6WXi o8qpYUOvXePfqDEzeswQ6vOTzescQOZv2F4xjHMdwxWWYGSIiw9VGXIeekVkPDYu6yIl 4rYO9HBjjQaREsao2yBDuqMyeu4+Yqd0zxL4XrLUrsUpK8iCyfe+XkZ1MUhEzMAKFwhi Ar3o9WeGOsFEb/Td+q9ue6VFvhKFKFxhAzeMxd4lkuz9kxy0515K1KsVsYqLTS8VevZN p6IQ==
X-Gm-Message-State: APjAAAV3rsgRMrwBk27psr5wpsC//NwsHFqprUwoJwcbht2uEk1Sig55 jrHRBICDKD4bgPq2kMgwmZULc4oMkYM7sUXkxBaWyg==
X-Google-Smtp-Source: APXvYqxLew27YKO2uDDuDYuDzbjn/sI0xcmBTTVHqgiZCkIhVR9MSMMDyFgW+Ec39JAO8DceCMbET+Cwp5kGeWlX+Ho=
X-Received: by 2002:a2e:7301:: with SMTP id o1mr12928516ljc.16.1573574135512; Tue, 12 Nov 2019 07:55:35 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Tue, 12 Nov 2019 07:54:58 -0800
Message-ID: <>
To: Peter Gutmann <>
Cc: Stephen Farrell <>, David Schinazi <>, Joe Touch <>, "" <>, Mirja Kuehlewind <>, tsvwg IETF list <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000006011e80597284754"
Archived-At: <>
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Nov 2019 15:55:41 -0000

On Wed, Nov 6, 2019 at 10:51 PM Peter Gutmann <>;

> .  So on the one hand we've got real-world experience with two protocols
> that do header encryption/protection which has yielded endless problems
> (IPsec) and security vulns (SSH), and on the other hand we've got what
> seems
> to be a faith-based belief in something that numerous academic papers have
> shown doesn't provide the service it claims to.

On the other hand, we also have WebRTC which tunnels SCTP over DTLS (thus
encrypting the SCTP headers) and that seems to work out fine.

As far as "the services it claims to", the primary argument for encrypting
headers in QUIC (and the handshake metadata in TLS 1.3) is to prevent
middleboxes interfering with protocol evolution. We certainly have evidence
of a number of cass where that has happened, though I don't think we yet
have strong evidence that encrypting more of the metadata prevents this
from happening because we mostly just started doing so. OTOH, I'm not aware
of any academic papers showing the contrary.