On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter < [email protected]> wrote:
> Eric, > > On 25/05/2017 14:32, Eric Rescorla wrote: > ... > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > ISSUE 1 > > The security situation here is pretty unspecified here, in at least two > > respects: > > > > 1. In terms of communication security, you seem to have two modes: > > > > (a) Punt it to ACP > > (b) Use TLS as specified in S 3.5.2.1 > > > > I'm not reviewing ACP here (though I have some comments on that too) > > Yes, that certainly needs a thorough security review ASAP. > > > but S 3.5.2.1 doesn't (for) instance explain how to do certificate > > validation, > > Indeed not. But... > > > which it clearly needs to do. > > We intentionally want to leave this for further study. Surely that > is allowed? The text seems very clear on that. Personally, I'm not competent to design that, and this draft is already plenty long enough. > So what can we write if we can't write "Further details are out of scope > for this document."? > It's the job of this group of specifications to provide a complete security story, so it must either be here or it must be in some other document which is normatively referenced from here and which therefore one can read to determine if this document achieves the appropriate security objectives. Just generally pointing in the direction of TLS is not sufficient. You could, of course, say that TLS is not to be used at all and you rely entirely on ACP, but the current text doesn't do that either. > Finally, I don't > > understand the security story for the multicast packets. > > I think I already typed this a day or two ago, but with an ACP, > they are secured, because the ACP is a secure virtual overlay > network. > This document then needs to state which precise properties of ACP it is relying on for that. A brief skim of ACP suggests that it relies on other protocols for its actual transport security and at least some of those protocols (e.g., DTLS) do not support multicast. With no ACP they are of course wide open, unless some new > magic has been invented that I'm not aware of. Hence the > restrictions in 3.5.2.2. "Discovery Unsolicited Link-Local" > As above, you need to specify which properties you are relying on, and how you bridge multicast to unicast. > This is especially relevant for Rapid mode, where you are > > attaching real work to these multicast packets. > > Correct. I think we need to forbid that in the no-ACP case. > > > 2. I didn't find the security model very clear. As I understand > > things, basically anyone on the network who has ACP credentials > > is trusted to engage in negotiation with you, so, for instance, > > if you want to get parameter X, then you basically just trust > > whoever on the network offers you X. is that correct? That seems > > like it needs to be very explicitly called out. And if that's not > > true, then I don't understand the spec. > > That is the trust model, but really as an explanatory matter I think > it belongs in draft-ietf-anima-reference-model rather than here. > I will add a few words in the High Level Deployment Model > section and/or the Security Considerations. > > What we do say already is that authorization of ASAs is out of scope. > I am certain that it needs to be tackled, but not here. > I don't see how you have a complete protocol without that. > > > ISSUE 3. > > I don't think I understand how the transition from UDP multicast > > to TCP/TLS unicast works. Maybe I'm just misreading the spec, > > so could you point me to the section that describes this. > > This only arises for discovery; the discovery result explicitly includes > the address/protocol/port for the actual operation. > > For discovery it's in > https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.4 > > <t>The listening port used for TCP MUST be the same port as used for > sending the > Discovery UDP multicast, on a given interface. In a low-end implementation > this MAY > be GRASP_LISTEN_PORT. In a more complex implementation, the GRASP > discovery mechanism > will find, for each interface, a dynamic port that it can bind to for both > UDP and TCP > before initiating any discovery.</t> > > Python code on request ;-) > Thanks. > Finally, I don't see a spec for how you map CBOR onto the wire. Do you > > just shove them on? Something else? > > Yep, CBOR is just a string of bytes. That's CBOR 101 so I don't > think we need to say anything more. > I don't agree. JSON is just a string of bytes and yet ACME, for instance, contains a rather extensive protocol mapping to HTTP. So, you need to at least state that you just shove them on the wire. > > > > I see that Martin Thomson raised a number of these issues in his review > > in more detail. > > > Martin Stiemerling I think. > Martin Stiemerling may or may not have reviewed this document, but I'm talking about Martin Thomson's review, which can be found at: -Ekr
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
