Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

"Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com> Sun, 05 February 2017 06:57 UTC

Return-Path: <michael.scharf@nokia.com>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B88129497; Sat, 4 Feb 2017 22:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.787
X-Spam-Level:
X-Spam-Status: No, score=-8.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U66JYDxNwtOi; Sat, 4 Feb 2017 22:57:17 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A726126579; Sat, 4 Feb 2017 22:57:17 -0800 (PST)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 3E2706130463A; Sun, 5 Feb 2017 06:57:13 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v156vDDj029370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 5 Feb 2017 07:57:14 +0100
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id v156v9I6032466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Feb 2017 06:57:10 GMT
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.142]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Sun, 5 Feb 2017 07:57:09 +0100
From: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>
To: "Holland, Jake" <jholland@akamai.com>, David Mazieres expires 2017-05-03 PDT <mazieres-pkpvjfsmw3tssivxtan28pfsqw@temporary-address.scs.stanford.edu>, "tcpinc@ietf.org" <tcpinc@ietf.org>
Thread-Topic: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
Thread-Index: AQHSfaH8bHX24B8Ba06t1pm3vEt1naFWrKGAgAE+RACAAg8N8A==
Date: Sun, 05 Feb 2017 06:57:09 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48D1DE65@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <D668D28F-42BB-40A4-81D1-1FF2D3D95ECB@akamai.com> <87fujvonza.fsf@ta.scs.stanford.edu> <1FD85C9B-BE52-4E9F-A6D9-54BAD0425C8A@akamai.com>
In-Reply-To: <1FD85C9B-BE52-4E9F-A6D9-54BAD0425C8A@akamai.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/WpfbdZjTIUC2lhBg7RspKw8yVZ8>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Feb 2017 06:57:19 -0000

[CCing TCPM for the part that matters to TCPM]

> 4. citing drafts in support of future large SYN options:
> “Is there harm in doing this?  E.g., is it bad practice to cite internet
> drafts (non-normatively, of course) in an RFC?”
> 
> 4.a. Citing drafts does go against the current BCP, as I understand it.
> 
> From https://tools.ietf.org/html/rfc2026#section-2.2, in a big star-box:
> “Under no circumstances should an Internet-Draft be referenced by any paper,
> report, or Request-for-Proposal, nor should a vendor claim compliance with an
> Internet-Draft.”
> 
> There’s a partial exception right afterward, which I’m not sure how well it
> applies in this case:
> “
>    Note: It is acceptable to reference a standards-track specification
>    that may reasonably be expected to be published as an RFC using the
>    phrase "Work in Progress" without referencing an Internet-Draft.
>    This may also be done in a standards track document itself as long
>    as the specification in which the reference is made would stand as a
>    complete and understandable document with or without the reference to
>    the "Work in Progress".
> “
> 
> 4.b. the moral case for truth in advertising:
> 
> That said, I do think it’s reasonable to make the point that extending SYN
> option space would benefit ENO, and to point to evidence of ongoing work in
> that direction, even if it’s a long shot.
> 
> I also agree that one of the cited drafts is legitimately attempting something
> that would help ENO in this way if it continues to move forward
> (https://tools.ietf.org/html/draft-touch-tcpm-tcp-syn-ext-opt-06). In my
> original comment, one of the 2 alternatives I suggested as an edit was to
> continue to cite that draft, but to point out that it’s experimental.
> 
> However, I think 2 of the citations currently used as evidence are misleading,
> one of them because it shows no signs of moving forward toward any form of
> adoption (https://tools.ietf.org/html/draft-briscoe-tcpm-inspace-mode-tcpbis-
> 00), and the other because it does not apply to SYN or SYN-ACK
> (https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-07), and therefore
> wouldn’t help ENO’s use case. That is why I suggested cutting them out. (Or
> alternatively, if this weakens the point by so much it’s not worth making, to
> cut out the paragraphs that rely on it.)
> 
> My underlying concern here is that someone might take hope from this section
> and try to push their luck by putting keys into the SYN option with a length
> near the lower edge of what’s OK for security, in hopes that by the time it’s
> a real problem they’ll get an extension on the option space, rather than
> wrestling with the likely-harder problem of sending the keys in the payload.
> 
> But in practice, the option space in SYN is likely to be even less than what’s
> pointed out in this draft, because if you leave window-scale, timestamps, and
> sack-permitted out of your SYN, you’re likely to lose more on performance than
> any gains you might have made by getting a key into the SYN.
>
> In my experience, this is exactly the kind of subtle early misunderstanding
> that can lead a team to spend 6+ months developing something, then abort the
> project once they discover it cannot be made both performant enough and secure
> enough under the constraints of an early design decision.
> 
> Therefore, I would prefer this doc not to present a rosier-than-reality
> picture of the likelihood that a future development will make large SYN
> options available.

While TCPM discusses large SYN options (for a long time already), all known solutions have downsides. I do not believe that a non-TCPM document should speculate on the feasibility solutions.

Michael
 
> To take that a little further, I’d almost rather see an explicit warning that
> provides clear support for a claim like “You cannot fit a cryptographically
> secure key into the SYN option unless and until further standards work makes
> it possible to have more space there. Don’t try, you’ll regret it.”
> 
> It’s kind of a minor point to get this much discussion, but that’s a more
> complete explanation of my objection.