Hi Paul, Thanks for the review! You can find an updated version of the document here:
https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html <https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html> Responses inline. > On Apr 15, 2020, at 8:48 AM, Paul Wouters via Datatracker <[email protected]> > wrote: > > Reviewer: Paul Wouters > Review result: Has Nits > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > The summary of the review is Has Nits > > Compared to my last review (-09) a lot of text has been removed, reducing the > technical details and giving a briefer (but arguably cleaner) overview. > > I do still have a personal preference of dropping CurveCP and MinimalT as I > don't really think these are anything but abandoned research items. I have > never seen or heard of these being deployed. I would be more tempted to list > openconnect (draft-mavrogiannopoulos-openconnect) which actually does see > quite > some deployment. If the intent is really to show different kind of API's, than > there are other esoteric examples that could be included, such as > Off-The-Record(OTR) or Signal, which are mostly encrypted chat programs, but > with the ability to generate session keys for encrypted bulk transport (eg for > video/audio or file transfer) We discussed for Signal and OTR. Our sense was that these protocols are more asynchronous application-layer protocols that are akin to MLS, that can be more independent from a transport layer. > > Section 5.1 > > "Session Cache Management (CM):" which does not include IKEv2/IPsec, even > though it does have session resumption (RFC 5723). I guess this is because the > section limits itself to "the application" that can restart the session. But > for IKEv2/IPsec the same could be said. An application that after a long idle > period sends a packet, triggers a kernel ACQUIRE, which triggers an IKEv2 > session resumption. WireGuard does not have this capability as there are no > API/hooks for packet trigger tunnel events (AFAIK) Indeed, this refers to an explicit interface for cache management. > > "Pre-Shared Key Import (PSKI):" lists WireGuard, but AFAIK it does not support > PSK based authentication - only public key based authentication. We discussed that WireGuard uses the IKpsk2 Noise pattern (see https://www.wireguard.com/protocol/, and https://noiseexplorer.com/patterns/IKpsk2/), in which a responder uses its PSK to additionally authenticate a connection. > While I > understand the IKEv2 entry (PSKs are used for authentication of peers), I am > not sure the ESP entry should be here. ESP does not "authenticate peers", > unless you call "being able to decrypt and authenticate packets" as an > instance > of "authenticating peer" We’ve changed the reference to be IPsec as a unit for IKEv2 + ESP in these lists. > > Section 5.2 > > This states "This can call into the application to offload validation.". This > "can" is only not supported by WireGuard, as all of this is happening inside > the kernel. Maybe a note could be useful here? Switched to "This can offload validation or occur transparently to the application." > > "Source Address Validation" - It is a little unclear why TCP based protocols > are not listed here. They (implicitly) do source address validation. Perhaps > the introduction in this paragraph can state this more explicitly. Eg "for > those protocols that do not use TCP and therefor do not have builtin source > address validation ......." We clarify here that: "Of the protocols listed above that depend on the transport for message framing, some do have well-defined mappings for sending their messages over byte-stream transports like TCP.” Thanks, Tommy > > > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
