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

[Gorry Fairhurst <[e-mail]>]

Ekr,

On 15/03/2020 13:19, Eric Rescorla wrote:
> Let me try to expand my point a bit.
>
> Longstanding practice is for entities in the middle of the network to
> use signals that were intended for the endpoint for their own
> purposes.  With QUIC (and a lesser extent SCTP/DTLS), those signals
> are being encrypted and thus unavailable to those non-endpoint
> entities; this draft is mostly devoted to documenting the negative
> impact of that change on the operations of those entities.
>
I disagree that this is "documenting the negative impact of that change".

The draft is about how this protocol information has and is being used. 
As long as I can remember, there has been devices that utilise some of 
this information, at the edge of an enterprise there is often at least 
one device with this role; within a managed network there are devices; 
etc. If the trend to use encrypted methods continues, some of these 
practices need to be re-assessed, and the functions more widely 
understood than in an era when nearly everything was thought to be TCP 
or "multimedia".

There has additionally also long been a viewpoint that transport layer 
information should not have only been used end to end. IPSec in the 
past, QUIC now, provide protocols that match that view. This is not that 
document.

> As I indicated in my review, I'm not aware of any significant new
> transport protocol that doesn't have this property. It's true that
> some protocols (QUIC, primarily) are deliberately exposing some
> information in the clear, but they're not doing it by not encrypting
> signals intended for the endpoint. Rather, as contemplated by RFC
> 8558, they are adding *extra* signals, such as the spin bit, that are
> intended only for the middle (indeed this is what makes them optional
> from the endpoint perspective).
>
> -Ekr
>
I like the IAB contributing documents like this, but it's information to 
help see a view of the future. I hope RFC 8558 provides useful input to 
this. This is not that document, either.

Personally, I'd be keen to see clearer differentiation about what 
infromation is to be used in what way - whether this is below or at the 
transport.

Hope that helps explain a little,

Gorry

>
> On Fri, Mar 13, 2020 at 10:30 AM Martin Duke <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     I have no idea, but the draft isn't meant to be a point solution
>     to loss bits. I suspect loss bits are not the last time someone
>     will want to expose more info.
>
>     On Fri, Mar 13, 2020 at 9:41 AM Eric Rescorla <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>
>         On Fri, Mar 13, 2020 at 9:36 AM Martin Duke
>         <[e-mail] <mailto:[e-mail]>> wrote:
>
>             (With all hats off)
>
>             ekr,
>
>             I don't think the encrypt-or-don't decision is as binary
>             as you suggest. Today, QUIC implementers can decide
>             whether or not they will implement the spin bit. As you
>             well know, QUIC loss bits are potentially coming down the
>             way and this draft, in some form, may inform that discussion.
>
>
>         Perhaps, but what fraction of the practices in this document
>         would be enabled by even the loss bits?
>
>         -Ekr
>
>
>             I'll abstain from any position on the tone of the document
>             until I have a chance to re-read it.
>
>             Martin
>
>             On Fri, Mar 13, 2020 at 9:21 AM Eric Rescorla
>             <[e-mail] <mailto:[e-mail]>> wrote:
>
>                 Document: draft-ietf-tsvwg-transport-encrypt-12.txt
>
>                 I more or less concur with David's comments.
>
>                 First, it's really not clear what purpose this
>                 document serves.  While
>                 superficially an analysis of the impact of transport
>                 layer encryption
>                 as a guide to designers, in the context of the design
>                 and deployment
>                 of QUIC and SCTP/DTLS, both of which encrypt most or
>                 all of the
>                 transport header, it's hard not to read this document
>                 as an implicit
>                 critique of those decisions. It's not like there's
>                 some other big
>                 transport protocol design effort going on in IETF that
>                 would be
>                 informed by these considerations.
>
>                 With that said, I don't think we should neutral on
>                 this topic: the
>                 last two newish transport protocol stacks that the
>                 IETF has designed
>                 (SCTP/DTLS and QUIC) both incorporate transport header
>                 encryption and
>                 I haven't heard anyone propose that we design a new
>                 protocol without
>                 that, so I think any document that we publish should
>                 state that this
>                 is a good thing while also documenting the challenges
>                 it creates.
>
>                 However, this document isn't really even neutral: it
>                 spends vastly
>                 more time on the negative impacts to non-endpoint
>                 network actors than
>                 it does on the benefits to the endpoints, and while it
>                 does
>                 acknowledge those benefits, they are often framed in a
>                 sort of "people
>                 say" framing, which isn't really applied to the
>                 practices which are
>                 negatively impacted, which are largely taken at face
>                 value. Compare
>                 the following passages:
>
>                    o  One motive to encrypt transport headers is in
>                 response to
>                       perceptions that the network has become
>                 ossified, since traffic
>                       inspecting middleboxes prevent new protocols and
>                 mechanisms from
>                       being deployed.  One benefit of encrypting
>                 transport headers is
>                       that it can help improve the pace of transport
>                 development by
>                       eliminating interference by deployed middleboxes.
>
>                 and:
>
>                    In some cases, network-layer use of transport
>                 header information can
>                    be benign or advantageous to the protocol (e.g.,
>                 recognising the
>                    start of a TCP connection, providing header
>                 compression for a Secure
>                    RTP flow, or explicitly using exposed protocol
>                 information to provide
>                    consistent decisions by on-path devices).  Header
>                 compression (e.g.,
>                    [RFC5795]) depends understanding of transport
>                 header and the way
>                    fields change packet-by-packet; as also do
>                 techniques to improve TCP
>                    performance by transparent modification of
>                 acknowledgement traffic
>                    [RFC3449].  Introducing a new transport protocol or
>                 changes to
>                    existing transport header information prevent these
>                 methods being
>                    used or require the network devices to be updated.
>
>                 In the first passage, the use "in response to
>                 perceptions" creates
>                 the impression that ossification is just some people's
>                 opinion,
>                 whereas it seems to me that it is a commonly
>                 understood fact of
>                 the network that has been an obstacle to deployment of
>                 everything
>                 from DNSSEC to TLS 1.3. By contrast, the second
>                 passage implies
>                 that tampering with acknowledgments is "benign or
>                 advantageous"
>                 when there is actually quite a bit of debate about whether
>                 this is a good idea (although I recognize that you are
>                 citing
>                 a BCP which recommends it).
>
>
>                 A second way in which this document is non-neutral is
>                 that it focuses
>                 largely on network-side interventions which seem to be
>                 well-intended
>                 (i.e., the operator is attempting to serve the users
>                 interests). However, there are also a wide variety of
>                 interventions
>                 which are adverse to the users interests (e.g.., RST
>                 spoofing, as is
>                 done by the Great Firewall [0]). By focusing on the
>                 downsides of encryption
>                 while minimizing the harms that encryption is intended
>                 to prevent
>                 this document again comes off as largely a critique of
>                 transport
>                 layer encryption in general.
>
>
>                 For these reasons, I don't think that this document
>                 should be published
>                 without extensive revision.
>
>                 -Ekr
>
>
>                 [0] https://www.cl.cam.ac.uk/~rnc1/ignoring.pdf
>
>
>
>                 On Thu, Feb 27, 2020 at 10:40 AM David Schinazi
>                 <[e-mail]
>                 <mailto:[e-mail]>> 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.
>