Subject: Re: [Design] Re: the KEY debate

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 17:26:49 -0400

"Jason Coombs" <[email-masked]> writes:

> Derek,
> 
> Neither SSH nor IPSec should ever be used to conduct secure communications
> with arbitrary dynamically-discovered third parties, so your examples don't
> make much sense to me.

I don't know your background, but it sounds like you're viewing SSH as
a telnet replacement, and IPsec as a VPN solution.  Unfortunately
you'd be wrong on both accounts.

I want 100% of my communications encrypted.  If I go and ping a host,
I want that encrypted.  If I finger, I want that encrypted.  If I ftp,
http, smtp, ntp, or anything else, I want that encrypted.

IPsec is the tool I'd like to use (because SSH is subject to the
TCP-RST attack).  I'd like IPsec to happen and start encrypting
traffic with EVERY HOST I contact, regardless of why I contact them,
or how.

Note that encryption != authentication/authorization.  If you want to
use SSH or IPsec for authentication/authorization, then you DEFINITELY
want to be able to verify the key.  However:

        1) I am not proposing that, and
        2) In many cases, a DNSSec-provided key can be "good enough" for
           limited authentication/authorization.

> Better for you to KNOW the keys needed, in advance, to secure communications
> with trusted hosts that you have an SSH or IPSec relationship with. Why do
> you want to discover them dynamically? In particular, why would you EVER
> want to discover them dynamically *across domains* ? That's just asking for
> trouble and it's a feature without a purpose. It might also be deficient in
> the area of common sense.

So I need to contact this random site out there -- I heard about it
through a friend of a friend.  I want my traffic encrypted.  How do I
get their key?  I now need to dynamically discover this key across
domains.  Why?  Because I want ubiquitous, end-to-end encryption of
all traffic.  I could just use ephemeral diffie-helman, but that's
vulnerable to a man-in-the-middle.  if I had some other key that I
could grab, even if it wasn't 100% guaranteed, I've now increased my
protection against the MitM.

Note that I want "good enough" security, not "protect me from the NSA"
security.  In this case, IPsec opportunistic encrypting using keys in
DNS would solve my problem.  This would give me my encryption, which
is all I want.

If you still do not understand this problem space I'd be more than
happy to talk to you offline -- we don't need to waste the list's
bandwidth on your education.

> Sincerely,
> Jason Coombs
> [email-masked]

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Aug 2002 09:04:18 -0400

>the area of common sense.

These questions have dogged me on this for quite a while, ever since 
our first effort to get SSH and DNS integrated (late 2000).  I rarely 
SSH to a host "for the first time" from across the Internet.

On the other hand, there are two reasons why you might not have the 
keys (etal) of the SSH host that you want to contact while you are on 
the road.  One is that the keys on the host may have been changed 
(local maintenance, emergency repair).  The other is that you may 
have just recompiled the kernel on your laptop, screwed it up, and 
had to reload from disk.  (Raise your hand if you have ever thought 
that the flight to the IETF would be a good time to "fix" your 
kernel.  Of course, if you are using security to carry out a truely 
critical function, you aren't likely going to rebuild your kernel.)

One aspect of the debate is not as much "how good" you want security, 
but is where on the sliding scale between "secure but brittle" and 
"loose and resilient."  Simplicity in security starts with having a 
restricted system and not letting it stray from the norm, like 
pinning down the routes to the roots.  Resilience in a system means 
that it will take any action necessary to reach the goal, even if 
unusual actions maybe needed, such as using alternate roads to travel 
around DC during rush hour.

If you desire resilience and security, you have to be prepared to do 
a lot of work.  Multiple certification chains are one start - 
although if you expect to use this, you open yourself to potentially 
eating up CPU cycles as part of a DOS attack.  You also had better be 
prepared to lose the use of your most expensive resource at any time 
(meaning you will have to budget at least 100% for overhead).

"It just goes to show you, it's always something." - I think this was 
Roseanne Roseanna Danna, a.k.a. Gilda Radner
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer