Hi, Michael, On Mon, Aug 20, 2018 at 9:11 AM Michael Welzl <mich...@ifi.uio.no> wrote:
> Hi, > > Thanks again ! > > > > On 20 Aug 2018, at 15:52, Spencer Dawkins at IETF < > spencerdawkins.i...@gmail.com> wrote: > > > > Hi, Michael, > > > > On Mon, Aug 20, 2018 at 3:57 AM Michael Welzl <mich...@ifi.uio.no> > 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 ... 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. 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] 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 Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
