RE: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

[<[e-mail]>]

Actually, no, similar holdups do not occur for concerns of error-handling. Examples:

in DTNRG (which, though IRTF, is highly relevant, being chaired as it is by the now security AD):
- LTP was developed with no error detection: RFC5326. Managed to get some shoehorned in at
the last moment in the NULL bits of RFC5237, but that was not a holdup.
- the bundle protocol was developed with no error detection, and no following of the
end-to-end principle. That took ten years or so, a lot of researchers, a national space agency...

but in DTNRG, security was paramount in the design (and focused on by the chairs). Those are the results.
The judgement calls come down in favour of security concerns above all else.

In the IETF:
RFCs 6935 and 6936, which relax the endpoint payload and pseudoheader check by
allowing zero checksums in IPv6, because tunnelled payloads with their own checks 
just don't need it. (That other applications do because IPv6 itself is lax on
reliability checks, has no header-only check and the closest it would get to an endpoint
header check would be UDP-lite, and the applications can be polluted by mis-arriving
errored  zero-checksum UDP packets, is neither here nor there. This is arguably the
predictable outcome of some poor design decisions in IPv6 twenty years ago.)

I'd welcome counterexamples where errors forced a holdup and rethink. I know of none.

We're heading into a world where security is paramount, and the only reason we have
any reliability in protocols at all is as a sideeffect of the security rejecting perceived attacks,
and not because we actually know how to design error-rejecting protocols. (How many
people here could design a CRC? How many design secure systems?)

There will be no further internet engineering (which, given that 6935/6936 are
proposed standards, never mind the horse-designed-by-committee IPv6 camel,
may actually not be a bad thing); any internet engineering done, or any
reliability obtained in implementations, will just be an unintended sideeffect
of security as a discipline.

Lloyd Wood
http://about.me/lloydwood

http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
________________________________________
From: Tim Bray [[e-mail]]

> There are very few (any?) absolutes in any of the protocols we build, just a wealth
> of often-conflicting design criteria, which force us to trade off and make judgment calls.
>  draft-perpass-attack says that mitigation of pervasive surveillance should be seen as
> one of the design criteria, and it’s not OK to ignore it. A reasonable take is that a specification
> could be held up if there are plausible arguments that this criterion has not been given appropriate
> consideration, and I see nothing wrong with that. Similar hold-ups regularly occur when there are
> concerns that there hasn’t been appropriate consideration for efficiency or error-handling or, well, lots of other criteria.