Subject: [Netconf] Reverse TLS and reverse SSH: Why support both?

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

Hi,

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

Why support SSH and TLS? Either protocol establishes a secure tunnel by
exchanging 1’s and 0’s.

Why leave the decision which protocol to use to the manufacture? If the WG
can’t decide if TLS or SSH is more secure then the manufacture won’t be
able to decide either.

Removing one of them from the implementation halves the possibilities for
an attacker to find vulnerabilities, enables the developer to spend 2x the
time (and care) on one protocol and removes complexity in general.

Focusing on one protocol and give that one protocol all attention (review,
testing, audit ...) could have some advantages.

Supporting multiple different protocols, bloating up the size of the code
(binary or source), adding complexity and leaving the manufacture in charge
to make security related decisions are all things that weaken the security.

My gut feeling is that reverse SSH should be dropped unless there is a
functionality or security benefit that cannot be achieved with reverse TLS.

Trusting a manufacture to generate secure X.509 certificates, having a
secure RNG and running a CA securely gives me a funny feeling. But hey,
what can possibly go wrong....:>

regards,

ralf

---

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

>exchanging 1¹s and 0¹s.

NETCONF supports both transports for good reasons.

> Why leave the decision which protocol to use to the manufacture? If the
>WG can¹t decide if TLS or SSH is more secure then the manufacture won¹t
>be able to decide either.

It isn't left to the manufacturer, each specific deployment chooses it for
themselves.

> Removing one of them from the implementation halves the possibilities
>for an attacker to find vulnerabilities, enables the developer to spend
>2x the time (and care) on one protocol and removes complexity in general.

> Focusing on one protocol and give that one protocol all attention
>(review, testing, audit ...) could have some advantages.

Noted.  Each manufacturer can choose what they want to implement and
support.

>functionality or security benefit that cannot be achieved with reverse

SSH is NETCONF's mandatory transport, as such, supporting Call Home with
SSH is a given.  

>what can possibly go wrong....:>

Your concern is unwarranted.  The spec clearly states that the
manufacturer should use a TPM.  These chips are typically awarded the
highest security certifications (FIPS, CC, etc.).   Also, this proposal
has been reviewed by multiple security experts with no concern raised.
But, really, what option is there, given the use-cases ZeroTouch tries to
solve?

Thanks,
Kent

---

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

> NETCONF supports both transports for good reasons.

What are these good reasons to support two transports which achieve the
same thing?

> It isn't left to the manufacturer, each specific deployment chooses it for

It was iterated again in today's Plenary Session: The less options you give
to the user/admin the more secure it will be.

Just from a security point of view I can not see why support both protocols
is more secure than just supporting one of them.

> SSH is NETCONF's mandatory transport, as such, supporting Call Home with

Why was SSH chosen instead of TLS? (just curious from a security point of
view).

> But, really, what option is there, given the use-cases ZeroTouch tries to

I've pushed a product through FIPS140-2 and CC and reviewed many others.
Some are broken beyond recognition and still get FIPS certified. FIPS does
not guarantee security. FIPS only shows that the product complies with some
(often outdated) policies.

It would not be the first FIPS device that gets broken. Anyway, there is no
alternative to the TPM. It's as good as it gets I guess. Let's see what
happens...

regards,

ralf