Improving TCP's Robustness to Blind In-Window Attacks
draft-ietf-tcpm-tcpsecure-13

This document is well written and clearly explains, without needing to flip back to RFC 793 and other docs, the attacks and the mitigations.

Whether or not this document updates RFC 793 depends, in my mind, on the meaning of SHOULD in text like this snippet from section 4.2:

   Instead, the handling of the SYN in the synchronized state SHOULD be
   performed as follows:

   1) If the SYN bit is set, irrespective of the sequence number, TCP
      MUST send an ACK (also referred to as challenge ACK) to the remote
      peer:

      <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

      After sending the acknowledgment, TCP MUST drop the unacceptable
      segment and stop processing further.

Does the SHOULD imply a change in TCP as defined by RFC 793 or does it apply in the sense of "if the stack implemements the mitigations described in this document, the handling of SYN ..."

I infer from this text in the "Applicability Statement" (section 1.1), that RFC 2119 text is all conditional on "if the stack implements these mitigations":

   The mitigations suggested in this draft
   SHOULD be implemented in devices that regularly need to maintain TCP
   connections of the kind most vulnerable to the attacks described in
   this document.

While this may seem like an editorial nit, I think the doc would be clarified and the issue of updating RFC 793 resolved with an explicit statement about the RFC 2119 text in the Terminology section.
---
In section 5.1, what is the "ACK value of [a] data segment"?
---
This text at the beginning of section 5.2 doesn't seem to appear anywhere in sections 3 or 4:

5.2.  Mitigation

   All TCP stacks MAY implement the following mitigation.

Is there something different about the mitigation in section 5 that is different from the other mitigations?

I see section 6 clarifies the issue I was getting at:

6.  Suggested Mitigation strengths

   As described in the above sections, recommendation levels for RST,
   SYN and DATA are tagged as SHOULD, SHOULD and MAY respectively.

At the risk of fussiness over an editorial nit, I suggest a clear sentence at the beginning of sections 3.2 and 4.2 like the one in section 5.2 explicitly describing the recommendation levels for those mitigations.

I don't think that UPDATES is required because an implementer can produce a perfectly compliant implementation without ever reading this document.