Re: [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

[Colin Perkins <[e-mail]>]

> On 6 Nov 2019, at 08:14, S Moonesamy <[e-mail]> wrote:
> At 06:48 PM 04-11-2019, Joe Touch wrote:
>> That only happens if the WG and IESG say this is out of scope for the IETF. I.e., the ISE isn't an end-run.
>> 
>> IMO, given the fact that this is squarely within TSVWG and there's no consensus, the way forward is clear.
> 
> The draft is within the scope of the IETF given that it is a Working Group draft.
> 
> I went through the draft.  In Section 2:
> 
>  "To achieve stable Internet operations, the IETF transport community
>   has to date relied heavily on the results of measurements and the
>   insights of the network operations community to understand the trade-
>   offs, and to inform selection of appropriate mechanisms to ensure a
>   safe, reliable, and robust Internet (e.g., [RFC1273])."
> 
> That statement is backed by a citation to a RFC which pre-dates the IETF.
> 
> Is the draft a statement from the transport community or is it intended to be a statement from the IETF (as a whole)?  If it is the latter, it could be read as building a case against RFC 7258.


The sentence immediately following that you quote is "Encryption is expected to form a core part of future transport protocol designs”, so I fail to see that. 

RFC 7258 says, in Section 2, that:

>    While PM is an attack, other forms of monitoring that might fit the
>    definition of PM can be beneficial and not part of any attack, e.g.,
>    network management functions monitor packets or flows and anti-spam
> 
> 
> 
> Farrell & Tschofenig      Best Current Practice                 [Page 3]
> RFC 7258            Pervasive Monitoring Is an Attack           May 2014
> 
> 
>    mechanisms need to see mail message content.  Some monitoring can
>    even be part of the mitigation for PM, for example, certificate
>    transparency [RFC6962] involves monitoring Public Key Infrastructure
>    in ways that could detect some PM attack techniques.  However, there
>    is clear potential for monitoring mechanisms to be abused for PM, so
>    this tension needs careful consideration in protocol design.  Making
>    networks unmanageable to mitigate PM is not an acceptable outcome,
>    but ignoring PM would go against the consensus documented here.  An
>    appropriate balance will emerge over time as real instances of this
>    tension are considered.

This draft is discussing some of the issues that go into finding such an appropriate balance when considering transport protocol design. It does not say do not encrypt transport headers; it does say to consider certain issues and make an informed choice what parts of the transport headers should be encrypted and what should be exposed. There is a trade-off in protocol design. As the QUIC spin bit and ossification discussions show, there are reasons to expose certain header information and ways of doing so that preserve user privacy and protocol extensibility. This draft is encouraging that discussion, not pre-judging its outcome.

-- 
Colin Perkins
https://csperkins.org/