Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging

Hi, Gorry,

> On Oct 12, 2019, at 12:48 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> 
> I'm intrigued by how far we can understand opportunities for open client logs to replace pcap dumps, and would like to delve a little deeper into what we understand - there seem many possible actors and that may be interesting to look at a few viewpoints:

> * a user of a transport protocol (e.g., understanding cost/benefit of feature choices);

There’s only one viewpoint that drives this conversation. It’s the user’s.

If the user wants to encrypt, that’s their prerogative. We should not be recommending or assuming otherwise, 

> * a protocol developer (e.g.,  debugging transport interactions end to end);

That’s fine for them to do ON THEIR TRAFFIC. Not everyone else’s.

> * a service provider (e.g., trying to understand performance impairments in the network);

They should never need to look at others’ transport headers to do this.

> * researchers/equipment developers seeking to correlate/tune transport timing with network policies (e.g., interactions between congestion control and link scheduling);

And if we’re part of their experiment, it needs to be by opt-in and with full understanding of what data they use and how they use it.

> * exploring traffic archives (e.g., trends in what is supported or determine when an anomoly appeared).

That’s just more reason to encrypt.

> I've taken all of these viewpoints at some time using pcap to look at TCP.
> 
> Clearly when we use QUIC, there can be alternatives and there is now some experience with client (and server) logs, what do you think we can usefully say in addition to or instead of what the draft says about logging (currently mentioned only briefly in section 6.1) ?
> 
> The text on spin-bit could indeed be developed a little (the present text predates the spin bit being incorporated as an optional part of the base spec). What do you think should be said (currently at the end of 6.4)?
> 

The doc currently states, in that area (sec 6) largely as somewhat of a conclusion:

   The choice of whether future transport protocols encrypt their
   protocol headers needs to be taken based not solely on security and
   privacy considerations, but also taking into account the impact on
   operations, standards and research.

That, in a nutshell, is the problem. 

NO. Security does NOT need to “take into account” the impact on the supposed “rights” of others to make our traffic part of an experiment.

Joe

> Gorry
> 
> 
> On 09/10/2019, 15:32, Christian Huitema wrote:
>> 
>> As the draft mentions:
>> 
>>    The use of transport layer authentication and encryption exposes a
>>    tussle between middlebox vendors, operators, applications developers
>>    and users
>> 
>> Much of the draft reads like a lamentation of the horrible consequences of encrypting transport headers, which looks very much like embracing the point of view of the middlebox vendors. Expressing that point of view is of course fine, and it might be enough to change the title, abstract and introduction to reflect that this is an opinion piece. But as a transport working group document I would like something a bit more balanced. It should spend more time acknowledging the ossification and privacy issues. It should ideally lay the ground work for alternative management solutions, such as controlled exposure like the spin bit in QUIC, IP header information, or standardized logs like the QLOG effort.
>> 
>> -- Christian Huitema
>> 
>> 
>> On 10/8/2019 2:08 PM, Black, David wrote:
>>> 
>>> FYI – some OPS area and SEC area eyes on this TSVWG draft now (during WGLC) would be a good thing ;-).
>>> 
>>> Thanks, --David (TSVWG co-chair)
>>> 
>>> *From:* Black, David <david.black@emc.com>
>>> *Sent:* Tuesday, October 8, 2019 5:06 PM
>>> *To:* tsvwg@ietf.org
>>> *Cc:* Black, David
>>> *Subject:* WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
>>> 
>>> This email announces a TSVWG Working Group Last Call (WGLC) on:
>>> 
>>> The Impact of Transport Header Confidentiality on Network Operation and
>>> 
>>>                       Evolution of the Internet
>>> 
>>>                 draft-ietf-tsvwg-transport-encrypt-08
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/
>>> 
>>> This draft is intended to become an Informational RFC.
>>> 
>>> This WGLC will run through the end of the day on Wednesday, October 23.
>>> 
>>> That should allow time before the Singapore draft submission cutoff for
>>> 
>>> the authors to revise the draft with any changes that result from WGLC.
>>> 
>>> Comments should be sent to the tsvwg@ietf.org <mailto:tsvwg@ietf.org> list, although purely
>>> 
>>> editorial comments may be sent directly to the authors. Please cc: the
>>> 
>>> WG chairs at tsvwg-chairs@ietf.org <mailto:tsvwg-chairs@ietf.org>  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, Gorry and Wes
>>> 
>>> (TSVWG Co-Chairs)
>>> 
>>> 
>>> _______________________________________________
>>> saag mailing list
>>> saag@ietf.org
>>> https://www.ietf.org/mailman/listinfo/saag
> 