Re: transaction security in the last mile

[Paul Vixie <paul@vix.com>]

> From: Eric Rescorla <ekr@networkresonance.com>
> 
> 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:
<55957.1216574145@nsa.vix.com>.  if you're not on namedroppers, i can send
you a copy, just ask.

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


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