Subject: [TLS] Are we holding TLS wrong?

From: David Schinazi <[email-masked]>
Date: Thu, 8 Nov 2018 09:14:25 +0700

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

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Thu, 8 Nov 2018 04:30:18 +0000

Hi David,

A few quick notes below.

Cheers

> Also, should the document contain guidance such as which DTLS version to

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 8 Nov 2018 05:53:20 +0100

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)" <[email-masked]>

An: "David Schinazi" <[email-masked]>

Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

Betreff: Re: [TLS] Are we holding TLS wrong?

Hi David,

A few quick notes below.

Cheers

authentication.

- s2.1

- s2.5

:-)

- s.3

--

Thomas

_______________________________________________

TLS mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Nov 2018 19:26:21 +0700

Hi David,

I couldn't find any description of the threat model involved here, nor
could I find any analysis of the security against that model.  Without
that, I can't really say whether this is right or not.  For instance,
there is specific mention of the certificate status request extension,
but there is no mention of why.

Given the configuration that I might infer from the hmac draft, I'm a
little surprised that this doesn't use PSK.

I'm somewhat dismayed by the firm recommendation to use the HMAC
mechanism, which doesn't seem particularly robust.  Offhand, it seems
like replays are possible if you allow the possibility of the node
crashing and dumping state.  The same applies during a rollover of the
32-bit counter.  Of course, that might not be permitted by the threat
model.
On Thu, Nov 8, 2018 at 9:15 AM David Schinazi <[email-masked]> wrote:
>
> Hi everyone,
>
> Over in the Babel working group we have a draft about securing Babel with DTLS:
> 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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 09 Nov 2018 17:10:54 +0100

> mechanism,

Yeah, this could probably be loosened somewhat.

> which doesn't seem particularly robust.

It's designed to be fairly robust.  Of course, we may have done things
wrong.

> Offhand, it seems like replays are possible if you allow the possibility
> of the node crashing and dumping state.

Unless I've missed something -- they are not, assuming you have
a sufficiently strong random number generator.  The challenge mechanism
rebuilds the shared state in a secure manner, and the index mechanism
ensures that an (index, seqno) pair is never reused.

> The same applies during a rollover of the 32-bit counter.

You generate a new index when the counter overflows, and send a new
challenge.  First point of Section 4.2 of the HMAC draft.

-- Juliusz

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Nov 2018 07:57:16 +0700

> ensures that an (index, seqno) pair is never reused.

I had a really hard time understanding this, even with this help.
Right now, I don't know what key is used for HMAC.  I think that the
expectation is that each peer has a fixed HMAC key, but the contents
of the packet always change, thereby ensuring that the resulting MAC
is different for every packet.

Given how non-intuitive this whole thing is, I would suggest that a
formal analysis would be a good idea.  Or you could just use DTLS and
get things like post compromise security and nice things like that.

---

From: David Schinazi <[email-masked]>
Date: Mon, 12 Nov 2018 17:32:49 -0800

Thanks for the feedback Thomas! Responses inline.

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

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

> forgot, sorry) L-L address in a clear-text multicast Hello and bypass

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

> as a more robust alternative.

Good point, I added text.

> make explicit signalling EOD at least a SHOULD?  It seems more polite

I agree, I upgraded politeness to a SHOULD.

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

---

From: David Schinazi <[email-masked]>
Date: Mon, 12 Nov 2018 17:32:55 -0800

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 <[email-masked]>
wrote:

> 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)" <[email-masked]>
> *An:* "David Schinazi" <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Betreff:* Re: [TLS] Are we holding TLS wrong?
> Hi David,
>
> A few quick notes below.
>
> Cheers
>

---

From: David Schinazi <[email-masked]>
Date: Mon, 12 Nov 2018 17:32:58 -0800

Hi Martin,

Thanks for looking into this.

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?

I've removed the mention of the certificate status request extension,
as I don't think it's relevant and don't remember why it was added.

PSK can either be used with:
- one key for the entire network, which does not allow revocation
- 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
so PSK would be suited in the simple case where revocation is not
wanted, but in that use-case we recommend Babel-HMAC.

I'll let the Babel-HMAC authors start a separate thread.

David

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Nov 2018 14:45:50 +1100

> Babel over DTLS is to prevent that. Can you suggest a better way

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.

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

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 13 Nov 2018 22:39:14 +0100

> HMAC-based protocol.

The scope of Babel-HMAC is deliberately limited.  Babel-HMAC aims to
implement the strict minimum of features that make it useful.

Any deployment that needs features beyond what Babel-HMAC provides should
use Babel-DTLS instead.

> If N^2 is feasible, it would be good to hear how those keys are managed.

Not in Babel-HMAC, no.  We've tried to be very clear about that in Section 1.1
of draft-ietf-babel-hmac-00 :

   The protocol defined in this document assumes that all interfaces on
   a given link are equally trusted and share a small set of symmetric
   keys (usually just one, two during key rotation).  The protocol is
   inapplicable in situations where asymmetric keying is required, where
   the trust relationship is partial, or where large numbers of trusted
   keys are provisioned on a single link at the same time.

   This protocol supports incremental deployment (where an insecure
   Babel network is made secure with no service interruption), and it
   supports graceful key rotation (where the set of keys is changed with
   no service interruption).

   This protocol does not require synchronised clocks, it does not
   require persistently monotonic clocks, and it does not require any
   form of persistent storage.

If you believe this deserves further clarification, we'll be grateful for
your guidance.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 13 Nov 2018 22:41:37 +0100

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

Note however that a neighbour is usually discarded when we loose too many
Hellos from it.  At that point, we've lost contact with the neighbour,
it's too late to be polite.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 14 Nov 2018 11:49:39 +0100

> is different for every packet.

That's the general idea, yes.  I'm not a cryptographer myself, and I don't
know how original this is.

> I would suggest that a formal analysis would be a good idea.

Yes, we're hoping to do that.  If you could point us to examples of papers
that contain a proof of correctness of a cryptographic protocol that you
believe is well done, that'd be helpful.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Wed, 14 Nov 2018 12:19:04 -0800

Hi everyone,

Thanks again for your feedback, we've updated the document to reflect it:
https://tools.ietf.org/html/draft-ietf-babel-dtls-02
https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-02

David