Subject: [tsvwg] draft-ietf-tsvwg-transport-encrypt-13.txt - concern summaries

From: "Black, David" <[email-masked]>
Date: Mon, 23 Mar 2020 13:12:08 +0000

David (S) and Ekr,

The prompt reviews are appreciated, thank you.  I first want to make sure that there’s a clear understanding of the concerns.

Looking at the email that David Schinazi referenced, this appears to be a good summary of his concerns:

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.

I’m having more difficulty in finding a good summary of Ekr’s concerns.   Going back to his comments on the -08 version during the first WGLC, I found this:

Having an IETF Consensus RFC that is so heavily weighted on the side of "this is how encryption inconveniences us" and so light on "these are the attacks we are preventing" gives a misleading picture of the IETF community's view of the relative priority of these concerns.  ISTM that RFC 8558 -- though perhaps imperfect -- far more closely reflects that consensus.

So, are those reasonable summaries of each of your concerns?  If not, please revise and send to the list, making effort avoid significant extensions (so that the results are still summaries).

Thanks, --David (as draft shepherd)

From: tsvwg <[email-masked]> On Behalf Of David Schinazi
Sent: Sunday, March 22, 2020 7:56 PM
To: Eric Rescorla
Cc: Gorry Fairhurst; tsvwg IETF list
Subject: Re: [tsvwg] Rev 13 of : draft-ietf-tsvwg-transport-encrypt-13.txt

[EXTERNAL EMAIL]
I went through the diff from -12 and -13 and didn't see that addressing my concerns [1].

I still personally oppose publication of the document as-is.

[1] https://mailarchive.ietf.org/arch/msg/tsvwg/nnSr8_nrw7YepWFWA7tLc1k3Nv0/

Thanks,
David

On Sat, Mar 21, 2020 at 6:40 AM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
I do not believe that this version of the document addresses my concerns. The overall tonal issues remain unchanged.

-Ekr

On Sat, Mar 21, 2020 at 5:18 AM Gorry Fairhurst <[email-masked]<mailto:[email-masked]>> wrote:
Thanks to all who provided comments on and off list, this document was improved by understanding the feedback. We worked with the document shepherd (David) to address the issues, and expect this revision is now in good shape to proceed.

Gorry (as Co-Editor)

Sent from my iPad

> On 21 Mar 2020, at 10:07, [email-masked]<mailto:[email-masked]> wrote:
>
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group WG of the IETF.
>
>        Title           : Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols
>        Authors         : Godred Fairhurst
>                          Colin Perkins
>    Filename        : draft-ietf-tsvwg-transport-encrypt-13.txt
>    Pages           : 50
>    Date            : 2020-03-21
>
> 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 or features.  These
>   considerations arise from concerns such as network operations,
>   prevention of network ossification, enabling transport protocol
>   evolution and respect for user privacy.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-13
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-13
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>

---

From: David Schinazi <[email-masked]>
Date: Mon, 23 Mar 2020 09:09:09 -0700

Hi David (B),

Yes, this summarizes my concerns.

David (S)

On Mon, Mar 23, 2020 at 6:12 AM Black, David <[email-masked]> wrote:

> David (S) and Ekr,
>
>
>
> The prompt reviews are appreciated, thank you.  I first want to make sure
> that there’s a clear understanding of the concerns.
>
>
>
> 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
>
> I’m having more difficulty in finding a good summary of Ekr’s concerns.
> Going back to his comments on the -08 version during the first WGLC, I
> found this:
>
>
>
> Having an IETF Consensus RFC that is so heavily weighted on the side of
> "this is how encryption inconveniences us" and so light on "these are the
> attacks we are preventing" gives a misleading picture of the IETF
> community's view of the relative priority of these concerns.  ISTM that RFC
> 8558 -- though perhaps imperfect -- far more closely reflects that
> consensus.
>
>
>
> So, are those reasonable summaries of each of your concerns?  If not,
> please revise and send to the list, making effort avoid significant
> extensions (so that the results are still summaries).
>
>
>
> *From:* tsvwg <[email-masked]> *On Behalf Of * David Schinazi
> *Sent:* Sunday, March 22, 2020 7:56 PM
> *To:* Eric Rescorla
> *Cc:* Gorry Fairhurst; tsvwg IETF list
> *Subject:* Re: [tsvwg] Rev 13 of :
> draft-ietf-tsvwg-transport-encrypt-13.txt
>
>
>
> [EXTERNAL EMAIL]
>
> [1]
> https://mailarchive.ietf.org/arch/msg/tsvwg/nnSr8_nrw7YepWFWA7tLc1k3Nv0/
>
>
>
> Thanks,
>
> David
>
>
>
> On Sat, Mar 21, 2020 at 6:40 AM Eric Rescorla <[email-masked]> wrote:
>
> I do not believe that this version of the document addresses my concerns.
> The overall tonal issues remain unchanged.
>
>
>
> -Ekr
>
>
>
>
>
> On Sat, Mar 21, 2020 at 5:18 AM Gorry Fairhurst <[email-masked]>
> wrote:
>
> Thanks to all who provided comments on and off list, this document was
> improved by understanding the feedback. We worked with the document
> shepherd (David) to address the issues, and expect this revision is now in
> good shape to proceed.
>
> Gorry (as Co-Editor)
>
> Sent from my iPad
>
> > On 21 Mar 2020, at 10:07, [email-masked] wrote:
> >
> > 
> >        Title           : Considerations around Transport Header
> Confidentiality, Network Operations, and the Evolution of Internet
> Transport Protocols
> > until the htmlized version and diff are available at tools.ietf.org.
> >