Re: transaction security in the last mile

[Eric Rescorla <ekr@networkresonance.com>]

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:
> >>> 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...
> 
> And prompt them when it changes?

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

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