[tsvwg] Review of draft-fairhurst-tsvwg-transport-encrypt

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 08 May 2018 17:22 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 22286127077 for <tsvwg@ietfa.amsl.com>; Tue, 8 May 2018 10:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 GJ5CnxvpTV-e for <tsvwg@ietfa.amsl.com>; Tue, 8 May 2018 10:22:57 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 9980A12D877 for <tsvwg@ietf.org>; Tue, 8 May 2018 10:22:57 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id f21-v6so39344595iob.13 for <tsvwg@ietf.org>; Tue, 08 May 2018 10:22:57 -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=udbU4Tu8eNTD9pUE+D4oqPMBOUPNaX5p6PK274lxNUI=; b=fC2hswrcejc81M+i3M7TgqfY/Q+AS4Lz61gX36VIGW/+xoOlOw+of5Cqf28fuBSjEq PxSJml9ByYgkr3uaFMRf/qIOaT47vVYTfKGlxhqB4R6qyjsoLLCkRWLF1UrkogYUWPSY y+iCek/9aIE0nyhStIgzcK7zycRbubb9kz/Ny/DLerd3nfrjXxg0aZ8kDEbi1Kf6ovnv e3pCvbE040QVYn/aZcbX/h3e0/krhBvZ/X6YENJaEliUVL0TcYqbXp/guLso2+RYvp+t QajsRAhH2kBnZfI67k8ac+AEobW7LNIHXRupSrpm0fXIdaxXQDGVLXMzNE2eDglSCDAf NiGQ==
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=udbU4Tu8eNTD9pUE+D4oqPMBOUPNaX5p6PK274lxNUI=; b=qisWP2X7lISAJcdX1wKwg75/GyOjU2zgaIJh9wVMbZ3E3tUMd5lPqdAM8uEcQsa2wD 3uYcxAoqeBKA02Qc51tNe507wNd7iBmF2w+UAhSvr509RAcBo71/UyWclJXuhQRmR9tX sPXQst8wOqqevhxe2xmfQ/GGGGjh5b7Z7KHGSCEeMqu4aVyRe9csfazDjyl5AkJw94Wx t+miWNVd+u5P3ZyWqVa1Wf99OLpYWYCqkKxGZdFhRLKJkCn0v48FIRGgwOMaGmiXECz1 LOozud4+H6kYWudStNuyBMFwA8mVMFqKBYWiHY9M6ax9+kLuvtBokKjxKQJV25aYhoJj OD7Q==
X-Gm-Message-State: ALQs6tD2SP0n5gM35OrM1WHeDe2bX0T15ajk3zlLMfR4WmZ5RPldTnH7 Mn9RhowMwLAy3AYTKBkPmmaBmMTfDp1LR5MvFceN6g==
X-Google-Smtp-Source: AB8JxZo1gcBV5kBDzTJUQ8vCf9P1u8qKOu7b/B45jCZx2Jv+Zfl+MBcnMGTGTb6h8MLKjaKoEXvNlJK22bLIszxNfu4=
X-Received: by 2002:a6b:9a05:: with SMTP id c5-v6mr37374489ioe.142.1525800176894; Tue, 08 May 2018 10:22:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.192.188.19 with HTTP; Tue, 8 May 2018 10:22:16 -0700 (PDT)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Tue, 8 May 2018 13:22:16 -0400
Message-ID: <CAHbuEH7DND0uz9bv9YSD_9BW02AfWB+YmONHMBMV+Xg7w-RDPw@mail.gmail.com>
To: tsvwg@ietf.org, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Colin Perkins <csp@csperkins.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/G99HJIH2uziTG4ejxwr9av520Tw>
Subject: [tsvwg] Review of draft-fairhurst-tsvwg-transport-encrypt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
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, 08 May 2018 17:22:59 -0000

Hello Gorry & Colin,

Thanks for your work on this draft.  In my opinion, it is very
important to dig through the implications of encrypting transport
headers.  The document is well written and easy to read, thanks for
that as well.  Al and I had a hard time with that since ours was
contribution driven and controversial.

Here's some feedback from my review that I hope you find helpful:

General:
If you added section references to mm-wg-encrypt where it is
referenced, that may be helpful to the reader.

Specific feedback:
The apps side will object to this phrasing as they don't see the need
for any 'help'.  I agree with your point, just warning of the obstacle
in case you can reword it to prevent objections.
   Choosing to encrypt all information may reduce
   the ability for networks to "help" (e.g., in response to tracing
   issues, making appropriate QoS decisions).

Section 3 intro text

Encrypted traffic can also be profiled to identify threat actors.
This will continue to be important as threat actors may have advanced
capabilities and may modify the encrypted streams in identifiable ways
that can differentiate their traffic from others.

I was expecting to see some text toward the end of 3 on adoption of
these protocols.  We can put out protocols, but it's up to industry to
decide when and where to adopt protocols.  From a few recent talks,
what I saw from the audiences is that those aware of QUIC are outright
blocking it.  The business imperative is not there for the
applications using QUIC to justify it's use within the business
network, at least not yet.

Section 3.3
Do you want to make this specific to IPsec tunnel mode since that
hides the true end points as well?  Transport mode isn't well deployed
because of interoperability issues and not current use case driving
it's usage, but that does leave the true IP source and destination
addresses exposed, more than what you see with tunnel mode.

Section 5.3
This is starting to touch on NetNeutrality and if you are going to go
there, you should state it explicitly.  At the enterprise level (it
doesn't seem like you are covering that in this draft), I am hearing
QUIC is outright blocked by those that are aware of it on the network,
so it's not just NetNeutrality that will impact it's deployment.
Perhaps rephrasing may help?  Here's the text I'm talking about:
   A lack of data reduces the level of precision with which mechanisms
   are applied, and this needs to be considered when evaluating the
   impact of designs for transport encryption.  This could lead to
   increased use of rate limiting, circuit breaker techniques [RFC8084],
   or even blocking of uncharacterised traffic.  This would hinder
   deployment of new mechanisms and/or protocols.

Section 5.4
I think you have a typo here:
   Integrity checks can undetected modification of protocol fields by
   network devices,

-- 

Best regards,
Kathleen