Return-Path: 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 58746120273; Tue, 12 Nov 2019 06:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 f5SNnBkTyt4m; Tue, 12 Nov 2019 06:43:14 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0: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 28D8C12020A; Tue, 12 Nov 2019 06:43:14 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id l20so14946946oie.10; Tue, 12 Nov 2019 06:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jws/dHrRDLttxup3Lu54WSwKLTs55bwKbiX/NoYtYTg=; b=GyO19HPh+IpWOC50Sd9spCvEQEkHaqOMi1sYWu5nWTJPjaGKCeCjdfYaH7d5zVoTfz Qip6GBHtgN3+RYtV14I9zzVVO0T3OubSAU3JTe8zsYQo2+L4+dct7y3Qu7KBDMn8K3HN 2PGJ6bpBVhh2DTFtGYLhUuojShYgdPVmg+bRNI8UGwb6euJkkdE2XvIttZqa44tGCISh gTSIfse1uZvfZCq9rgtaJ16etzRODFncyQjkcCGB+vg0xiQlty7pjARJgyzLO/McqtiV LPUpzBAIOtlHChMEMNtRdd0FxARVolYTUveR8IfrHJi25D78tDYWWDSbJ6Aab8+djZez Q6vw== 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=jws/dHrRDLttxup3Lu54WSwKLTs55bwKbiX/NoYtYTg=; b=tD6j11QW0JCTmQq6WJiSwdsMp4AE41W7umlZ7SuwUHxh8tJRUxQlCqIHu6XNhcwLvC pBpGVrR9k/y3+yZRZyXMTuWjxh7h15uaiq97ufy8V5+lIU3XMUG5KUdfwLFFPi6ILqes PnWKe8xfV3xyLNwiy00Cc/Cj/Z6Dw45xeBXWx1XOa39S2915ErBzAbk2bSXhKWSWuioX 6PmD5bNSZ8O2riGtbxBngUGO596Nhqo7zR8Ryj8GHt/RL9awRdQoCkHe5sMPIjRGRdIj eEQnhofXYoPKsZGtZmynpmOLodDNYWDTJluoPwcNnAcjkIYUzfQuV+EC9+rwHizlpkpY Id1Q== X-Gm-Message-State: APjAAAX4fB1WHvpDYKMXOTLTA8rOvLIH41p2a6ZWqZaFgidthgKrt/Wb oZVpEDW6tsQDYYJE8AFyoNb6SllrYMqjpeNAB9g= X-Google-Smtp-Source: APXvYqxtMaCNvrYSm8fk32o98TKgPpY65GUpyqW1qTBT2AuB5Bf6O2L1qPtKrkxeOTEkaU6WYcVi9cyvqeIOAEdqyNs= X-Received: by 2002:aca:280a:: with SMTP id 10mr4122186oix.119.1573569793475; Tue, 12 Nov 2019 06:43:13 -0800 (PST) MIME-Version: 1.0 References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com> <1573035094775.62307@cs.auckland.ac.nz> <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie> <1573109463764.56084@cs.auckland.ac.nz> <1573542420083.60501@cs.auckland.ac.nz> In-Reply-To: <1573542420083.60501@cs.auckland.ac.nz> From: Kathleen Moriarty Date: Tue, 12 Nov 2019 09:42:37 -0500 Message-ID: To: Peter Gutmann Cc: Tom Herbert , "gorry@erg.abdn.ac.uk" , Joe Touch , tsvwg IETF list , Mirja Kuehlewind , "saag@ietf.org" , David Schinazi Content-Type: multipart/alternative; boundary="00000000000091ca1905972744c4" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 14:43:16 -0000 --00000000000091ca1905972744c4 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 12, 2019 at 2:07 AM Peter Gutmann wrote: > Tom Herbert writes: > > >The problems of protocol ossification and middleboxes meddling in E2E > >protocols has been discussed at length in IETF in various contexts. > > I'm aware of RFC 3234, which was written seventeen years ago and focuses on > middleboxes messing with application-layer data, as well as farcical stuff > like RFC 3424, of the same vintage, but it's mostly complaining rather than > actual rigorous analysis, and often seems to be based on opposition to > middleboxes as an article of faith, notoriously manifested in IPsec's "NAT > is > bad, therefore we will make sure IPsec breaks NAT, because NAT is bad", > which > has caused endless headaches for pretty much anyone who's ever had to work > with IPsec ever since. > > In particular for this case, since the discussion is about header > encryption > and not middleboxes in general, I'm not aware of any rigorous analysis of > its > purported benefits, or even a clear statement of its purported benefits, > something like "here is a definition of the service that header encryption > provides, here is a real-world study showing that it provides this and > demonstrating that it can't be readily defeated". Contrast this with the > two > dozen plus studies that look at the analysis of encrypted traffic despite > the > encryption, an example being (just one picked at random) "Identifying > HTTPS- > Protected Netflix Videos in Real-Time", Andrew Reed and Michael Kranch, > Proceedings of the 7th Conference on Data and Application Security and > Privacy > (CODASPY'17), March 2017, p.361. > > So when people complain that the draft doesn't say enough about all the > Good > Things header encryption provides, I would respond that it does, it's cited > all of the available literature on the benefits of header encryption, and > all > of the studies showing that it's effective, in Appendix B. > > After work on RFC8404, I do think having such research conducted would be beneficial. This was one of the aims of the proposed group SMART. If there is interest in conducting this work (writing research drafts, etc.), please let me or Kirsty Paine know. Best regards, Kathleen > The draft is actually quite restrained in this regard, as I mentioned in my > previous message the two notable examples of header encryption/protection > deployed at scale into the real world, IPsec and SSH, have both been a > disaster (for functionality, IPsec, and security, SSH), but it very > politely > omits mention of this. > > Peter. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Best regards, Kathleen --00000000000091ca1905972744c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 12, 2019 at 2:07 AM Peter= Gutmann <pgut001@cs.auckla= nd.ac.nz> wrote:
Tom Herbert <tom@herbertland.com> writes:

>The problems of protocol ossification and middleboxes meddling in E2E >protocols has been discussed at length in IETF in various contexts.

I'm aware of RFC 3234, which was written seventeen years ago and focuse= s on
middleboxes messing with application-layer data, as well as farcical stuff<= br> like RFC 3424, of the same vintage, but it's mostly complaining rather = than
actual rigorous analysis, and often seems to be based on opposition to
middleboxes as an article of faith, notoriously manifested in IPsec's &= quot;NAT is
bad, therefore we will make sure IPsec breaks NAT, because NAT is bad"= , which
has caused endless headaches for pretty much anyone who's ever had to w= ork
with IPsec ever since.

In particular for this case, since the discussion is about header encryptio= n
and not middleboxes in general, I'm not aware of any rigorous analysis = of its
purported benefits, or even a clear statement of its purported benefits, something like "here is a definition of the service that header encryp= tion
provides, here is a real-world study showing that it provides this and
demonstrating that it can't be readily defeated".=C2=A0 Contrast t= his with the two
dozen plus studies that look at the analysis of encrypted traffic despite t= he
encryption, an example being (just one picked at random) "Identifying = HTTPS-
Protected Netflix Videos in Real-Time", Andrew Reed and Michael Kranch= ,
Proceedings of the 7th Conference on Data and Application Security and Priv= acy
(CODASPY'17), March 2017, p.361.

So when people complain that the draft doesn't say enough about all the= Good
Things header encryption provides, I would respond that it does, it's c= ited
all of the available literature on the benefits of header encryption, and a= ll
of the studies showing that it's effective, in Appendix B.

After work on RFC8404, I do think having such researc= h conducted would be beneficial.=C2=A0 This was one of the aims of the prop= osed group SMART.=C2=A0 If there is interest in conducting this work (writi= ng research drafts, etc.), please let me or Kirsty Paine know.
Best regards,
Kathleen

=C2= =A0
The draft is actually quite restrained in this regard, as I mentioned in my=
previous message the two notable examples of header encryption/protection deployed at scale into the real world, IPsec and SSH, have both been a
disaster (for functionality, IPsec, and security, SSH), but it very politel= y
omits mention of this.

Peter.

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--

Best regards,
Kathleen
--00000000000091ca1905972744c4--