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

[Gorry Fairhurst <[e-mail]>]

We discussed the scope a lot at the start, and the advice I received was 
that this is not the document to tell people about what they have to do.

I think the decisions about whether to encrypt all transport fields or 
some or none isn't something I saw huge consensus upon. I did see many 
strong arguments, but what I heard often depended on which working group 
was speaking and the background of people involved. Had I asked a 
different question, e.g. do you think Privacy is important I would have 
got a different answer (we do have a BCP that notes that).

The AD advice I recall at the time we asked to work on this, correct me 
Spencer if I am wrong, was to not attempt a BCP until the WG could first 
publish an informational document. This is that document. The purpose 
then, as I see, is to examine where we have arrived. Had we had a 
document like this, other discussions such as how to manage QUIC, 
whether PLUS could be useful, etc could have been more informed and 
focussed.

Gorry

On 27/02/2020 18:39, David Schinazi wrote:
> 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] 
> <mailto:[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/
>     <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.
>