Subject: Re: [saag] suggested text for opportunistic definition

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Jun 2014 14:01:20 +0100

Folks,

I've not seen discussion/progress on Steve K's draft for over a month
(perhaps this'll prompt that:-), and I would like to get this topic
sorted, so I'd also be interested in whether folks have opinions on
Viktor's shorter proposal, visible at [1], not yet an I-D. Please
comment...

Thanks,
S.

[1] https://www.ietf.org/mail-archive/web/saag/current/msg04962.html

On 04/05/14 09:56, Viktor Dukhovni wrote:
> On Sun, Apr 27, 2014 at 01:37:40PM +0100, Stephen Farrell wrote:
> 
>> Or even maybe try suggest an alternative for the whole
>> thing if you've energy.
> 
> OK.  How about the below (removed TOC, BCP 78/79 boilerplate,
> pagebreaks, ... leaving just the content).  This is quite short,
> and to the point, which is I think a significant advantage.  Most
> of what is left unsaid is I think inessential to the definition.
> If the below is a reasonable start, and anyone wants to see some
> more words, I am not opposed to reasonable expansion of the text
> and/or clarification, provided we keep the separation of the
> essential definition from any illustrative examples or properties
> that some opportunistic security protocol or other might have.
> (XML, HTML, ...  available, and I can post a more formal I-D if
> this is a reasonable starting point).
>

---

From: ianG <[email-masked]>
Date: Sun, 15 Jun 2014 15:59:25 +0100

On 15/06/2014 14:01 pm, Stephen Farrell wrote:
> (perhaps this'll prompt that:-),

URL?

> and I would like to get this topic

Viktor's proposal is good.  I could quibble, but cannot see how to make
it better.

> [1] https://www.ietf.org/mail-archive/web/saag/current/msg04962.html

iang

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 15 Jun 2014 08:01:07 -0700

One concern about the draft is the denigration of TOFU. SSH is very widely used and characterizing it as "fragile" does not match my experience, although key continuity obviously has some drawbacks. The physician's credo "First, do no harm" should also apply here.

> On Jun 15, 2014, at 6:01 AM, "Stephen Farrell" <[email-masked]> wrote:
> 
> 
> Folks,
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Jun 2014 17:40:41 +0100

>> (perhaps this'll prompt that:-),

Ah, sorry. Steve's draft is [1]

S.

[1] https://datatracker.ietf.org/doc/draft-kent-opportunistic-security/

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 15 Jun 2014 16:43:33 +0000

On Sun, Jun 15, 2014 at 08:01:07AM -0700, Bernard Aboba wrote:

> One concern about the draft is the denigration of TOFU. SSH is
> very widely used and characterizing it as "fragile" does not match
> my experience, although key continuity obviously has some drawbacks.
> The physician's credo "First, do no harm" should also apply here.

Thanks for the feedback.  I wrote:

    Encryption is easy, but key management is difficult. Key management at
    Internet scale remains an incompletely solved problem. The PKIX ([RFC5280])
    key management model introduces costs that not all peers are willing to
    bear and is also not sufficient to secure communications when the peer
    reference identity is obtained indirectly over an insecure channel or
    communicating parties don't agree on a mutually trusted certification
    authority (CA).  DNSSEC is not at this time sufficiently widely adopted to
    make DANE a viable alternative at scale. Trust on first use (TOFU) key
    management models (as with saved SSH fingerprints and various certificate
    pinning approaches) are fragile and require user intervention when key
    continuity fails.

How would you like to express this better?  I did not mean to
disparage TOFU.  SSH works well enough because it is not used to
connect to arbitrary hosts, any one user generally only logs in to
a relatively small set of systems (as compared with web sites they
visit, domains they might send email to, ...).

So I am not trying to disparage TOFU, merely suggest that it does
not generally scale to authenticating any peer on the Internet.

I could remove the two words "are fragile", if they are seen too
judgemental and not essential to make the point.

-- 
	Viktor.

---

From: Mouse <[email-masked]>
Date: Sun, 15 Jun 2014 13:02:53 -0400 (EDT)

>                                              Trust on first use (TOFU) key

> How would you like to express this better?

I wouldn't say they're _fragile_, exactly, just that they are
appropriate to only a relatively restricted set of problems.  (That
it's what SSH uses merely means that SSH is not an appropriate solution
outside that set.  That SSH gets used anyway just means that that set,
restricted though it is, contains some useful problems.)

> So I am not trying to disparage TOFU, merely suggest that it does not
> generally scale to authenticating any peer on the Internet.

I don't think it's a question of scale; TOFU scales just fine to a very
large number of peers.  What it won't do is work for problem domains
where first use is likely to be attacked - regardless of how large the
set of peers in question is.  (That is, it may not be suitable for
authenticating arm's-length peers over the open Internet, but the
reason isn't scale per se.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Christian Huitema <[email-masked]>
Date: Sun, 15 Jun 2014 17:14:03 +0000

> restricted though it is, contains some useful problems.)

What about replacing "are fragile" by "are not always appropriate?"

Apart from that, I like Viktor's text. It is clear, to the point and easy to read. I would vote to adopt and publish.

-- Christian Huitema

---

From: ianG <[email-masked]>
Date: Sun, 15 Jun 2014 20:39:37 +0100

On 15/06/2014 17:40 pm, Stephen Farrell wrote:

>> Steve's draft is [1]

Ah, thanks.  I think Viktor's at bottom is far superior.  It looks
forward and upwards, climbing up from no security to a position of some
good ol' opportunistic cryptography.  Establishes some principles, and
leaves it at that.

In contrast, IMHO the /Countermeasure/ draft looks downwards,
apologetically.  It is as if it needs to justify the downgrade from the
position of other protocols, and especially prior dogma as to
authentication.  It's the wrong starting point, we don't need to justify
or downgrade, and doing so adds length to little effect, while clouding
the principles needed.

my 2c, iang

---

From: Eliot Lear <[email-masked]>
Date: Sun, 15 Jun 2014 22:06:06 +0200

On 6/15/14, 7:02 PM, Mouse wrote:
> appropriate to only a relatively restricted set of problems.

I would suggest a simpler change:

just remove the words "are fragile and".

Eliot

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 15 Jun 2014 20:43:33 +0000

> just remove the words "are fragile and".

I'd like to convey two flavours of limitations, one is key continuity
failure, the other is of course securing the initial contact (or
sufficiently infrequent repeated contact).  Since this is not
intended to be a draft about TOFU, I'd like to keep it short, so
how about:

-   approaches) are fragile and require user intervention when key
-   continuity fails.
+   approaches) don't protect initial contact and require user
+   intervention when key continuity fails.

In any case, I think the question at hand is not whether the draft
is finished (I've not even submitted it yet), but whether it is a
good start.  If the consensus is that this is an acceptable starting
point, which repository does saag like to use for work-in-progress
documents?  I've noticed that the TLS WG now has a git repository,
is there anything similar for saag?

What should the draft be called?  The metadata is tentatively:

    <rfc category="info"
	 docName="draft-dukhovni-opportunistic-security-00"
	 ipr="trust200902">

-- 
	Viktor.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 15 Jun 2014 22:56:54 +0000

> +   intervention when key continuity fails.

That's good for me.

>	 docName="draft-dukhovni-opportunistic-security-00"

As good a name as any, although the convention would be "draft-dukhovni-saag-opportunistic-security-00."

-- Christian Huitema

---

From: ianG <[email-masked]>
Date: Mon, 16 Jun 2014 00:49:07 +0100

> not generally scale to authenticating any peer on the Internet.

Well, we don't have that in any of the other systems, either.  As some
might recall, another popular system doesn't scale well beyond credit
card holders.

> judgemental and not essential to make the point.

I'm fine with the phrase left in.  I understand that the words are a nod
and a wink to others who will otherwise kick up a stink.  E.g., from the
alternate Kent document:

   SSH ([RFC4251], [RFC4252], [RFC4253]) makes use
   of a trust on first use (TOFU) approach (aka a leap of faith, see
   below) for server authentication.

But, I agree with other poster, there is nothing 'fragile' about the SSH
method, it works stupendously well within its parameters and its purpose
space.  SSH's record is strong.  If TOFU is 'fragile' the same criticism
can be levelled at the other mechanisms, which work fine only as long as
the system of authentication is working well.  In just about all systems
of authentication, there are 'leaps of faith' where we'd rather we had
better answers.  If TOFU is a leap of faith, its competition is a swan
dive with blindfold.

Let's not let the perfect be the enemy of the good, and let's not let
the argument drift to bickering around terms.

I vote it forward regardless.

iang

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Jun 2014 06:57:12 +0200

> +   intervention when key continuity fails.

Fine.

> 	 docName="draft-dukhovni-opportunistic-security-00"

Also fine.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Jun 2014 07:58:41 +0200

>> not generally scale to authenticating any peer on the Internet.

Just to come back to this point, I like the examination of design
space.  Here's something to keep in mind: we are increasing the number
of devices we have in our homes, and that is an area that at least today
is not well served by X.509-based certificates.  TOFU or something like
it seems more important, because you're not looking for certification
that Eliot Lear is THE Eliot Lear who has paid a few bucks for a cert,
but just that I happen to be the same guy who wanted to configure the
printer/thermostat/refrigerator/... the last time 'round.  And add to
the mix a lack of DNS, use of mDNS/Bonjour, and it really is its own
thing.  Even ssh-style TOFU does serve us well there.  Now a perfectly
reasonable thing to say might be that the fundamental problem is the
lack of unified name space, but rather than waiting for that, perhaps a
few words around this problem space and appropriate solutions might be
useful.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Jun 2014 08:03:05 +0200

Ahem...
On 6/16/14, 7:58 AM, Eliot Lear wrote:
> ....And add to
> thing.  Even ssh-style TOFU does serve us well there.

That should be "... does NOT serve us well there."

---

From: Derek Atkins <[email-masked]>
Date: Mon, 16 Jun 2014 16:11:30 -0400

> judgemental and not essential to make the point.

I think that's a good start. I would reword the last sentence to read:

     Trust on first use (TOFU) key management models (as with saved SSH
     fingerprints and various certificate pinning approaches) provide
     key continuity across multiple sessions but require user
     intervention when key continuity fails.

For the record, I have 285 entries in my SSH known hosts file.  While
not in the millions, it's still a decent sample IMHO.  I find I need to
change keys.... rarely.  And normally only at my own doing so I know to
expect it.  I think I've had to change keys less than a half-dozen
times.

-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

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 16 Jun 2014 20:33:28 +0000

> expect it.  I think I've had to change keys less than a half-dozen

I should perhaps emphasize that the goal of this sentence was not
to claim that TOFU is a poor fit for SSH, but rather that the
approach is not generally suited to all applications.  For example,
I don't see it working well for email...   All in the context of
explaining that we don't have a silver-bullet for Internet-scale
authentication, and so ubiquitous security needs to make authentication
optional.

Should I make it explicit that the remark is intended to suggest
that TOFU is not *universally* applicable to all application domains?
I was hoping to get away with a concise statement for what is a
minor point in an argument that is itself deliberately concise.

I want to stay on focus and not deep-dive into any tangential topics.

-- 
	Viktor.

---

From: Derek Atkins <[email-masked]>
Date: Tue, 17 Jun 2014 13:38:38 -0400

> I want to stay on focus and not deep-dive into any tangential topics.

Fair enough.

I did see another wordsmithing option thrown out (after I sent my
suggestion) that also tends to help in the same direction.

I'm not trying to bog you down in minutia.  Mostly I just want to make
sure that TOFU doesn't get thrown out entirely just because it does
require manual intervention when key continuity fails and because the
the initial contact isn't protected.  As you say there are multiple use
cases for different solutions, and for some use cases TOFU is "good
enough".

Thanks,

-derek

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Tue, 17 Jun 2014 19:08:53 +0000

I think that it IS important to capture in a short paragraph how (1) TOFU differs from "OS" and (2) under what circumstances it is (still) applicable.
Just having a statement such as "TOFU is not generally suited to all applications" will raise more questions than provides answers.
Since we have the experts, the energy, and a couple of good text suggestions, please, let's capture their essence in the document. By doing that we might avoid repeating this debate again and again.
	
Thanks a lot,
Orit.

> -----Original Message-----
> From: saag [mailto:[email-masked]] On Behalf Of Derek Atkins
> Sent: Tuesday, June 17, 2014 10:39 AM
> To: [email-masked]
> Subject: Re: [saag] suggested text for opportunistic definition
>

---

From: Paul Lambert <[email-masked]>
Date: Tue, 17 Jun 2014 12:30:12 -0700

>>> not generally scale to authenticating any peer on the Internet.

TOFU could be secure and scale when we include out-of-band validation.
I also don¹t feel this is black-and-white with ³trust².
As you learn more about a key, it could have more attributes
that would enable different usage models of the key.
This would be a "trust it more as you learn more" model.

>lack of unified name space,
No.  
> but rather than waiting for that, perhaps a

SSH does not require a ³name space².  The hash of the key is a unique
identifier.
Bitcoin does not need a unique name space, it hashes keys.
Keys and hashes of keys are a universally unique name space.

Keys and ids of keys (hash) should come first and subsequent interactions
may associate a name to the key.  This could be by X.509, DNSEC or manual
entry.

Paul

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Jun 2014 22:37:33 +0200

Paul,

> SSH does not require a ³name space².  The hash of the key is a unique

Sure.  Are you proposing that we consider local naming models with that
approach?  NDN has something similar.  FWIW, I am NOT suggesting we
address that in this program.

Eliot

---

From: ianG <[email-masked]>
Date: Tue, 17 Jun 2014 21:49:15 +0100

> I think that it IS important to capture in a short paragraph how (1) TOFU differs from "OS" and (2) under what circumstances it is (still) applicable.

In which case we need to do the same for all systems?  There is a
section at bottom "Terminology" where this might be better placed than
the rather open discussion at top.

> Just having a statement such as "TOFU is not generally suited to all applications" will raise more questions than provides answers.

I agree.  Drop the statement.  It's a designer's issue to decide what
the best method is, surely...  Beyond scope?

> Since we have the experts, the energy, and a couple of good text suggestions, please, let's capture their essence in the document. By doing that we might avoid repeating this debate again and again.

It somewhat depends on whether this document is about TOFU or whether it
is about opportunistic encryption.  I suppose someone could write
another document about TOFU...

While we're at it, on further reading, I think also the phrase 'leap of
faith' should be expunged.  It is a pejorative used by the supporters of
one system to criticise another system.  Problem is, in TOFU there is a
small and tractable leap of faith within the acceptable reach of most
all sysadms, whereas in the competing system there is a religion's worth
of faith which defies rationalisation by any user at the coalface.  The
pejorative backfires.

(Yeah, I know, TOFU was probably a pejorative as well, but I like it, it
sounds much better than others, and has found widespread acceptance.)

iang

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Jun 2014 14:18:38 +0300

> SSH does not require a ³name space².  The hash of the key is a unique

This is incorrect. SSH do require name space. The name space is stored
on the client database where it maps the user interface selection to
the public key of the host (or hash of the public key, but I think all
implementations actually store the full public key).

I.e. when you write "ssh fireball.acr.fi" your ssh client will do
local "database lookup" and find the public key for identifier
fireball.acr.fi, and will get some public key back. Then when it makes
connection to the remote host, it will verify that the public key is
same than what was stored in the local database with the same name I
used on the command line.

If I use command "ssh fireball.kivinen.iki.fi" or "ssh
2001:1bc8:100d::2" it will connect to the same host, but use different
local database identifier when fetching the public key. This database
lookup based on the user interface selection of the user is critical
for the security of the system.

I.e. if I type "ssh fireball", and my search path happens to be
"acr.fi" the client must not do database lookup based on the expanded
"fireball.acr.fi". It must do database lookup based on the identifier
I typed in on the command line, i.e. "fireball", and get public key
based on that. That public key might be the same than what was stored
for the "fireball.acr.fi".

If I use same "ssh fireball" on environment where the dns search path
is for example "hacker.org", the ssh client still needs to use
"fireball" as identifier, not "fireball.hacker.org", so I will notice
when I connect to different host I expected it to connect as it has
wrong key.

So to claim that SSH does not require name space is incorrect, as you
need to have name -> public key mapping on your local setup.

When using GUI the public key is stored to the stored profile or
similar for the host you are connecting to.

For example the clients who do dns lookups and store more keys to the
database than what was given on the command line (like both name user
typed in and the IP-addresses of the hosts), are unsecure and should
not be used, as now local database stores keys which user have not
typed in, but instead trusts data from dns.

Oh, I just noticed openssh seems to be that kind of vulnerable
implementation.

Openssh seems to do dns lookup based on the name user types in and
does dns lookup and stores both the name and IP-address to the
database. I.e. if hacker manages to trick me to connect to
test.hacker.org and returns ip-address of 83.145.195.1 from the dns to
me, and reroutes those packets going to that ip-address to them this
will cause the openssh to store to the database an entry which says
"test.hacker.org,83.145.195.1" as a key with test.hacker.org public
key.

Now if I ever use "ssh 83.145.195.1" (for example because hacker next
broke the dns and I had to revert to ip-address to connect back to
home) they will be able to hijack that connection. I assume it will
connect to my own host at home, and either uses the public key I have
stored on the database or ask me to verify the public key. But instead
hacker can hijack that connection and forward it again to
test.hacker.org and the openssh will happily accept the public key
from there. 

It would be ok to store the both the name typed on the command line
and then add extra selector for the ip-address. The ip-address would
only be used if there are multiple keys for the same host name. I.e.
where you have name like www.iki.fi, which have three ip-address and
three different hosts and three different public keys, so when I
connect to the www.iki.fi first time, and it selects one of the
ip-addresses it stores the www.iki.fi for the key and adds extra
selector saying that this key is for ip-address x out of x,y, and z,
so if I get different key when connecting to www.iki.fi using
ip-address y, it could tell me that.

Openssh seems to have some kind of safeguards against this attacks, as
it seems it will not store the ip-address every time, perhaps it
checks that it will only store ip-address if it is not yet stored to
the database or something, so perhaps it is not that easy to use this
attack.
-- 
[email-masked]

---

From: Paul Lambert <[email-masked]>
Date: Tue, 24 Jun 2014 03:16:47 -0700

>implementations actually store the full public key).

Yes, muddled thinking on my part.  HIP would of been a better example
for showing that it is possible to escape the need for
coordinated name spaces.

Just as a thought experiment - what does SSH look like when
You use IPv6 with a HIT?

Paul