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

Daniel B Giffin <> Fri, 17 November 2017 03:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4D201241F3; Thu, 16 Nov 2017 19:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 623sVMKI_Hd9; Thu, 16 Nov 2017 19:14:51 -0800 (PST)
Received: from ( [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F4A8126B71; Thu, 16 Nov 2017 19:14:51 -0800 (PST)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id vAH3EofD084998; Thu, 16 Nov 2017 19:14:50 -0800 (PST)
Received: (from dbg@localhost) by (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 <>
To: Adam Roach <>
Cc: Kyle Rose <>, "Mirja Kuehlewind (IETF)" <>, The IESG <>, tcpinc <>,,
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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.


> Again, this remains a suggestion and not a blocking comment. You can feel
> free to proceed with the document as-is.
> /a