Re: transaction security in the last mile

[Eric Rescorla <ekr@networkresonance.com>]

[ 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. ]

At Sun, 20 Jul 2008 18:43:10 +0000,
Paul Vixie wrote:
> 
> > 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.

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.


> > 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.

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...


> > 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.

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

--
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/>