[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: transaction security in the last mile



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

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?

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

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