Subject: [dane] Need better opportunistic terminology

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 6 Mar 2014 09:23:23 +0000

The term opportunistic has become the new synonym for 'Good' but it is
being used for many different things.

A) Unauthenticated key exchange

B) Upgrade from plaintext to encrypted without controlling security policy
requiring use of encryption.

C) Silent-fail on bad credentials

D) Silent-success on bad credentials

There are arguments for all of these but I am just watching a presentation
on 'opportunistic encryption' in DANE and I think the term is selling DANE
short.

DNS is an authoritative path for statements about DNS labels. Ergo
authenticated DNS RRs are authenticated statements about them. DANE
provides authenticated statements about security policy and keys. Ergo DANE
cannot support opportunistic encryption because it is policy directed
encryption (i.e. better).

-- 
Website: http://hallambaker.com/

---

From: Joe Touch <[email-masked]>
Date: Thu, 6 Mar 2014 09:03:52 -0800

> On Mar 6, 2014, at 1:23 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> The term opportunistic has become the new synonym for 'Good' but it is being used for many different things.
> 

Fwiw, this is IMO an error since I first introduced BTNS, and I had to clear it up on Wikipedia multiple times. I see nothing opportunistic about this mode as a stand-alone concept. 

I personally don't this the term applies to the modes listed below either. 

One mode you didn't include - that I recall as one of tho first uses of the term opportunistic, and remains the only one I associate with the term. - is the use of a key before either the key or encryption in general has been negotiated and is not the protocol default. (I.e., a little like B but more just start using it then an 'upgrade'. )

Joe

> B) Upgrade from plaintext to encrypted without controlling security policy requiring use of encryption.
> 
> There are arguments for all of these but I am just watching a presentation on 'opportunistic encryption' in DANE and I think the term is selling DANE short.
> 
> DNS is an authoritative path for statements about DNS labels. Ergo authenticated DNS RRs are authenticated statements about them. DANE provides authenticated statements about security policy and keys. Ergo DANE cannot support opportunistic encryption because it is policy directed encryption (i.e. better).
> 
> 
> 
> -- 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 7 Mar 2014 00:44:32 +0000

> being used for many different things.

Since I am the primary perpetrator of the thought crime in question,	:-)
I'd like to explain the term we used, and why, and solicit a better
term if the IETF has a better way of expressing the underlying idea.

Background:

    In the Postfix community, we've historically used the term
    "opportunistic TLS":

	http://www.postfix.org/TLS_README.html#client_tls_may

    to refer to a client that employs TLS encryption without any
    authentication when the server's EHLO response includes STARTTLS.
    In this case the client is willing to otherwise send in the clear,
    and, in fact, will fallback to cleartext when the TLS handshake fails.

In the (new) DANE SMTP draft the terminology section reserves the
term "(pre-DANE) opportunistic TLS" for the above client behaviour.

    http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-07#section-1.1

We introduce a new term (also listed in the terminology section) which is
"opportunistic DANE TLS".

The thought crime in question predates the last summer's pervasive
monitoring disclosures.  The work on the draft began in March 2013,
and the new term was used (correctly or otherwise) from the outset.

So you might ask what was the word "opportunistic" doing in our
avant-garde use of the term "opportunistic DANE TLS"?  The answer
is that as with (pre-DANE) opportunistic TLS, the client is willing
to send in the clear to any server for which no "secure" TLSA
records are available.

Thus, until the happy future when a significant fraction of domains
are DNSSEC signed, and their MX hosts are accompanied by DNSSEC-validated
"secure" TLSA records, in practice the protocol is essentially the
same as with (pre-DANE) opportunistic TLS.  The client employs the
best security level available (including cleartext).

What DANE does is raise the bar, so that for some destinations,
the ones with secure TLSA records, the best available is authenticated
TLS, and this status can be determined in a downgrade-resistant
manner.

I am open to any reasonable terminology that conveys to the user that the
security policy is still "best effort", but when DANE is applicable we can
do better than unauthenticated TLS with cleartext fallback.

So Phillip is quite right that DANE gets us stronger semantics,
but I would argue, that because the actual security posture is
*conditional* on published receiving system capabilities, from the
perspective of the sending system, this is just a "hardened" version
of opportunistic TLS where, for just some destinations not known
to the sender in advance, MITM attacks cannot trivially downgrade
senders to plaintext or compromise transport integrity or
confidentiality.

So in Postfix documentation, we'll still describe the resulting
security as a form of opportunistic TLS (this is how the email
administrator should think about this "hardened" best-effort
security).

    http://www.postfix.org/TLS_README.html#client_tls_dane

In IETF documents, I'm open to anything that aligns reasonably well
with other documents.  We do not mean to cause any confusion.  If
there is a clear precedent or consensus for naming "opportunistic
DANE TLS" in some other way, I for one have no objections.

-- 
	Viktor.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Mar 2014 04:35:06 -0500

Viktor Dukhovni <[email-masked]> wrote:
    > avant-garde use of the term "opportunistic DANE TLS"?  The answer is
    > that as with (pre-DANE) opportunistic TLS, the client is willing to
    > send in the clear to any server for which no "secure" TLSA records are
    > available.

    > Thus, until the happy future when a significant fraction of domains are
    > DNSSEC signed, and their MX hosts are accompanied by DNSSEC-validated
    > "secure" TLSA records, in practice the protocol is essentially the same
    > as with (pre-DANE) opportunistic TLS.  The client employs the best
    > security level available (including cleartext).

And, in particular, I think that "opportunistics TLS" interoperates with
"opportunistics DANE TLS".  The two sides don't have to have to known each
other's policies.

    > So Phillip is quite right that DANE gets us stronger semantics, but I
    > would argue, that because the actual security posture is *conditional*
    > on published receiving system capabilities, from the perspective of the
    > sending system, this is just a "hardened" version of opportunistic TLS
    > where, for just some destinations not known to the sender in advance,
    > MITM attacks cannot trivially downgrade senders to plaintext or
    > compromise transport integrity or confidentiality.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 7 Mar 2014 10:20:27 +0000

> "opportunistics DANE TLS".  The two sides don't have to have to known each

Yes.  This is quite common.  Servers generally don't know how and
whether clients perform TLS authentication.  The best they can hope
for is that clients find their certificates useful.  I should
however note that opportunistic DANE TLS sends SNI when the server
has TLSA records.  We don't yet know whether there are MTA
implementations which would fail to complete the TLS handshake when
they don't have a certificate with an exactly matching name.  The
draft requires servers to continue with a suitable default certificate
if no SNI match is found.

Since the draft precedes any significant deployment of SMTP servers
with TLSA records, one can hope that server operators will not
publish TLSA records if their server is "allergic" to "opportunistic"
DANE TLSA clients (really SNI hints that turn out to not match any
certificate configured on the server).  Thus far no such servers
have been observed, but the number of deployed clients and servers
is still quite small.

I am not aware of any MTAs that support server-side SNI, but this
could be mere ignorance.  If some do, those might be the ones that
get unhappy with unexpected SNI signals from clients.  Servers that
have completely ignored SNI to date (e.g. Postfix) will continue to
do so.

Any suggestions for a better name for this mode of operation?

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 9 Mar 2014 19:55:12 +0000

On Sat, Mar 08, 2014 at 12:19:31PM -0700, Peter Saint-Andre wrote:

> [...]
> So if regular folks have any mental association for the word
> "opportunistic", it's something like "selfish and unscrupulous".

Perhaps so, but the draft is written for potential implementors
and to some extent administrators of SMTP TLS security, not so much
"regular folks".  By the target audience, "opportunistic TLS" is
I think already understood in its proper context.

> IMHO, it would be better to use terms like "best effort security" or
> "optimistic security" (as in "we're hoping it's secure but we can't
> make any promises").

The situation calls for a reasonably clear term for a mode of
operation where DANE authenticated TLS is used whenever TLSA records
are published via DNSSEC, with fallback to opportunistic TLS otherwise.

The result is in a way doubly "opportunistic".  Not only is DANE
employed when possible (downgrade-resistant modulo DNSSEC compromise),
but when DANE is not applicable, unauthenticated TLS is employed
when possible (passive attack resistant, but vulnerable to MITM
attacks).  This said the intent is that the modifier "opportunistic"
is to be understood to apply to "DANE".  For example, Postfix also
implements a "dane-only" security policy that can be used to insist
on DANE security.  This latter security policy is described as
"mandatory" rather than "opportunistic".

So while I am quite open to using better terminology, nothing
obvious comes to mind.   I don't think that "optimistic" is closer
to the mark.  The optimist might assume there are no attackers and
always send in the clear.  Doing best effort crypto to the extent
of hardening STARTTLS against MITM attacks is, if anything, a
somewhat pessimist/realist view of the security of the Internet.

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 11 Mar 2014 17:53:25 -0400

Joe,

> On Mar 6, 2014, at 1:23 AM, Phillip Hallam-Baker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Fwiw, this is IMO an error since I first introduced BTNS, and I had to 
> clear it up on Wikipedia multiple times. I see nothing opportunistic 
> about this mode as a stand-alone concept.
The original use of the term appears to be from RFC 4322, Micheal 
Richardson's document.
He describes how to use keys retrieved from the DNS with IPsec/IKE, 
without prior, bilateral
arrangements for access control, via the SPD. He defined OE that way, 
and noted that it was
not an unauthenticated mode of IPsec. I prefer that we stick with that 
definition of the term,
which is IPsec-specific. I have suggested "opportunistic keying" as a 
preferred term, since
its the key management, not the encryption per se, that distinguishes 
other proposed modes of
operation for IPsec, TLS, etc. The breakout group at the STRINT workshop 
that discussed terminology
suggested using the term noted above.

Steve

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Mar 2014 15:12:35 -0700

Hi, Steve,

On 3/11/2014 2:53 PM, Stephen Kent wrote:
> The original use of the termappears to be from RFC 4322, Micheal
> Richardson's document. He describes how to use keys retrieved from
> the DNS with IPsec/IKE, without prior, bilateral arrangements for
> access control, via the SPD. He defined OE that way, and noted that
> it was not an unauthenticated mode of IPsec.

RFC4322 defines OE.

Section 1.2 describes "anonymous encryption" which is basically 
unauthenticated key exchange.

 From later in that section:

    Although it is a useful mode, anonymous encryption is not the goal of
    this project.

Michael and I discussed the difference between the two (OE and anonymous 
encryption) on many occasions, and I don't think either of us ever 
confused the two (though someone who edited Wikipedia did once). The 
sentence above confirms that, AFAICT.

 > I prefer that we stick
> with that definition of the term, which is IPsec-specific.

I'm not quite sure what term or what definition you're referring to: OE, 
anonymous encryption, or unauthenticated key exchange. Can you clarify?

> I have
> suggested "opportunistic keying" as a preferred term, since its the
> key management, not the encryption per se, that distinguishes other
> proposed modes of operation for IPsec, TLS, etc.

I agree if you're replacing OE with OK ;-)

> The breakout group at the STRINT workshop that discussed terminology

Sorry, but to clarify, which term?

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Mar 2014 15:29:51 -0700

> Hi, Steve,
....
> I agree if you're replacing OE with OK ;-)

One clarification: I don't see the use of unauthenticated keying as 
opportunistic in any sense of the word.

Opportunistic would mean making an assumption that might be wrong, but 
when it's right it saves time/effort.

There's no savings here; by using unauthenticated key exchange, you're 
really just lowering the bar.

That said, I don't like the term "anonymous encryption" because it 
implies identity hiding, which isn't the purpose either.

Why not just use the term "unauthenticated encryption", when that's 
exactly what's happening?

Joe

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Mar 2014 20:20:57 -0400

> and, in fact, will fallback to cleartext when the TLS handshake fails.

I think that this term is consistent with rfc4322's use of opportunistic
(IPsec) encryption.

(I clipped the rest, because I have nothing to add)

---

From: Peter Palfrader <[email-masked]>
Date: Wed, 12 Mar 2014 07:27:56 +0100

> exactly what's happening?

There is such a thing as authenticated encryption[1], as in AES GCM for
instance, and what we're doing here is not its opposite.  Thus, I think
calling this "unauthenticated encryption" would be a bad idea.

Cheers,

1: https://en.wikipedia.org/wiki/Authenticated_encryption
-- 
                           |  .''`.       ** Debian **
      Peter Palfrader      | : :' :      The  universal
 http://www.palfrader.org/ | `. `'      Operating System
                           |   `-    http://www.debian.org/

---

From: Tony Finch <[email-masked]>
Date: Wed, 12 Mar 2014 11:37:17 +0000

I am inclined to avoid the word "opportunistic". Judging by the confusion
over the meaning of the word, and the several possible meanings that
people gave at the meeting last week, I don't think its jargon usage is
precise enough to be helpful. And its dictionary meaning has some slightly
unpleasant overtones.

How about the straightforwardly descriptive terms "unauthenticated
STARTTLS" and "DANE STARTTLS"?

STARTTLS implies this is an upgrade from cleartext, which I think you said
last week was one of the concepts you wanted to capture in the phrase. And
unauthenticated vs DANE should suggest the key security difference.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
German Bight: Variable 3 or 4. Smooth or slight. Fair. Good, occasionally poor
later in south.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Mar 2014 22:13:49 +0000

Hiya,

(Bcc'ing dane and saag for reasons that'll become obvious:-)

On 03/11/2014 09:53 PM, Stephen Kent wrote:
> I prefer that we stick with that definition of the term,
> which is IPsec-specific. 

I don't think we need to face any such constraint at all.
We might choose to, but there's no reason our definitions
need to honor previous ones since any use of the OE term
will conflict with someone's understanding. I also don't
want us to end up with IPsec (or TLS) specific terminology.

> I have suggested "opportunistic keying" as a
> preferred term, since

I agree the OK term is better for the reasons you state.
(And Pete Resnick likes the idea of OK protocols:-)

If/when we re-do the MPLS thing we'll move to use that
and I think it'll be useful if other folks do too.

And speaking of terminology, I canvassed a few folks last
week and there was reasonable support for doing the draft
that defines these terms within the UTA WG. So I'd suggest
we move the discussion there if that's ok just to try get
it in one place.

S.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 11 Mar 2014 17:27:52 -0700

]On 3/11/2014 3:12 PM, Joe Touch wrote:
]> Hi, Steve,
]....
]>> I have
]>> suggested "opportunistic keying" as a preferred term, since its the
]>> key management, not the encryption per se, that distinguishes other
]>> proposed modes of operation for IPsec, TLS, etc.
]>
]> I agree if you're replacing OE with OK ;-)
]
]One clarification: I don't see the use of unauthenticated keying as
]opportunistic in any sense of the word.
]
]Opportunistic would mean making an assumption that might be wrong, but
]when it's right it saves time/effort.

Opportunistic keying does provide authentication, it's just that 
the authentication is only to the public key and is not
tightly bound to any other type of identification (address, name, etc.)

The binding of the key to other information useful for access control
decisions is deferred. Other mechanisms are used to associate 
the key with an appropriate access policy.  At this point is
where it seems to get a little trickier to describe a generic model
for multiple protocols. Different applications have different 
identifiers and binding requirements.

I'm assuming the intent generally that the first key discovered 
for a specific context would be bound to that specific usage.
Without some type of pinning of the key to a context we
end up with unauthenticated encryption.

This implies that we will be creating more applications
that display public keys or hashes of public keys. Human
validation of key ownership is always a good security check
(although not always the best user experience).

The definition should be clear on the necessity of the
additional binding and possible check of the key ownership.

One idea for formalization of such opportunistic mechanisms
would be to clearly define the state of the key binding to
it's use in a particular context.  A key newly discovered
and being used for a particular dns address could be
in an invalidated state, while one that was explicitly 
checked in some manner would be in a validated state.

Note - I'm working on protocols for bootstrapping
P2P security that are very close to these discusions. 
Basic design is that all devices have a public 
Key and they are introduced for a particular 
set of communications (service).  In this application
out-of-band channels can be used to support the
introduction (e.g. NFC, QR Code, label on device, dynamic
label on display).  I've been calling aspects of this
bootstrap process 'key centric' versus opportunistic since
we are trying to always have a means to securely bind the
key to the specific usage.  Keys are the identity and
are maintained in ACLs and groups for access control.

Usability concerns in products will introduce 
implementations that are more promiscuous and 
connect opportunistically with minimal human interaction.

The different types of security policies that this creates
is a problem in that it lacks clear user oriented definitions.
Right now, in the Wi-Fi industry the terminology is 
either 'open' or 'encrypted' (aka WPA2).
Now there will be new modes like: encrypted but 
anyone can connect (e.g. open printer kiosk).

I suspect that that this differentiation in policies
will also occur in other uses of opportunistic encryption.

Paul

]
]There's no savings here; by using unauthenticated key exchange, you're
]really just lowering the bar.
]
]That said, I don't like the term "anonymous encryption" because it
]implies identity hiding, which isn't the purpose either.
]
]Why not just use the term "unauthenticated encryption", when that's
]exactly what's happening?

]
]Joe
]
]_______________________________________________
]saag mailing list
][email-masked]
]https://www.ietf.org/mailman/listinfo/saag

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 Mar 2014 09:35:15 -0400

Joe,

> ...
> I'm not quite sure what term or what definition you're referring to: 
> OE, anonymous encryption, or unauthenticated key exchange. Can you 
> clarify?
OE. I argue that OE is defined only for IPsec, because the definition 
focuses on how to
avoid the need to coordinate SPD entries at each end.
> I agree if you're replacing OE with OK ;-)
yeah, I like OK (and I like IKE too, for those of us old enough to
appreciate that election slogan)
> Sorry, but to clarify, which term?
OK vs. OE.

Steve

---

From: Tony Finch <[email-masked]>
Date: Wed, 12 Mar 2014 13:44:15 +0000

Viktor Dukhovni <[email-masked]> wrote:
> attacks).

I think what you are describing is just protocol feature negotiation and
so it does not need a special term. We don't talk about opportunistic
cipher suites, for example.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle: Southwesterly veering westerly 5 to 7, but 4 at first in southeast,
perhaps gale 8 later in west. Moderate or rough, occasionally very rough in
northwest. Rain later. Moderate or good.

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Mar 2014 09:49:16 -0700

Steve (et al.),

> avoid the need to coordinate SPD entries at each end.

Agreed.

> appreciate that election slogan)

I'm still a little hesitant, thinking on it further, about the term 
"opportunistic" in this sense at all.

BTNS uses unsigned key exchanged, and there's nothing "opportunistic" 
about it. Unsigned authentication is the goal from the start.

OE as defined in RFC 4322 isn't about using unsigned key exchange; the 
"opportunistic" sense is derived from using keys retrieved from DNS 
without prior agreement. That's not what happens in BTNS.

Paul just noted:
"Opportunistic keying does provide authentication, it's just that
the authentication is only to the public key and is not
tightly bound to any other type of identification (address, name, etc.)"

I.e., fundamentally, opportunistic approaches are completely different 
from those that don't ever bother to authenticate. I don't think it's 
useful (and could be confusing) to confuse the two by overlapping 
terminology.

I don't like the term "optimistic" either; it too implies something that 
you "hope works". There's no "hope" associated with unsigned key 
exchange; you do it (IMO) because you know what it is and you know its 
impact (e.g., raising the bar of an attacker to performing a full key 
exchange, vs. just tossing single packets like RSTs around).

Is there a reason not to just call unauthenticated key exchange what it 
is - unauthenticated key exchange?

If you want something pithy, maybe "Zero-ID security"?

>> Sorry, but to clarify, which term?

Thanks for the clarification.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Mar 2014 17:04:02 +0000

(again, I'd suggest one list for this if we can and the
UTA wg list, but hopefully that'll settle down when there's
an I-D, and since I'm not the boss of us anyway...:-)

> "opportunistic" in this sense at all.

I do think we want to define that term even if we do not
want to encourage its use. It is being used and with
subtly different meanings by different folks.

> is - unauthenticated key exchange?

Yes. "authenticated encryption" is a term of art (AEAD etc) and
this would be confusingly close - it'd be inevitable that some
would end up saying unauthenticated encryption and thereby would
confuse the real crypto folks.

I like the OK term myself and would be happy if we landed on
encouraging its use, based on a good definition.

But I'm fine if we end up calling it squiggle, so long as we
all end up calling the same "it" that.

> If you want something pithy, maybe "Zero-ID security"?

Too close to zero-touch (which is not ad-hominem, but is
a term being used in netconf - Joe you just *have* to get
involved in that:-)

S.

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Mar 2014 12:06:01 -0500

>> appreciate that election slogan)

OK will present difficulties as an acronym...  Otherwise I like
"opportunistic keying", but it could cover a large range of behaviors
(e.g., TOFU).

> BTNS uses unsigned key exchanged, and there's nothing "opportunistic" about
> it. Unsigned authentication is the goal from the start.

For me the goal was to use channel binding at the application layer.
But we never got there: no one seems to care much about end-to-end
IPsec, sadly.  (Well, it's not that no one cares, but that it's too
late now; TLS is king.)

> "opportunistic" sense is derived from using keys retrieved from DNS without
> prior agreement. That's not what happens in BTNS.

Stephen has it right: OE in the RFC4322 sense is about applying
protection even when SPDs don't agree on this, but it still requires a
keying infrastructure (i.e., trust paths).

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Mar 2014 10:30:49 -0700

...
> For me the goal was to use channel binding at the application layer.

Having unsigned key exchange has two ultimate uses:

	- raising the bar for attacks
		above 'send a RST' but below MITM

	- providing a network-level mechanism that can be linked
	to security at higher layers

App-layer channel binding could be useful for BTNS, or for other 
approaches too (e.g., where a single key protects a set of ports).

> IPsec, sadly.  (Well, it's not that no one cares, but that it's too

TLS still doesn't protect the transport or network layers.

> keying infrastructure (i.e., trust paths).

Right, but then "O" isn't quite the right term for security that avoids 
the need for keying infrastructure altogether.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Mar 2014 13:28:42 -0700

On 3/12/2014 1:02 PM, Derek Atkins wrote:
> Joe Touch <[email-masked]> writes:
>
> Well, it's not necessarily what's happening.  The data itself might
> still have "integrity protection" (which is a form of authentication.

Yes, and might be inaccessible to anyone except the endpoints that 
negotiated the key too.

So you have a protected exchange both in privacy and integrity, but you 
don't know with whom.

> You're just not authenticating the endpoint, which means you could be
> subject to a MitM attack.  Alternate terms could be "Unauthenticated
> Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to
> what's going on.

Sure - yes, but neither acronym is desirable, unfortunately.

Unidentified Security?

Joe

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Mar 2014 16:47:17 -0400

> calling this "unauthenticated encryption" would be a bad idea.

+1
and, the privacy that results from the encryption, while the primary carrot,
is simply the result of finding a way to do a DH operation.  The part that
we are all discussing is determining how (much) to trust the DH results.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Mar 2014 20:53:06 +0000

Hi Michael,

On 03/12/2014 08:47 PM, Michael Richardson wrote:
> The part that we are all discussing is determining how (much) to
> trust the DH results.

I don't think that's a very accurate characterisation
to be honest.

I think the most relevant (but intertwined) factors are:

- - trading off ease of deployment vs. endpoint authentication
- - trading off protection against passive vs active attack
- - better separating key exchange from endpoint authentication
  so that traditional authentication or TOFU or whatever can
  be used before during or after key exchange

S.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Mar 2014 17:13:38 -0400

> - trading off ease of deployment vs. endpoint authentication
    > - trading off protection against passive vs active attack
    > - better separating key exchange from endpoint authentication

But, you made my point.

While the end user sees the overall benefit is:
      my traffic can not seen

The problems and challenges that we have are not in how or even when to
apply AES, it's how/when to do the DH.

To the end user, having the word "encryption" in the terminology is useful
because it tells them why they should pay attention to it.

To us, it's a red-herring, because it's not where the issue is.
You listed the issues.

(BTW: my TLA cache is failing on "TOFU")

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Mar 2014 21:46:48 +0000

Hiya,

On 03/12/2014 09:13 PM, Michael Richardson wrote:
>>> The part that we are all discussing is determining how (much)
>>> to trust the DH results.
> 
>> I don't think that's a very accurate characterisation to be
>> honest.
> 
>> - trading off ease of deployment vs. endpoint authentication -
>> trading off protection against passive vs active attack - better
>> separating key exchange from endpoint authentication so that
>> traditional authentication or TOFU or whatever can be used before
>> during or after key exchange
> 
> But, you made my point.

Well yes and no, we're agreeing and almost but not quite
discussing the same things I figure, let's see if that
continues... :-)

> While the end user sees the overall benefit is: my traffic can not
> seen
> 
> The problems and challenges that we have are not in how or even
> when to apply AES,

Agreed.

> it's how/when to do the DH.

"How" to do DH is pretty much the same everywhere or at least
the diffs are not relevant for a generic terminology draft.

"When" is I think as-soon-as-you-can (modulo amortizing DH over
multiple "sessions" or similar).

I think our challenges are not in when to do DH but in how that
relates to when we might do what forms of endpoint authentication
(or none) and the consequences of each of those options.

That's why I think a generic terminology draft will be useful, as
there are lots of potential combinations. Naming each (or whatever)
will make it easier for protocol developers to argue about what's
suitable for their particular environments.

For example, in the limit, I think it'd be worth thinking about
whether a post-facto MITM detection protocol perhaps run a day or
two later might have value. That'd be more of a research topic
really, but could still represent a form of useful endpoint
authentication even if it only detected a MITM with say a 1%
probability. Think of Alice and Bob depositing a witness pair
derived from the DH secret and some HASH(shared-info + application
traffic) some place(s) so someone (else) could detect if there
was a Charlie in the middle. (BTW: I'm not sure such a useful
generic protocol exists, but it'd be fun to work it out.)

> To the end user, having the word "encryption" in the terminology is
> useful because it tells them why they should pay attention to it.

Good point. Maybe that's why folks keep coming back to OE
as a term.

> To us, it's a red-herring, because it's not where the issue is.

Also true.

Cheers,
S.

> -- Michael Richardson <[email-masked]>, Sandelman Software
> Works -= IPv6 IoT consulting for hire =-
> 
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 Mar 2014 17:47:09 -0400

Joe,
> without prior agreement. That's not what happens in BTNS.
agreed.
> tightly bound to any other type of identification (address, name, etc.)"
Public keys are not principles. We went through that long and painful 
discussion
during the SPKI days. So, saying that OE provide authentication of a key 
seems
meaningless to me, especially if the key is ephemeral.
> useful (and could be confusing) to confuse the two by overlapping 
We'll, we don't have an agreed upon definition for O* yet. My view is 
that the primary goal of
this effort is to remove barriers to using encryption. Since 
authenticating the identity or a
peer or server has tended to be a barrier, we seem willing to make that 
form of authentication
optional. But, we still prefer authentication, because we'd like to 
avoid MiTM attacks. That suggests
that O* refers to techniques that emphasize encryption, prefer that it 
be authenticated, but are
willing to fall back to un-autnenticated encryption if that's thbe best 
we can do. (And to fall back
to plaintext if the peer/server is not capable of our new-fangled O*)
> I don't like the term "optimistic" either; it too implies something 
> that you "hope works". There's no "hope" associated with unsigned key 
I'm not wedded top either term, but I'd like to emphasize that the 
encryption process is
the same in all cases; it's the key management that's different.
>
> Is there a reason not to just call unauthenticated key exchange what 
> it is - unauthenticated key exchange?
I think we want more than that, as I described above, hence the desire 
to coin a new term.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 Mar 2014 17:56:09 -0400

Stephen,

> an I-D, and since I'm not the boss of us anyway...:-)
This is a broader topic than TLS, as later messages from Joe indicated, so
I don't think UTA is the right place for this discussion.

Steve

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Mar 2014 14:59:34 -0700

Steve (et al.),

On 3/12/2014 2:47 PM, Stephen Kent wrote:
...
> I think we want more than that, as I described above, hence the desire

No disagreement; there seems to be a need then for two terms:

	1. unauthenticated key exchange/use

	2. security that uses authentication when available,
	but allows unauthenticated methods as a backup

Personally, I'd call the first "zero-ID" (yes, FWIW, the similarity to 
'zero-touch' was intentional), and the second "zero-ID fallback".

I'm not wed to either term, but "opportunistic" doesn't seem useful 
because OE seems to me a lot more like "use this key and hope it works", 
which isn't part of either case above.

Joe

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 13 Mar 2014 00:37:52 +0000

On Wed, Mar 12, 2014 at 02:59:34PM -0700, Joe Touch wrote:

[ It seems the discussion has moved on beyond the specifics of the title of
  the SMTP with DANE draft: "SMTP security via opportunistic DANE TLS".  So
  if anyone has a considered proposal for a better name, please start a new
  thread on the DANE list only, or just send me your suggestions off-list. ]

> 	but allows unauthenticated methods as a backup

Moving beyond the SMTP with DANE use-case, the space for SMTP alone
is definitely larger than just two cases.  For example, with email,
we have:

    0. Opportunistic TLS.

	What's opportunistic here is not the key management (long-term
	keys are not used or ignored), but the *use* of TLS.  If
	the server EHLO response includes STARTTLS, TLS is attempted,
	otherwise not.

    1. Mandatory unauthenticated TLS (similar to 1. above).

	http://www.postfix.org/TLS_README.html#client_tls_encrypt

       Use of TLS is not opportunistic, the transmission channel
       is always encrypted.  However as with "0." there is no
       authentication.

    2. Opportunistic use of authenticated TLS (e.g. via DANE) with
       fallback to "0." when the destination authentication policy
       is not available. 

	http://www.postfix.org/TLS_README.html#client_tls_dane
	(with the "dane" security level)

       Here when "usable" secure TLSA records are published,
       the server is always authenticated.  But otherwise, we
       do our best to at least not send in the clear.

    3. Mandatory authentication:

	http://www.postfix.org/TLS_README.html#client_tls_fprint
	http://www.postfix.org/TLS_README.html#client_tls_secure
	http://www.postfix.org/TLS_README.html#client_tls_dane
	(with the "dane-only" security level)

       Similar to HTTPS, but no user to click OK, so deployment is limited
       to small set of administrator designated destinations.

    4. Audit-only authentication (on the drawing board for Postfix):

       An attempt is made to authenticate the peer with the
       administrator selected policy (2 when destination policy is
       known or one of static policies in 3).  Authentication
       results are logged, but mail delivery proceeds even when
       authentication fails.  The failure mode can be configured
       to either "0." or "1."

There are of course additional models (TOFU, Tack, ...)

So perhaps a small list of terms (nouns or noun-phrases) will not
cover all the models in a generic way.  We can however provide some
guidance on the appropriate use of some popular "adjectives", to
encourage people to use them in a more appropriate, consistent
fashion.

My contention is, for example, that the use of "opportunistic" in
"opportunistic TLS" to describe TLS in case "0" is a proper use of
that adjective.  Similarly "opportunistic DANE TLS" for case "2"
is also reasonable.  By way of contrast one might speak of "mandatory
TLS", "mandatory DANE TLS", ...

Finally, the terminology is the least of our worries, lets get more
of the security protocols deployed!

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Mar 2014 22:27:46 -0400

I don't particularly mind what the definition is, provided I can know what
the speaker means by it. Which right now I don't. I am quite happy if we
defer the definition of what OE is until we have decided what to do and
then decide that that is OE by definition.

Some terms that come to mind for encryption using credentials that are not
authenticated:

Faith-Based Encryption
Passive Protection
Junk Encryption (cf Junk bonds which are worth a lot more than zero but a
lot less than par)

---

From: Derek Atkins <[email-masked]>
Date: Wed, 12 Mar 2014 16:02:29 -0400

> Joe

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Paul Lambert <[email-masked]>
Date: Wed, 12 Mar 2014 18:14:18 -0700

On 3/12/14, 2:47 PM, "Stephen Kent" <[email-masked]> wrote:

>during the SPKI days.

Your level of pain in a discussion is not a measure of a concepts validity
:-) 

Public keys and the hashes of public keys are the fundamental identifier
of a Œprincipal¹ when we are using public key based authentication. The
principal is the end user or computer that controls the use of the public
key.  The public key is authenticated in a key exchange or signature
validation process and is the primary connection in the process to the key
holder (principal).  Other information may be associated with the key
locally or through a trusted path (out-of-band, signed, etc.) that can be
used for authorization decisions.  The other information may even include
information associated with the key in a X.509 or other form of
certificate.

The public key and associated key hash for a principal may change.
Changing keys could be viewed as either a new identifier for the same
principal or a new principal with the same associated attributes as a
previous principal.  Either way, the public key (or hash) is a unique
identifier of a principal which can then be usefully processed in a
security policy.   

There are several usages of ³opportunistic² in this thread.  Clearly new
terms are needed.  I¹m primarily interested in Œkeys as identifiers¹ where
longer term keys are used to identify principals. Security policies are
built on hashes of keys and optionally other associated information that
may include names, labels, group membership, etc.

This may be getting a little far afield of the TLS-DANE or IPsec
opportunistic specific usage.  Still, the deferred binding and the TOFU
model are compatible with a perspective of keys as identifiers of
principals.

>So, saying that OE provide authentication of a key
>seems
Yes, ephemeral keys do not provide any long term identity. This can also
be a feature.  A Œprincipal identifier¹ with no associated information
would only be authorized for actions that have no restrictions on specific
principals.  

Paul

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 12 Mar 2014 17:28:48 -0400

> (BTW: my TLA cache is failing on "TOFU")

Trust on First Use (aka the SSH Model).
A step up from completely unchecked DH, but a step below DANE or
Certificate Validation.

-derek

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Mar 2014 21:59:00 +0000

Sure, that's arguable.

My main reason for suggesting UTA is that I figure its
drafts will have more/soonest dependencies on the
terminology draft.

However, if folk prefer saag, for now at least that's
fine. But let's drop the cross-posting to dane then
please? (Which I bcc'd)

S.

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Mar 2014 19:48:46 -0500

>   thread on the DANE list only, or just send me your suggestions off-list. ]

It has moved beyond SMTP w/ DANE because we actually need general
terminology for some of these behaviors.

>        do our best to at least not send in the clear.

Right, we should distinguish "authenticate with TLS server PKI" from
authenticate via DANE".

> TLS", "mandatory DANE TLS", ...

No argument from me.  You're right too that we're going to compose two
or more words.

> of the security protocols deployed!

Well, you'd be surprised.  Terminology makes a huge difference 'round
these here parts.  In this particular space we have a chance to define
generic terms because a lot of the behaviors in question are new(ish).
 Sounds like a huge win to me!

Nico
--

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 13 Mar 2014 08:59:12 +0100

> Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to

To get any movement in this area among developers and sysadmins, 
we need a language that any sysadmin or developer understands. 
I believe we can easily get them to understand "Opportunistic encryption"
but if we go into explaining "keying" or "key exchange" they will be lost in 
the OpenSSL documentation maze again.

We might have to separate a "marketing name" of the overall concept
from a set of technical definitions we can refer to when explaining this in
RFCs. For me, I can happily accept using OE as the unclear marketing
bullshit term for a set of solutions that set up an encrypted communication
channel - regardless of URI or configuration, without any indication to
the user in the phone UI or browser UI - no locks!

I can understand that this may be hard to accept in a technical community, but
we have a huge educational effort ahead of us in order to get this done.
The general concept has to be easy to explain.

In summary, I propose that we keep OE as the overall term and define
a set of more precise terminology to explain what goes on in the background.
As Victor pointed out, there may be different solutions in different
protocols.

As a side note:

https://tools.ietf.org/html/rfc5630

Use the term "best-effort TLS" to describe that a SIP ua is perfectly
allowed to set up a TLS session based on policy regardless if there
is a "sips:" URI. I don't know where that terminalogy came from. It's
always used with quotation marks in the RFC. This "best-effort TLS"
still requires verification of the certificate though.

Cheers
/O

---

From: Tony Finch <[email-masked]>
Date: Thu, 13 Mar 2014 12:48:45 +0000

Viktor Dukhovni <[email-masked]> wrote:
> that adjective.

I think a better phrase would be "negotiated unauthenticated TLS".
(Or "unauthenticated STARTTLS" since STARTTLS implies negotiated TLS).
"Opportunistic" implies that someone is taking advantage of someone else
to their detriment, whereas SMTP TLS is by mutual agreement.

> Similarly "opportunistic DANE TLS" for case "2" is also reasonable.  By
> way of contrast one might speak of "mandatory TLS", "mandatory DANE
> TLS", ...

The mandatory cases are where the postmaster has overridden normal
protocol negotiation, which implies that they should get a weirder name
than the normal negotiated cases.

Postfix's use of "opportunistic" is a bit weird. Sendmail and Exim do not
use the term, though Microsoft Exchange does.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon: South or southeast 3 or 4, veering southwest 4 or 5 later. Moderate
or rough. Fair. Moderate or good.

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Mar 2014 08:08:28 -0700

> the OpenSSL documentation maze again.

The problem is that OE isn't what's going on when you simply choose not 
to authenticate keys. Yes, it's a simple term, but it's also an 
incorrect one.

I appreciate the desire to find a cute marketing term, which is why I 
offered "zero-ID" - which is more accurate and easier to explain to 
developers and sysadmins (what do you *do* to make OE? it's easy to make 
zero-ID - you stop using IDs).

I'm not wed to that term, but market-speak is your metric, OE fails on 
multiple counts.

> still requires verification of the certificate though.

That's similar reasoning as to why I don't like OE.

Joe