Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)

[David Schinazi <[e-mail]>]

Hi Gorry,

Thanks for updating the document, and for slightly tweaking the
tone to focus less strongly on the downsides of transport header
encryption. It's much appreciated.

However, I'm now pretty confused by the latest version (-12).
Could you help me answer these two questions please:
1) Who is the target audience for this document?
2) What should that audience walk away with?

I initially assumed that the answer to (1) was "designers
of new transport protocols". But considering myself in that
category, I don't know what I'm supposed to take away
from the draft. I was expecting the answer to (2) to be
"you SHOULD or SHOULD NOT encrypt transport protocol
headers (pick one)" but that's not the case.

Here are excerpts from the draft's Conclusion section:

   This document has described some current practises, and the
   implications for some stakeholders, when transport layer header
   encryption is used.  It does not judge whether these practises are
   necessary, or endorse the use of any specific practise.

   This document does not make recommendations about what
   information ought to be exposed, to whom it ought to be observable,
   or how this will be achieved.

   An appropriate balance will emerge over time as real instances
   of this tension are analysed [RFC7258].

The messages I'm walking away with are:
A) there is a tension between folks who want to encrypt and
    folks who don't
B) we don't have enough information, it's too early to tell what the
    impact of transport header encryption really is

As such, I'm now more confused than I was before reading the
draft, as it doesn't help me answer the question of "when designing
a new transport protocol, should I be encrypting my transport
headers or not?".

I personally oppose publication of the document as it stands,
because I find it confusing and non-actionable. I would like to see
this useful content in a BCP document once we have enough
information to actually recommend something.

Thanks,
David

On Thu, Feb 27, 2020 at 1:09 AM Gorry Fairhurst <[e-mail]>
wrote:

> The editors have just uploaded a new revision of
> draft-ietf-tsvwg-transport-encrypt following review comments. We are not
> aware of further review comments and now think that this new version is
> now ready to proceed.
>
> Best wishes,
>
> Gorry and Colin
>
> ---
> A new version of I-D, draft-ietf-tsvwg-transport-encrypt-12.txt
> has been successfully submitted by Godred Fairhurst and posted to the
> IETF repository.
>
> Name: draft-ietf-tsvwg-transport-encrypt
> Revision: 12
> Title: Considerations around Transport Header Confidentiality, Network
> Operations, and the Evolution of Internet Transport Protocols
> Document date: 2020-02-26
> Group: tsvwg
> Pages: 48
> URL:
>
> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-transport-encrypt-12.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/
> Htmlized:
> https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-12
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-12
>
> Abstract:
> To protect user data and privacy, Internet transport protocols have
> supported payload encryption and authentication for some time. Such
> encryption and authentication is now also starting to be applied to
> the transport protocol headers. This helps avoid transport protocol
> ossification by middleboxes, while also protecting metadata about the
> communication. Current operational practice in some networks inspect
> transport header information within the network, but this is no
> longer possible when those transport headers are encrypted. This
> document discusses the possible impact when network traffic uses a
> protocol with an encrypted transport header. It suggests issues to
> consider when designing new transport protocols, to account for
> network operations, prevent network ossification, enable transport
> evolution, and respect user privacy.
>
>