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

Fernando Gont <fernando@gont.com.ar> Tue, 01 September 2009 05:34 UTC

Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5DF3A6EBA for <tcpm@core3.amsl.com>; Mon, 31 Aug 2009 22:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.166
X-Spam-Level:
X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipBnNOTJD2XP for <tcpm@core3.amsl.com>; Mon, 31 Aug 2009 22:34:08 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 967F63A6E1B for <tcpm@ietf.org>; Mon, 31 Aug 2009 22:34:06 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 7DAA46B6600; Tue, 1 Sep 2009 02:34:24 -0300 (ART)
Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n815Y0a1020393; Tue, 1 Sep 2009 02:34:01 -0300
Message-ID: <4A9CB254.7050802@gont.com.ar>
Date: Tue, 01 Sep 2009 02:34:12 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <200908262238.AAA06336@TR-Sys.de> <4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar> <4A9AB5C2.4090209@isi.edu>
In-Reply-To: <4A9AB5C2.4090209@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 01 Sep 2009 02:34:23 -0300 (ART)
Cc: Alfred ? <ah@tr-sys.de>, tcpm@ietf.org
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2009 05:34:09 -0000

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: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1