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

Joe Touch <touch@ISI.EDU> Sun, 30 August 2009 17:24 UTC

Return-Path: <touch@ISI.EDU>
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 D08003A6BB6 for <tcpm@core3.amsl.com>; Sun, 30 Aug 2009 10:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.282
X-Spam-Level:
X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_50=0.001]
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 b9e4tCd0lfMp for <tcpm@core3.amsl.com>; Sun, 30 Aug 2009 10:24:30 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A54613A6AF4 for <tcpm@ietf.org>; Sun, 30 Aug 2009 10:24:30 -0700 (PDT)
Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n7UHOI5h026340; Sun, 30 Aug 2009 10:24:20 -0700 (PDT)
Message-ID: <4A9AB5C2.4090209@isi.edu>
Date: Sun, 30 Aug 2009 10:24:18 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <200908262238.AAA06336@TR-Sys.de> <4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar>
In-Reply-To: <4A9894C3.4020300@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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: Sun, 30 Aug 2009 17:24:31 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>> The various past reviewers of the original document had
>>> appreciated the focus on implementer's point of view,...
>> This is a good point. This isn't just an implementer's guide, however.
>> Some of the issues are being discussed in detail for the first time in
>> this doc.
> 
> 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. However, we'd also be allowing (if not encouraging) use
of protections as appropriate, rather than encouraging everyone to
implement every protection - some of which are not agreed as recommended
by the WG.

...
>> Some of the ways to address vulnerabilities are choices that the specs
>> left open to implementers. Some are weaknesses in the protocol itself
>> that a clever implementation can overcome (e.g. SYN cookies to overcome
>> the state introduced at SYN receipt). Others are created by inefficient
>> implementations (e.g., badly implemented TIME-WAIT state lists).
> 
> What's the difference in here? Are we concerned about "who gets the blame"?

This doc isn't only useful to implementers. People developing specs care
about #1 - maybe these are holes to be filled. #2 can result in
interactions between the solution and the protocol that were unintended.
#3 is just good design.

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.

...
>> In the submitted I-D, protocol field properties are covered in sections
>> 3,5,8,9,11,13,14,15. 
> 
> I disagree. Protocol field properties are covered in Sections 3 and 4.
> e.g., Sections 5 through 9 cover specific mechanisms or policies, but
> not the fields themselves.

Well, I found 8 places. You found 2 places at least, if not another 2
for a total of 4 (I don't care whether it's a mechanism or policy, if it
affects the field).

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.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqatcIACgkQE5f5cImnZrsKVwCePmS9DAO6Xxt4+weErbm/wBRL
YnwAn2awO7qNPzPmrhn4LsJZR9bt3htO
=+qJs
-----END PGP SIGNATURE-----