Re: [tcpm] tcp-security: Request for feedback on the outline of the document

[Fernando Gont <[e-mail]>]

Hello, Joe,

>> The latter is true, but the document is still meant to target
>> implementers. If you spread the advice on a per-attack basis, or on a
>> protocol-weaknesses vs. implementer's-choice-weaknesses, you're
>> basically spreading the advice about a single protocol field or option
>> among multiple sections.
> 
> Maybe - some fields are susceptible to only a small set of attacks that
> may be related. 

That's the exception, not the rule.


> However, we'd also be allowing (if not encouraging) use
> of protections as appropriate, rather than encouraging everyone to
> implement every protection - 

Joe, this is about hardening a TCP implementation, not about mitigating
some vulnerabilities while leaving the door open to the rest of them.



> An implementer needs to know when they're playing inside a box the spec
> created (#1), playing around in ways that could affect the protocol now
> or in the future (#2), or just need to apply known algorithms rather
> than modify the protocol.

Exactly. That's why the document does not simply provide the "what to
do", but also provides a discussion of the mitigations, etc.

But the document is still aimed at implementers. A bunch of implementers
have already reviewed the document, and found the current outline useful.



> The point is that in the outline proposed in ID-0, there are multiple
> top-level sections where these issues are discussed. The idea that "an
> implementer wants to find things in one place" is fine, but IMO the
> outline I proposed may to a mode useful job of aggregating this
> information than ID-0.

Again: the goal of this document is helping TCP implementers harden
their TCPs. And for that target, having everything about a protocol
field in a single place is the only document outline that does not get
in the middle of the developer and the implementation. If you spread the
advice among lots of places, this is what will happen: some mitigations
will be missed.

I'm not saying the outline you propose is "wrong". I'm saying it's not
the best approach for the public this document targets. That doesn't
mean that an alternative outline can be included in an appendix. -- that
may be useful.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1