Subject: [tcpm] 793bis: New security considerations section

From: Wesley Eddy <[email-masked]>
Date: Mon, 13 Nov 2017 14:22:55 -0500

Hi, one thing that I want to make the WG aware of in the latest RFC 
793bis draft is the new security and privacy considerations section.

https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-07#section-6

The original RFC 793 predates security considerations sections, so I 
didn't have much to start from.  My goal was to point to relevant 
references without creating dozens of pages of meandering text on every 
little possible security issue (most of which are well-known by now).

This is a first crack at it, and it could likely be improved in big 
ways.  Your feedback, suggestions, corrections, etc. is appreciated.

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Nov 2017 19:47:29 -0800

Hi, Wes (et al.),

It looks OK but appears to omit some of the advice from various
non-cryptographic security methods, notably that they are recommended
only in particular environments (e.g., see RFC 5961 Sec 1.1). IMO, the
same could be said of others that predate that consideration.

Joe

On 11/13/2017 11:22 AM, Wesley Eddy wrote:
> references without creating dozens of pages of meandering text on
> every little possible security issue (most of which are well-known by
> now).
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 17 Nov 2017 13:14:20 -0500

Hi Joe, that is a great point, and I agree that the applicability 
statement you mention should be noted.

Additionally I wanted to mention that the way I currently handled RFC 
5961 in the document should be reviewed along with the Errata on 5961.

(1) I added references to 5961 added in the relevant places where 
validations are taking place, and content has been taken from the 
"Mitigation" subsections of 5961 where the state machine modifications live.

(2) I put in errata 5068 on RFC 5961 in order to correct a problem I 
found, but it isn't yet verified (but I so far assumed that it will be 
in 793bis).  See: 
https://www.rfc-editor.org/errata_search.php?rfc=5961&eid=5068

My description in the Notes there is:

    The text in section 3.2 begins by stating a change from RFC 793 for
    RST bit handling "when in a synchronized state" (which means all
    states except for LISTEN, SYN-SENT, and SYN-RECEIVED). Later in the
    section, the same change is described more loosely and text states
    that it's applicable "In all states except SYN-SENT", and separate
    behavior is provided for SYN-SENT, but the earlier text leaves
    uncertainty if the former is supposed to apply to SYN-RECEIVED as
    well, since the earlier text in the section section begins by
    discussing only "synchronized" states.

    Since the check is totally valid for SYN-RECEIVED, and the behavior
    in steps 1, 2, and 3 are valid for SYN-RECEIVED, it seems
    appropriate to make sure this is clarified in the earlier text.

If there isn't agreement that this should be Verified as an Errata to 
5961, then we'll have to change 793bis accordingly.

---

From: Joe Touch <[email-masked]>
Date: Sat, 18 Nov 2017 09:18:05 -0800

> statement you mention should be noted.

FWIW, I also think that the security section should be a little more
clear on the following:

    - if you want TCP security, you need IPsec or TCP-AO
        anything else protects only a small fraction of TCP control
(tcpcrypt) or no TCP control at all (TLS)
    - all other "security" measures only partially hinder attacks at
best (they might be better at anti-tracking than attack resistance)
        e.g., ISN generation, RST sequence number checks, etc.

Joe