Hi, In line below:
> On 20 Aug 2018, at 17:34, Spencer Dawkins at IETF > <[email protected]> wrote: > > Hi, Michael, > > On Mon, Aug 20, 2018 at 9:11 AM Michael Welzl <[email protected]> wrote: > Hi, > > Thanks again ! > > > > On 20 Aug 2018, at 15:52, Spencer Dawkins at IETF > > <[email protected]> wrote: > > > > 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. > > Great - it seems this is also the only one that calls for a change of the > version that I now have. So, I'm removing the rest and just keeping this: > > > > -- > > > > 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! > > Can I just make this sentence replacement and be done with it? I mean, it IS > a very nice and clean solution, IMO... > > So, here's what I'm thinking ... > > I'm not sure if you saw my suggestion about qualifying the reference to > [I-D.ietf-taps-transport-security] as "Section 5 of > [I-D.ietf-taps-transport-security]", but assuming that we're good on that one > ... I saw it and agree. I thought that it's not necessary for the specific sentence that you ended up proposing, but now I agree that even in this sentence it's better. I'll update it to include "Section 5 of" just ahead of this reference. > Tl;dr = Spencer wants to make sure that his suggested text isn't overriding > what the working group is thinking, but since the working group has been > copied on this e-mail thread, it's probably fine to submit an updated draft > and start Last Call. I'll submit the update with the small correction above after this email. > For anyone curious ... > > What I was reading into the original text was roughly > > minimal transport service set = this document + Section 5 of > [I-D.ietf-taps-transport-security] > > The text I offered, is roughly > > minimal transport service set = this document > minimal secure transport service set = this document + Section 5 of > [I-D.ietf-taps-transport-security] I, for one, understood that and think that this is a fine solution. Cheers, Michael > We explicitly chartered TAPS for transport services in 2014, and didn't add > responsibility for transport security until February of this year. It seems > to me that publishing a minimal transport service set has value now, and > publishing a minimal transport service set has additional value later. > > If that's the intention, my suggested text would work. > > If the intention was to say that the minimal transport service set requires > transport security, the original text was correct and Spencer just missed a > turn someplace, but a reasonable review question would be "if the minimal > transport service set requires transport security, why publish the insecure > part now?" > > Either answer is OK with me, but what's not OK is for me as AD, is tell the > working group "I'm sure you meant THIS", in a way that doesn't invite > "Spencer, we meant exactly THIS, and your comment explains why we don't have > ADs write all the documents" :-) > > And thanks for your quick responses. That's always helpful. > > Spencer > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
