EXEC SUMM: SONN was extra plumbing with no clear benefits and significant
downsides for the security analysis of the entire system.
The document is fine as it is.Toerless Eckert <[email protected]> wrote: > I was surprised to see SONN go away. I do not understand what was considered to be > underspecified about it. Everything about that text was IMHO "OK". Now i was > not a big fan of the text, but if you do not want to bring it back then IMHO > we would need some other equivalent explanation. > Just as a reminder: The use-case for SONN is the ACP: > - you discover a candidate ACP neighbor with DULL > - You build a TLS connection to that candidate ACP neighbor > - You run "SONN" inside the TLS connection to negotiate the ACP protocol, eg: IPsec > with/without GRE, or dTLS or IP over CoAP or what the heck. 1) I object to negotiating the use of which negotiation protocol to use. It's just asking for complicated state machines with very hard to analyze bid-down attacks at multiple layers. 2) We have no meaningful specification for IP over *TLS thing. (but that, I mean a deployed protocol with an RFC and widespread implementation. We aren't here to invent protocols, but rather to put them together) 3) I have been trying to understand the MACsec KMP, as some would like to run the ACP over MACsec. I originally was led to believe that there was no KMP, but after finding the full specifications, it's clear that there is support for PSK and other things and even IDevID are mentioned. I'd still like to suggest that we negotiate the use of MACsec (or of some yet-to-be-well-defined IP over TLS) via IKEv2. It's not at all hard, and if IKEv2 is the MTI, then we need it implemented anyway. An IKEv2 minimal implementation can be very small; lwig has some good advice, but it assumes initiator only, and we need both. I can not see a purpose for SONN, and I do not think we can do a proper security analysis, and it forces TLS to be MTI. SONN will therefore add a significant (3-5 pages) of text on how to use TLS properly. I believe that this will confuse the market, and slow implementations significantly (both the writing of, and the performance of). -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
