Re: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04

David Borman <> Fri, 01 June 2012 14:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 614AB11E814C; Fri, 1 Jun 2012 07:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.909
X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DZq+2W9M2rKS; Fri, 1 Jun 2012 07:06:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4677C11E8120; Fri, 1 Jun 2012 07:06:15 -0700 (PDT)
Received: from pps.filterd (m0001158 []) by (8.14.4/8.14.4) with SMTP id q51E535k005396; Fri, 1 Jun 2012 07:06:04 -0700
Received: from ([]) by with ESMTP id 156qb2ge2y-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 01 Jun 2012 07:06:04 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 1 Jun 2012 07:05:39 -0700
Received: from ([fe80::6081:f8af:54f6:10cc]) by ([fe80::e4fd:df34:99ee:ac5e%20]) with mapi id 14.01.0355.002; Fri, 1 Jun 2012 08:06:03 -0600
From: David Borman <>
To: "Scharf, Michael (Michael)" <>
Thread-Topic: secdir review of draft-ietf-tcpm-tcpmss-04
Thread-Index: AQHNPnXIPFIPS9owW0+7AUuNti9CaZbi+xyAgAAC+4CAAAs/AP//voCggAMfLYA=
Date: Fri, 1 Jun 2012 14:06:01 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-06-01_03:2012-05-21, 2012-06-01, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1206010117
X-Mailman-Approved-At: Fri, 01 Jun 2012 07:33:13 -0700
Cc: "<>" <>, The IESG <>, "<>" <>
Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Jun 2012 14:06:16 -0000

On May 30, 2012, at 3:47 PM, Scharf, Michael (Michael) wrote:

>>>> I don't have a strong opinion about the current content of the 
>>>> Security Considerations section.  My leaning is to just 
>> leave it as 
>>>> is, but I'd be fine with moving the content up to section 
>> 5.4 as an 
>>>> "Additional Consideration", and then have section 6, "Security 
>>>> Considerations" just have a comment that there are no security 
>>>> considerations, if folks generally feel that would be better.
>>> I don't feel comfortable with a security consideration that 
>> isn't, so I would lean towards your alternative proposal.
>> Ok, I'll move the content to section 5, and leave "Security 
>> Considerations"
>> empty, unless someone else objects to making that change.
> Instead of an empty security considerations section, you could also add a sentence explaining that the document just clarifies what is mandated by RFC 1122, and that it thus does not result in new security issues.
> According to the working group discussions and the WGLC feedback, TCPM is apparently not aware of any security issues with this draft, and I think that TCPM would be fine with mentioning this more explicitly.

Ok, how about:
	This document clarifies how to determine what 
	value should be used for the MSS option, and does
	not introduce any new security concerns.

			-David Borman

> Just a thought...
> Michael (as document shepard)

The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.