Draft: draft-ietf-taps-transport-security

Commentary: We got another Secdir review : Reviewer :   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 do n'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 ) 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 ) " Pre - Shared Key Import ( PSKI ): " lists WireGuard , but AFAIK it does not support PSK based authentication - only public key based authentication . 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 " 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 ? " 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 ....... " 
 On which protocols to include , MinimalT and CurveCP have different feature sets and interfaces exposed , which I think warrants their inclusion . Things like Signal and OTR indeed have seen very wide deployment , though they 're asynchronous , application - layer protocols akin to MLS , which I think is out of scope . I 'd also not like to add draft - mavrogiannopoulos - openconnect , if for no other reason than to draw a line in the sand . ( We run the risk of indefinitely delaying this while adding more protocols . ) On Session Cache Management , this is an explicit interface , and the example  mentions , while correct , does not exercise such an explicit interface . On WireGuard and PSK import , WireGuard uses the IKpsk2 Noise pattern ( see , and ) , in which a responder uses its PSK to additionally authenticate a connection . On ESP and PSK import , we note that importing a PSK can be used for " encrypting ( and authenticating ) communication with a peer , " which remains true for IPsec . ( Right I 'll address the issues in 5.2 in a PR !
Paragraph (version A):
Configuration interfaces are used to configure the security protocols
before a handshake begins or the keys are negotiated.
Paragraph (version B):
Configuration interfaces are used to configure the security protocols
before a handshake begins or keys are negotiated.
Paragraph (version A):
Identity Validation (IV): During a handshake, the security
protocol will conduct identity validation of the peer.  This can
call into the application to offload validation.
Paragraph (version B):
Identity Validation (IV): During a handshake, the security
protocol will conduct identity validation of the peer.  This can
offload validation or occur transparently to the application.
Paragraph (version A):
Source Address Validation (SAV): The handshake protocol may
interact with the transport protocol or application to validate
the address of the remote peer that has sent data.  This involves
sending a cookie exchange to avoid DoS attacks.