Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)
Daniel B Giffin <dbg@scs.stanford.edu> Fri, 17 November 2017 03:14 UTC
Return-Path: <dbg@scs.stanford.edu>
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 C4D201241F3; Thu, 16 Nov 2017 19:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 623sVMKI_Hd9; Thu, 16 Nov 2017 19:14:51 -0800 (PST)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 4F4A8126B71; Thu, 16 Nov 2017 19:14:51 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id vAH3EofD084998; Thu, 16 Nov 2017 19:14:50 -0800 (PST)
Received: (from dbg@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id vAH3EnRt099019; Thu, 16 Nov 2017 19:14:49 -0800 (PST)
Date: Thu, 16 Nov 2017 19:14:49 -0800
From: Daniel B Giffin <dbg@scs.stanford.edu>
To: Adam Roach <adam@nostrum.com>
Cc: Kyle Rose <krose@krose.org>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, tcpinc <tcpinc@ietf.org>, tcpinc-chairs@ietf.org, draft-ietf-tcpinc-tcpcrypt@ietf.org
Message-ID: <20171117031449.GB11150@scs.stanford.edu>
References: <151018832684.17229.17081270342741352337.idtracker@ietfa.amsl.com> <2E9FA28D-CCE3-4F4D-A25A-976543A70C03@kuehlewind.net> <e674acae-925e-10e7-b473-46629452d0a2@nostrum.com> <CAJU8_nXRGk2ao2A=pjuqBoGWADg0+e9iEAdSgHfSnASHzBFsJw@mail.gmail.com> <2b941a77-bf43-6855-6dbd-b988babdcec9@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2b941a77-bf43-6855-6dbd-b988babdcec9@nostrum.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/7hQVBCE0vGg2sjsjRbKDfH_5kPw>
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: Fri, 17 Nov 2017 03:14:53 -0000
Adam Roach wrote: > On 11/9/17 08:16, Kyle Rose wrote: > > On Thu, Nov 9, 2017 at 10:11 AM, Adam Roach <adam@nostrum.com> wrote: > > > On 11/8/17 19:45, Mirja Kuehlewind (IETF) wrote: > > > > 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. > > Mirja's is my interpretation, as well. > > > > Off-path attackers wouldn't be able to sent segments with the right > > sequence number with high probability, so it's unlikely that this is a > > DoS vector; but giving implementations the option of simply dropping > > segments for which the authenticity check fails is not likely to cause > > recurring timeout problems for correct implementations. > > Yes, and you're giving implementors options here without really explaining > why -- which means they're probably just going to pick one randomly. Adding > text that gives some notion about why one might choose one option over the > other would allow them to make an informed choice rather than a random one. That makes sense. How about the following text instead? (It is very similar to how we treat spurious FIN in the following section, 3.7.) [...] The output of this operation is either a plaintext value `P` or the special symbol FAIL. In the latter case, the implementation SHOULD abort the connection and raise an error condition distinct from the end-of-file condition. But if none of the TCP segment(s) containing the frame have been acknowledged and retransmission could potentially result in a valid frame, an implementation MAY instead drop these segments. This doesn't speculate on how the corruption came about (I agree it's difficult to find a reasonable case), but it gives a reasonable default via SHOULD and also leaves a little room for implementations with some sort of clever anti-DOS mitigation. daniel > > Again, this remains a suggestion and not a blocking comment. You can feel > free to proceed with the document as-is. > > /a
- [tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tc… Adam Roach
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Mirja Kuehlewind (IETF)
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Adam Roach
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Mirja Kuehlewind (IETF)
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Kyle Rose
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Adam Roach
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Daniel B Giffin
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Daniel B Giffin
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Adam Roach
- Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpin… Adam Roach