Hi, Michael, On Mon, Aug 20, 2018 at 3:57 AM Michael Welzl <[email protected]> wrote:
> Hi Spencer! > > Thank you so much for your detailed work and all these comments! > I'm commenting in line below, and marking my comments with "MW:". > I'm terminating my responses with a "--". > > I'm attaching an update which incorporates the changes described in this > email, but I'm delaying its submission until it's clear that this > conversation has converged. > We're pretty darned converged. I have a couple of follow-ups below, but I deleted everything that we're already good on (and thank you for those, in advance). My only significant question is on Section 7. Spencer > -- > > This text in 7. Security Considerations > > Authentication, confidentiality protection, and integrity protection > are identified as transport features by [RFC8095]. As currently > deployed in the Internet, these features are generally provided by a > protocol or layer on top of the transport protocol; no current full- > featured standards-track transport protocol provides all of these > transport features on its own. Therefore, these transport features > are not considered in this document, with the exception of native > authentication capabilities of TCP and SCTP for which the security > considerations in [RFC5925] and [RFC4895] apply. The minimum > security requirements for a transport system are discussed in a > separate document [I-D.ietf-taps-transport-security]. > > confuses me, because I think at least two things are in play. First, I > think the point you're probably making is that the underlying transport > protocols remain unmodified, so the security considerations for each of > those protocols apply unchanged, and this document isn't doing anything to > create new security considerations. So, modulo SECDIR and SEC AD comments, > I think that's all you need to say. > > Second, you guys are the experts, but I think a reference to > [I-D.ietf-taps-transport-security] isn't actually needed for this document, > because that document surveys security protocols, rather than specifying > minimum security requirements. That document might someday discuss the > minimum security requirements, in the way this document discusses the > minimum set of transport services, but at least in > https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that > document is much more comparable to RFCs 8095 and 8304 than to this > document. > > MW: I would agree about [I-D.ietf-taps-transport-security] if it didn't > have section 5. > I believe section 5 in this document is an effort to do the same as minset > does, here; > are you maybe asking for this section of > [I-D.ietf-taps-transport-security] to use a > more authoritative tone? Either way, as things stand now, the existence of > [I-D.ietf-taps-transport-security] is used as a justification to not > include the > security related features of TCP and SCTP in the minimum set, and I think > this > citation is necessary. > So, for what it's worth, I wouldn't have ever noticed that Section 5 of [I-D.ietf-taps-transport-security] provided the equivalent of this document, based on the Abstract and Introduction, which both talk about surveys a lot more than minimum sets, but that's not your problem to solve (and I'm not providing AD comments on documents that the working group is still working on, because you guys are more likely to get stuff right than I am, so no action required from anyone else). But what is for you ... At a minimum, I'd suggest qualifying the reference to [I-D.ietf-taps-transport-security] as "Section 5 of [I-D.ietf-taps-transport-security] ", because I don't suppose that any other reviewer is more likely to figure this out than I am, but ... Quoting from the Introduction in -02 of I-D.ietf-taps-transport-security, what that draft is covering is This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols. It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and WireGuard. I may be confused about this, but I'm not seeing an obvious pattern match between those protocols and "security related features of TCP and SCTP in the minimum set". Is that document talking about what you hope it's talking about? Assuming so ... I'm probably struggling with the idea that there is no minimal set of transport services that doesn't involve one of the protocols listed in I-D.ietf-taps-transport-security or a near equivalent. That may really be the right thing for the working group to say, but I wanted to make sure that's the point that's being made, because that's what I think you're saying, by including the reference to I-D.ietf-taps-transport-security in your security considerations. If the last sentence read The minimum {delete "security"} requirements for a {insert "secure"} secure transport system are discussed in a separate document [I-D.ietf-taps-transport-security]. I'd agree with that statement, without anyone having to explain anything to me! But we'll be ready for Last Call on your next version, either way. > -- > > You folks know what you actually did, but I'm hoping that > > 2. Reduction: a shorter list of transport features is derived from > the categorization in the first step. This removes all transport > features that do not require application-specific knowledge or > cannot be implemented with TCP or UDP. > > was actually "cannot be implemented with TCP, SCTP, or UDP". Was that an > omission in this text, or do we need to chat? > > MW: the point was that TCP and UDP can't work as a fall-back in case e.g. > SCTP isn't available. As stated at the beginning of the document, the > minset can be implemented "one-sided" over TCP. (and with some > limitations, also UDP). For example: it's fine (within "best effort") to > always send everything in order when an application allows out-of-order > delivery - but there's simply no way to implement SCTP's out-of-band > transmission of a number ("Indicate (and/or obtain upon completion) an > Adaptation Layer via an adaptation code point") with TCP or UDP. If an > application relies on that, TCP or UDP fall-backs become impossible. We > were asked to avoid writing using the term "fall-back", for good reasons, > but this particular sentence may have ended up being less clear as we > simply replaced "fall-back" with "implemented with". > > I changed the sentence as follows, is it better? > > NEW: > > This removes all transport features that do not require > application-specific knowledge or would result in semantically incorrect > behavior if they were implemented over TCP or UDP. > I'm not entirely sure why, but this helps me a lot. Thanks for making the suggestion. It works for me. > > -- > > (Somewhere about here, I started thinking about "automated" - I didn't see > a clear definition of this in the document. I think I understand what you > mean at a hand-waving level, but you might consider adding a definition > earlier in the document, so that's clearer without relying on context > clues. > > MW: "automated" doesn't appear in the draft - I'm sure you mean > "automatable". > It only appears in the appendix, where it's defined upon its first > occurrence, in paragraph 5 of Appendix A.1, as follows: "The transport > features of IETF transport protocols that do not require > application-specific knowledge and could therefore be transparently > utilized by a transport system are called "Automatable"." - maybe you just > missed this? I believe it's in the most suitable place. I now made this > sentence a bit clearer now, by changing it into: "The transport features of > IETF transport protocols that do not require application-specific knowledge > and could therefore be utilized by a transport system on its own without > involving the application are called "Automatable"." > Good work. Here, you guessed what *I* meant. "Writing text is hard" - Spencer. Aaron has many examples of Spencer proving this, dating back to us being co-chairs in PILC in the late 1990s. But your suggested text (answers the comment I was trying to make, and) works for me. Thanks for that. > -- > > And finally, at a high level, I don't understand why there are > "Implementation over $Protocol" lines so often that name $Protocols that > weren't listed in "Protocols:" at the beginning of each description. I have > several guesses about what that might mean, but I bet all of them are > wrong, so I have to ask. > > MW: maybe that's related to your confusion about the omission of SCTP, > which I hope > I have addressed (as explained above). So that's answered by text that > appears just before we list the transport features, which now reads: > "The "minimal set" derived in this document is meant to be implementable > "one-sided" over TCP, and, with limitations, UDP. Hence, for all transport > features that are categorized as "functional" or "optimizing", and for > which no matching TCP and/or UDP primitive exists in "pass 2" of [RFC8303], > a brief discussion on how to implement > them over TCP and/or UDP is included." > Again, that's fixing my confusion above. Thanks for that.
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
