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

From: "Aaron Falk" <[email-masked]>
Date: Wed, 10 Apr 2019 10:12:05 -0400

Dear TAPS working group,

It’s time to perform a last call review of “A Survey of Transport 
Security Protocols.” Please send comments, including “ready to 
publish”, to [email-masked].  Alternatively, specific issues can be 
raised via GIT 
(https://github.com/ietf-tapswg/draft-ietf-taps-transport-security).

This review period will conclude Monday, April 29.

--aaron

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 22 Apr 2019 10:58:24 +0100

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.

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 22 Apr 2019 09:47:44 -0400

Hi Gorry,

> the RFC-series and not making a statement on recommending or otherwise 

As this document is intended for Informational status and not, say, BCP 
or standards track, I think there is no implicit endorsement.  I felt 
the text was clear that it is a descriptive analysis of various 
protocols.  So, my view is that nothing else is needed.  Nevertheless, 
I’m open to hearing other opinions.

--aaron

---

From: "Aaron Falk" <[email-masked]>
Date: Thu, 25 Apr 2019 12:57:44 -0400

Reminder that the working group last call for this draft ends next 
Monday. Please send comments and opinions on whether the doc is ready to 
publish to this list.

https://tools.ietf.org/html/draft-ietf-taps-transport-security-06

--aaron

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 28 Apr 2019 16:00:04 -0700

Thanks, Aaron!

I've just done an editorial pass on the document now that we believe it is technically complete.

Some of the nits addressed:

- Remove redundancy between intro and abstract
- Update language on Security Features to have a consistent tense/voice between definitions of features
- Refer to QUIC as a name, not an acronym
- Update all TLS 1.3 references to the RFC number
- Don't have any empty section headers
- Remove incorrect normative "SHOULD" from information doc

Commits can be found here:
https://github.com/ietf-tapswg/draft-ietf-taps-transport-security/commits/master

In my opinion, once we've incorporated the PR from Aaron, we should be good. If anyone has other nits or comments, though, please file an issue or PR!

Thanks,
Tommy

> On Apr 25, 2019, at 9:57 AM, Aaron Falk <[email-masked]> wrote:
> 
> Reminder that the working group last call for this draft ends next Monday. Please send comments and opinions on whether the doc is ready to publish to this list.
> 
> https://tools.ietf.org/html/draft-ietf-taps-transport-security-06 <https://tools.ietf.org/html/draft-ietf-taps-transport-security-06>
> --aaron
> 
> It’s time to perform a last call review of “A Survey of Transport Security Protocols.” Please send comments, including “ready to publish”, to [email-masked]. Alternatively, specific issues can be raised via GIT (https://github.com/ietf-tapswg/draft-ietf-taps-transport-security <https://github.com/ietf-tapswg/draft-ietf-taps-transport-security>).
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Mon, 29 Apr 2019 12:58:26 +0200

Hi,

just did one pass over the latest GitHub version and it looks ready to me.
I only found three small nits I opened Issues on GitHub for.

AVE!
   Philipp S. Tiesel

--
Philipp S. Tiesel
https://philipp.tiesel.net/