Subject: [Netconf] Why bother with DNSSEC for ZeroTouch?

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 5 Nov 2013 19:09:07 +0000

Hi,

I’ve only just joined the discussion. I was at the IETF88 netconf WG
meeting yesterday morning and that was the first time I heard about
netconf. I’m a newbie here. Have nothing to contribute except some security
concerns. Most (maybe all) have been discussed already.

Security principal: Anything that does not improve security or
functionality should be removed or disabled.

The security vulnerabilities grow linearly with the size of the source
code. Anything that is (unnecessarily) left inside a product weakens the
security of a product: It is where an attacker can attack, it is extra code
(binary or source) that has to be audited, it is extra complexity and it is
developer’s time wasted on things that do not improve security or
functionality.

DNSSEC does not add functionality. (Anything that can be done with DNSSEC
can be done with DNS [but insecurely]).

Does DNSSEC add security?

If DNS is used an attacker can make the device to connect to a bogus NMS.
The secure connection would fail because of SSH/TLS. Ultimately an attacker
can trigger a DoS. That’s it. Not more.

There are many other ways for an attacker to make the device to connect to
a bogus NMS and even more ways to DoS the device (preventing the device to
connect to the NMS at all) – regardless if DNSSEC is used or not.

So why bother with DNSSEC for ZeroTouch?

(Removing DNSSEC also seems to solve other non-security
related/compatibility issues and reduces the complexity for the manufacture
as well. As easier security is as faster and wider it will get adopted).

regards,

ralf

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Nov 2013 11:27:55 -0800

On 05 Nov 2013, at 11:09, Ralf Skyper Kaiser <[email-masked]> wrote:

> Hi, 
> 
> 
> 
> I’ve only just joined the discussion. I was at the IETF88 netconf WG meeting yesterday morning and that was the first time I heard about netconf. I’m a newbie here. Have nothing to contribute except some security concerns. Most (maybe all) have been discussed already.
> 
>  
> Security principal: Anything that does not improve security or functionality should be removed or disabled.
> 
>  
> The security vulnerabilities grow linearly with the size of the source code. Anything that is (unnecessarily) left inside a product weakens the security of a product: It is where an attacker can attack, it is extra code (binary or source) that has to be audited, it is extra complexity and it is developer’s time wasted on things that do not improve security or functionality.
> 
>  
> DNSSEC does not add functionality. (Anything that can be done with DNSSEC can be done with DNS [but insecurely]).
> 
>  
> If DNS is used an attacker can make the device to connect to a bogus NMS. The secure connection would fail because of SSH/TLS. Ultimately an attacker can trigger a DoS. That’s it. Not more.

I don’t agree. The attacker has an open TCP session and can use it for other attacks, not only DoS. Already the information about the existence and address of the device might be a problem. 

Other that that, DNSSEC can be useful in connection with DANE (RFC 6698), so that a certificate of a DNSSEC root (public or private) is all that’s needed - NMS certificate can thrn be obtained from DNS.

Lada

> 
>  
> There are many other ways for an attacker to make the device to connect to a bogus NMS and even more ways to DoS the device (preventing the device to connect to the NMS at all) – regardless if DNSSEC is used or not.
> 
>  
> (Removing DNSSEC also seems to solve other non-security related/compatibility issues and reduces the complexity for the manufacture as well. As easier security is as faster and wider it will get adopted).
> 
> 
> regards,
> 
> ralf
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 5 Nov 2013 19:55:47 +0000

Hi,

.

On Tue, Nov 5, 2013 at 7:27 PM, Ladislav Lhotka <[email-masked]> wrote:

> I don’t agree. The attacker has an open TCP session and can use it for
> other attacks, not only DoS. Already the information about the existence
> and address of the device might be a problem.
>
>
Even with DNSSEC an attacker can make the device to connect to a bogus NMS
and thus giving the attacker an open TCP session to the device......

> Other that that, DNSSEC can be useful in connection with DANE (RFC 6698),
> so that a certificate of a DNSSEC root (public or private) is all that’s
> needed - NMS certificate can thrn be obtained from DNS.
>

In ZeroTouch the CA bundle is pre-programmed into the device. So DANE is
not required. (And it DANE would be required than the CA key to verify the
DNSSEC request would need to be preprogrammed into the device - nothing is
gained beside making it complex?).

regards,

ralf

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Nov 2013 12:10:31 -0800

On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser <[email-masked]> wrote:

> Even with DNSSEC an attacker can make the device to connect to a bogus NMS and thus giving the attacker an open TCP session to the device……

With DNSSEC this becomes considerably harder.

> In ZeroTouch the CA bundle is pre-programmed into the device. So DANE is not required. (And it DANE would be required than the CA key to verify the DNSSEC request would need to be preprogrammed into the device - nothing is gained beside making it complex?).

The device can only be pre-programmed with DNSSEC trust anchor, and that’s all. I don’t call it complex.

Lada

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 5 Nov 2013 20:18:55 +0000

Hi,

On Tue, Nov 5, 2013 at 8:10 PM, Ladislav Lhotka <[email-masked]> wrote:

> > Even with DNSSEC an attacker can make the device to connect to a bogus
> NMS and thus giving the attacker an open TCP session to the device……
>
No it does not.
DNSSEC does not prevent any of these to redirect the reverse TLS/reverse
SSH traffic:
- arp poisoning
- Switch/CAM table tricks
- transparent proxy
- router reconfiguration
- directly tapping the physical wire
- .. this list is not complete....pretty much anywhere and using any method
between the client and the NMS.

DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS
poisoning. Not more.

regards,

ralf

---

From: Kent Watsen <[email-masked]>
Date: Wed, 6 Nov 2013 01:14:18 +0000

Hi Ralf,

Please explain the specific attack you're envisioning.  I agree that the device's call-home connection could be steered to another system and I'll agree that that system could blindly authenticate the device's public key.   But in order for security to be compromised, that system needs to be able to authenticate itself to the device, which is where it will fail because it will not know the real NMS's auth credentials (e.g. private key).

Keep in mind, that the data ZeroTouch pulls down has dual goals: 1) to configure the device with the NMS it's to connect to and 2) to configure the device with information it can use to authenticate the NMS with.  It is this 2nd piece of information that prevents the spoofer from succeeding.  Critical to this is that the device can verify the authenticity of the information it downloads from the network, which is where using DNSSEC plays a role.  Makes sense?

PS: I also agree with your premise that unnecessary code leads to a larger attack surface, but devices should already have support for DNSSEC.  It is not envisioned that this solution introduces new code to the device but, if it does, it is a good thing.

Thanks,
Kent

From: Ralf Skyper Kaiser <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 5, 2013 12:18 PM
To: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
Cc: NetConf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch?

Hi,

On Tue, Nov 5, 2013 at 8:10 PM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:

On 05 Nov 2013, at 11:55, Ralf Skyper Kaiser <[email-masked]<mailto:[email-masked]>> wrote:

>
> Even with DNSSEC an attacker can make the device to connect to a bogus NMS and thus giving the attacker an open TCP session to the device......

No it does not.
DNSSEC does not prevent any of these to redirect the reverse TLS/reverse SSH traffic:
- arp poisoning
- Switch/CAM table tricks
- transparent proxy
- router reconfiguration
- directly tapping the physical wire
- .. this list is not complete....pretty much anywhere and using any method between the client and the NMS.

DNSSEC in ZeroTouch prevents one (of many!) redirection methods: DNS poisoning. Not more.

regards,

ralf

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Wed, 6 Nov 2013 20:25:22 +0000

Hi Kent,

The only thing that I can find in the ZeroTouch draft is that DNSSEC is
used to retrieve information that are public and if wrong (by an attacker)
end up in a DoS:

- IP of NMS
- username for NMS
- if reverse TLS or reverse SSL should be used.

A scenario where an attacker can change/modify either of those ends up in a
DoS. What other attack vector does DNSSEC solve beside DoS against the
device?

If DNSSEC in this scenario only solves a DoS then why bother with DNSSEC
considering that the attacker can already mount a DoS attack with far less
resources at a far lower cost.

DNSSEC does not solve this DoS problem (and you should not try to solve it
either as the attacker will always have the upper hand _in this scenario_
of device DoS).

regards,

ralf

On Wed, Nov 6, 2013 at 1:14 AM, Kent Watsen <[email-masked]> wrote:

>
>  Hi Ralf,
>
>  Please explain the specific attack you're envisioning.  I agree that the
> device's call-home connection could be steered to another system and I'll
> agree that that system could blindly authenticate the device's public key.
>   But in order for security to be compromised, that system needs to be able
> to authenticate itself to the device, which is where it will fail because
> it will not know the real NMS's auth credentials (e.g. private key).
>
>  Keep in mind, that the data ZeroTouch pulls down has dual goals: 1) to
> configure the device with the NMS it's to connect to and 2) to configure
> the device with information it can use to authenticate the NMS with.  It is
> this 2nd piece of information that prevents the spoofer from succeeding.
>  Critical to this is that the device can verify the authenticity of the
> information it downloads from the network, which is where using DNSSEC
> plays a role.  Makes sense?
>
>  PS: I also agree with your premise that unnecessary code leads to a
> larger attack surface, but devices should already have support for DNSSEC.
>  It is not envisioned that this solution introduces new code to the device
> but, if it does, it is a good thing.
>
>  Thanks,
> Kent
>
>
>   From: Ralf Skyper Kaiser <[email-masked]>
> To: Ladislav Lhotka <[email-masked]>
> Cc: NetConf <[email-masked]>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 7 Nov 2013 01:13:05 +0000

> A scenario where an attacker can change/modify either of those ends up
>in a DoS. What other attack vector does DNSSEC solve beside DoS against
>the device?

I don't understand, how could an attacker change/modify the call home data
in DNS without invalidating a DNSSEC signature?  Using DNSSEC is more
about preventing MITM than DoS.

>considering that the attacker can already mount a DoS attack with far
>less resources at a far lower cost.

Because a MITM (not-detectable) is worse than a DoS (detectable) - makes
sense?

Thanks,
Kent

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Thu, 7 Nov 2013 11:55:47 +0000

Hi

> about preventing MITM than DoS.
Misunderstanding.

I'm using the word 'DNS' when I'm talking about traditional DNS (RFC1034).
I'm using
 'DNSSEC' (and DNSSEC-request) to refer to a secure DNS (RFC3833).

Your are saying "DNSSEC is more about preventing MITM than DoS".

Which is correct. I'm not proposing any new magical trick against
the security of DNSSEC.

My point is that in ZeroTouch the DNSSEC is used to protect information
which
if transmitted by DNS do not stop DoS (in general) against ZeroTouch
devices.

Assuming ZeroTouch would use DNS (not DNSSEC) the attacker can send wrong
information to the ZeroTouch device which ultimately ends in a DoS (e.g. the
ZeroTouch device will attempt but fail to establish a secure connection
(TLS/SSH)
to the wrong NMS).

The sole and only use for DNSSEC in ZeroTouch (not in general) is to
prevent (or detect) a DoS-by-MITM.

DNSSEC does not prevent an attacker (in general) to perform a DoS (by MITM
or
other means).

You can not stop an attacker to DoS the ZeroTouch device regardless if
ZeroTouch
uses DNSSEC or not.

In fact performing a DoS where the ZeroTouch device connects to the wrong
NMS
even when DNSSEC is used is possible with far less effort and without
breaking
DNSSEC (see my previous email with the list of other MITM attacks).

ZeroTouch has to deal with the problem that a ZeroTouch device might
connect to the
wrong NMS even when DNSSEC is used.

ZeroTouch deals with this in a correct and secure way: It uses TLS/SSH. The
TCP connection to the wrong NMS will succeed but the secure connection will
fail.

It appears that DNSSEC is used in an attempt to prevent one (of many) ways
to
DoS the ZeroTouch device.

An attack will laugh at this attempt and say "Well, if I can not DoS
ZeroTouch device
by DNS poisoning I just use any of my other 10 MITM tricks [see previous
email for
a list] against which ZeroTouch currently does not protect".

An attacker gets what he wants (DoS) even if DNSSEC is used.

So why bother with DNSSEC? It just adds code and complexity.

(This would be all different if DNSSEC were to be used to transfer
information which have
to be authentic - like public key material).

> Because a MITM (not-detectable) is worse than a DoS (detectable) - makes

No, because you do not protect (or detect) any of the other DoS either (and
you should
not try to).

Maybe a real life fairy tale scenario helps (sorry, that's the best I can up
with at 3am in the morning):

10 gates to enter a castle. You put one guard (DNSSEC) at just 1 of the 10
gates
saying that you will now detect DoS (at that gate).

DoS still gets in to any of the 9 other gates.

You can not protect all 10 gates. Might as well use the guard (e.g.
resources) to do
something else.

DNSSEC in ZeroTouch adds unnecessary complexity. (The guard at 1 of the 10
gates does
not solve your problem).

thanks & regards,

ralf

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Thu, 7 Nov 2013 18:49:58 +0000

Inline with [Yi]

From: Ralf Skyper Kaiser <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 5, 2013 3:18 PM
To: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
Cc: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] Why bother with DNSSEC for ZeroTouch?

<snip>

No it does not.

[Yi]: In the above cases, they have to be launched in  the path between the client and NMS, or around the clients. But without DNSSEC, the attacker can be anywhere.

[Yi]: In addition, the threat scope is different. Those aforementioned threats will influence a subnet of clients which are closed to the subverted devices. But without DNSSEC, all clients across network will be impacted.

regards,

ralf

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 19 Nov 2013 12:22:41 +0000

Yi,

DNSSEC in netconf is used to prevent one particular DoS attack. That's it.
Not more. Not less.
(It does not protect against other DoS attacks. So netconf anyway has to
deal with DoS [and it
does so very well - ultimately with TLS/SSH authentication]).

DNSSEC is not use to prevent wrong netconf-configuration to be send to the
device (That's done
by TLS/SSH - not DNSSEC).

DNSSEC protect against this 1 DoS that has no practical gain for the
attacker (e.g. the DoS does not enable
the attacker to send wrong netconf configuration to the device). (A DoS
also means that the attacks risks
detection - something that most attacks do not want.)

I appreciate the effort to protect netconf against this 1 DoS. From my
experience will this reduce the
security of netcont. I said this before:

DNSSEC is a complex beast. The source/program code does contain remote
vulnerabilities (we have just
not found them yet - believing that it is vulnerability free would be
naive).

Netconf enabled devices are mostly embedded. Those device have a long
shelf-life time before deployment.
A vulnerability in DNSSEC/netconf will be found and you wont have any
chance of fixing them beside
recalling hardware - which wont happen.

That's the cost of protecting against 1 DoS. It's out of balance.

(and same argument goes for supporting TLS and SSH. You are doubling the
amount of source/programm code vulnerabilities...).

regards,

ralf

On Thu, Nov 7, 2013 at 6:49 PM, Yi Yang (yiya) <[email-masked]> wrote:

> Cc: Netconf <[email-masked]>
>
>  [Yi]: In the above cases, they have to be launched in  the path between
> the client and NMS, or around the clients. But without DNSSEC, the attacker
> can be anywhere.
>
>  [Yi]: In addition, the threat scope is different. Those aforementioned
> threats will influence a subnet of clients which are closed to the
> subverted devices. But without DNSSEC, all clients across network will be
> impacted.
>