Thanks for your comment Hannes! One of the motivations for Babel-HMAC (the custom format only offering integrity protection) is to have a simple mechanism with smaller dependencies for inclusion in small embedded devices that do not necessarily have a DTLS stack.
We could define a mechanism that performs Babel-DTLS and then leverages a keying material exporter to have keys for Babel-HMAC and use that for multicast, but potentially in a later draft -- we're trying to minimize complexity for this current pass. David On Wed, Nov 7, 2018 at 8:53 PM Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: > I took a quick look at the document and I don't know Babel. > > I see that you have two different proposals for securing Babel messages, > namely > * DTLS, and > * a custom format offering integrity protection only. > > You correctly note in the document that DTLS offers more features. It is > an authentication and key exchange protocol. > > One option to explore is to use DTLS to perform authentication and key > exchange then use your custom format for integrity protection of packets > with the keys exported from DTLS. Design-wise this approach is similiar to > what we have done with DTLS-SRTP. This would also allow you to cover the > multicast security case. > > Ciao > Hannes > > *Gesendet:* Donnerstag, 08. November 2018 um 11:30 Uhr > *Von:* "Fossati, Thomas (Nokia - GB/Cambridge)" <thomas.foss...@nokia.com> > *An:* "David Schinazi" <dschinazi.i...@gmail.com> > *Cc:* "draft-ietf-babel-d...@ietf.org" <draft-ietf-babel-d...@ietf.org>, " > tls@ietf.org" <tls@ietf.org> > *Betreff:* Re: [TLS] Are we holding TLS wrong? > Hi David, > > A few quick notes below. > > Cheers > > The 11/08/2018 09:14, David Schinazi wrote: > > Hi everyone, > > > > Over in the Babel working group we have a draft about securing Babel with > > DTLS: > > https://tools.ietf.org/html/draft-ietf-babel-dtls-01 > > > > It's 5 pages long, could any TLS experts please give it a quick read and > > let us know if we're using DTLS correctly? > > > > Also, should the document contain guidance such as which DTLS version to > > use? > > > > Thanks, > > David > > Premise: I don't know Babel -- apologies for any nonsense! > > One high level thing which I can't extrapolate from the draft (which is > probably due to my ignorance with Babel) is whether you envisage that > *every* node does DTLS on the unicast channel, IOW that non-DTLS nodes > are excluded from the mesh? Or would it be acceptable to mesh HMAC and > DTLS neighbours? What about clear-text speakers? (It'd seem unwise to > let them in an otherwise secured enclave.) > > You should probably provide some guidance about the kind of > credentials do you plan to use (certs, raw pkeys)? > > It seems to me that the P2P nature of the protocol requires mutual > authentication, could you confirm it? This seems to be a critical thing > to prevent a rogue node to spoof the lowest (highest, I have already > forgot, sorry) L-L address in a clear-text multicast Hello and bypass > authentication. > > - s2.1 > "Nodes SHOULD ensure that new client DTLS connections use different > ephemeral ports from recently used connections to allow servers to > differentiate between the new and old DTLS connections." > > Maybe you could suggest using a sufficiently entropic connection id here > as a more robust alternative. > > - s2.5 > Not sure what the ceremonies around flushing a neighbor are, but I'd > make explicit signalling EOD at least a SHOULD? It seems more polite > :-) > > - s.3 > Not sure which TLS stack Babel nodes will use (are you targeting > extremely constrained devices with custom TLS implementations?), but all > the stacks I know of let the application set the MTU and take care of > splitting the messages in MTU sized chunks transparently. > > -- > Thomas > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
