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

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Thu, 09 November 2017 01:45 UTC

Return-Path: <ietf@kuehlewind.net>
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 BBB3912711A for <tcpinc@ietfa.amsl.com>; Wed, 8 Nov 2017 17:45:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 rvgJ9LzUjO4s for <tcpinc@ietfa.amsl.com>; Wed, 8 Nov 2017 17:45:52 -0800 (PST)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3884F124B18 for <tcpinc@ietf.org>; Wed, 8 Nov 2017 17:45:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=wQKkcLR0GqtLvIrS7W9H3fHpqTCQT84nlfer2qDAcFabSrI/5d4CmRzGJaOiDM0zwhgO3ZvwFhh1zcJxw09IJKaw8AUJgcmeGGdXYXLUn1iLkvGcbyD5HfGesi74a4EusICiB8qZW/VW6u3934ow89pq33P4TLf3+k8xaXc1CLQ=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 16188 invoked from network); 9 Nov 2017 02:45:50 +0100
Received: from unknown (HELO ?172.30.1.8?) (121.135.231.251) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 9 Nov 2017 02:45:48 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <151018832684.17229.17081270342741352337.idtracker@ietfa.amsl.com>
Date: Thu, 09 Nov 2017 10:45:35 +0900
Cc: The IESG <iesg@ietf.org>, tcpinc <tcpinc@ietf.org>, krose@krose.org, tcpinc-chairs@ietf.org, draft-ietf-tcpinc-tcpcrypt@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E9FA28D-CCE3-4F4D-A25A-976543A70C03@kuehlewind.net>
References: <151018832684.17229.17081270342741352337.idtracker@ietfa.amsl.com>
To: Adam Roach <adam@nostrum.com>
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20171109014550.16179.37972@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/L5V3AR-N0o094OuDSCBLcjE3sbE>
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 01:45:55 -0000

Hi Adam,

one/two comment(s) below.

> Am 09.11.2017 um 09:45 schrieb Adam Roach <adam@nostrum.com>:
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-tcpinc-tcpcrypt-09: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for a well-written document. I have some suggestions for improvement
> (two minor, and one significant).
> 
> This document has several references to tables that are quite distant from the
> table being referenced. It might be useful to readers if these were phrased
> something like "Table 4 in section 7," so they know where to go looking for the
> table.
> 
> Section 3.5 says:
> 
>   If an active opener receives a resumption suboption for a particular
>   TEP and the received identifier-half does not match the "resume[i]"
>   value whose other half it previously sent in a resumption suboption
>   for the same TEP, it MUST ignore that suboption.  In the typical case
>   that this was the only ENO suboption received, this means the host
>   MUST disable TCP-ENO and tcpcrypt: that is, it MUST NOT send any more
>   ENO options and MUST NOT encrypt the connection.
> 
> I think the text here would benefit from pointing out that the client MUST NOT
> attempt to resume a session with this host for the next TCP connection attempt.
> 
> ____
> 
> Section 3.6 stipulates:
> 
>   When a frame is received, tcpcrypt reconstructs the associated data
>   and frame nonce values (the former contains only data sent in the
>   clear, and the latter is implicit in the TCP stream), and provides
>   these and the ciphertext value to the the AEAD decryption operation.
>   The output of this operation is either a plaintext value "P" or the
>   special symbol FAIL.  In the latter case, the implementation MUST
>   either drop the TCP segment(s) containing the frame or abort the
>   connection; but if it aborts, the implementation MUST raise an error
>   condition distinct from the end-of-file condition.
> 
> In the text above, the choice to "drop the TCP segment(s)" seems a little
> underspecified, and both ways that I can interpret it are problematic.
> 
> 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.

The option to abort the connection is if the decryption failure is assumed to be accounted to some kind of interference or attack. If guess we could try to give more advice when to do what. Like if one packet fails to decrypt you should just drop if, if the decryption failure rate is high or the same packet fails multiple time, there might be an attack and you MAY abort. However, I think the default is silent drop. The only important part is that if you decide to abort to also must raise an appropriate error.

> 
> 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. All data are delivered in order and cannot be processed if data is missing. There are no messages exposed in TCP; it's all one stream to the application. If a packet would continuously fail to decrypt, the remaining higher order data will not be delivered to the application and at some point the receive window will be full and the sender cannot send any new data anymore. If I remember correctly, I guess if that situation would persist for long, one end should probably reset the connection anyway at some point.

> 
> Unless my analysis here is confused, I think this text needs to be changed to
> conclude:
> 
>   In the latter case, the implementation MUST
>   abort the connection and raise an error
>   condition distinct from the end-of-file condition.
> 
>