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

David Schinazi <dschinazi.ietf@gmail.com> Thu, 07 November 2019 19:24 UTC

Return-Path: <dschinazi.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 8F07D120B22; Thu, 7 Nov 2019 11:24:19 -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 MNdg-Hj_2rdw; Thu, 7 Nov 2019 11:24:16 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 6A181120A2D; Thu, 7 Nov 2019 11:24:16 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id y23so3532310ljh.10; Thu, 07 Nov 2019 11:24:16 -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=bRwRgqVmH/cYqZUbyCuOrZz5BbspH6VkjdCoFNsQUzE=; b=pGM/xpVc30I9m/GyDfo43WLtdTT8314odFWXL/i8ckyGpGfypaah0IZvwqwK08jG7b 6VBMA/paAjDt9Zac5wqNdFAnvYR7w21sWLyfAi7Fr6HPz1VnTRO8cuz9EDifHQykrDRp e0UW7AwJTm3rH4MDqTBVTy+HoPGi9Qt8o0hc9GUwxOwssCYk/cWK0kLfgurKLU4kCZU+ uKvRfBuIAsX7ksMLKASOwyW+CA/sJIeudpG9TqO1B3+v/NQSNwYg4XibOi5iIn1vgLdM DJ4WMmRVtTLgL7S1bRkOhVLTVNOfl/+RrFbRGy/0km2BsOiLoQZd3u5CqmBy3meRv1wR BvsQ==
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=bRwRgqVmH/cYqZUbyCuOrZz5BbspH6VkjdCoFNsQUzE=; b=VLMX6JMRFrDhM122agyM/udgNOMd6yGd3L3sG11uW6Sq/e0s4WNeFfuYDieeSJEkRV v33ZY75YluXRKl3yrpqqfTCAig7CdYnl2ImjHWtRalq1LnYTc/rsFXbF8AxsB6Vg79n8 k7uepVPRJtbXhWRzIcR3QZmz/uljNPVpLyloTVsGKXT2ExBhU4InPQ27bC1dU11egpoF DOju3fX8UUaKcyp8/iGzkheEEd2NcI92/FNPKAaZmHyx5pwAFEoQLWRFyT7pctYjKHn+ lxSFdIQKmI1of4cwKhzTQHklIGYqQirtH0JjmuEqdOQOfcyCKgwHGzD5tU6OI7S9RA+/ MBYw==
X-Gm-Message-State: APjAAAVojRqk5s9iwc9MWc74dRNP24BMdkqCUpkUHQa2pkicfJg+g1O8 +GxAD3AqzPEXkSfmOD4Gew9busKesrgjWeTaA8Y53Q==
X-Google-Smtp-Source: APXvYqxdN21z8dgcgTracpbAj6kfVr3k2vBt6sLzrolPGnDAwwjndRJ0u2SIPDgi++GZtqUb2NIfIynyHSSZzuCnmxc=
X-Received: by 2002:a2e:2c19:: with SMTP id s25mr3674472ljs.26.1573154654408; Thu, 07 Nov 2019 11:24:14 -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> <9687A3AC-870A-46E1-BD2A-7041410CFF75@ericsson.com> <CAPDSy+6Ls0DLgN+-Ju5Zr+56wgqgq_PUj+2kkhwcAhhYUC3dCA@mail.gmail.com> <A3BBFF1F-11FB-41F8-9E5E-D7C5E9C34CAF@csperkins.org>
In-Reply-To: <A3BBFF1F-11FB-41F8-9E5E-D7C5E9C34CAF@csperkins.org>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Thu, 7 Nov 2019 11:24:02 -0800
Message-ID: <CAPDSy+6aRWVcyEUSM9=q-abKex3R3F6HRS-wTaVAzoR2njOqkw@mail.gmail.com>
To: Colin Perkins <csp@csperkins.org>
Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@ericsson.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Joe Touch <touch@strayalpha.com>, tsvwg IETF list <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005a54cc0596c69c3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/cgPaAtgqLi6Oa_R1zEIzTDtUD7U>
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: Thu, 07 Nov 2019 19:24:19 -0000

Hi Colin,

Thanks for the clarification. If the intent is to get protocol developers
to think, that's always a good thing. However, I think the tone of the
document does not match this intent. I realize that this is purely
subjective, but upon reading it I really had the impression that this
document suggests that the downsides of encrypting transport
headers outweigh the benefits. Perhaps the document should
instead aim for a middle-of-the-road approach. For example, the
document could expand the mention of QUIC into a case study: the
draft could explain how QUIC considered these issues and made
the informed decision to encrypt its transport headers.

David

On Thu, Nov 7, 2019 at 11:10 AM Colin Perkins <csp@csperkins.org> wrote:

> David,
>
> I don’t know what Mirja thinks is the desired outcome, but my intent – as
> an author of the draft – is that you think about the issues raised and how
> they relate to your protocol, then make an informed decision about what
> parts of the headers to protect and what parts it might make sense to
> expose.
>
> And, to be explicit, if you think about the issues discussed in the draft
> and then decide to encrypt all the transport layer headers, *that’s fine
> by me. *
>
> Colin
>
>
> On 6 Nov 2019, at 17:52, David Schinazi <dschinazi.ietf@gmail.com> wrote:
>
> Hi Mirja,
>
> Perhaps I misunderstood the document. The draft makes a lists
> of issues that arise when you encrypt transport headers, then
> concludes with a call to action to take these issues into
> consideration. In your reading, what is the desired outcome of
> this document? As a protocol designer, what do you expect me
> to do differently when I design my next protocol after reading this
> document? The tone seems to imply that I should leave some
> headers unencrypted in order "to ensure network operators,
> researchers and other stakeholders have appropriate tools to
> manage their networks". If this is not the intent of this draft, then
> what is it? What exact outcome or we hoping for?
>
> Thanks,
> David
>
>
> On Tue, Nov 5, 2019 at 11:14 PM Mirja Kuehlewind <
> mirja.kuehlewind@ericsson..com <mirja.kuehlewind@ericsson.com>> wrote:
>
>> Hi David,
>>
>> This document is not intended to discourage header encryption but to make
>> sure that operational considerations are taken into account when exactly
>> design new protocols that should have header encryption (as well as payload
>> encryption). If you think this document discourages header encryption, we
>> need to fix that. Would be helpful if you could indicate to the authors
>> where you think this is the case.
>>
>> Mirja
>>
>>
>> Am 05.11.2019 um 23:10 schrieb David Schinazi <dschinazi.ietf@gmail.com>om>:
>>
>> I also oppose publication of draft-ietf-tsvwg-transport-encrypt. This
>> document discourages transport header encryption and publishing it could
>> harm future protocol development.
>>
>> David
>>
>> On Tue, Nov 5, 2019 at 1:04 PM Joe Touch <touch@strayalpha.com> wrote:
>>
>>>
>>>
>>> > On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind <mirja.kuehlewind=
>>> 40ericsson.com@dmarc.ietf.org> wrote:
>>> >
>>> > What I’m hearing is that 2-3 people think this is not aligned but
>>> don’t actually say why exactly they think that
>>>
>>> That’s not what we’re saying. We gave reasons.
>>>
>>> Joe
>>>
>> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>
>