[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems
I think the problem is not specifically "global PKI" but "global trust
infrastructure".
It would be useful if IKE could use different trust models, including
delegation this to another protocol.
However, I think in most cases, binding up your key to an IP address
probably isn't that useful, due to ephemeral nature of IP addresses - my
impression is that this just gets worse with IPv6.
The important thing is that you can authenticate who your peer is - there's
no reason why this has to be bound up in an IP address - and that your
policy allows to communicate with them.
Chris
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: 15 August 2001 16:54
> To: Henry Spencer
> Cc: Michael Thomas; ipsec@lists.tislabs.com; FreeS/WAN Design Issues
> Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption
> deployment problems
>
>
> Henry Spencer writes:
> > On Sat, 11 Aug 2001, Michael Thomas wrote:
> > > > > [anonymous encryption]
> > > > We thought about that, but decided that some
> authentication was better
> > > > than none, especially since it would upgrade transparently...
> > >
> > > Well... How is this especially different than just
> > > using self-signed certificates and having a wide open policy?
> >
> > The transparent upgrade to full security is important. As
> I said before,
> > there's an important difference between temporary and
> permanent security
> > holes. The nice thing about having DNSSEC verify the
> provenance of the
> > public keys is that instituting this requires no changes
> to the protocol
> > *or the protocol software*. Going from self-signed
> certificates to a
> > certificate signing chain would.
>
> Huh? IKE requires that you be able to verify signatures
> back to a trusted root. There is absolutely no difference
> whether you get those certs from DNS, IKE, or
> pony express. The verification process is
> essentially identical. The only difference I
> can see is if you want to not use certs and
> instead rely on naked public keys. I'm dubious
> about this as there are better thought out ways
> of doing a centralized key management scheme
> (namely, kerberos) which is what that amounts
> to (enrollment being the hard problem).
>
> > Before too very long, it *will* be necessary to secure
> DNS, whether that
> > is done by the current DNSSEC or by other means. Why
> duplicate that work
> > in each application?
>
> The implications of secure DNS is a global
> PKI. The same global PKI that doesn't exist.
> I have little reason to believe that the
> PKI fairy will leave one under our pillow
> any time soon.
>
> > One must distinguish carefully between two different
> categories of people:
> > the users, and the attackers. It's not unreasonable to
> aim protocols at
> > 80% of the users, but that means those users should be
> secure against very
> > nearly 100% of the attackers. It only takes one
> aggressive attacker to
> > put many users in jeopardy.
>
> > Most especially and particularly, there are quite a number
> of countries in
> > the world where you can be 100% sure that the government will be an
> > attacker, *because it already is*. And it has the
> cooperation, willing or
> > unwilling, of the ISPs... so MITM attacks will not be
> difficult to mount.
> > This is an important type of attacker.
>
> I guess I differentiate your average luser script
> kiddie with attackers who really know what they're
> doing. Like door locks and other common sense
> security measures, you can do an adequate job of
> most of the petty crimes by raising the bar to
> a sufficient degree of sophistication that the
> average kiddie is going to go back to making
> OE bombs instead. The latter category is and has
> always been far more problematic.
>
> In any case, there is already a way to thwart MITM
> attacks using IKE *today*. There is no need whatsoever
> to bring DNS into the picture to do that, and indeed
> DNS obscures the situation, IMO. Instead of making
> a single self contained complicated system, you now
> have two extremely complicated systems to analyze.
>
> Mike
>
>
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
Follow-Ups: