Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)

Adam Roach <adam@nostrum.com> Thu, 09 November 2017 02:12 UTC

Return-Path: <adam@nostrum.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 5F09E129ADF; Wed, 8 Nov 2017 18:12:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 gjsFK_JoTwSp; Wed, 8 Nov 2017 18:11:56 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45A212957C; Wed, 8 Nov 2017 18:11:56 -0800 (PST)
Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA92BtU9069340 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 8 Nov 2017 20:11:55 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Cc: The IESG <iesg@ietf.org>, tcpinc <tcpinc@ietf.org>, krose@krose.org, tcpinc-chairs@ietf.org, draft-ietf-tcpinc-tcpcrypt@ietf.org
References: <151018832684.17229.17081270342741352337.idtracker@ietfa.amsl.com> <2E9FA28D-CCE3-4F4D-A25A-976543A70C03@kuehlewind.net>
From: Adam Roach <adam@nostrum.com>
Message-ID: <e674acae-925e-10e7-b473-46629452d0a2@nostrum.com>
Date: Wed, 8 Nov 2017 20:11:49 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <2E9FA28D-CCE3-4F4D-A25A-976543A70C03@kuehlewind.net>
Content-Type: multipart/alternative; boundary="------------F8FAB135FDE83A53ADACBB7F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/u_q_riCfQeFW09UL1x4rutkZ0iU>
Subject: Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 09 Nov 2017 02:12:04 -0000

On 11/8/17 19:45, Mirja Kuehlewind (IETF) wrote:
>> In one interpretation, the TCP stack acts as if those packets were never
>> received, and so they are never acknowledged. Since retransmissions will
>> contain the same contents and also fail to decrypt, this is basically just
>> going to cause a connection failure upon expiration of the retransmission timer
>> -- in which case an immediate failure is clearly preferable.
> That’s not true. This is to cover the case where the packet got corrupted on the path, thus hopefully the retransmission will decrypt correctly.


So, to be clear, you're talking about packet corruption that happens to 
produce a valid checksum, right? If that's the reasoning here, the 
authors probably want to include that rationale in the document.


>> The other interpretation is that the TCP packet is processed as received, but
>> that all of the data that could not be decrypted is elided from the stream of
>> bytes provided to the receiving application. This is also a problem, since many
>> applications rely on the in-order delivery aspects of TCP. The prospect that a
>> sender could provide "Message A", "Message B", and then"Message C" to its TCP
>> socket and the receiver only get "Message A" followed immediately by "Message
>> C" is not something that applications will generally be capable of handling. As
>> before, a connection reset would be preferable to violating the in-order
>> delivery guarantees of TCP.
>
> This can never happen with TCP.


Right. That's exactly my point.

/a