Re: [TLS] Are we holding TLS wrong?

["Fossati, Thomas (Nokia - GB/Cambridge)" <[e-mail]>]

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