On Tue, Nov 13, 2018 at 12:33 PM David Schinazi <dschinazi.i...@gmail.com> wrote: > Our threat model should be described in the introduction. From your > comments I'm guessing it isn't clear, so we should fix that. The basic > idea is that any on-link device can change the routing of the entire > network, and that's bad for hopefully obvious reasons. The goal of > Babel over DTLS is to prevent that. Can you suggest a better way > to convey that?
It might pay to describe who is involved, and what prior information is assumed. There might be a few different deployment assumptions, which probably means pointing at other documents. Your list of PSK options (below) assumes a range of options, each assuming a different threat model. I hadn't even considered that option - the draft mentions asymmetric-key-based authentication. Which you should probably pin down to either certificates or raw public keys. Not choosing is a different sort of choosing. > PSK can either be used with: > - one key for the entire network, which does not allow revocation In this case, you would assume that there is no possibility of compromise or defection of any entity in a "network". That doesn't seem like a reasonable threat model. > - one key per node (N), but that requires all nodes to know all keys > which allows impersonation > - pairwise (N^2) keys, which does not scale well Yep, all of which speaks to some serious shortcomings of the HMAC-based protocol. If N^2 is feasible, it would be good to hear how those keys are managed. 1 and N similarly don't seem feasible from a deployment and operational perspective. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
