Re: [TLS] Are we holding TLS wrong?

[David Schinazi <[e-mail]>]

Thanks for the feedback Thomas! Responses inline.

On Wed, Nov 7, 2018 at 8:30 PM Fossati, Thomas (Nokia - GB/Cambridge) <
[e-mail]> wrote:

> 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.)
>

The main use-case would be that the entire mesh runs over DTLS and
cleartext nodes are excluded.
However, if a deployment has specific properties, one could configure this
per-interface:
a router could require DTLS over the Wi-Fi interface but allow non-DTLS on
the secure VPN
interface. That would allow cleartext speakers over VPN into the
DTLS-secured enclave,
but that should only be used by someone who wants that property. I've added
a subsection.


> You should probably provide some guidance about the kind of
> credentials do you plan to use (certs, raw pkeys)?
>

We actually don't currently have guidance to give, as it might depend on
the use-case.
For example, there will be a document specifying how HOMENET uses Babel
over DTLS,
and I suspect that document will provide very specific guidance on what
credentials to use
and how they are provisioned.


> 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.
>

Absolutely, this requires mutual authentication, I'll add a specific note
to the draft.


> - 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.
>

Good point, I added text.


> - 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
> :-)
>

I agree, I upgraded politeness to a SHOULD.


> - 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.
>

The goal is for this to work on general-purpose stacks as well as embedded
ones.
Since Babel datagrams are comprised of a sequence of TLVs, it's best to
fragment
at the Babel layer because that way a single fragment is still parseable in
the
presence of packet loss. I added text to clarify this.