Subject: [keyassure] Thanks for starting this - my wishlist :)

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Aug 2010 12:30:00 -0400 (EDT)

Hi,

First of all, thanks for starting this list. I have been talking to various 
people to do precisely this....

As I see it, we have a few problems to resolve.

1) Key packaging (eg using raw keys or using certificates or using usage bits)
2) Try to make a new DNS record that can be used by more then just one
    application (eg not SSHFP) to avoid spamming the apex.
3) Try to make the new DNS record specific enough that we can request specific
    ones (eg I need the key for TLS over SMTP, not the ipsec or ssh key)
4) Think about EDNS (secure?) signaling to reduce latency when asking for
    something that will contain an additional trust type record
5) Think about EDNS signaling to request "anonymity". This could be used by a
    browser to request a a local DNS server to not resolve itself, but to use a
    proxy/SOCKS/forwarding servce (eg tor) to aggregate or disguse DNS requests.
6) Think about application requests, eg "I only want the A record when it was
    DNSSEC validated"
7?) think about reducing the size of any new record as much as possible

One link that was missing from the summary send to the list before was the 
original KEY record. It did try to distinguish between applications/protocols
(just only DNSSEC was assigned)

ftp://ftp.rfc-editor.org/in-notes/rfc2535.txt

For instance, see section 3.1.3 The Protocol Octet that talks about application 
usage.  The RFC that then obsoleted application use is:

ftp://ftp.rfc-editor.org/in-notes/rfc3445.txt

I personally think that if we use the trust model of DNSSEC, we should
not have any CA's. However, we probably do need to have "usage bits",
which also exist within the X.509/ASN.1 space, so perhaps it is prudent
to re-use some of that?

I think the biggest immediate win, will be to get HTTPS raw keys in
DNSSEC, supported in a browser like firefox, reducing the 80% of warnings
from self-signed SSL certs that are out there right now.

A next logical step might be to see if we could use the DNS to see if we
should start out with HTTPS (and not HTTP) when connecting to site. Eg
the pressense of a bit or a flag that gives a preference on how to be
contacted. (eg HTTPS preferred pver HTTP, or HTTPS only)

Last, there *might* be a need to say "return even mangled stuff",
which could potentially be used when you're trying to get through a
hotspot/payportal location, where you send a DNS probe for the sole
reason of getting it mangled for portal access.

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Aug 2010 09:58:20 -0700

On Aug 18, 2010, at 9:30 AM, Paul Wouters wrote:

> 
> Hi,
> 
> First of all, thanks for starting this list. I have been talking to various people to do precisely this....
> 

Or hashes of keys.  This would be my vote, as a hash allows

a)  Efficient recording of data
b)  Sufficient information to validate the actual received data is legit in the existing protocol key exchange.

>   ones (eg I need the key for TLS over SMTP, not the ipsec or ssh key)

Hmm, this would require some sort of subdomain scheme then, eg
KEYMATERIAL ssl.www.mydomain.com -> RR for SSL key
KEYMATERIAL ssh.www.mydomain.com -> RR for ssh key

Does that really make things better vs
KEYMATERIAL www.mydomain.com -> {ssl-fingerprint: X, ssh-fingerprint: Y}??

Especially since if its hashes/fingerprints, the data is small (~256b/entry)

> 6) Think about application requests, eg "I only want the A record when it was

You example of this is worse than useless.  Any application smart enough to ask that question should be smart enough to not need to trust the answer.

Application requests for validation are essential, but the records being validated are key fingerprints or other material where it is the material itself that needs to be authentic, thus keystore records, TXT records, etc will be the ones validated.

This is also why I believe this group is essential if DNSSEC is to do ANY good what-so-ever.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Aug 2010 13:13:31 -0400

> You example of this is worse than useless.  Any application smart enough to ask that question should be smart enough to not need to trust the answer.

That's insane.  What you're suggesting is that every application needs
to have its own full, DNSSEC-aware validator inside it.  The answer to
"the whole world has access to ring 0 on this operating system" is not
to write a mini OS inside every application.  It's to make the OS
secure enough so that applications running inside it can trust
facilities offered by the OS.

If we need every application that wants DNSSEC benefits to have to
understand DNS and DNSSEC, we will never get anywhere.  The platform
needs to provide simple, easy access to sec_getaddrinfo() or whatever.
Otherwise, application builders simply won't use that facility.  They
have enough work to do.  Our job down in the DNS layer is not to make
it impossible for higher-layer applications to use our facilities;
it's to make the facilities easy and natural, so that the best things
we can do are automatically available to application developers.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Aug 2010 13:25:06 -0400 (EDT)

> Or hashes of keys.  This would be my vote, as a hash allows

Yes, hashes is what i meant with "raw key", sorry.

> KEYMATERIAL ssh.www.mydomain.com -> RR for ssh key

We could have sub typing instead. That would avoid ugly name space collison, eg if
I have a server named ssl.mydomain.com.

> KEYMATERIAL www.mydomain.com -> {ssl-fingerprint: X, ssh-fingerprint: Y}??

that could get big with 10 different apps on a server?

> You example of this is worse than useless.  Any application smart enough to ask that question should be smart enough to not need to trust the answer.

The example was bad because it is actually covered by the AD bit, yes.
Let's say "I only want the A record when you can get data through an anonymizer" 
We currently can only ask for "passed validation", which is limiting.

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Aug 2010 10:34:08 -0700

NOTHING I said implied that the application does the validating, just that the application uses an API that does/indicates the need to do the validating: the application NEEDS to tell the host to validate and how to treat validation failures (because the default will be wrong, no matter what the default is, unless the default is to say 'sod DNSSEC'), and the validation does need to be done on the end host (see previous rants on what should be done with existing APIs and DNSSEC...).  

And that using such an API for validating A records is useless, since any application thats smart enough to bother asking "is this A record validated" is smart enough to realize that the A record validation is meaningless [1]: a corrupted A record is just simply one of many possible MitM attacks, so focus on blocking MitM attacks, not A records: from an application viewpoint, there is no difference between a poisoned DNS entry, a poisoned ARP cache, BGP games, or a WiFi packet injector: a MitM is a MitM.

And, frankly speaking, the "benefits" from DNSSEC only come when the application is aware of DNSSEC: the benefits actually lie in the domain of this group: developing ways of using DNSSEC to validate key material or other data directly.

[1] Assuming that the resolver has suitable protections against out of path adversaries, of course, or that the host contains its own recursive resolver.

On Aug 18, 2010, at 10:13 AM, Andrew Sullivan wrote:

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Aug 2010 13:52:05 -0400 (EDT)

> And that using such an API for validating A records is useless, since any application thats smart enough to bother asking "is this A record validated" is smart enough to realize that the A record v…

Not all DNS entries are meant for A records. What if I have an OTR fingerprint record,
that I use further down whatever IM network I have access to (jabber, MSN, whatever)

> And, frankly speaking, the "benefits" from DNSSEC only come when the application is aware of DNSSEC: the benefits actually lie in the domain of this group: developing ways of using DNSSEC to valida…

Yes, I was saying just the AD bit might not be enough, because we don't want applications to need to
do a lot of DNS(SEC) work on the error condition.

> [1] Assuming that the resolver has suitable protections against out of path adversaries, of course, or that the host contains its own recursive resolver.

My assumption is always the end node is running its own resolver. You can't really trust anything
else. So local validation+cache using a DHCP supplied forwarder when possible (using something like
unbound that has protection against DNSSEC stripping)

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Aug 2010 14:06:28 -0400

On Wed, Aug 18, 2010 at 10:34:08AM -0700, Nicholas Weaver wrote:

> NOTHING I said implied that the application does the validating,

Well, there were two ways I found to interpret your argument, and the
other one seemed to me to be the well-worn arguments about why
offloading to an upstream validator was a Bad Idea.  I didn't figure
you'd be hauling that argument to this list from another one, but I
guess I was wrong.  In the enterprise situation, we _have_ an
implementer who is using the AD bit and IPSEC for the last hop.  You
keep insisting that's a dangerous model, but in the enterprise
environment it isn't necessarily (and arguing from home-user-to-ISP
analogies is simply irrelevant).

The trouble in the case of the AD bit is that it's too little
information.  But we don't get to dismiss that use case just because
we're currently not sure how to answer the query.  And we might have
an opportunity here to address such issues (I kinda doubt it, but
maybe).

> to do the validating: the application NEEDS to tell the host to
> validate and how to treat validation failures (because the default
> will be wrong, no matter what the default is, unless the default is

I think this is right.  It sounds to me like an API issue.  The
present one is likely the wrong list for that, though.  I wish I knew
what to suggest apart from dnssec-deployment.

> And that using such an API for validating A records is useless,
> since any application thats smart enough to bother asking "is this A
> record validated" is smart enough to realize that the A record
> validation is meaningless [1]: a corrupted A record is just simply
> one of many possible MitM attacks, so focus on blocking MitM
> attacks, not A records: from an application viewpoint, there is no
> difference between a poisoned DNS entry, a poisoned ARP cache, BGP
> games, or a WiFi packet injector: a MitM is a MitM.

So your argument is that if the DNSSEC validation comes back correct,
we still aren't sure routing hasn't been compromised, so this is all
useless?  Surely that's wrong.  Another way to do this would be to
offload the validation to a trusted DNS server and offload similar
validation for BGP &c. to something else, no?  I don't really want my
phone doing hundreds of DNSSEC validation calculations for every
cnn.com page view, do I?

> And, frankly speaking, the "benefits" from DNSSEC only come when the
> application is aware of DNSSEC

I happen to think it is an advantage if I push validation to some
layer (or system) I don't have to worry too much about, and then
simply get a failure when someone is spoofing the DNS answer.  I
cheerfully concede it's not a complete solution to every possible
problem; but if I were interested in solving world peace and hunger,
I'd be a diplomat or a missionary rather than a geek.  You appear to
be arguing that because DNSSEC validation successes do not prevent
attacks on the routing infrastructur, therefore DNSSEC validation does
no good.  That strikes me as a hard position to maintain.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Anthony Iliopoulos <[email-masked]>
Date: Wed, 18 Aug 2010 13:24:01 -0500

> On Wed, Aug 18, 2010 at 10:34:08AM -0700, Nicholas Weaver wrote:

[...]

> what to suggest apart from dnssec-deployment.

What ever happened to draft-hayatnagarkar-dnsext-validator-api btw ? 
Perhaps this is now relevant enough to resurrect ?

Regards,
Anthony

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Aug 2010 11:37:11 -0700

> phone doing hundreds of DNSSEC validation calculations for every

You're missing the point:  Against a man in the middle, it doesn't matter HOW they became a MitM, what matters is using end-to-end cryptography in the application/transport to prevent the MitM from doing any damage.

You don't try to block packet-injection based DNS forging, BGP forging, ARP poisoning, DHCP poisoning, WiFi packet injection, and the whole rest of the laundry list.  Its huge, and some can't be prevented without changing the layer 1/2 network completely.

Instead, you build the system to resist a MitM and don't worry how the attacker became a MitM.

And this is why I don't consider DNSSEC to secure DNS A records against a MitM productive, or validating on the not-the-end-host resolver: it only matters when the DNS MitM wouldn't be on the final application path MitM, which IS pretty much just the not-the-end-host resolver.

> no good.  That strikes me as a hard position to maintain.

Except that this system, if not on the final end host IS both the adversary, and 99.9% (being charitable here, probably 100%) of the 'spoofing' detected by this system will not be spoofing, but someone messing up the key handling.

EG, how many times is it WRONG to say "sure, I'll accept the self signed cert" in web browsing?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Aug 2010 15:02:26 -0400

I don't think either works.

We should be encouraging people to use a separate private key for each
physical host. So we certainly should not be creating specs that make
it hard to do that.

In the case of SSL the relying application has the certificate in hand
at the start of the validation process. It is thus possible to put an
attribute in the cert to say 'hey I have a DNS key chain' and to give
a prefix that can be used for distinguishing between certs.

There are two separate issues here

1) Validating keys
2) Determining what the security criteria are for a given app.

I would prefer to use the CERTHASH record I proposed in the other post
to do the first and separate out the second into a per-protocol
security options record that gives security related info. For example

_smtp._tcp.example.com OPTION "SSL=OFFERED KEYSERVER=LDAP,XKMS"
_submit._tcp.example.com OPTION "SSL=REQUIRED AUTH=REQUIRED"
_http._tcp.example.com OPTION "SSL=ALWAYS SRV=TRUE AUTH=YAFAP"

I see the elements in an OPTION record as being protocol specific.
There would have to be a draft written for each protocol to say what
the interpretation of the code points would be for that particular
protocol.

For some limited protocols, possibly only SSH and like protocols that
typically bind to specific hosts rather than abstract services, it
might even make sense to put the raw SSH key into an OPTION record.
But I see that as a special case, rather than the norm.

Note that for SMTP I specify two methods of obtaining user certs for
sending an encrypted message. This is where I see user keys coming
from. In my view user keys do not belong in the DNS because the DNS is
an infrastructure for locating network services, not network users. It
is of course the infrastructure that we use to locate the
infrastructure for locating users however.

On Wed, Aug 18, 2010 at 1:25 PM, Paul Wouters <[email-masked]> wrote:
>> You example of this is worse than useless.  Any application smart enough
>> to ask that question should be smart enough to not need to trust the answer.
>
> Let's say "I only want the A record when you can get data through an
> anonymizer" We currently can only ask for "passed validation", which is
> limiting.
>
> Paul

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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Aug 2010 15:06:40 -0400

> EG, how many times is it WRONG to say "sure, I'll accept the self signed cert" in web browsing?

If you don't think that's a problem, then why do this work?  (That is,
dope that I am, I don't even understand why you think this debate is
worth joining if you think the whole thing a non-problem.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Aug 2010 12:07:34 -0700

> physical host. So we certainly should not be creating specs that make

I'm not so sure about this.  So much of the Internet relies on LOGICAL host, being defined by hostname rather than IP, that separate key for logical host is what is done today, so it actually does fit well with DNSSEC.

Otherwise, if you want to store material on a physical host (approx by IP), you need to first get the logical host list and then do a reverse DNS lookup on the IP to get the key material.

But I can see that being worth supporting too: so you do a query for both

keymaterial for hostname
keymaterial for IP

and use the union of those two sets as the key material for the host you are commuinacting with.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Aug 2010 15:08:49 -0400

I agree with what Andrew is saying here. But this is a discussion that
is in-charter for DNSEXT.

Basically I am seeing people looking at DNSCURVE for last hop and
there are certainly many people doing IPSEC. As a security specialist,
I know that there are security capabilities I can provide in that
model that are not possible through endpoint security alone.

My view is that where the validation takes place is for applications
and users to decide. It may even make sense to have no validation at
all. I have argued for years that Web Browsers should not provide a
warning when a site offers a self-signed cert, the browser should
simply turn on the crypto and not tell the user about it at all. If
the web browser will take the user to a site without any crypto
without a warning it should accept imperfect crypto on the same basis.

In the medium term, neither IPSEC or DNSCURVE (or SSL) are ideal for
this purpose. We can do better, but I won't elaborate the reasons why
here.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Aug 2010 12:20:41 -0700

> worth joining if you think the whole thing a non-problem.)

My attitude towards DNSSEC is exactly why I think THIS group is valuable.  

DNSSEC for DNSSEC's sake is already happening thanks to various mandates, even if, for securing Name->Address mappings, it is a combined world of hurt and useless.  

But if this world is going to exist, I believe we should extract something very VERY useful out of that, which is using DNSSEC for Name->Key material mappings (or other data that is consumed directly by the client rather than simply being used to contact a remote host.)

Since I think DNSSEC is incredibly valuable for securing Name->Key Material mappings: providing, for nearly-free, certificates which flow along already existing trust relationships, and without the proliferating root of trust problems existing in SSL, the price gouging which exists in SSL for wildcard certs, or the leap-of-faith problems present in ssh, I think its very important to make sure that we actually have a good way of doing this.

Since this group is about developing ways to make sure that Name->Key Material bindings can happen and are useful, this group is exactly where I believe the emphasis should be.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Aug 2010 15:38:45 -0400 (EDT)

On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote:

> In my view user keys do not belong in the DNS because the DNS is
> an infrastructure for locating network services, not network users.

I disagree. You are locating an identity. Currently, that is mostly done
based on an IP address and port. I'd hope tomorrow that would mostly be
done based on a public key or hash. Especially with mobile devices, IP's
are very volatile. To locate a service or user, we need the DNS.

Paul