IETF Logo Mail Archive

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

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Thu, 09 November 2017 03:02 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 14185120713 for <tcpinc@ietfa.amsl.com>; Wed, 8 Nov 2017 19:02:49 -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=unavailable 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 PutyEo8RVsSV for <tcpinc@ietfa.amsl.com>; Wed, 8 Nov 2017 19:02:48 -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 47ABB129467 for <tcpinc@ietf.org>; Wed, 8 Nov 2017 19:02:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=JLe1BFSH2DIBIo7jNRsHzM5Y9T7NSJIXgN+xxfxZQlYBvK5fpTJa7elCKapFLhcLUcnmhfsKc/iQiqDrVSO25HdqDpx///gbIEiFklGU8IdeyuCwEpHOa9TB+bvwspbcpPr1VKxpOHCK0/tRuziNElrSFksWQMhMGldkAt3vfBA=; 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 24497 invoked from network); 9 Nov 2017 04:02:45 +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 04:02:43 +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: <e674acae-925e-10e7-b473-46629452d0a2@nostrum.com>
Date: Thu, 09 Nov 2017 12:02:16 +0900
Cc: tcpinc <tcpinc@ietf.org>, krose@krose.org, tcpinc-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-tcpinc-tcpcrypt@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B8041A4D-DB98-4943-ACA9-62FF3F601218@kuehlewind.net>
References: <151018832684.17229.17081270342741352337.idtracker@ietfa.amsl.com> <2E9FA28D-CCE3-4F4D-A25A-976543A70C03@kuehlewind.net> <e674acae-925e-10e7-b473-46629452d0a2@nostrum.com>
To: Adam Roach <adam@nostrum.com>
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20171109030245.24488.48591@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/UTl4xUN2cDOV9AnnrsNDWU1Nhbk>
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 03:02:49 -0000

Hi Adam,

> Am 09.11.2017 um 11:11 schrieb Adam Roach <adam@nostrum.com>:
> 
> 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.
> 

True. Actually I let the author jump in at this point to make sure they don’t have any other cases in mind. In any case it’s probably good to the explicitly as possible about these thing we know here.

Thanks!
Mirja

v2.23.0 | Report a Bug | By Email