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