Subject: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile

From: Ondřej Surý <[email-masked]>
Date: Mon, 30 Aug 2010 10:57:25 +0200

Hi,

I was convinced by Phillip that the charter should be as open-minded as 
possible, even though the original idea was to include just TLS.  Anyway
I would like to ask you, if you think about adding SSH(FP) to our 
charter to do a little homework and try using SSHFP with OpenSSH and 
then write down what's missing from SSHFP.  Ie. what will the future 
work of this group look like on that field.

I have used SSHFP in the past and there are two minor and one bigger 
problem:

Minor:

1) openssh server: the setup - you need to run sshfp utility and put the 
result into the DNS -> some kind of help from OpenSSH would be great - 
at least print the SSHFP records by default

2) openssh client: you have to enable SSHFP validation by hand, because 
default value of VerifyHostKeyDNS is "no".

Bigger:
3) Secure Last Mile: I think it was already stated here (or on other 
place) that simply trusting AD bit is not sufficient, and there is a 
strong need for securing last mile.  Could it be a validating resolver 
on localhost (but it's not secure on multi-user machine).  Could it be 
IPSec (but this is probably valid only in strictly controlled 
environment).  Could be SIG(0) to your resolver?

Hence I don't think that there is a much work to do for SSH since the 
work there is finished (maybe couple of BCP with recommendations how to 
use it), but there is a big piece of work on securing the last mile, 
which will probably need a changed APIs in the system libraries in the 
long run, and application stub resolvers in the short run.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: David Conrad <[email-masked]>
Date: Mon, 30 Aug 2010 11:44:15 -0700

On Aug 30, 2010, at 1:57 AM, Ondřej Surý wrote:
> 3) Secure Last Mile: I think it was already stated here (or on other place) that simply trusting AD bit is not sufficient, and there is a strong need for securing last mile.  Could it be a validating resolver on localhost (but it's not secure on multi-user machine).  

I'd imagine that if you can't trust your resolver on your local machine (multi-user or not), you have bigger problems than the risks associated with DNS response corruption.

> Could it be IPSec (but this is probably valid only in strictly controlled environment).  Could be SIG(0) to your resolver?

There's TSIG too. Basically, it is any way you can establish a secure channel to the trusted resolver.  Since establishing a secure channel over the Internet is generally harder than doing so on the local machine, I've argued that the right place for a validating resolver is on the local host (and you also have a better chance of getting access to logs to figure out why stuff fails when those logs are on the local machine). 

> Hence I don't think that there is a much work to do for SSH since the work there is finished (maybe couple of BCP with recommendations how to use it),

I'd agree.

> but there is a big piece of work on securing the last mile, which will probably need a changed APIs in the system libraries in the long run, and application stub resolvers in the short run.

Personally, I've felt pretty much all of the current APIs are fundamentally broken, e.g., encouraging folks to make assumptions like data associated with names never change (or IP addresses associated with end points never change or IP addresses have particular structure, etc.) for the lifetime of the application. We could probably come up with some hacks to bandaid over the sucking chest wound that is the current API model, but it is a big swamp to drain and I suspect doing it right would be a bit beyond the scope of the potential working group being discussed here.

Regards,
-drc

---

From: Warren Kumari <[email-masked]>
Date: Mon, 30 Aug 2010 14:52:46 -0400

On Aug 30, 2010, at 2:44 PM, David Conrad wrote:

>> 3) Secure Last Mile: I think it was already stated here (or on  
>> other place) that simply trusting AD bit is not sufficient, and  
>> there is a strong need for securing last mile.  Could it be a  
>> validating resolver on localhost (but it's not secure on multi-user  
>> machine).
>
> I'd imagine that if you can't trust your resolver on your local  
> machine (multi-user or not), you have bigger problems than the risks  
> associated with DNS response corruption.
>
>> Could it be IPSec (but this is probably valid only in strictly  
>> controlled environment).  Could be SIG(0) to your resolver?
>
> There's TSIG too.

No, no there isn't. Here is where I go into my standard rant about the  
fact that standard stub resolvers don't support either of these:
Standard stub resolvers don't support SIG(0) / TSIG. Every time I want  
to do this, someone says "Yeah, it's super easy, you setup the server  
like <blargh> then, on the client, you edit /etc/resolv.conf and  
enter.... erm.... weeeeellll.... gimma a sec... bugger..."
Sorry, but yes, I *do* feel better now....

W

> Basically, it is any way you can establish a secure channel to the  
> trusted resolver.  Since establishing a secure channel over the  
> Internet is generally harder than doing so on the local machine,  
> I've argued that the right place for a validating resolver is on the  
> local host (and you also have a better chance of getting access to  
> logs to figure out why stuff fails when those logs are on the local  
> machine).
>
>> Hence I don't think that there is a much work to do for SSH since  
>> the work there is finished (maybe couple of BCP with  
>> recommendations how to use it),
>
> I'd agree.
>
>> but there is a big piece of work on securing the last mile, which  
>> will probably need a changed APIs in the system libraries in the  
> Personally, I've felt pretty much all of the current APIs are  
> fundamentally broken, e.g., encouraging folks to make assumptions  
> like data associated with names never change (or IP addresses  
> associated with end points never change or IP addresses have  
> particular structure, etc.) for the lifetime of the application. We  
> could probably come up with some hacks to bandaid over the sucking  
> chest wound that is the current API model, but it is a big swamp to  
> drain and I suspect doing it right would be a bit beyond the scope  
> of the potential working group being discussed here.
>
> Regards,
> -drc
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Credo quia absurdum est.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 30 Aug 2010 11:58:41 -0700

On Aug 30, 2010, at 1:57 AM, Ondřej Surý wrote:
> Bigger:
> 3) Secure Last Mile: I think it was already stated here (or on other place) that simply trusting AD bit is not sufficient, and there is a strong need for securing last mile.  Could it be a validating resolver on localhost (but it's not secure on multi-user machine).  Could it be IPSec (but this is probably valid only in strictly controlled environment).  Could be SIG(0) to your resolver?

Actually, the resolver on localhost is secure on a multi-user machine, in the sense that any adversary who could corrupt that resolver could corrupt other parts of the victim.

IPSec or others to a "trusted" secondary resolver is, IMO, silly:  DNSSEC is all about not needing to trust the infrastructure, so why change the DNS client model to one that establishes a 'secure' connection to a 'trusted' resolver instead of just having the client validate the information directly and, if it can't validate the information, fetches it for itself if you don't trust the external resolver?

---

From: David Conrad <[email-masked]>
Date: Mon, 30 Aug 2010 12:35:50 -0700

On Aug 30, 2010, at 11:52 AM, Warren Kumari wrote:
>> There's TSIG too.
> No, no there isn't. Here is where I go into my standard rant about the fact that standard stub resolvers don't support either of these

Implementation detail (half :-)). I'm sure the fine folks at ISC and/or NLNetLabs would be more than happy to implement the appropriate hacks to resolv.conf and stub resolvers if you wave money at them.  I suspect the reason TSIG/SIG(0) protected channel between validating resolvers and stub resolvers hasn't been implemented to date is (a) no point given DNSSEC hadn't been deployed, (b) IPSec does the same thing and already exists and/or (c) running a local validating resolver is easier.

Regards,
-drc

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Aug 2010 15:14:02 -0700

At 11:58 AM -0700 8/30/10, Nicholas Weaver wrote:
>On Aug 30, 2010, at 1:57 AM, OndÞej Sur˜ wrote:
>> Bigger:

This exposes something that people in the security community constantly grapple with / trip over: who is the trust anchor? In the "localhost" scenario above, it is the DNSSEC root or whichever lower DNSSEC trust anchors you have manually installed. In the "IPsec or others" scenario, it is a trusted third party who is doing resolution for you, such as "your ISP" or "your corporation".

Those are radically different models that are desired by different types of people with different needs. You can't say one is more important than the other because you are making a value judgement for people with whom you disagree.

The "localhost" solution is defined today. The "IPsec or others" is too, but in a zillion different ways. If there is interest in making the latter more focused, that's great, but such work is for the DNSEXT WG, not here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 30 Aug 2010 18:25:51 -0400

DNSSEC is an internet security scheme not an intranet security scheme.
There is a big difference in the approaches and the constraints that
are relevant.

The objective of DNSSEC is to secure the DNS protocol. As an
enterprise I could not give a hoot for the security of the DNS
protocol unless it negatively impacts my actual security objectives.
In particular DNSSEC is designed to ensure that a client has a
faithful copy of the authoritative DNS, I don't want my machines to
connect to the authoritative DNS and to connect to every Internet site
any more than I would want them to run every program run by every
random bozo I never met.

In short, enterprise security is not the same as what individuals
chose to run for themselves.

What is taken to be a demand for 'security' is more often a regulatory
requirement for compliance. And it is instructive to see how very
subtle changes in a system can create massive compliance issues.

So for example, I move from using SSH with bilateral keys to SSH with
keys stored and distributed via the DNS. It is really easy to show
that this offers the same theoretical degree of control if the
applications are using a trust root that I control or I have a direct
contractual agreement with. What do I tell the auditor if I am
trusting a root I don't control and nor does the party being
authenticated?

It shows up fairly starkly in SSH because we are moving from an
environment with direct key management with an organized hierarchy. It
is much harder to spot this situation where we are talking about
moving from 99% of traffic having no security to having better than
nothing security.

-- 
Website: http://hallambaker.com/