Subject: [websec] Use of DNS/DNSSEC for strict security

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Oct 2010 14:21:05 -0400

Has anyone (else) been considering the possible use of the DNS to signal a
strict security requirement?

While I like the idea of strict security, signaling by means of HTTP headers
creates a circular dependency. I can only guarantee strict security after
first achieving a secure connection. And anything that is done for HTTP
becomes a one-off that cannot be applied to SMTP and other protocols.

I am not arguing against doing the HTTP header approach. Given the attacks
we are facing I do not want strict security to be dependent on successful
DNSSEC deployment. But I would like to see a HTTP header approach that is
consistent with eventual deployment of a DNSSEC based approach.

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

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Tue, 12 Oct 2010 21:04:04 +0200

> consistent with eventual deployment of a DNSSEC based approach.

I am not against the suggestion, and I recognize that there are problems  
with the bootstrapping process, but:

Any such system would need to define an API akin to that specified by RFC  
3493 (the APIs used to do namelookups for IPv6) that must be implemented  
in every Operating System.

Anything else would require the client to implement full DNS(SEC) support,  
discover the network configuration, or go direct to deduced nameservers,  
and as a result cause at least potential interoperability problems and  
inefficiencies due to less use of DNS caching.

Additionally, there is the problem with network configurations that does  
not allow any external network traffic except through an HTTP proxy. IOW:  
General DNS is not always available. A workaround for that might be a  
HTTP(s?) based webservice interface to DNS(SEC).

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 12 Oct 2010 13:09:35 -0600

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
> Sent: Tuesday, October 12, 2010 11:21 AM
> To: websec
> Subject: [websec] Use of DNS/DNSSEC for strict security

> Has anyone (else) been considering the possible use of the DNS to signal a strict security requirement?

Yes.  We've (Jeff and I) done a lot of thinking on this topic.   I think the biggest discussion is around whether we need a global security policy framework and STS can be advertised there, or whether we should just put up an STS DNS indicator now and figure out the larger policy question later.

Some of our thinking is based on:

"Web Sites Should Not Need to Rely On Users"
http://www.eecs.harvard.edu/~stuart/papers/w3c06.pdf

and associated draft spec - http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/att-0332/http-ssr.txt

Given the timeframe of getting HSTS deployed in web browsers (FF and Chrome live, rumors of others being interested) I think we have some time to figure out all of the policies we'd like to convey during a bootstrapping process, and create a policy framework/language for it, and not just tackle STS as a one-off.

We didn't get into a real strong taxonomy in our paper - http://w2spconf.com/2010/papers/p11.pdf - but there are some policies that you'd like to securely bootstrap over something like DNS(SEC) and others than can be delivered inline or via the same protocol (crossdomain.xml).

Dan Kaminsky had a rough sketch of including STS indicators that he presented at BH this year.  We haven't ourselves taken that forward in any way yet.

- Andy

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 12 Oct 2010 13:11:28 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Yngve N. Pettersen
> Sent: Tuesday, October 12, 2010 12:04 PM
> To: websec; Phillip Hallam-Baker
> Subject: Re: [websec] Use of DNS/DNSSEC for strict security
> 
> 

Yep. This was pointed out pretty clearly by Dan in his BH talk.  His solution was to tunnel DNSSEC lookups over HTTP(S) since we know middleboxes will pass that traffic. 

Seems insane on the surface, but might be the only deployable solution in our lifetimes :) 

- Andy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Oct 2010 16:46:24 -0400

An API is definitely required.

Based on my experience of how changes turn out to be necessary in the light
of PKI deployment, I do not want to be dependent on host processing. That is
the deployment error that sank SET.

I much prefer a model in which DNSSEC processing is performed at a recursive
resolver that the host has established a trust relationship with.

The attack model that is being considered in DNSSEC is the one where a
malicious party modifies a DNS record. I am rather more concerned about the
attack where the malicious party registered the DNS record. Just because
someone has registered a domain does not mean I want my machine to connect
to theirs.

The idea of taking DNS service from an untrusted middlebox was always bogus.
It might well be necessary to use some form of tunneling to route round
malicious middleboxen as Dan described to get to a resolver we can trust.
But I don't want to connect to the unedited DNS either.

If APWG has a domain identified as a phishing site, chances are that I want
to have that domain blocked rather than resolve.

On Tue, Oct 12, 2010 at 3:11 PM, Steingruebl, Andy <
[email-masked]> wrote:

> Yep. This was pointed out pretty clearly by Dan in his BH talk.  His
> solution was to tunnel DNSSEC lookups over HTTP(S) since we know middleboxes
> will pass that traffic.
>

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Wed, 13 Oct 2010 14:44:57 -0600

> From: Phillip Hallam-Baker [mailto:[email-masked]] 
> Sent: Tuesday, October 12, 2010 1:46 PM

> An API is definitely required. 

While I don't disagree that there may be room to have common API usage for this, and have it potentially provided for by the OS/Platform rather than application, a lot of the current OS/Platform APIs don't easily allow the passing or this type of data.  This potentially requires substantial rework and timelag to get deployment.  And, just as certain services come with specific platforms, not all applications choose the use the OS versions and provide their own.  For example, Firefox always uses NSS even on platforms such as Windows that provide their own versions.

> Based on my experience of how changes turn out to be necessary in the light of PKI deployment, I do not want to be dependent on 
> host processing. That is the deployment error that sank SET.

In the case we're discussing, we're definitely going to be dependent on host processing, unless I misunderstand what you mean.  The current DNSSEC last-hop problem is real, and must be solved for successful deployment of any of the technologies being contemplated.

> I much prefer a model in which DNSSEC processing is performed at a recursive resolver that the host has established a trust relationship with. 

OK, but as Kaminsky has demonstrated repeatedly this won't work over the DNS protocol itself today, because of both malicious and clueless middleboxes.

> The attack model that is being considered in DNSSEC is the one where a malicious party modifies a DNS record. I am rather more concerned about 
> the attack where the malicious party registered the DNS record. Just because someone has registered a domain does not mean I want my machine
>  to connect to theirs.

DNS response filtering is entirely unrelated to anything we're discussing here, and I'd rather not muddy these waters with it.  Deal with rogue hosts in another context please, they are an entirely orthogonal problem.

> The idea of taking DNS service from an untrusted middlebox was always bogus. It might well be necessary to use some form of tunneling
> to route round malicious middleboxen as Dan described to get to a resolver we can trust. But I don't want to connect to the unedited DNS either.

The problem isn't just malicious middleboxes, it is broken ones.  There are a lot of devices currently deployed that make pure E2E DNSSEC impossible today.  

Now that I've written all of this though, I think this forum is more about what problems we're solving, what policies need to exist and when (when in a connection lifecycle/timeline) and then lastly we can worry about the deployment concerns related to DNSSEC, etc.   We can chase our tail for a long time here on how to get DNSSEC values reliably to end-nodes, but I'd rather not solve that problem in this forum, nor deal with other things like rogue hosts, hosting providers, etc.  Those are entirely separate issues.

- Andy

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 24 Oct 2010 18:08:18 +0100

Having read all the comments, this looks worth investigating further.
And to agree with Andy, we should probably start with thinking about
what problem we're solving and work from there to DNSSEC for strict
security and then deployment questions.

Would anyone volunteer to maybe describe/write-up the underlying
requirement for DNSSEC for strict security?
We could then add this to the overall websec requirements doc or at
least use it to guide the discussion?

Many greetings, Tobias

On 10/13/2010 09:44 PM, Steingruebl, Andy wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 24 Oct 2010 12:25:16 -0700

>requirement for DNSSEC for strict security?

Is there an agreed-to definition for "strict security"? So far, there has been:

a) A statement that the responder for a particular application always has TLS/DTLS available

b) (a) plus "with this particular crypto"

c) (a) and maybe (b) plus "with this particular public key"

d) (a) and maybe (b) plus "with a cert that chains to this particular trust anchor"

e) A statement that the responder for a particular application always *requires* the use of TLS/DTLS (plus maybe some of the rest of above)

f) A statement that a particular host always uses IPsec transport mode

g) (f) plus "with this particular crypto" (and possibly the public key or the trust anchor)

Even though I'm an IPsec kind of guy, I would rather that (f) and (g) not be what we discuss here.

And, yes, I would be willing to do a presentation in Beijing on the result of this thread.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Sun, 24 Oct 2010 22:49:17 +0200

> g) (f) plus "with this particular crypto" (and possibly the public key or the trust anchor)

I think that (a) is sort of take-it-or-leave-it, so it's not "strict", even if you add (b) through (d).

(f) and (g) are not what we're discussing here. I think everybody's been talking about (e).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Oct 2010 08:11:41 -0400

I can do that.

I discussed this issue with Tim Polk, the Security AD and he was thinking
mostly in terms of 'experimental' as a first step here. Which is exactly
what I would be asking for in his position.

The DNS is unquestionably the right infrastructure to use to deploy security
policy. But it is a difficult system to change and anyone who relies on use
of DNSSEC is building on research.

On Sun, Oct 24, 2010 at 1:08 PM, Tobias Gondrom
<[email-masked]>wrote:

> > While I don't disagree that there may be room to have common API usage
> for this, and have it potentially provided for by the OS/Platform rather
> than application, a lot of the current OS/Platform APIs don't easily allow
> the passing or this type of data.  This potentially requires substantial
> rework and timelag to get deployment.  And, just as certain services come
> with specific platforms, not all applications choose the use the OS versions
> and provide their own.  For example, Firefox always uses NSS even on
> platforms such as Windows that provide their own versions.
> >
> >> Based on my experience of how changes turn out to be necessary in the
> light of PKI deployment, I do not want to be dependent on
> > In the case we're discussing, we're definitely going to be dependent on
> host processing, unless I misunderstand what you mean.  The current DNSSEC
> last-hop problem is real, and must be solved for successful deployment of
> any of the technologies being contemplated.
> >
> >> I much prefer a model in which DNSSEC processing is performed at a
> recursive resolver that the host has established a trust relationship with.
> > OK, but as Kaminsky has demonstrated repeatedly this won't work over the
> DNS protocol itself today, because of both malicious and clueless
> middleboxes.
> >
> malicious party modifies a DNS record. I am rather more concerned about
> >> the attack where the malicious party registered the DNS record. Just
> because someone has registered a domain does not mean I want my machine
> >>  to connect to theirs.
> > DNS response filtering is entirely unrelated to anything we're discussing
> here, and I'd rather not muddy these waters with it.  Deal with rogue hosts
> in another context please, they are an entirely orthogonal problem.
> >
> >> The idea of taking DNS service from an untrusted middlebox was always
> bogus. It might well be necessary to use some form of tunneling
> >> to route round malicious middleboxen as Dan described to get to a
> resolver we can trust. But I don't want to connect to the unedited DNS
> either.
> > The problem isn't just malicious middleboxes, it is broken ones.  There
> are a lot of devices currently deployed that make pure E2E DNSSEC impossible
> today.
> >
> > Now that I've written all of this though, I think this forum is more
> about what problems we're solving, what policies need to exist and when
> (when in a connection lifecycle/timeline) and then lastly we can worry about
> the deployment concerns related to DNSSEC, etc.   We can chase our tail for
> a long time here on how to get DNSSEC values reliably to end-nodes, but I'd
> rather not solve that problem in this forum, nor deal with other things like
> rogue hosts, hosting providers, etc.  Those are entirely separate issues.
> >
> > - Andy

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Oct 2010 07:35:44 -0700

>(f) and (g) are not what we're discussing here. I think everybody's been talking about (e).

So far, only Yoav and Phill have chimed in. Doesn't anyone else on the list have an opinion on what "strict security" means? I'm fine if not (it will make the presentation much shorter), but am surprised given what I heard over the past few years.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Oct 2010 11:44:58 -0400

I see a hierarchy of potential security policy statements as follows:

1) example.com always offers TLS
2) example.com always offers TLS with minimum trust criteria
3) example.com always offers TLS with minimum trust criteria from a specific
provider.

Given that most Internet traffic is not encrypted at all, my first priority
is to allow a site to prevent a downgrade attack and state that they either
always offer or require the use of TLS .

This is also the simplest form of security policy to specify. TLS has
protocol protections against downgrade attacks once the TLS protocol is
initiated but cannot protect against a downgrade attack on use of TLS
itself.

Levels (2) and (3) are important but more challenging. There is more than
one way to achieve this level of policy.

The feedback I have got from the ADs over several years is that they want to
be convinced that any proposal will come to a successful conclusion.

So I am willing to do (1) in advance of (2) and (3), but don't want to adopt
any mechanism that forecloses the possibility of going beyond (1).

A second aspect of policy is that it allows a site to state that its
security requirements either suggest or require the use of a separate
browser that is designed for security sensitive applications. I particularly
like the work that Diane Smetters and others did at Xerox on this approach.

The problem I have seen with trying to get strong security into regular
browsers is that most users are only performing security sensitive tasks 2%
of the time. The usability designers are optimizing the security experience
for the other 98% of interactions. As a result every proposal to provide a
strong security signal gets watered down by the usability people.

My view of what a strong security signal would be is to freeze the entire UI
of the machine for about three seconds on startup and display an
interstatial page showing the user that they have entered the security mode
and are now communicating securely with Paypal or Fidelity or whoever. After
that point there would be a distinctive UI look and feel and a constant
reminder that they are on the secure site.

This is not something that end users could or should expect for their
regular diet of facebook browsing, slashdot and porn. But it is a mode of
use that has real value when security is essential.

On Tue, Oct 26, 2010 at 10:35 AM, Paul Hoffman <[email-masked]>wrote:

> >> e) A statement that the responder for a particular application always
> *requires* the use of TLS/DTLS (plus maybe some of the rest of above)
> >>
> So far, only Yoav and Phill have chimed in. Doesn't anyone else on the list
> have an opinion on what "strict security" means? I'm fine if not (it will
> make the presentation much shorter), but am surprised given what I heard
> over the past few years.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 26 Oct 2010 10:51:29 -0600

> Behalf Of Paul Hoffman

I vote for (e).  This is what HSTS currently does, and I think really what we're discussing.  STS generically is just about requiring TLS, I think other mechanisms should be used for conveying any other policy statements such as how keys are verified, etc. 

- Andy

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 27 Oct 2010 18:39:45 +0100

Definitely agree with (e).

And maybe to go into this further:
What of the options b,c,d, do we really need for that:
b) plus "with this particular crypto"
c) and maybe (b) plus "with this particular public key"
d) and maybe (b) plus "with a cert that chains to this particular trust
anchor"

Would we need finer granularity?
I think we definitely should include b to forbid outdated crypto and
avoid attacks trying to sneak outdated crypto in.
About (c) am not so sure whether we really need that granularity, but
(d) would be good to offer the trust of the specific anchor.

Other opinions?

Tobias

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Wed, 27 Oct 2010 11:42:46 -0600

> Behalf Of Tobias Gondrom
> Sent: Wednesday, October 27, 2010 10:40 AM
> To: [email-masked]
> d) and maybe (b) plus "with a cert that chains to this particular trust anchor"
> 
> I think we definitely should include b to forbid outdated crypto and avoid
> attacks trying to sneak outdated crypto in.

It seems to me that the decision to use TLS, and then other specifications of how to verify endpoints and establish that secure channel, aren't directly in scope.  Doesn't TLS already handle proper negotiation of all crypto properties?  What attack are you trying to protect against that TLS itself in normal operating modes doesn't protect against?  

- Andy

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Oct 2010 12:04:07 -0700

>(d) would be good to offer the trust of the specific anchor.

If we can come to agreement on (b), we will have done better than any other IETF WG in the past. DKIM spent years on it and then gave up.

(c) and (d) are the likely topics of the possibly-soon-to-be KIDNS WG.

--Paul Hoffman, Director
--VPN Consortium

---

From: Marsh Ray <[email-masked]>
Date: Wed, 27 Oct 2010 15:16:45 -0500

On 10/27/2010 12:42 PM, Steingruebl, Andy wrote:
>
> It seems to me that the decision to use TLS, and then other
> specifications of how to verify endpoints and establish that secure
> channel, aren't directly in scope.  Doesn't TLS already handle
> proper negotiation of all crypto properties?

Yes, that's the theory but <em>only as long as the server's cert is
properly validated and its private key has not been compromised</em>.

Specifying requirements for, say, the symmetric cipher in DNSSEC records
would be redundant, that's already configurable (with some complexity)
in the client and server applications.

There are two main things protecting the security of the handshake. The
server's public key and the Finished.verify_data hash.

The algorithm for Finished.verify_data is critical for securing the
entire handshake. It is not independently negotiated in the handshake,
instead it is specified by the particular TLS version in use. If a
problem were to be found in the algorithm for TLS 1.0 (MD5+SHA-1), it
would likely require a new protocol version number. Therefore, it seems
like the minimum acceptable TLS protocol version number would be an
important thing to secure in the DNSSEC records.

The Finished.verify_data hash also depends critically on the
connection's master secret, which is derived from the premaster secret,
which is usually generated by the client and encrypted to the server's
public key. So the server's public key is critical, and the whole job of
PKI is to provide trust in it.

x509 certificates are the standard public key container and are more or
less required by the definition of the TLS protocol, but this does not
preclude the possibility of publishing a public key directly in DNSSEC.
Apparently there are even some circumstances where multiple certs will
use the same public/private key pair.
I think the relevant spec refs are:
http://tools.ietf.org/html/rfc5280#section-4.2.1.1
http://tools.ietf.org/html/rfc5280#section-4.2.1.2

In the case (D) of using DNSSEC to specify a particular trust anchor, 
this would identify a particular cert, right?

Wouldn't this cert clearly define the requirements for its own 
signatures? (hash algorithm, asymmetric key length, etc)

 > *requires* the use of TLS/DTLS (plus maybe some of the rest of

The term 'available' sounds a little weak to me. Isn't the point of this
to state its usage is 'required'?

If DNSSEC says to use TLS, when would you ever want the client to fall 
back to non-TLS?

> b) (a) plus "with this particular crypto"

I think we can define "particular crypto" with just "minimum
TLS version number". A big part of TLS is stating all those other 
particulars securely. The rest of the parameters should be covered by
C and D.

> c) (a) and maybe (b) plus "with this particular public key"

It would be nice to be able to generate a simple self-signed (or
unsigned) x509 cert and fix the public key securely in DNSSEC.

> d) (a) and maybe (b) plus "with a cert that chains to this particular

This would be nice too.

Perhaps you wouldn't want to require such a "trust anchor" to be a
self-signed "root-like" cert, it could be useful for an organization to
sign all their servers with a cert that is also an intermediate (WRT
some private organizational root cert).

This could also take the form of a bare public key.

Also, how about:

h) "Server will never request a client cert over the null connection 
state". Perhaps this could prevent attacks where an attacker forces the 
client to transmit his client cert in the clear and possibly even sign 
with it before the client can fully authenticate the server.

- Marsh

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 Oct 2010 10:20:45 +1100

I've been considering it for a slightly different purpose; serving the key for signing HTTP responses.

After talking to a lot of people about this, it seems like it's much simpler just to host the key (and by extension, other policy information for the transport) on SSL. 

It's a bit of a pity, but there you go...

Cheers,

On 13/10/2010, at 5:21 AM, Phillip Hallam-Baker wrote:

> While I like the idea of strict security, signaling by means of HTTP headers creates a circular dependency. I can only guarantee strict security after first achieving a secure connection. And anything that is done for HTTP becomes a one-off that cannot be applied to SMTP and other protocols.
> 
> I am not arguing against doing the HTTP header approach. Given the attacks we are facing I do not want strict security to be dependent on successful DNSSEC deployment. But I would like to see a HTTP header approach that is consistent with eventual deployment of a DNSSEC based approach.
> 
> 
> -- 

--
Mark Nottingham   http://www.mnot.net/