Re: [Taps] WGLC for draft-ietf-taps-transport-security (ending 4/29)

[Gorry Fairhurst <[e-mail]>]

Review of draft-ietf-taps-transport-security-06.

I have read the above document as a transport person, and contributor to 
the group and think this document contains the material that was 
discussed by the working group and is very near a version that is ready 
to publish.

I have a number of comments below.

Scoping and potential use to endorse non-ietf protocols:

As a technical question to the Chairs/AD - does the document need to 
carry some caveat about non-IETF protocols being standardised outside 
the RFC-series and not making a statement on recommending or otherwise 
endorsing their use?

Abstract

I think the abstract should define “TAPS”. probably this should also be 
defined when first used also in the body of the text. Similarly protocol 
names such as: Transport Layer Security (TLS), TCP-AO, ALTs, BGP, AH, 
IKE,etc should be defined when first used, and abbreviations such as MAC 
(PRF), EAP, ALPN, Server Name Indication (SNI), DoS, PKI.

Abbreviations

“starting with TLS 1.3”
- should there be a reference here?
“NAT rebindings”
- should there be a reference to one of the BEHAVE RFCs here?

I think I-D.ietf-tls-tls13 has been published as RFC 8446

X.509 certificates are mentioned in 4.10.1, and could benefit from a 
reference.

authenticates the payload using HMAC is mentioned in 4.10.1, and could 
benefit from a reference.

In section 4.2:
“DTLS is modified from TLS to operate with the possibility of packet
loss, reordering, and duplication that may occur when operating over
UDP. “
- I think this can be used over datagram protocols, and it would be 
worth saying that and adding ane maple of: Datagram Transport Layer 
Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)
RFC 5238

Typo in reference format?:
“{{I-D.ietf-tls-dtls13}”

In Section 4.2.2:
- Could you provide a cross-reference to the section in “ See also the 
features from TLS.”

Comments on the text:

I support Aaron’s comment on the term “network security layer” - do we 
need to use the term layer here, since this is expected to be placed 
below the transport API?

In Section 4.2.3. (on Protocol Dependencies)

o DTLS relies on UDP.
- or any datagram service? (see above note on DTLS over DCCP as an 
example.), in 4.93 the text says “An unreliable transport protocol such 
as UDP.” - which could be more appropriate?

“Path MTU discovery.”
- Could we write this as “discovery of the Path MTU” to explicitly not 
say use the name of a protocol here?

In Section 4.3.1:
“The QUIC transport layer support multiple streams”
- insert “s” after “support”.
“Once TLS completes, QUIC uses the
resultant traffic secrets to for the QUIC connection to protect the
rest of the streams.”
Replace “to for” by “for”?

“Owing to middlebox ossification issues, tcpcrypt only protects the
payload portion of a TCP packet. It does not encrypt any header
information, such as the TCP sequence number.”
- I am not sure I agree with the implication here!
- Would it be OK to state this more neutrally as:
“Because of the possible presence of firewalls and other middleboxes on the
path, tcpcrypt only protects the
payload portion of a TCP packet. It does not encrypt any header
information, such as the TCP sequence number.”

Security Considerations:

Section 8 uses a RFC2119 keyword: “ Applications using Security 
Interfaces SHOULD take such
limitations into consideration when using a particular protocol
implementation.”
- I suggest replacing this by “ought to”?

Acknowledgments

NiT: “Theresa Enghardt” is an editor and an acknowledged contributor, 
suggest you remove the name from the ACK section.

References

The references have not been divided into normative and informative 
references. I am unsure/uneasy at this time if this list of references 
all need to be normative.
- In particular, some non-IETF documents are cited as normative 
references. This strikes me as difficult to justify and something that 
needs careful consideration.
- I am concerned there are normative references to quite a number of 
Internet drafts. Are these necessary - if these need to be normative 
then the WG needs to consider if this may block publication of the 
document for some time to come!
- I note that in RFC 8095 we chose to make all protocol references 
informational.

Security

This review was from a viewpoint of providing transport oversight. I did 
not review the summary table contents nor the assertions on which 
mechanisms were present in which protocols, where security expertise is 
needed.