Subject: [manet] DLEP-16: "Use TLS" indicator has issues

From: RJ Atkinson <[email-masked]>
Date: Mon, 17 Aug 2015 15:28:42 -0400

DLEP version 16, in Sections 9.2 and 9.3, defines
a non-authenticated indicator of whether TLS should
be used.

A) Protocol Design

Consuming 8 bits for a binary indicator isn’t really
great protocol design.  Ignoring security for a moment,
the usual protocol design approach would be to define
an 8-bit (or whatever length) FLAGS field, allocate
the 1 bit to “Use TLS” and reserve the remaining bits
for future use by the DLEP protocol.

B) Security Problem

That aside, the current approach creates a trivially exploited
“downgrade attack” where by a Man-in-the-middle simply clears 
the “Use TLS” indicator from a packet to indicate that TLS 
ought not be used.  I think that is a fatal security flaw
for this protocol extension (small “e”).

Yours,

Ran

---

From: Henning Rogge <[email-masked]>
Date: Mon, 17 Aug 2015 22:02:51 +0200

> for future use by the DLEP protocol.

My original idea was to make it a "connection type" field with an IANA
registry attached, but a bitfield would work fine.

B) Security Problem
> for this protocol extension (small “e”).

If your endpoints still support "no TLS", even a signature would not
prevent the downgrade. Because the man-in-the-middle could just remove the
signature and pretend to be "no TLS" only, which is the point of the
downgrade attack.

If the endpoint only supports TLS but doesn't check the other sides
certificate, the man-in-the-middle could still do its attack by running a
TLS session to each side.

If the endpoint only supports TLS AND check the validity of the
certificate, the downgrade will fail when you start the TCP session.

Did I miss something?

Henning Rogge

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 17 Aug 2015 16:42:53 -0400

> On 17  Aug 2015, at 16:02 , Henning Rogge <[email-masked]> wrote:
> 
> prevent the downgrade. Because the man-in-the-middle could just remove
> the signature and pretend to be "no TLS" only, which is the point
> of the downgrade attack.

Meaning:  The “Use TLS” signal of DLEP-16 doesn’t work.

Also, please note that if my other Security Considerations text 
proposal were accepted into DLEP++, then implementations that 
don’t support TLS would eliminate vulnerability to the attack 
by restricting DLEP endpoints to non-routable IP addresses.

My goal is risk reduction.  If one can reduce the risk without
using cryptography, I think that actually is preferable, because
it eliminates potentially expensive computations and also reduces
overall application complexity.

> If the endpoint only supports TLS but doesn't check the other sides certificate, the man-in-the-middle could still do its attack by running
> a TLS session to each side.

This is out-of-scope for the DLEP specification, in that certificate
checks are (I believe) required by TLS.  In any case, your text above
is a very good reason to cite [BCP195] in the Security Considerations
section.

> certificate, the downgrade will fail when you start the TCP session.

The DLEP version 16 specification says that DLEP users make the 
decision about whether TLS is used or not for their particular
session(s).  So the concept of a DLEP implementation that ALWAYS
uses TLS (and always checks Certs as any good TLS implementation
would) appears to be prohibited by the DLEP draft.

Thanks for identifying the various cases and analyzing them
individually.

Cheers,

Ran

---

From: Henning Rogge <[email-masked]>
Date: Tue, 18 Aug 2015 06:40:35 +0200

My point is that there is no security gain in using something like DTLS
and/or signatures on the UDP packets in the presence of a man-in-the-middle.

Henning Rogge

On Mon, Aug 17, 2015 at 10:42 PM, RJ Atkinson <[email-masked]> wrote:

> certificate, the man-in-the-middle could still do its attack by running
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 18 Aug 2015 07:47:36 -0400

> On 18  Aug 2015, at 00:40 , Henning Rogge <[email-masked]> wrote:
> 
> My point is that there is no security gain in using something like
> DTLS and/or signatures on the UDP packets in the presence of a
> man-in-the-middle.

That sentence is much more clear to me than yesterday’s note 
as to your thinking.  Thanks.

In any case, one would need to differentiate link-local 
circumstances from off-link circumstances.  An oddity is that 
the DLEP draft is NOT currently specific anywhere (e.g. in IANA 
Considerations) about which IP Multicast address block (e.g. 
Link-Local, other) the DLEP IP Multicast addresses ought to be 
allocated from.  Based on my read of the DLEP-15 draft and list 
discussion, I have suggested (both back in July and yesterday) 
specific IP Multicast Address blocks from which the DLEP IP Multicast
addresses ought to be allocated.

That said, use of DTLS was not suggested in any of my notes yesterday,
based on previous list discussion (e.g. during July, before Prague).

Yours,

Ran