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.
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
