Subject: transaction security in the last mile

From: Paul Vixie <[email-masked]>
Date: Fri, 18 Jul 2008 16:15:28 +0000

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

whereas XQID or anything like it would either rely on EDNS and would have
to fall back to less security if an attacker could spoof a non-EDNS reply,
or would bypass EDNS and do its own feature negotiation where the fallback
would be something like "repeat the whole transaction several times using
newly randomized QID and UDP.PORT (and maybe QNAME 0x20) each time", and

whereas TSIG relies on a pre-shared secret key involving out of band key
exchange (such as "sneaker-net") which is expected to scale badly in large
installations and be useless in ISP or ASP situations, and

whereas GSS-TSIG relies on a working GSS (think kerberos 5) installation
that encompasses both RDNS and its client stubs, which is known to be rare
in the world and never present in ISP or ASP situations, and

whereas SIG(0) (or is it RRSIG(0) now?) relies on a working Secure DNS
system containing a TKEY RR at the RDNS's hostname, which has proven
elusive due to the extreme duration of Secure DNS's development and the
lack of general interest among anybody other than technology vendors and a
few CCTLDs, and

whereas BCP38 deployment has utterly stalled in recent years and is likely
to never be complete enough to make IP source addresses generally repudiable
and even if we somehow did reach universal BCP38 deployment the sense of
security this would give us would be false since backsliding could happen
at any instant and would be mostly transparent at first, and

whereas we have now randomized everything we can (QID, UDP port, QNAME 0x20)
and this gives us only stant statistical protection against DNS forgeries
involving injection of packets having spoofed IP source addresses, yet we
have no cause for confidence in our continued safety in a world full of
smart ambitious security researchers (some good, many evil) whose computers
and networks get faster every year, ...

..

.. i think it's time for a new debate on the nature of the relationship
between the stub and the RDNS.  i wish to leave aside the relationship
between the RDNS and ADNS, since these are far more numerous, and the kinds
of negotiations or state that are practical in the stub/RDNS relationship
might be completely impractical in the RDNS/ADNS relationship.  in this
discussion, a "stub" refers to either an initiator with no DNS-layer cache,
or to an RDNS configured to use a "forwarder".  in both cases, the number
of relationships a given initiator is in, or that a given responder is in,
is finite and manageable.

here are some possible roads, and the reasons they're each hard to follow.

1. always use tcp.  with random initial sequence numbers now the standard,
we generally consider tcp sessions unspoofable unless the ISO-L2 is
insecure near either endpoint, or unless the routing layer is attacked.
for many stub/RDNS deployments, the number of stubs simultaneously doing
DNS will be lower than the number of tcp protocol control blocks or socket
descriptors available on the RDNS host and application.  however, in many
ISP deployments there can be millions or tens of millions of stubs for
every RDNS, and not even anycasting or load balancing will make that fit,
so we'd be contemplating a very short (subsecond) timeout for idle DNS TCP
sessions, which calls for some modelling to find out what the packet count
and RTT cost would be for the average stub in that environment.  also, stubs
would have to funnel their queries through shared local protocol agents,
and these agents may become a new target for injection attackers.

2. diffie-hellman.  it is possible, with the exchange of several random
numbers used as encryption and decryption keys, for two endpoints with no
shared secret to establish a trust relationship.  this takes measureable
time and effort, so the existence of this trust relationship is usually
remembered by the endpoints, creating "session state" which can be used to
generate nonces or shared keys.  RFC 2930 is an example of such a method,
whereby the TKEY meta-RR is used to carry keying information for the TSIG
meta-RR.  no known large deployment currently uses TKEY to create trust and
then TSIG to protect query transactions, so while this approach may be
practical, its error modes remain unmeasured.  because such relationships
are not held in protocol control blocks and/or socket descriptors, it may
be possible for an RDNS to relate to millions of stubs in this way.
however, the stubs will probably require additional processes or files to
hold the trust state for each RDNS, and this state may become a new target
for injection attackers.  there's also a lurking downgrade attack involving
spoofed ICMP-Port-Unreach, since the D-H and key data won't be in the first
64 octets of the payload, which ICMP uses as a nonce.

3. IPv6 multiplicity.  in IPv6, most LANs will have 64-bit netmasks, leaving
64 bits for host addressing, which are expected to be sparsely allocated.
it is possible that a stub host could allocate a few dozen addresses, and
choose one at random as a source for requests to RDNS.  there is a tension
between having enough source addresses to matter from a security nonce point
of view, vs. having too many to manage in the exit gateways who must maintain
ARP state for each address, mapping back to each stub's MAC address.  it's
unlikely that the number of additional random bits we need can be accomodated
by this layer of the IPv6 architecture, and furthermore, IPv6 isn't here yet.

4. new port.  most of the constraints are due to backward compatibility
problems, and if we simply allocate a new UDP port, other than 53, then we
can make new rules.  it's easy to design a completely stateless replacement
for stub DNS that involves 128-bit random nonces.  while there would be some
delay while IETF debates which part of the kitchen sink to leave in or remove,
it's safe to say that there would be no authority or additional data section,
no RD bit, very few options in general, and that we could avoid having this
turn into a replacement for the current global DNS protocol used for the
RDNS/ADNS relationship.  what's less clear is how the fallback strategy would
be secure, since a "new-stub" would have to fall back to standard UDP/53 if
it could not get an answer on the new UDP port from any of its RDNS's.  could
we put the nonce near the front of the UDP payload so that ICMP-PortUnreach
(which uses the first 64 bytes of the datagram) would be hard enough to forge
that we could confidently assume that there was never a downgrade attack?

i know that's a paltry list.  others here should be able to think of more
alternatives.  i'd like to avoid a re-debate over XQID, though, so if that's
your position i ask that you hold off on elucidating it here to let this topic
be explored on the basis that XQID, TSIG, SIG(0), and BCP38 are nonstarters.
i'd really like to know whether always-tcp, diffie-hellman, ipv6-multiplicity,
or new-port are practical or not, and whether there are other ideas lurking.

of the ideas above, i dislike the new-port idea the least, and that's very
depressing, since from a deployment perspective, SIG(0) would be about the
same total cost.  (the largest part of the cost is touching all or most of
the stubs, not in the specific complexities added by that touch.)

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Alex Bligh <[email-masked]>
Date: Fri, 18 Jul 2008 20:17:35 +0100

--On 18 July 2008 16:15:28 +0000 Paul Vixie <[email-masked]> wrote:

> between the RDNS and ADNS, since these are far more numerous, and the
> kinds of negotiations or state that are practical in the stub/RDNS
> relationship might be completely impractical in the RDNS/ADNS
> relationship.

Question: most of the attack modes these seem to address would also be
avoided by DNSSEC, which wasn't in your "whereas" list. I presume
that is on the basis of an estimate of DNSSEC deployment times exceeding
the deployment time of the changes to stub resolvers to implement 1-4.

If so, and if quick deployment is the necessity, are there not existing
protocols that might help? For instance, 2 (diffie-helman) proposes
key exchange etc. Are there not bits of IPsec we could pull (without
encryption) which would do the job?

Alex

---

From: Florian Weimer <[email-masked]>
Date: Fri, 18 Jul 2008 22:16:27 +0200

... whereas the last mile (on the IP layer) is no longer transparent for
53/UDP packets, which significantly limits further protocol evolution,

> here are some possible roads, and the reasons they're each hard to

First of all, I think it's mostly pointless to protect stub to local ISP
resolver communications.  This only requires local source address
validation, so it's something the ISP can and should implement today.

However, there are at least two applications for a DNS last mile that
does not end at the customer ISP: external DNS services with enhanced
data (new roots etc.), and DNS forwarders which are DNSSEC-transparent
and suitable for end-to-end validation.

There's an incentive for ISPs to stop the first application, by some
sort of DNS proxy.  The port number does not really matter: If it's
well-known. it will be proxied.  Unfortunately, this type of proxy will
not be DNSSEC-transparent, so the second application is affected as
well.

So we need crypto.  And crypto for connection-less services means DTLS.
It could be that DTLS requires too much server-side state (to avoid
running the relatively expensive private RSA operation too often), or
that a really good cipher suite hasn't been specified, but these things
should be fixable.

Diffie-Hellman is probably too expensive for key agreement (and the ECC
variants too encumbered by patents).

(Just a few thoughts -- I'm really interested in this topic because we
need to solve it before we can enable some form of DNSSEC validation on
mobile devices.)

---

From: bert hubert <[email-masked]>
Date: Fri, 18 Jul 2008 22:37:43 +0200

> variants too encumbered by patents).

CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice. 

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Florian Weimer <[email-masked]>
Date: Fri, 18 Jul 2008 22:52:55 +0200

> CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice. 

Could be, indeed.  But my DTLS comment remains valid: you should get it
into DTLS use that protocol.

---

From: David Conrad <[email-masked]>
Date: Fri, 18 Jul 2008 14:16:40 -0700

On Jul 18, 2008, at 9:15 AM, Paul Vixie wrote:
> between the stub and the RDNS.

Long past time, actually.

> 1. always use tcp.
> 2. diffie-hellman.
> 3. IPv6 multiplicity.
> 4. new port.

5. if you feel there could be a risk, run a local (validating) RDNS.

Regards,
-drc

---

From: Joe Abley <[email-masked]>
Date: Fri, 18 Jul 2008 17:33:48 -0400

> installations and be useless in ISP or ASP situations, and

... and synchronised clocks, lack of which is likely to cause an even  
greater support headache than the problem of sharing a TSIG key  
amongst a community of customers...

Joe

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Jul 2008 14:56:30 -0700

> validation, so it's something the ISP can and should implement today.

You may think you're talking to your ISP when you are not...

---

From: David Ulevitch <[email-masked]>
Date: Fri, 18 Jul 2008 15:28:30 -0700

> You may think you're talking to your ISP when you are not...

These days it feels like it's more likely the case that you think you 
ARE NOT talking to your ISP when you in fact really ARE, thanks to their 
new high-speed packet manglers.

Regardless, improving the integrity between the stub resolver and the 
recursor is long overdue regardless of the vector.

-David

---

From: David Conrad <[email-masked]>
Date: Fri, 18 Jul 2008 20:31:06 -0700

Paul,

On Jul 18, 2008, at 8:10 PM, Paul Vixie wrote:
> after august 6 there will always be a risk, 100% of the time, for  
> ever and
> ever or until Secure DNS is fully implemented end to end (which is  
> the same
> thing).

If I have confidence in my firewalls that the bad guys won't be able  
to spew at my stub resolver, I would feel the risk is mitigated.

If I have an IPSEC VPN between me and my caching server, I would feel  
the risk is mitigated and wouldn't worry about the stub resolver IPC.

If I've configured SIG(0), TSIG, GSS-TSIG, etc., I would feel the risk  
is mitigated.

Etc.

In all other cases, I'd run a local validating caching server.

> do we want to say, stub is dead, stop using it, everybody needs to
> run RDNS, including PDAs, IPv6-enabled home appliances, no  
> exceptions, for
> the lifetime of the internet?

Personally, if the device is ever going to be open to the Internet, I  
think this is the right answer.  Smart devices, stupid network.  And  
devices are only going to get smarter.

Regards,
-drc

---

From: Robert Elz <[email-masked]>
Date: Sat, 19 Jul 2008 12:45:13 +0700

If the aim is to solve this for the v4 world, because "and furthermore,
IPv6 isn't here yet", then there cannot be any solution that really works.

v4 is being kept functional (ie: enough address space, the rest of v4
works fine) by more and more addressing hacks, and they are coming to
absolutely require DNS hacks along the way to keep things operational.

That is, DNS packets MUST be "spoofed" these days in order to keep many
parts of the v4 network alive.   I put spoofed in quotes, as this isn't
being done in any kind of harmful way (except to purity), and the only
part of the packet that needs to be altered for this is the RDATA part
of A records.   That is, all the anti-forgery type techniques in the
other draft (and even that foul qname 0x20 hack, in its own draft) are
not a problem at all, as alterations to A RDATA aren't affected by any
of that - but any kind of crypto integrity mechanism will be, those things
are designed to prevent tampering, whereas "tampering" is what is required
to keep v4 hobblingalong.

Much the same consideration makes Paul's #4 even harder than he suspected,
in that these days it isn't really the stub resolver that is really hard
to upgrade (and I don't mean to imply that's any easier than Paul suggested)
but that the stub server (the thing the resolvers talk to, beats me what
current terminology for that is these days) tends to be embedded in off the
shelf ADSL routers and such (along with NAT DHCP, and all kinds of address
hacking weirdness), and getting those things upgraded is even harder.
After all, uSoft can just release a "security patch" and a large fraction of
the end systems will get upgraded within weeks, nothing similar exists for
those other systems, they're commodity, and more or less untouchable.

So, back to the assumption that started this message, "IPv6 isn't here yet".
That's really only true in the sense that the incentive to deploy it
still doesn't really exist, all those hacks that are keeping v4 working
(kind of) are allowing people to defer making v6 really available, with
the undoubted (particularly staff education) costs involved.

Perhaps DNS security could be the issue that actually provides the
impetus to overcome the "no benefit for me that I can see" objections,
as in v6 there's no problem using encryption if that turns out to be
the solution (that's at least available as an option), and the vast
per LAN address space makes other things, like Paul's #3, available
as alternatives.

That is, maybe this is the time to actually stand up and say that we
simply cannot really solve this with v4, and simply give up trying.

kre

---

From: Florian Weimer <[email-masked]>
Date: Sat, 19 Jul 2008 11:03:07 +0200

* Ted Lemon:

>> First of all, I think it's mostly pointless to protect stub to local
>> ISP resolver communications.  This only requires local source address

If you're alluding to malware, that's outside the WG scope.

If the ISP is not able to protect traffic to and from his own address
space (because customers are connected directly to a layer 2 switch
cloud, for instance), this is not really a DNS problem, either.

I think the problem is in the opposite direction (i.e. talking to the
ISP when you don't want to).

---

From: Florian Weimer <[email-masked]>
Date: Sat, 19 Jul 2008 11:05:17 +0200

> 5. if you feel there could be a risk, run a local (validating) RDNS.

Does this really work?  Often, when I'm in a hotel room, I get AA=0 RA=1
answers from all authoritative servers (actually, from almost all IP
addresses).  Somehow I doubt that I can run DNSSEC over this
construction.

End-to-end DNSSEC validation for mobile devices is currently an unsolved
problem.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 19 Jul 2008 05:27:14 +0000

> CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice. 

d-h is very expensive to set up.  it's even a tiny bit worse than tcp.  it
would, as i said at the outset, be important for both stubs and RDNS' to keep
state.  however, since it's application layer state, rather than kernel state,
it's reasonable to consider it for an RDNS serving millions of stubs.  which
bitswizzler is used in the various one-way transforms inside the D-H is just a
detail at this stage of the discussion.

wrt DTLS (http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security or
http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html have background
and http://tools.ietf.org/html/draft-rescorla-dtls-05 has the details), i'm
concerned about two elements of that protocol.  first, it appears that the
handshake can be made to fail using spoofed ICMP-Unreach messages, which may
not be a problem for most protocols, but in our case the fallback is UDP/53
and so this is a downgrade vector.  this is because the first 64 octets of
the IP payload, which means the UDP headers and the start of the UDP payload,
do not include the randomized bits (so, DTLS' nonce is not within ICMP's
nonce).  second, and less troubling, DTLS has message secrecy as a goal,
which is a red herring that will cause huge debates if we try to standardize
on DTLS for stub/RDNS transactions.

i'd like it very much if a DTLS expert could show me how the initial handshake
messages put highly random content into the part of the IP datagram that must
be present in an ICMP-Unreach message.  if not, then the fact that stub/RDNS
will fallback to UDP/53 on DTLS failure means that some other handshake will
have to be designed to carry the D-H exchange.
-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Fri, 18 Jul 2008 20:29:25 +0000

> validation, so it's something the ISP can and should implement today.

not all stubs use their ISP for RDNS, and this is an accelerating trend
as more and more ISP's deploy nxdomain-remapping to turn errors into ads.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 18 Jul 2008 19:28:55 +0000

> avoided by DNSSEC, which wasn't in your "whereas" list. 

yes, it was:

	whereas SIG(0) (or is it RRSIG(0) now?) relies on a working Secure
	DNS system containing a TKEY RR at the RDNS's hostname, which has
	proven elusive due to the extreme duration of Secure DNS's
	development and the lack of general interest among anybody other
	than technology vendors and a few CCTLDs, and

> I presume that is on the basis of an estimate of DNSSEC deployment times
> exceeding the deployment time of the changes to stub resolvers to
> implement 1-4.

unless you believe that the tooth fairy is going to touch her golden wand
to the head of the U. S. Gov't and make them either set ICANN free or give
ICANN permission to sign the root zone, then the deployment of the things
SIG(0) depends on is much longer than just the time it will take to touch
all of the DNS endpoints in the world.  i do not believe in the tooth fairy,
though i'd like it if none of you told that to my youngest children.

> encryption) which would do the job?

i love the D-H approach except for the downgrade attack (ICMP spoofing) due
to the TKEY and TSIG data not being within the first 64 bytes of the payload
(which is what ICMP uses for its nonce).  and if we're going to change the
protocol to put the randomness first, then we wouldn't bother with D-H since
it has some state setup and maint costs.  if we're inventing a new protocol
for the stub/RDNS relationship, we'd invent a stateless one.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 19 Jul 2008 03:10:51 +0000

> 5. if you feel there could be a risk, run a local (validating) RDNS.

after august 6 there will always be a risk, 100% of the time, for ever and
ever or until Secure DNS is fully implemented end to end (which is the same
thing).  do we want to say, stub is dead, stop using it, everybody needs to
run RDNS, including PDAs, IPv6-enabled home appliances, no exceptions, for
the lifetime of the internet?

i was thinking we needed to preserve the stub/RDNS relationship.  maybe not?

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Jul 2008 11:58:42 -0700

At 4:15 PM +0000 7/18/08, Paul Vixie wrote:
>shared secret to establish a trust relationship.

Naked Diffie-Hellman results in the two parties having a channel with 
integrity and privacy, and *no authentication of either party*. If 
the initiator (stub) wants authentication of the responder (RDNS), 
then you need to add some sort of authentication to the naked DH. 
DTLS (and numerous other IETF protocols) does this.

>   this takes measureable
>generate nonces or shared keys.

What you have shifted into describing is an establishment protocol 
for a long-lived, strong mutual key. You don't need Diffie-Hellman to 
do this: there are lots of other protocols as well. Once you have a 
long-lived, strong mutual key, you can either use that to 
integrity-protect the communication stream between the stub and the 
RDNS, or you can use it to integrity-protect the messages from the 
RDNS to the stub (such as with an HMAC). The RDNS needs to remember 
this key for a long time in order to prevent re-establishing the key 
by mutual re-authentication.

>for stub DNS that involves 128-bit random nonces.

Note that this does *not* prevent man-in-the-middle attacks such as 
an intermediate ISP who wants to do their own answering of your 
queries. It only prevents offline spoofing.

If you want to prevent ISP-in-the-middle attacks, you need to add 
strong authentication for the responder to your protocol. If you want 
mutual authentication, you need to design that in.

--Paul Hoffman, Director
--VPN Consortium

---

From: David Conrad <[email-masked]>
Date: Sat, 19 Jul 2008 13:11:45 -0700

On Jul 19, 2008, at 2:05 AM, Florian Weimer wrote:
> Does this really work?

Like everything, it depends on how broken the network you're on is.

> Often, when I'm in a hotel room, I get AA=0 RA=1
> addresses).

Yeah, it is pretty stunning what vendors for hotels (in particular)  
think is acceptable.  And they'll continue to muck things up until  
their customers, the hotels, scream for them to stop.

> Somehow I doubt that I can run DNSSEC over this construction.

Actually, if you try, DNSSEC will likely work exactly as advertised --  
it'll drop answers due to validation failures as clearly somebody is  
mucking with the data in transit.

> End-to-end DNSSEC validation for mobile devices is currently an  
> unsolved problem.

No.  End-to-end DNSSEC validation for mobile devices works fine. End- 
to-end DNSSEC validation in the face of deliberate byzantine screwage  
is an unsolved problem and will likely always be.  You can get around  
this screwage the exact same way you get around folks who (say) block  
all ports except port 80 (also seen at hotels), you figure out what  
does get through and tunnel somewhere that isn't broken.

If you're worried about stuff working in broken hotel walled gardens,  
then the new port approach is a waste of time, as is the forced TCP  
approach (since the same walled gardens will almost certainly block  
TCP port 53) and IPv6 (haven't seen a hotel yet that supports IPv6).   
Maybe DH will work?

Regards,
-drc

---

From: Florian Weimer <[email-masked]>
Date: Sat, 19 Jul 2008 22:21:39 +0200

* Paul Vixie:

> and so this is a downgrade vector.

You don't downgrade.  There's a place from which you get your DNS
resolvers, and that place tells you to use the new protocol.

> second, and less troubling, DTLS has message secrecy as a goal, which
> is a red herring that will cause huge debates if we try to standardize

Hmm.  I fear we may need message secrecy to get clean resolutions (or
any data at all).  However, DTLS also supports the NULL cipher.

BTW, there's a strange footer at the end of your messages, see
<http://article.gmane.org/gmane.ietf.dnsext/11747>.  I don't know if it
is intended.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Jul 2008 13:48:28 -0700

At 1:11 PM -0700 7/19/08, David Conrad wrote:
>End-to-end DNSSEC validation for mobile devices works fine.

Right. "Mobile" is irrelevant for DNSSEC, fortunately.

>End-to-end DNSSEC validation in the face of deliberate byzantine 
>screwage is an unsolved problem and will likely always be.

It *has* to be, by definition. DNSSEC provides integrity. Screwage 
breaks the one security feature of DNSSEC.

If you want your integrity policy to be less than all-or-none, you 
are begging for creative screwage and then changing your policy to 
react to it, and so on.

>You can get around this screwage the exact same way you get around 
>folks who (say) block all ports except port 80 (also seen at 
>hotels), you figure out what does get through and tunnel somewhere 
>that isn't broken.

And then you don't need the integrity protection of DNSSEC, and you 
can turn it off.

>If you're worried about stuff working in broken hotel walled 
>gardens, then the new port approach is a waste of time, as is the 
>forced TCP approach (since the same walled gardens will almost 
>certainly block TCP port 53) and IPv6 (haven't seen a hotel yet that 
>supports IPv6).
>Maybe DH will work?

Until the hotel intercepts it, sure.

--Paul Hoffman, Director
--VPN Consortium

---

From: David Ulevitch <[email-masked]>
Date: Sat, 19 Jul 2008 14:23:21 -0700

> ISP when you don't want to).

That is the correct problem statement.

---

From: David Ulevitch <[email-masked]>
Date: Sat, 19 Jul 2008 16:11:05 -0700

Paul Vixie wrote:
> end users who really just can't tolerate provider-in-the-middle attacks will
> use VPN to reach an RDNS they trust, or will run an RDNS of their own using
> a VPN through some trusted relay point for their RDNS/ADNS traffic.

Agreed.

> i therefore reject that problem statement.

It was in the context if Ted's view of that specific issue.  Perhaps it 
was off-topic for namedroppers.

What is not off-topic, is that people should be able to securely resolve 
names from the provider of their choice regardless of who their pipe 
provider is.

-David

---

From: Paul Vixie <[email-masked]>
Date: Sat, 19 Jul 2008 23:30:10 +0000

> > wrt DTLS ... first, it appears that the handshake can be made to fail
> > using spoofed ICMP-Unreach messages, which may not be a problem for
> > most protocols, but in our case the fallback is UDP/53 and so this is a
> > downgrade vector.
> 

in mail to ben laurie cc'ing this list, which the moderators have not yet
approved, i spake thusly:

	in my deployment scenario, we have hundreds of millions of stubs
	talking to millions of RDNS', and if we require preshared keys we
	lose, and if we require changes to the DHCP lease options we lose,
	and if we require that a stub user know whether to expect a given
	RDNS to support DTLS or not we lose.

	therefore, whatever new stub/RDNS protocol we put in will have to
	be opportunistic, such that if it works it gets used and if it
	doesn't get used then cleartext UDP/53 gets used.  therefore, there
	must not be a trivial way to make the protocol negotiation fail,
	forcing fallback, or else we've got ourselves a downgrade attack
	vector (like in EDNS, though please note, i do not regard this as a
	failing of EDNS.)

	if DTLS can be forced to fail by sending well timed trivially
	spoofed ICMP, then it's no protection over what the stub will fall
	back to.

all forms of the "tells you to use the new protocol" are equally impractical
due to the extreme size of the installed base, many of which are laptops.
either static, or DHCP, or rendezvous, there's no way to roll out a new
stub/RDNS fabric that lacks fallback to UDP/53 for its first 20 years of use.

but let's turn that around -- do you agree that DTLS is subject to induced
failure via spoofed ICMP?  and, if so, can we work around it by running the
session setup multiple times with unpredictable delays, and then caching the
session state for some random period of time of at least several hours?

because if so, then fallback can't be forced under those circumstances, and
folks who don't want fallback (like you, florian) can just turn it off.

> <http://article.gmane.org/gmane.ietf.dnsext/11747>.  I don't know if it

it's not.  i'm working on getting rid of that.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 19 Jul 2008 23:41:16 +0000

> names from the provider of their choice regardless of who their pipe

i can think of a huge number of ISP's who would vigorously disagree with
that assertion.  so while i happen to agree with it, i won't try to defend
it in the face of low-margin ISP's who monetize their NXDOMAIN traffic to
try to stay alive or be profitable.

and while it may be on-topic for namedroppers, it's off-topic in this thread,
since my goal is to prevent cache poisoning by true third parties.  i don't
want to prevent it from being done by an ISP, or by opendns/dnsadvantage,
or paxfire.  (i mean, i do, but not today.)  those are not true third parties
since there is an intended relationship between the enduser and each of them.
there was not an intended relationship between affected endusers and eugene
kashpureff, nor between endusers and drive-by DNS configuration resetters, or
between endusers and those who will weaponize dan kaminsky's current exploit
once it becomes public.

for this thread i want to avoid the debate about whether opendns/dnsadvantage,
or an ISP using nominum or paxfire, ought to win their coming war of eyeballs.

i just want to talk about attacks by true third parties at the moment.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Jul 2008 00:04:27 +0000

> integrity and privacy, and *no authentication of either party*.

"no"?  i think if you can complete that exchange, then it means the agent
you then share a channel with persistently has the IP address you used to 
communicate with them.  i say "persistently" since it could be that they
really have it and should have it, or that some kind of ARP or routing
attack allows them to both send packets from and receive packets to that
address even though they shouldn't be allowed to.

i can live with that as a difference-without-distinction.  if someone really
has the IP address i think i should be using for my RDNS, then that's good
enough for most purposes.  for other purposes, i'll use IPSEC or a VPN with
enough pre-shared keying information to guaranty that i'm talking to the
actual agent i want to talk to, and not just to someone who can persistently
use the IP address i've been told to use.

> If the initiator (stub) wants authentication of the responder (RDNS),
> then you need to add some sort of authentication to the naked DH. DTLS
> (and numerous other IETF protocols) does this.

that's a solved problem, as any hotel visitor who IPSEC||VPN's back to their
corporate network can tell you.  we do not have to handle that as a special
case for stub/RDNS communications, because the people who have this problem
have it for ALL protocols not just DNS.

> What you have shifted into describing is an establishment protocol for a
> long-lived, strong mutual key. You don't need Diffie-Hellman to do this:
> there are lots of other protocols as well. Once you have a long-lived,
> strong mutual key, you can either use that to integrity-protect the
> communication stream between the stub and the RDNS, or you can use it to
> integrity-protect the messages from the RDNS to the stub (such as with an
> HMAC). The RDNS needs to remember this key for a long time in order to
> prevent re-establishing the key by mutual re-authentication.

fine by me.

> Note that this does *not* prevent man-in-the-middle attacks such as an
> intermediate ISP who wants to do their own answering of your queries. It
> only prevents offline spoofing.
> 
> If you want to prevent ISP-in-the-middle attacks, you need to add strong
> authentication for the responder to your protocol. If you want mutual
> authentication, you need to design that in.

authentication is out of scope for me, anyone motivated enough to want it,
can get it, no matter what their ISP or hotel tries to do to them, using
IPSEC or VPN.  most corporate and government travellers only use the local
wired or wireless network as a bearer channel for their VPN.  i'm not going
to start trying to solve MiTM for DNS as though it was a distinct problem
from MiTM in general.  i'm only trying to secure a communications path from
stub to RDNS against true third parties who want me to believe that 
www.paypal.com's A RR is some botted web server somewhere -- not the ones
who want me to believe that wwww.paypall.comm is their advertising server.

---

From: Duane <[email-masked]>
Date: Sun, 20 Jul 2008 13:05:56 +1000

> address even though they shouldn't be allowed to.

The point he was trying to make about no authentication is the requests
can be intercepted and proxied, just because you have a secure channel,
doesn't mean you know who it's to.

-- 

Best regards,
 Duane

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Jul 2008 20:45:23 -0700

At 12:04 AM +0000 7/20/08, Paul Vixie wrote:
>"no"?

Correct: no.

>i think if you can complete that exchange, then it means the agent
>communicate with them.

Wrong. A man-in-the-middle can do the Diffie-Hellman exchange with 
you, and then do a different Diffie-Hellman exchange with the host at 
the IP address you intended to go to, and neither of you will know it.

>i say "persistently" since it could be that they

True, but if you don't care who "they" are. Your long list of 
whereas' sounded like you cared that you were talking to your RDNS.

>i can live with that as a difference-without-distinction.

Except that there is a distinction. You have no idea if the system at 
the IP address when you started the Diffie-Hellman is actually the 
system you wanted to communicate with. You need authentication in 
order to know that.

>authentication is out of scope for me,

You could have said that initially. What you did say, in a thread 

>between the stub and the RDNS.

Please forgive those of us had the mistaken impression that this was 
a debate, not a restricted mandate.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Jul 2008 03:43:18 +0000

From: Duane <[email-masked]>
> doesn't mean you know who it's to.

i understood that perfectly.  my counter response was that this is fine for
the purpose of stub/RDNS relationships as long as they are SSH-like in that
there is an expensive setup involving a generated shared secret and another
expensive randomly periodic key rollover.  these will have to be retriable
in the event of possibly-spoofed ICMP based failures, and any UDP/53 fallback
has to be configurably turn-off-able.  

under those conditions, an instruction from DHCP of "use RDNS a.b.c.d" is
sufficient since "who i think it is" is a.b.c.d and that is indeed who it
will be to.  if an ISP wants to launch a provider-in-the-middle attack, they
will have to be able to spoof the address i wanted to reach, persistently,
in order to do the secret-exchange dance, both initially and at rollovers.

the case i'm guarding against is when i think i'm talking to a.b.c.d and i'm
really not.  an ISP who can spoof a.b.c.d persistently is dangerous and
annoying, but not so dangerous as someone who isn't my ISP spoofing it in a
flood of QID-guessed responses as was demonstrated last year by amit klein.

again, i really don't care to change the method by which a stub learns to
use a given RDNS, and that method is, "use a.b.c.d".  no keys, no secrets,
no identity information.  but with sufficient state, this can be made more
secure than it is now.

(fallback in a hotel room is interesting.  if the prospective new protocol
does not work, would a hotel visitor prefer no internet service at all, or
would they drag out their VPN machinery, or would they just send their DNS
queries in UDP/53 and be mightily suspicious about what came back?  this is
interesting in like of KRE's observation that DNS spoofery may be necessary
to preserve the illusion of IPv4 reachability when we run out of new IPv4
addresses but want to keep growing with IPv4.)

---

From: Duane <[email-masked]>
Date: Sun, 20 Jul 2008 13:45:49 +1000

> has to be configurably turn-off-able.  

I realise what you are getting at when you say SSH-like, but SSH uses
public key cryptography which is why you get the message about
fingerprints, but I'm all for that :)

-- 

Best regards,
 Duane

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Jul 2008 06:13:48 +0000

> >i think if you can complete that exchange, then it means the agent you
> >then share a channel with persistently has the IP address you used to
> >communicate with them.
> 
> Wrong. A man-in-the-middle can do the Diffie-Hellman exchange with you,
> and then do a different Diffie-Hellman exchange with the host at the IP
> address you intended to go to, and neither of you will know it.

that's a danger i'd like to have the luxury of worrying about, but since
solving it would require that a stub be told more than just an IP address
as a way to reach its RDNS, i consider it out of scope.  besides which, it
is again not the kind of attack i'm worried about.  the next time someone
like amit klein breaks a PRNG and wants to inject spoofed-source responses
i would like to be able to ignore them at the outset.

> ... Your long list of whereas' sounded like you cared that you were
> talking to your RDNS.

i should have explained my problem statement better.  if someone can take
over the ip address i'm trying to use as my RDNS, then nothing will save
me except DNSSEC.  after all, they could also just take over the RDNS
server itself; who am i to judge which of those two similar sounding
problems is worthy, and which is not?

> Except that there is a distinction. You have no idea if the system at the
> IP address when you started the Diffie-Hellman is actually the system you
> wanted to communicate with. You need authentication in order to know that.

so you'd like this to be like SSH, where there's a binding between the host
key used by the responder, and the expected value maintained by the
initiator, and either a new key or a rolled key would require out-of-band
config?  this is the scary stuff, for me, since if we need a new DHCP
element to carry the expected host key, it'll take years longer to roll
this out.  and if we have a popup window to ask if some new key is OK, then
most users will just click OK so they can get back to their work.

i'm currently exploring a "no new config elements" and "if your RDNS or its
IP address gets pwned, then you shoulda used DNSSEC" path forward, because
we have an installed base rather than a blank slate to work within, and if
we can't deploy this for several years, then we should just push DNSSEC.

> You could have said that initially. What you did say, in a thread that has
> the word "security" in the title, was:
> 
> Please forgive those of us had the mistaken impression that this was a
> debate, not a restricted mandate.

if you have ideas in this area which you want to explore publically, don't
let me stand in your way.  it's not my place to mandate topics here.  i am
just trying to learn what's possible within some narrow constraints.  if
those constraints rule out this problem space then i'm sorry to have wasted
your time.

it's just that we already solved the authenticated stub/RDNS relationship
problem, five times.  IPSEC, GSS-TSIG, TKEY/TSIG, TSIG, and SIG(0).  anyone
willing to configure shared secrets before doing RDNS has that power.  we
could even define a DTLS profile for DNS on UDP/253.  but i don't know if
we can get apple and microsoft to implement that on their clients if it
makes the user experience more complex, especially if there are no servers
answering with it right away, and no DHCP servers capable of carrying the
keying info, and that's assuming we trust DHCP to carry the keying info.

---

From: Duane <[email-masked]>
Date: Sun, 20 Jul 2008 16:44:22 +1000

> most users will just click OK so they can get back to their work.

Actually the draft I'm trying to get comments on the at the moment does
just this minus the pop-ups which generally serve no useful purpose as
you pointed out.

SMTP-TLS is humming away just fine for the most part and can be
hop-by-hop or end to end depending if you run your own mail server or
use someone else's etc.

Prolonged man in the middle attacks by the 3rd parties you are thinking
of are usually expensive to some degree to keep them going, so as long
as you track the keys used to communicate with and only throw up
warnings when things change all should be well usually.

The alternative is just as you wrote about hotels with broken resolvers,
you would have to fall back, tunnel or ... to be able to resolve hostnames.

-- 

Best regards,
 Duane

---

From: Alex Bligh <[email-masked]>
Date: Sun, 20 Jul 2008 15:02:46 +0100

> i would like to be able to ignore them at the outset.

A better reason not to worry about authentication is as follows:

If we are worried about authentication at all, we should be worried about
authentication of the RDNS to the stub resolver, and not vice versa (I
haven't seen reasons for anyone to care if a "fake" stub queries a resolver
besides the DoS amplification routes).

However, if we are worried about the stub authenticating the RDNS (to avoid
an MITM attack), the stub would (as Paul Vixie says) need some info about
the real RDNS (such as a public key) to ensure it is the real DNS. Where
did it get this information from, in an environment where the stub is
mobile? The answer, invariably, is BOOTP/DHCP, which is just as susceptible
to MITM attacks. Rather than work out how to insert a MITM on some form of
DH protected link between the stub resolver and the RDNS, wouldn't an
attacker just fake the DHCP response and give an entirely bogus set of DNS
server results? Far easier, and (I would suggest) far more effective.

If you are worried about threats like the above, the answer is to IPsec
to something with a trusted RDNS behind it, or run your own RDNS (though
I note this itself is vulnerable to MITM attacks by the simple expedient
of intercepting every DNS query to the root servers).

Alex

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Jul 2008 09:11:48 -0700

At 6:13 AM +0000 7/20/08, Paul Vixie wrote:
>i should have explained my problem statement better.

+1

>if someone can take
>me except DNSSEC.

Not true, but not relevant for what I think your problem statement is.

>after all, they could also just take over the RDNS

For many attackers, it is much easier to "take over the IP address" 
of a host than to take control of the host itself. Man-in-the-middle 
attacks act like taking over the IP address.

(I only bring those two up because they are myths that might come 
back on the list later.)

So, let's go back to your problem. I hate it when people put words in 
my mouth, but I'm going to try to do that to you in a way where you 
can correct me. To make that clearer, I won't yell out my proposed 
solution until I'm sure we have a complete and correct problem 
statement.

1) The attack being defended against is an off-path attacker flooding 
the stub with guesses at responses to queries so that the attacker 
can spoof an answer to an expected query.

2) Stub has gotten the IP address of the RDNS in a possibly-untrusted 
fashion such as DHCP.

3) Stub and RDNS don't have a long-term preshared secret because 
managing those out of band is difficult.

4) Stub doesn't have the signing key of the RDNS.

5) Man-in-the-middle attacks are not of interest. If there is a smart 
man-in-the-middle, they win.

6) There is a strong desire to minimize expensive calculations (D-H 
and/or signatures), particularly those that would expose the RDNS to 
CPU exhaustion attacks.

Paul: is that complete and correct? If not, please edit.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Jul 2008 09:18:30 -0700

At 3:02 PM +0100 7/20/08, Alex Bligh wrote:
>to MITM attacks.

Good question. The answer you give is true for most deployments 
today, but there are other possible answers for different potential 
protocol changes in the future. If this is a problem we want to deal 
with (and that's not clear; it's not one that is in scope for Paul 
Vixie's thread), there is plenty we can do other than throw up our 
hands.

>If you are worried about threats like the above, the answer is to IPsec

s/the/an/  There are many others.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Jul 2008 18:06:36 +0000

> ... To make that clearer, I won't yell out my proposed solution
> until I'm sure we have a complete and correct problem statement.

i've just issued a problem statement, analysis, and proposed solution,
under the title, "dns hop by hop transaction security for queries".

> ...

yes.  fortunately for all of us, donald eastlake got here years ago,
and this can most likely be done without protocol or API changes, just
some work by DNS implementors and integrators and operators.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Jul 2008 18:21:18 +0000

> From: Ben Laurie <[email-masked]>
> 
> Paul Vixie wrote:
> > under those conditions, an instruction from DHCP of "use RDNS a.b.c.d"
> > is sufficient since "who i think it is" is a.b.c.d and that is indeed
> > who it will be to.  if an ISP wants to launch a provider-in-the-middle
> > attack, they will have to be able to spoof the address i wanted to
> > reach, persistently, in order to do the secret-exchange dance, both
> > initially and at rollovers.
> 
> Not quite getting this. If the address came from DHCP, then who you think
> it is is irrelevant. You are talking to whomever the ISP wanted you to
> talk to.

i must have said it in the wrong order, thus conveying undue meaning.  if
you're going to trust DHCP, then you are at the mercy of your L2/L3 provider,
one way or the other.  if on the other hand you prefer to use opendns or
dnsadvantage, or you are still using a static open resolver from three ISP's
ago, then you are still at the mercy of your L2/L3 provider.

if you do not want to be at the mercy of your L2/L3 provider, then you have
to use some kind of VPN, not just to protect your DNS against eyeball thieves
but to protect your HTTP against eyeball thieves.  note that right now, the
average ISP or hotel has a hands-off approach to VPN, because it's rare and
because the people who want to use it are mostly high-end corpies and govvies.
but if ever VPN became ubiquitous, then the hotels and ISPs of the world would
start fighting back, since there would be too much revenue loss, and because
the average VPN user would become less powerful (a fatter target).  we'll call
this "the eyeball wars" in the history books.  i'd like DNS to remain neutral
but sell arms to all sides of the conflict.

> From: Ben Laurie <[email-masked]>
> 
> Paul Vixie wrote:
> > (fallback in a hotel room is interesting.  if the prospective new
> > protocol does not work, would a hotel visitor prefer no internet
> > service at all, or would they drag out their VPN machinery, or would
> > they just send their DNS queries in UDP/53 and be mightily suspicious
> > about what came back?  this is interesting in like of KRE's observation
> > that DNS spoofery may be necessary to preserve the illusion of IPv4
> > reachability when we run out of new IPv4 addresses but want to keep
> > growing with IPv4.)
> 
> This is crazy talk.

then you should argue with Message-ID: <[email-masked]>
rather than with me.  i take most of what robert elz says without a grain of
salt.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Jul 2008 18:43:10 +0000

> From: Eric Rescorla <[email-masked]>
> 
> Paul Vixie wrote:
> > so, either there can be no fallback, or there must be additional
> > configuration information for the stub/RDNS relationship (beyond the
> > RDNS's IP address; for example it could include a TSIG shared-secret.)
> 
> True. Though it could also just contain the one bit of information
> that the server will do a secure channel, right?

in for a dime, in for a dollar.  it's not the number of new bits, it's
that the number of new bits is zero or not.

> > TCP however is not subject to this kind of spoofed-ICMP induced failure.
> 
> Because the ISN is in the first 64 bits and ISNs are hard to predict?

that's my hope, but since i thought it was bytes not bits, it could be
that the ISN isn't in the first 64 quatloos, and TCP can be shot in the
head by spoofed ICMP just as easily as UCP can.

> > so perhaps i've been overthinking this.  what if ...
> > 
> > be it noted, there is still no authentication here.  ...
> 
> Without taking a position on this particular design, I think there's a
> high order question about whether you'd like to authenticate the server
> of just get continuity, right?

there is no question that all i care about here is continuity, since the
larger problem of endpoint authentication already has plenty of solutions
and all of them have high cost and most of that high cost is due to the
fact that there are a nonzero number of new bits of configuration data.

> If you do, then you should do the initial key establishment via some
> public key authentication mechanism, at minimum SSH-style leap of faith.

i don't see microsoft or apple adopting that approach for their stubs.  it
is not reasonable to present an end user with a popup that asks them for
input they know they are not qualified to give.  so, that's why i'm not
trying to do an SSH-style leap of faith on this.

> On a slightly different note, wouldn't another possibility be to simply
> ignore ICMP unreachables and rely on timeouts?

that tends to be a kernel change rather than an application change.  there
may even be a setsockopt() that does this on some BSD-like or Linux-like
operating systems, or on WIN32-like operating systems, but not on all of
them.  if we offer a new mechanism that's only secure after a change to
the kernel's UDP stack, then we'll never be sure what got deployed, but we
can safely bet that it won't be universal.

note, i have posted a new problem statement, analysis, and proposal, under
the name, "dns hop by hop transaction security for queries", Message-ID:
<[email-masked]>.  if you're not on namedroppers, i can send
you a copy, just ask.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Jul 2008 19:19:59 +0000

> >> So why not DTLS-over-UDP/53 falling back to plain-over-UDP/53?
> >
> > because TKEY already exists.  see RFC 2930.
> 
> I think it would be fair to say that DTLS already exists, too, and provides
> properties TKEY does not.

DTLS would be a new protocol for stubs and RDNS to speak, but i'll ask,
features does DTLS have that TKEY doesn't have and do we need those?

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Jul 2008 21:48:32 -0700

At Mon, 21 Jul 2008 05:44:25 +0100,
Ben Laurie wrote:
> 
> Eric Rescorla wrote:
> > At Sun, 20 Jul 2008 18:43:10 +0000,
> > Paul Vixie wrote:
> > Well, I agree that there's a qualitative difference between 0 and 1,
> > but I think there's still a pretty big difference between 1 and 160.
> > 
> > 
> > So, I'm not saying that l-o-f will necessarily work here, but
> > I don't think it's necessary to prompt the user. Rather, you
> > can just accept the first key you see...
> 
> And prompt them when it changes?

Good question. Probably retry via the original channel. I agree it's
not a real adequate answer...

-Ekr

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Jul 2008 05:29:25 +0000

> Good question. Probably retry via the original channel. I agree it's not
> a real adequate answer...

in Message-ID: <[email-masked]> which is the top of the thread
whose subject is "dns hop by hop transaction security for queries", i wrote:

	... if at least one TSIG signed query transaction succeeds to a
	responder, and then later transactions fail with TSIG errors
	(BADSIG) then TKEY over TCP/53 should be repeated.  if no TSIG
	signed query ever succeeds, then after some small number of
	retries, the TKEY should be discarded and no longer used. ...

in case this wasn't clear, there is no great answer, but my proposal is that
if a key stops working, you renegotiate a new key with whoever now operates
the internet radio station at the address you're trying to use as your RDNS.

this points up an obvious but inevitable and necessary weakness, which is
that an on-path MiTM can insert himself into your trust with no barriers.
i'm not worried about this, since off-path IP spoofing attacks are the
problem i'm trying to solve, and on-path MiTM already has so many non-DNS
powers that i really think anyone worried about on-path MiTM is already
going to be using one of the authenticated protocols like DNSSEC, SIG(0),
GSS-TSIG, or some kind of VPN.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Jul 2008 15:59:25 +0000

> a) The ICMP unreachable message includes 64 _bits_ of the payload,
> according to RFC 792, not 64 bytes, so only the UDP header is covered,
> and so all UDP protocols have this issue.

oops.  my apologies, as usual, for displaying my ignorance so readily.

so, either there can be no fallback, or there must be additional configuration
information for the stub/RDNS relationship (beyond the RDNS's IP address; for
example it could include a TSIG shared-secret.)

all forms of complex setup including DTLS and TKEY are subject to the same
spoofed-ICMP downgrade attack, if there is a fallback.

TCP however is not subject to this kind of spoofed-ICMP induced failure.  so
perhaps i've been overthinking this.  what if we use TKEY-over-TCP/53 to set
up the trust relationship, and then TSIG-over-UDP/53 for queries thereafter,
and go back and do a new TKEY-over-TCP/53 if the TSIG ever stops working?

be it noted, there is still no authentication here.  the stub won't know what
actual entity is speaking from its RDNS' IP address.  but the stub could be
certain that it was the same entity from setup onward throughout.  that's my
bugaboo.

---

From: Florian Weimer <[email-masked]>
Date: Sun, 20 Jul 2008 11:04:06 +0200

> a VPN through some trusted relay point for their RDNS/ADNS traffic.

Speaking as a vendor, I want to standardize the VPN infrastructure, so
that our users are not tied into the VPN infrastructure we provide.  I
want interoperability at the protocol level, too, so that the software
at the endpoints is interchangeable.

It would be really neat if we could use official DNS protocols for that.
If we can't, it's not a showstopper, but it means that the approach will
be proprietary, no matter how much source code we release.  On the other
hand, I'm not sure if the underlying problem is of sufficient general
interest to justify IETF involvement.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 20 Jul 2008 18:19:05 +0100

> in order to do the secret-exchange dance, both initially and at rollovers.

Not quite getting this. If the address came from DHCP, then who you 
think it is is irrelevant. You are talking to whomever the ISP wanted 
you to talk to.

This is crazy talk.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Jul 2008 17:48:40 +0000

> From: Florian Weimer <[email-masked]>
> 
> * Paul Vixie:
> > end users who really just can't tolerate provider-in-the-middle attacks
> > will use VPN to reach an RDNS they trust, or will run an RDNS of their
> > own using a VPN through some trusted relay point for their RDNS/ADNS
> > traffic.
> 

i believe that the proposal i just sent out does that.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 19 Jul 2008 18:59:45 +0000

> > ... i'm concerned about two elements of that protocol.  first, it
> > appears that the handshake can be made to fail using spoofed
> > ICMP-Unreach messages, which may not be a problem for most protocols,
> > but in our case the fallback is UDP/53 and so this is a downgrade
> > vector.
> 
> Eh? If you're using DTLS you are already on UDP.  Do you mean the 
> fallback is to plaintext UDP? If so, why?

in my deployment scenario, we have hundreds of millions of stubs talking to
millions of RDNS', and if we require preshared keys we lose, and if we
require changes to the DHCP lease options we lose, and if we require that a
stub user know whether to expect a given RDNS to support DTLS or not we
lose.

therefore, whatever new stub/RDNS protocol we put in will have to be
opportunistic, such that if it works it gets used and if it doesn't get
used then cleartext UDP/53 gets used.  therefore, there must not be a
trivial way to make the protocol negotiation fail, forcing fallback, or
else we've got ourselves a downgrade attack vector (like in EDNS, though
please note, i do not regard this as a failing of EDNS.)

if DTLS can be forced to fail by sending well timed trivially spoofed ICMP,
then it's no protection over what the stub will fall back to.

> All of your possible roads appear to me to be susceptible to [MiTM]
> attacks. If we're going to fix this, let's fix it properly.

i think hotel-in-the-middle and provider-in-the-middle are inevitable, for
economic reasons (NXDOMAIN remapping) and technical ones (as told here by
KRE this morning, involving IPv4 longevity measures.)  there's a credible
"first-meeting" trust model, like in SSH, where the identities and secrets
of the parties are established at some high cost when they first meet, after
which any change in those identities or secrets only at some higher cost, by
which these MiTM "attacks" would be much harder to launch.

however, i did say that my list was paltry, and if you have a suggestion,
i'd be grateful to you for sharing it.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 20 Jul 2008 20:09:00 +0100

> because TKEY already exists.  see RFC 2930.

I think it would be fair to say that DTLS already exists, too, and 
provides properties TKEY does not.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Jul 2008 23:02:52 +0000

> ... Rather, you can just accept the first key you see...

yes, that's what i'm proposing.  we're ensuring identity continuity between
the entity who could hear and speak from an IP at session initialization
time and the entity who can later transmit responses from that IP.

> Maybe I'm missing something, but why do you need to change the kernel?
> As I recall, UDP sockets, unlike TCP sockets, don't die just because an
> ICMP message is received. Can't the application just ignore the error?

if the socket is connected, then read() will show an error if an ICMP
arrives that was putatively due to a previous write().  it's a mess.  yes,
you can ignore all ICMP-causable errors from read() or write() (or sendto()
or recvfrom(), etc).  or you can just not bother to connect() the socket
in which case you should never see ICMP-causable errno values.  but i'm
only speaking from a BSD sockets perspective, i don't know how STREAMS does
it, or WIN32 sockets, or linux sockets, or embedded system sockets.  is it
safe to design with application-layer ignore-ICMP as an implementation
requirement?  (i really don't know if these errors are ever sticky on some
platforms.)

ignoring ICMP during TKEY is testable, but is not necessary for
interoperability, so it's a strange kind of requirement to specify.  but
if it means we could forget the TCP requirement for TKEY, it means we were
even closer to already having a working solution than i'd thought we were.

note, we're already designing with the assumption that ICMP redirect will
be ignored by the kernel, since that kind of spoofing has already been done
and unlike ARP spoofing it's a spoofable protocol element we could afford
to declare to be a bad idea in general and stop honouring it, which we did.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 20 Jul 2008 17:37:37 +0100

> example it could include a TSIG shared-secret.)

There can be fallback, it just has to use the same port.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 20 Jul 2008 12:29:27 +0100

> on DTLS for stub/RDNS transactions.

So, I asked Eric Rescorla about this (copied) and he responds that:

b) TLS and DTLS support non-confidential modes, e.g. TLS_RSA_WITH_NULL_SHA.

> have to be designed to carry the D-H exchange.

If RFC 792 is wrong and you are right, then Eric informs me that DTLS 
has randomness at byte 33 in the payload (i.e. byte 41 in IP payload) so 
its covered.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 19 Jul 2008 23:04:03 +0000

> That is the correct problem statement.

according to KRE, whose opinion i do not lightly discount, this is nec'y
for various IPv4 prolongment tricks, and unless the world is ready to move
en masse to IPv6, we won't succeed in trying to stop provider-in-the-middle
attacks.

providers of advanced DNS services, such as opendns, have always been on
shaky ground, since they are fighting for a chance to be the MiTM, and their
opponents in that fight own the last mile L2/L3.  but while that's bad for
these advanced DNS service providers, it's not clear that the users benefit
or suffer more based on who their provider-in-the-middle turns out to be.

in other words there's a fix to provider-in-the-middle for motivated end
users, and no way to outlaw them altogether unless we can abandon IPv4, and
the greatest remainder of suffering is by dnsadvantage, opendns, and similar.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 21 Jul 2008 05:44:25 +0100

---

From: Ben Laurie <[email-masked]>
Date: Mon, 21 Jul 2008 10:38:29 +0100

> features does DTLS have that TKEY doesn't have and do we need those?

Obviously the main one is for certificate hierarchies. Whether we need 
those is another question - they sounds like a useful optional extra to 
me :-)

I haven't studied TKEY in detail - there may be others.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 20 Jul 2008 12:33:02 +0100

Paul Vixie wrote:
> nonce).

BTW, the obvious (I think!) defence against this would be to operate 
DTLS over the same port, so unreachable causes complete failure.

A downgrade attack would still potentially be possible by a MitM, but 
not by spoofing. However, you have argued elsewhere that MitM is 
actually a design feature (not sure I agree!).

Also, a knowledgeable user should be able to insist on DTLS if they know 
the properties of their resolver.

> second, and less troubling, DTLS has message secrecy as a goal,

---

From: Ben Laurie <[email-masked]>
Date: Sat, 19 Jul 2008 18:25:18 +0100

> this is because the first 64 octets of

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Jul 2008 15:47:23 -0700

Maybe I'm missing something, but why do you need to change the kernel?
As I recall, UDP sockets, unlike TCP sockets, don't die just because
an ICMP message is received. Can't the application just ignore
the error?

-Ekr

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Jul 2008 18:09:33 +0000

---

From: Ben Laurie <[email-masked]>
Date: Sat, 19 Jul 2008 18:25:35 +0100

> is finite and manageable.

All of your possible roads appear to me to be susceptible to 
man-in-the-middle attacks. If we're going to fix this, let's fix it 
properly.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Jul 2008 10:23:47 -0700

At Sun, 20 Jul 2008 15:59:25 +0000,

> so

Without taking a position on this particular design, I think
there's a high order question about whether you'd like to
authenticate the server of just get continuity, right? If
you do, then you should do the initial key establishment via
some public key authentication mechanism, at minimum SSH-style
leap of faith.

On a slightly different note, wouldn't another possibility be
to simply ignore ICMP unreachables and rely on timeouts? As
you know, enough firewalls and NATs block ICMP that you can't
trust them anyway, so you have to be prepared to fall back
to timeout. And if you were to cache the initial information
that the server was/wasn't prepared to do the new security protocol
(a la SSH), then you would only have timeout issues when
you contacted a new server. (You could reprobe periodically...)

-Ekr

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 21 Jul 2008 09:00:13 -0500

> not a real adequate answer...

This is the pervasive question for almost all security schemes. How does 
a client system establish, and then "maintain", trust in a remote party 
which you (the designer, with your opinion perhaps reflected reflected 
in a "policy") assume equiped with more skills in IT security management.

DNSEXT revisits this question because ... because what, I don't know. 
Actually the question belongs to the IT security community of experts 
which never addressed the question for what it is, i.e. pervasive for 
almost all security schemes.

Thanks to Eric for joining the discussion and bringing it to this point.

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Mon, 21 Jul 2008 17:56:47 +0100

On Sun, 20 Jul 2008, Ben Laurie wrote:
> a) The ICMP unreachable message includes 64 _bits_ of the payload, according
> to RFC 792, not 64 bytes, so only the UDP header is covered, and so all UDP
> protocols have this issue.

It's the IP header (20 bytes) plus 64 bits (8 bytes) of the IP payload,
which is just enough to cover the whole UDP header, or the port numbers
and sequence number from the TCP header.

RFC 4884 allows the amount of payload to be greater than this minimum.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FISHER: NORTH OR NORTHWEST 5 TO 7. ROUGH OR VERY ROUGH DECREASING MODERATE OR
ROUGH. SHOWERS. MODERATE OR GOOD.