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

[Martin Thomson <[e-mail]>]

On Tue, Jun 9, 2020, at 11:41, Black, David wrote:
>  1. Whether or not to proceed with a request for RFC publication
> of the draft. 

I think that this is in many ways vastly improved over earlier versions.  Much of the language that was more directly addressing the shortcomings.

If RFC 8517 had IETF consensus and RFC 8404 had IETF consensus, then this would clearly be a good companion to those documents.  In many ways, this is a far better document.  If you were to consider this the unabridged version of Section 2 of RFC 8558, then it's a pretty good attempt at capturing uses.  Though, like Ekr, I wonder about the distinct absence of stuff that is clearly bad, because there's a lot of that too.

However, despite having quite a reasonable introduction and conclusion, the impression the document leaves is that the use of encryption is endangering the livelihoods of a great many people and that is a bad thing.  I don't think that it is possible to avoid with a document in this form.

After reading it through (again, it's quite long), I reached the conclusion that all the trappings and disclaimers don't serve their intended end, but they tend to work against it.  By so clearly addressing the whole problem in framing, but then spending the bulk of the text on one aspect of that problem, the overwhelming impression is that there is a great deal of substance to the view that use of encryption produces harms.  After all, look at all these useful things that can't be done any more.

Instead, I think it could be better to dispense with the attempt to be balanced and simply present - without attempts to motivate, frame, or justify - the practices that are employed by intermediaries.  Including a brief diversion regarding some of the bad things, realizing that any attempt to plumb the depths of that particular rathole would never end.

Of course, that makes me even more inclined to recommend following the path RFC 8517 took.