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

[<[e-mail]>]

I think there needs to be some form of hum relating to this. There seems
to be a relatively small number of people expressing relatively strong
opinions on this document that are clearly incompatible. One key thing,
regardless of how we actually decide to split the work, Fernando's
current ToC is too long... 3 pages of ToC is excessive. I think the
sections aren't grouped at a high enough level (e.g. connection
establishment and tear-down could be in one section on connection
management, buffer management and re-assembly could probably be grouped
into memory management, etc). This is separate to any consideration as
to whether you should be presenting things in a completely different
order... I think Joe actually raised this before...

1 inline comment as well

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> Fernando Gont
> Sent: 01 September 2009 06:34
> To: Joe Touch
> Cc: Alfred ?; [e-mail]
> Subject: Re: [tcpm] tcp-security: Request for feedback on the outline
> of the document
> 
> 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.

So if this is entirely aimed at implementers shouldn't that be
explicitly stated in the title? I appreciate that in theory BCP is meant
to imply implementation guidance but this might be more appropriately
titled something like "Implementers guidelines for mitigating TCP
security threats" or "Guidance on secure implementation of TCP"


> 
> 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
> 
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm