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

Re: opportunistic encryption deployment problems


: Bill Sommerfeld wrote:
:
: > While it's outside the scope of a protocol specification, the spec
: > should recommend that, in the absence of some form of certification,
: > implementations should make {dnsname,address}->key mappings "sticky"
: > using techniques similar to those currently used by ssh.
:
: I very much like the idea of opportunistic encryption. However,
: I'm concerned on the reliance on secure DNS as the only
: authentication mechanism. While I do like how OE can be
: used from small to large deployment of DNSSEC, I'm
: concerned that (a) DNSSEC will eventually bring the same
: trouble as a large scale PKI would [such as the worries
: about people being able to control their reverse mappings
: or their DNS at all], and (b) it may not be the most effective
: weak authentication scheme [and it is weak until the root
: gets signed].
:
: In particular, I wonder if ssh-like leap-of-faith authentication at
: the time of first contact and subsequent strong authentication
: would be a better weak authentication scheme. Not much memory
: is needed for this, just a mapping from a claimed identity to
: a hash of the public key. Additionally, this has the benefit that
: dynamic IP addresses can be accommodated as the identity
: could be e.g. the user's e-mail rather than the changing IP/dns.
: I believe there are vendors who are already using self-signed
: certificates to do something like this.
:
[well, I'm still supposed to be on vacation but before I leave to Lapland
I give my comments :)]

We've had this ssh-like leap-of-faith authentication as Jari suggested a
long time now in SSH Sentinel and we think it works very well.  It is
especially handy when you do not have complex PKI systems in hand.  While
we use it only with certificates (we negotiate IKE with remote end,
receive the certificate (show the fingerprint) and sign it with our
self-signed certificate) it would work as well with plain RSA public keys
too - in conjuction with DNS and DNSSEC systems, and with OE as well.  I
too like the idea of the OE and think that the DNS approach might work,
but it is not perfect yet as we discussed with Hugh and others in the
interop.  I don't much like that the OE would be added to IKE in
anyway; I think it should be a separate process, after all how the OE is
employed is very much implementation issue (and we might not actually end
up doing IKE at all).

For an implementation the authentication for example may be just using
plain DNS or maybe DNSSEC, or it might show the fingerprint of the key
when it fetches it, or it may show it and sign it with self-signed
certificate, or may it just accept all keys and cache them and sign
them.  I think that the opportunisim can be interpreted so that "doing
IPSEC is fine, I think I'll try that first, and you can try it too, but if
we can't get it working I can settle to plaintext too", where the
authentication might not be the primary concern of yours.  In fact, the
primary concern might be just getting the IPSEC working, after all it is
better than doing plaintext.  But of course, I think if you are going to
do the authentication then you should do it well.  I think the protocol
can suggest something for this.  The opportunisim can also be interpreted
so that it is not different from doing IPSEC with predefined connections
except that we don't have them preset and the authentication is very
important - and plaintext is not an option.

	Pekka
___________________________________________________________________________
 Pekka Riikonen                    | Email: priikone@silcnet.org
 SSH Communications Security Corp. | http://silcnet.org/~priikone
 Tel. +358 (0)40 580 6673          | Snellmanninkatu 34 A 15, 70100 Kuopio
 PGP KeyID A924ED4F: http://silcnet.org/~priikone/pubkey.asc
References: