Code change:
Application dependency: Specification of application-specific extensions. <del> Session caching (and management): Sessions should be cacheable to enable reuse and amortize the cost of performing session </del> <ins> Session caching and management (SC): Sessions should be cacheable to enable reuse and amortize the cost of performing session </ins> establishment handshakes. Transport dependency: None. Application dependency: None. <del> Length-hiding padding: Applications may wish to defer traffic padding to the security protocol to deter traffic analysis </del> <ins> Length-hiding padding (LHP): Applications may wish to defer traffic padding to the security protocol to deter traffic analysis </ins> attacks. Transport dependency: None. Application dependency: Knowledge of desired padding policies. <ins> 5.3. The following table lists the availability of the above-listed optional features in each of the analyzed protocols.  "Mandatory" indicates that the feature is intrinsic to the protocol and cannot be disabled.  "Supported" indicates that the feature is optionally provided natively or through a (standardized, where applicable) extension. M=Mandatory S=Supported but not required U=Unsupported *=On TCP; MPTCP would provide this ability **=TCP provides SYN cookies natively, but these are not cryptographically strong +=For transport packets only </ins> 6. This section describes the interface surface exposed by the security

Related discussion:
text: WIP addressing . I don't want to pull this as-is: I just want comments on the format and usefulness of this. This closes the circle created by the list of protocol features in section 3, and indicates where we probably want more consistency and completeness in that list so the derivation of common optional features is more obvious.
Still a WIP. I have a bunch of comments as a result of doing this exercise: Feature availability for some protocol/feature combinations is not clear from the descriptions in the doc. Wireguard is IP encapsulation within UDP, but this is not stated anywhere in the doc. The set of features we list here should be called out or evident from the protocol features subsections under each protocol description. I think there's still some confusion in sections around symmetric authentication vs. signatures, i.e., AEAD-style authentication ("packets belong to this session") vs. PKI endpoint authentication ("this connection belongs to a peer I trust and is not being MITMed"). This may be a comment on the unfortunateness of the literature using "authenticated" for both.

Feature availability for some protocol/feature combinations is not clear from the descriptions in the doc. Can you give examples? Can you please open an issue to address this? See the other open pull request. :-) Where in particular are these things confused?
NAME ping!
Sorry, am away for the holiday weekend. The ones I have listed with a "?", for instance. I guessed on a few of the others, as well (e.g., configuration extensions for MinimalT). The right answer is for me to go back through this table and enumerate all the areas where the text isn't clear, and fix them. I'll file an issue. Will do. I'm not quite sure what I was thinking here. After reading it through again, I think I'm okay with how this is presented.
NAME can you please update this PR?
A few more questions: Is there any existing client puzzle/proof of work standardized for TLS or DTLS, or is URL as far as something's gotten? Same goes for IPsec; I can find no standardized version of any of these things. Should algorithms like TLS, DTLS, etc. that support native authentication but also can export a cryptographic channel binding be listed as supporting authentication delegation? My instinct is yes.