Re: [TLS] Are we holding TLS wrong?

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.Tschofenig@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.fossati@nokia.com>
> *An:* "David Schinazi" <dschinazi.ietf@gmail.com>
> *Cc:* "draft-ietf-babel-dtls@ietf.org" <draft-ietf-babel-dtls@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
>