Thanks, Michael - inline.
On Wed, Jun 07, 2017 at 05:55:40PM -0400, Michael Richardson wrote:
>
> 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.
So, in some near term future, ANI/ACP is so successfully that we
have four possible ACP channel protocols: IPsec, IPsec/GRE, dTLS and 802.1ae
Question: How would you negotiate between two ANI peers which protocol to use ?
Lets say that the negotiation was also somewhat complex in so far that devices
may have two levels of performance support for a particular protocol
"i suck, but i do it to be compatible (software)"
"i do it with hardware acceleration"
So the negotiation would have to be done in a way that both sides will agree
on the protocol they both support und suck the least with.
The answer that the current ACP spec has to do this is incomplete but AFAIK
still the most simple one:
a) We need a security association before we negotiate so the negotiation does
not become an attack vector. Solution: We build a a TLS connection
b) We need a negotiation protocol. Well. GRASP proposes we use it for this
purpose. So we just run GRASP (no IP etc.) inside the TLS.
Its incomplee because we have not defined the exact name of objective/
parameters for this type of negotiation though.
ACP spec also specifies how to select a protocol without this degree of
negotiatio, which is that you start the subset of all the possible protocols
that you support, and once you have working connections you use a simple
decider to
select which of the two peers takes the master role and closes the unneeded
connections. Thats the only solution to avoid the additional layer of
negotiation, but it is of course limited, because it will not allow to
negotiate any parameter not known via the existing (negotiation) protocols.
Such as the aforementioned performance of any of the possible protocols.
Aka: Without the GRASP/TLS negotiation i could not figure out that
in one case both sides have best performance via eg: 802.1ae.
> 2) We have no meaningful specification for IP over *TLS thing.
> (but that, I mean a deployed protocol with an RFC and widespread
> implementation.)
The negotiation is just GRASP inside TLS. No IP needed.
> (We aren't here to invent protocols, but rather to put them together)
See above, i think it's not relevant to this discus.
> 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.
Would be great if you could point me to some example RFC where something like
this ("how to use TLS appropriately") is done!
I have sent a question to the same end to the SEC ADs.
Its fine with me not to have SONN defined in the GRASP document even though
i did like the text. Instead i would have to add more text to the ACP spec
explaining how to use GRASP across TLS to achieve above described negotiation.
And as you said: finding the minimum necessary definition of a TLS profile
would then be up to me.
If we make progress with the rest of ACP faster than with this piece, then
i will yank that section of GRASP negotiated ACP channel selection from ACP
draft and we can put it into a separate document.
> I believe that this will confuse the market, and slow implementations
> significantly (both the writing of, and the performance of).
Sure. Hope the above strategy of pushing this up in the doc stack
(GRASP -> ACP -> separate document) as needed makes sense.
Cheers
Toerless
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
