Dear all,
hi Mark,
...hm, apparently I *will* comment on the structure of the current document,
inline below...
On 01 May 2017, at 05:45, Mark Nottingham <mnot(_at_)mnot(_dot_)net> wrote:
Overall, this document reads as if it was originally written to highlight the
downsides of increased use of encryption, and then rewritten to be more neutral
in tone. Unfortunately, some of the original intent posited there still seeps
through.
In doing so, it often fails to convey that there are any options other than "this
has to be done by the network." I know that this has been cast as a survey of
potential impacts, and therefore doesn't necessary need to enumerate alternatives, but
the way that it's written could easily lead a reader to think that there aren't
alternatives. It also is odd that alternatives are not enumerated when they're often
well-known, and the really interesting issues are in the tradeoffs between doing
something in the network (i.e., as a third party) vs. by one of the endpoints (a first
party to communication) or their delegates.
I think the statement of alternatives is a different document, though; it's one
that needs to be written, yes, but the division of problem space and solution
space is IMO useful here.
I would agree.
The operators are used to manage their network in a certain way.
The change for more encrypted traffic will force a change of those
operational practices.
This document should serve as for a starting point to have this debate
at the IETF, based on the documentation of those operational practices.
I see this as the analogous to the split between RFC 7624 and
draft-iab-privsec-confidentiality-mitigations. It was quite useful in having the former
as a complete statement of what we think the problem is (in more detail that 7258's
declaration) before recommending solutions. And, indeed, it's entirely possible that an
IETF consensus statement on the solutions available for a given problem is "we have
decided that this is not actually a problem we should design for", as in RFC 2804.
And again agree. Not all problems in this document are valid IETF
problems. It doesn't mean that we should not document them.
Regards, Benoit
Cheers,
Brian