IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Tue, 12 November 2019 15:55 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E061A12082E for <tsvwg@ietfa.amsl.com>; Tue, 12 Nov 2019 07:55:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 nXu_YAKlNgNM for <tsvwg@ietfa.amsl.com>; Tue, 12 Nov 2019 07:55:37 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 6B83B12006E for <tsvwg@ietf.org>; Tue, 12 Nov 2019 07:55:37 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id v8so18387072ljh.5 for <tsvwg@ietf.org>; Tue, 12 Nov 2019 07:55:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; 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; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EPZNeg+JV3mFIqz2COEoeHPNE1NMOngYfazcZI04m1o=; b=iypzWpxTv7OwLRPlUaiuJuehdOZM7wWycXl81strH4tESmSRlnCXwmVLc9dXV89sWh P0BvuhS/tmnxdcEgjswcTDlHrCTs08aMcQz32YoCjo/o4W0WyjWFZ5oYx1B5nJHnfZ9i dKEu60Gw0ijC9lUlYLGIFcQLs5VzPHKAxhOyPoZasjkc/JEfhQ+SDl8o4UvkoZ8Pkg1v CsOH1CubwHbWy8zNJX7gZCbm8bJIr1dzT00X2r4npPKMcfh2Ljgo5GPqHypmrGLpNg58 PQOk72F/Wx/aWc845j3c/zsvJfxIID4dZ1WE8jAKmdHl+zGxiYuy722W4dIYqDPOH3Zk NMGw==
X-Gm-Message-State: APjAAAXe/tacTMfJlLNWqiKgEKIHMW5WXEgHxBBpw02EZTEIT3jvQ5gd oCiYXY9JpG9htfhcZPZv5d+h+YQcd0t9UDlgRdmhNQ==
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: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com> <CAPDSy+5rvaXgEGZ7_V4pRdmBss7Hf1XmaGbiXGZceQu9hjjRTQ@mail.gmail.com> <1573035094775.62307@cs.auckland.ac.nz> <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie> <1573109463764.56084@cs.auckland.ac.nz>
In-Reply-To: <1573109463764.56084@cs.auckland.ac.nz>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 12 Nov 2019 07:54:58 -0800
Message-ID: <CABcZeBMLc0CEhaCOfT=3DE5yq4TaSPh6h+hnJwxYLL93e-FYGw@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, David Schinazi <dschinazi.ietf@gmail.com>, Joe Touch <touch@strayalpha.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, tsvwg IETF list <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006011e80597284754"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/clVRTEO5oi7IUvkVYJnqCGgruAw>
Subject: Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2019 15:55:40 -0000

On Wed, Nov 6, 2019 at 10:51 PM Peter Gutmann <pgut001@cs.auckland.ac.nz>
wrote:

> .  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.

-Ekr

v2.23.0 | Report a Bug | By Email