Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

[Mike Bishop <[e-mail]>]

At a high level, I find myself agreeing with David and Ekr: this document doesn’t tell you whether to encrypt, it describes what breaks if you do.  According to the Conclusion, that is its goal.

   This document has described some current practises, and the

   implications for some stake holders, when transport layer header

   encryption is used.  It does not judge whether these practises are

   necessary, or endorse the use of any specific practise.

I was surprised, however, that it doesn’t go into equal depth about what breaks if you don’t encrypt.  While both sides of the coin are present in the document, one side is presented in considerably more detail than the other.  This document starts off fairly balanced; I found Section 2 to be an excellent discussion of the trade-offs in this space.  Section 3 turns a corner into an extensive discussion of all the things inspection of the transport headers are used for today, weighing in at 14 pages.  Interestingly, this includes at least one example of exactly the behavior that’s discussed as a problem in Section 2:

      A network operator can observe the headers of transport protocols
      layered above UDP to understand if the datagram flows comply with
      congestion control expectations.

Dropping packets which don’t comply with the operator’s “expectations” in a protocol they don’t understand is exactly why new protocols and evolution of existing protocols want to limit the ability of these devices to inspect their traffic.

Section 4.1 devotes all of one page to the reasons why protocol developers might choose to encrypt; the rest of section 4 describes various forms of integrity and confidentiality mechanisms in extant protocols.  The remainder of the document discusses alternative ways to enable the scenarios of Section 3 in the presence of encryption.


On the whole, I think this document could be suitable for publication as an Informational RFC; it provides real-world context for a trade-off that every protocol designer needs to consider carefully.  However, I don’t believe its current state reflects, in Ekr’s words, “the IETF community's view of the relative priority of these concerns.”


From: QUIC <[e-mail]> On Behalf Of Lars Eggert
Sent: Wednesday, June 10, 2020 4:08 AM
To: IETF QUIC WG <[e-mail]>
Subject: Fwd: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

FYI


Begin forwarded message:

From: "Black, David" <[e-mail]<mailto:[e-mail]>>
Subject: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
Date: June 9, 2020 at 4:41:40 GMT+3
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: int-area <[e-mail]<mailto:[e-mail]>>, IETF SAAG <[e-mail]<mailto:[e-mail]>>

This email announces a limited-scope 3rd TSVWG Working Group Last Call (WGLC) on:

    Considerations around Transport Header Confidentiality, Network
     Operations, and the Evolution of Internet Transport Protocols
                 draft-ietf-tsvwg-transport-encrypt-15
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/

This draft is intended to become an Informational RFC.  This WGLC has
been cc:’d to the SAAG and INT-AREA lists courtesy of the breadth of
interest in this draft, but WGLC discussion will take place on the TSVWG
list ([e-mail]<mailto:[e-mail]>) – please don’t remove that list address if/when
replying with WGLC comments.

This 3rd WGLC will run through the end of the day on Monday, June 29,
2 weeks before the draft submission cutoff for IETF 108.

This 3rd WGLC is limited to the following two topics:


  1.  Whether or not to proceed with a request for RFC publication
of the draft.   The decision on whether or not to proceed will
be based on rough consensus of the WG, see RFC 7282.
During the 2nd WGLC, Eric Rescorla and David Schinazi expressed
strong views that this draft should not be published –  those
concerns have not been resolved and are carried forward to
this WGLC.  This email message was an attempt to summarize
those concerns:
https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/
Further explanation from both Eric Rescorla and David Schinazi
is welcome and encouraged to ensure that their concerns are
clearly understood.


  1.  Review of changes made since the -12 version of the draft that
was the subject of the second WGLC (e.g., whether or not they
suffice to resolve concerns raised during that WGLC, other
than overall objections to publishing this draft as an RFC):
https://www.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-transport-encrypt-12&url2=draft-ietf-tsvwg-transport-encrypt-15

Comments should be sent to the [e-mail]<mailto:[e-mail]> list, although purely
editorial comments may be sent directly to the authors.  Please cc: the
WG chairs at [e-mail]<mailto:[e-mail]>  if you would like the chairs to
track such editorial comments as part of the WGLC process.

No IPR disclosures have been submitted directly on this draft.

Thanks,
David and Wes (TSVWG Co-Chairs – Gorry is recused as a draft author)