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

[Colin Perkins <[e-mail]>]

Right – my goal with this draft is not to say ‘encrypt' or 'don’t encrypt' the transport headers, but rather to highlight various issues to consider when deciding whether, and what, to encrypt. It’s information to help transport designers make an informed choice. 

Colin



> On 27 Feb 2020, at 21:26, Martin Duke <[e-mail]> wrote:
> 
> One thing that came out of the spin bit discussion is that some transport protocol experts honestly do not understand how this information is used constructively in the network. That may be why the initial tone may have been a little unbalanced.
> 
> To answer your question, David, I think your takeaway as a transport designer is to understand what you are sacrificing when you encrypt transport headers, and consider exposing specific items if the benefits would suit the use case. Other transport designers (though none that I actually know) might benefit from an explanation on why transport encryption is worth doing.
> 
> Martin
> 
> On Thu, Feb 27, 2020 at 12:25 PM Spencer Dawkins at IETF <[e-mail] <mailto:[e-mail]>> wrote:
> Speaking as a non-area director (so, I don't have a hat to remove) ... 
> 
> On Thu, Feb 27, 2020 at 1:18 PM Gorry Fairhurst <[e-mail] <mailto:[e-mail]>> wrote:
> We discussed the scope a lot at the start, and the advice I received was that this is not the document to tell people about what they have to do.
> 
> I think the decisions about whether to encrypt all transport fields or some or none isn't something I saw huge consensus upon. I did see many strong arguments, but what I heard often depended on which working group was speaking and the background of people involved. Had I asked a different question, e.g. do you think Privacy is important I would have got a different answer (we do have a BCP that notes that).
> 
> The AD advice I recall at the time we asked to work on this, correct me Spencer if I am wrong, was to not attempt a BCP until the WG could first publish an informational document. This is that document. The purpose then, as I see, is to examine where we have arrived. Had we had a document like this, other discussions such as how to manage QUIC, whether PLUS could be useful, etc could have been more informed and focussed.
> 
> I believe I was the AD who gave this advice, and Gorry is recounting that story the way I remember it. 
> 
> From my perspective, we had just been through a great deal of kerfluffling with MARNEW(1), SPUD(2), ACCORD(3), PLUS(4), and "Effects of Pervasive Encryption on Operators"(5), all of which had various levels of food-flinging, and all of which had various levels of assertions about whether operators needed to manage transport protocols, with little agreement on ground truths about what was, and was not, possible to manage when looking at existing transport protocols. 
> 
> I wasn't seeing anything that led me to expect that to change before the earth fell into the sun, and the volume level was increasing (watching Meetecho for the PLUS BOF would drive anyone to drink, even today). So I encouraged Gorry to focus on ground truths, so that we would be able to actually have discussions about what might go into a BCP for protocol designers (as David reasonably points out, that would be great), and/or a BCP for network operators.
> 
> One can debate whether I did the right thing (but that wasn't appealed, and I wasn't recalled). I'd defer to the current ADs (both now and after IETF 107) on what to do next, but I thought it would be useful to provide background on how TSVWG got here.
> 
> Best of luck to Magnus, Mirja, and Martin, of course. And you don't HAVE to have a name that starts with the letter "M" to stand as a nominee for TSV AD this coming Nomcom cycle :-)
> 
> Best,
> 
> Spencer
> 
> (1) https://datatracker.ietf.org/doc/rfc8462/ <https://datatracker.ietf.org/doc/rfc8462/>
> (2) https://datatracker..ietf.org/doc/minutes-92-spud/ <https://datatracker.ietf.org/doc/minutes-92-spud/>
> (3) https://www.ietf.org/proceedings/95/minutes/minutes-95-accord <https://www.ietf.org/proceedings/95/minutes/minutes-95-accord>
> (4) https://datatracker.ietf.org/doc/minutes-96-plus/ <https://datatracker.ietf.org/doc/minutes-96-plus/>
> (5) https://datatracker.ietf.org/doc/rfc8404/ <https://datatracker.ietf.org/doc/rfc8404/>


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