Subject: [saag] The floor on OS (Re: new terminology ID posted)

From: Nico Williams <[email-masked]>
Date: Mon, 7 Apr 2014 14:43:50 -0500

On Mon, Apr 7, 2014 at 2:09 PM, Nico Williams <[email-masked]> wrote:
> On Mon, Apr 7, 2014 at 9:14 AM, Stephen Kent <[email-masked]> wrote:
>> I was not asking for a consensus call, yet. And, even if I were, the
>> issue is not whether DANE-enabled TLS is good or bad (I think it';s
>> very good) but whether it will be included in a definition of OS.
>
> OK, so let's define OS.  My definition:
>
>     You get the strongest security in the Internet threat model that
> can be obtained, and you get as strong a floor on security in the
> Internet threat model as that which you can securely discover, else
> the floor may be as low as protection only against passive attacks.

It's hard to overstate the importance of having the floor strength be
variable _and_ that when the floor is strong you have no fallback on
weaker levels of security.  So, new thread.

Floors:

 - no security whatsoever (everything sent in cleartext);

 - unauthenticated key exchange (note that RSA key transport can do
this), which obtains protection against passive attackers;

   It goes without saying that keys are exchanged so they can be used
for authenticated encryption and possibly for channel binding (or
other MITM detection schemes), so I won't repeat this below.

 - unauthenticated key exchange w/ TOFU/LoF/TACK/pinning, which
obtains protection against passive attackers and forces MITMs to
remain in the middle for longer than they might be prepared, willing,
or able to;

   There is the risk that forcing a capable MITM to always be in the
middle causes further disclosures to them.  But having fallen victim
to an MITM once this seems like a small additional risk.

 - authenticated key exchange.

Authentication can be done in any number of ways, from DNSSEC-based to
PKI-based, to web of trust-based.  If one does TOFU/LoF then on
subsequent exchanges we have a form of authenticated (pseudonymous)
key exchange.

"Opportunistic" necessarily means that the floor that one gets might
be very low strength.  But it must not mean that a fallback on
low-strength is always required.  We'd be doing a great disservice to
the public if required fallback to the lowest floor in all
circumstances!

We must allow for discovery of floor strength for specific peers.

TOFU/LoF, TACK, pinning -- these are technologies for setting the
floor in the future to be no lower than today (modulo expiration,
...).

PKI (DNSSEC or x.509/PKIX) is a technology for discovering the lowest
floor in the present.

DNSSEC/DANE in particular is a technology for out-of-band high floor
discovery, which therefore strongly indicates that fallback on lower
strength floors should be NOT permitted.

DNSSEC is a PKI of sorts however, with all the problems that that
implies.  This is a reason to expect some pushback on DNSSEC-based
solutions.  If one does not trust the DNSSEC PKI then either one must
not use DANE or one must require the use of other technologies (e.g.,
TOFU/LoF) in addition to DANE to add a measure of security.

Allowing the floor to rise as possible -and to stay strong- is critical.

Aside #1: Channel binding is no help if there's not a separate,
higher-layer authentication mechanism to take advantage of it.

Aside #2: Any technology that requires persistent local storage (e.g.,
TOFU/LoF, TACK/pinning) may fail to be usable on highly constrained
devices, but that's very much a side issue.  Mobile devices today have
plenty of persistent storage.  Embedded devices mostly don't really
need to speak to potentially any peer on the Internet, so PSK or
similar are generally good enough for them.

Nico
--

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Mon, 7 Apr 2014 20:21:31 +0000

In UTA, we have spent numerous email cycles discussing how different (supporting) techniques relate (or not) to the "opportunistic" concept. The level of mutual understanding and agreement that we have achieved is still to be seen in the next round of UTA drafts.
So...I can see a lot of value in capturing the concepts/cases listed below in a single protocol-independent document under the general security area.

Thanks,
Orit.

> -----Original Message-----
> From: saag [mailto:[email-masked]] On Behalf Of Nico Williams
> Sent: Monday, April 07, 2014 12:44 PM
> To: Stephen Kent
> Cc: [email-masked]
> Subject: [saag] The floor on OS (Re: new terminology ID posted)
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Apr 2014 09:57:25 -0400

Nico,
> On Mon, Apr 7, 2014 at 2:09 PM, Nico Williams<[email-masked]>  wrote:
>> On Mon, Apr 7, 2014 at 9:14 AM, Stephen Kent<[email-masked]>  wrote:
you have my feedback on that definition in my previous reply.
> weaker levels of security.  So, new thread.
another not easy to comprehend comment ...
> subsequent exchanges we have a form of authenticated (pseudonymous)
I have no objection to the ordered list of options you provide above.
I don't agree that the term "pseudonymous" is appropriate above. In
many (most?) TOFU/LoF contexts the asserted identity is not pseudonymous.
> the public if required fallback to the lowest floor in all
I would not suggest fallback to the lowest floor as a goal, but
rather recognize it as a possible outcome depending on the context.
> We must allow for discovery of floor strength for specific peers.
that's nice, but if discovery adds to RTTs, it's not a good prerequisite.
I think

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Apr 2014 10:36:30 -0400

Nico,
> ...

yes, RSA key transport can do this, if the keys are sent w/o binding
to identities. But D-H seems preferable, especially if we want to promote
PFS.
> other MITM detection schemes), so I won't repeat this below.

OK.
> remain in the middle for longer than they might be prepared, willing,

agreed, but TOFU/LoF/pinning all pose problems when key change is needed,
and often they assume a human user in the loop. thus they may not be
viewed as fundamental aspects of all OS proposals, of even universally
applicable next steps in an incremental list,, such as the one you have
constructed here.
> to an MITM once this seems like a small additional risk.

can't parse these two sentences.
> subsequent exchanges we have a form of authenticated (pseudonymous)
I would not mix Web PKI and DNSSEC (DANE?) based mechanisms too
freely with TOFU/LoF. Pinning is an appropriate mechanism to detect
a change in credentials that may indicate a security problem when using
the 3 sources of authenticated keys you noted.

> the public if required fallback to the lowest floor in all

Agreed. not in all circumstances, but in some, if we believe universal
interoperability also is a requirement.
> We must allow for discovery of floor strength for specific peers.

"must" is a bit strong here. if what you mean is that IF one can
discover the security capabilities for a given peer, and IF one
remembers what has been discovered, and IF a peer never regresses,
then we can prevent future downgrade attacks while using OS.  it what
what you mean by must?
> floor in the future to be no lower than today (modulo expiration,

agreed, but expiration and key compromise are nasty details
that we cannot ignore.
> PKI (DNSSEC or x.509/PKIX) is a technology for discovering the lowest
Not sure what you mean here. the Web PKI in the HTTPS environment
is based on credentials passed for every session. So, what you knew
yesterday and what you learn today may differ. DANE may operate the
same way, unless clients maintain state for previously discovered
TLSA records. We can explore the notion of clients maintaining state
for certs and TLSA records, but do we believe we should mandate this
now?
> strength floors should be NOT permitted.
agreed.
> TOFU/LoF) in addition to DANE to add a measure of security.
yes, DANE is PKI-like, and with any PKI if you don't trust he CAs,
life is very messy.

So, is your bottom line that OS can offer better than plaintext fallback 
under
certain circumstances, like the ones discussed above? if so, we have no 
disagreement.
but, we also have to recognize that any universal statement about OS 
must encompass
the situation in which not every peer supports OS, and thus the floor if 
plaintext,
unauthenticated communication. So is this just a matter of communicating 
both notions
ion our definition of OS?

Steve