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 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.
Cheers,
Brian
signature.asc
Description: Message signed with OpenPGP using GPGMail