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

Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Michael" == Michael Thomas <mat@cisco.com> writes:
    Henry> We thought about that, but decided that some authentication was better
    Henry> than none, especially since it would upgrade transparently to full
    Henry> authentication.  It's one thing to accept security loopholes as a
    Henry> temporary measure, and another to define a protocol that will always
    Henry> have security loopholes.

    Michael> Well... How is this especially different than just using
    Michael> self-signed certificates and having a wide open policy? I don't
    Michael> think there's anything protocolwise that even needs to be done
    Michael> there. Clearly you can upgrade that by using rooted certs in the
    Michael> future as well.

  Agreed.
  Nor is there anything protocol-wise that needs to be done to use DNS. The
difference is that DNS, via DNSSEC, provides a theorectical upgrade path to
get some additional authentication. 

  For those that do control their reverse map, the reverse map does provide a 
way to point towards a gateway box. In an end-game situation where all hosts
do IPsec, this may no longer be necessary. This is the one advantage that DNS
currently has over self-signed certificates. 

    Michael> I guess what bothers me is that you are expecting to use DNS as
    Michael> a directory service for certs which it wasn't really intended
    Michael> for thus making an already complicated situation even more

  I'm not sure that I agree that DNS was not meant for storing certificates.
I think that this facility has been in DNSSEC for some time now. It has not
been widely deployed yet.

    Michael> I guess that I view that there's probably an 80/20 rule here
    Michael> which is being missed: *most* people aren't going to go to the
    Michael> lengths of creating an active MITM attack to snoop on boring old
    Michael> every day conversations.  Thus encrypting everything -- by
    Michael> accepting MITM attacks where there is no pragmatic alternative
    Michael> -- will kill off all of the passive snooping. Given the advent

  So, I think that we are open to this view. We call it "anonymous encryption"
although this term has been said to be confusing.

  In the draft we are attempting to document what FreeSWAN does *NOW*.

  If there is interest in enhancing this, that should be the subject of a
future draft.
  
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface

iQCVAwUBO3wnIYqHRg3pndX9AQEMOAQAvsYeCLjaw9s9p35xiAGnP0lg4hdugOnX
IWwwjxUswevKa/piHZLQHVH8r8iVy/iMFBTRdAIfdJq6MihKoGXjtEORvL+0k+nA
9UE0Th80Ks+PNUNs+ziXj2gY7SbB75Ebw9q2wpBSj3yz1p4eYJVJJxjmnWy630Tp
LcwwLiQAyAY=
=/dy+
-----END PGP SIGNATURE-----
References: