Subject: [saag] 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: Michael Richardson <[email-masked]>
Date: Fri, 07 Mar 2014 04:35:06 -0500

Viktor Dukhovni <[email-masked]> wrote:
    > 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).

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: 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: 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: 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: Peter Saint-Andre <[email-masked]>
Date: Sat, 08 Mar 2014 12:19:31 -0700

> do better than unauthenticated TLS with cleartext fallback.

I think the term "opportunistic" is the problem - most people aren't 
clear on what it means and definitions like this don't really help (from 
Wiktionary):

"taking advantage of situations that arise"

"said of people who will take advantage of situations to advance their 
own interests, without regard for principles"

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

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

Peter

---

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:

> [...]

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 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: 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: Michael Richardson <[email-masked]>
Date: Tue, 11 Mar 2014 20:23:07 -0400

> I think the term "opportunistic" is the problem - most people aren't clear on
    > what it means and definitions like this don't really help (from Wiktionary):

    > "taking advantage of situations that arise"

This definition works just fine.

    > "said of people who will take advantage of situations to advance their own
    > interests, without regard for principles"

my interest is securing email, and I don't care for any "national security"
concerns.  Sounds right to me :-)

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

    > "optimistic security" (as in "we're hoping it's secure but we can't make any
    > promises").

I accept that maybe the general public needs a friendlier term.
s/opportunistic/optimistic" has the nice advantage that many other acronyms
might not change... :-)

---

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: 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 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: Derek Atkins <[email-masked]>
Date: Wed, 12 Mar 2014 16:02:29 -0400

> exactly what's happening?

Well, it's not necessarily what's happening.  The data itself might
still have "integrity protection" (which is a form of authentication.
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.

> Joe

-derek

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

---

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

> 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.

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

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

> 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.

+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: "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: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:54:23 -0400

Joe,

...
> above 'send a RST' but below MITM
whether this feature accrues depends on the layer at which we provide the
O* technology. IPsec addresses this issue, TLS does not, tcpcrypt does, ...
> to security at higher layers
In this case you explicitly say network layer, but the discussion has 
been broader than that.
> TLS still doesn't protect the transport or network layers.
right, but that doesn't mean it's not useful. Operating above the 
transport layer
avoids NAT problems, for example.

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: Nico Williams <[email-masked]>
Date: Wed, 12 Mar 2014 16:57:46 -0500

On Wed, Mar 12, 2014 at 4:54 PM, Stephen Kent <[email-masked]> wrote:
> right, but that doesn't mean it's not useful. Operating above the transport
> layer

And mobility, if one is willing to use UDP a-la mosh or DJB's
MinimaLT, or frequently reconnect TCP.  Either way the app protocol
needs reworking to do that, but it's becoming common to do this sort
of thing instead of relying on lower layers for security and mobility.
 Frankly, I can't fault app developers for doing things this way!

Nico
--

---

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: 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: Joe Touch <[email-masked]>
Date: Wed, 12 Mar 2014 15:00:53 -0700

Agreed on all points; I was giving an example in the context of BTNS, 
and I agree that it's useful here to find a term that doesn't assume a 
particular layer.

Joe

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Mar 2014 17:14:20 -0500

On Wed, Mar 12, 2014 at 5:00 PM, Joe Touch <[email-masked]> wrote:
> Agreed on all points; I was giving an example in the context of BTNS, and I
> agree that it's useful here to find a term that doesn't assume a particular
> layer.

I'm yet to find a term I really like.

"Opportunistic" really does fit, and we would reject it only because
it conflicts with prior usage.  Bummer.

There's really a very wide range of behaviors we might be after:

 - unauthenticated crypto -- defeat passive attackers

 - unauthenticated crypto + TOFU == pseudonymous authentication

 - unauthenticated crypto at one layer w/ channel binding from another
== privacy protection of identities relative to passive attackers

 - unauthenticated crypto in which to tunnel (w/ channel binding)
further authentication == privacy protection of identities relative to
passive attackers

   (this is the same as the previous item, but in the same layer;
i.e., TLS renego)

 - unauthenticated crypto + attempt to authenticate inside that tunnel
w/ fallback on TOFU or not even

 - ... + cert pinning / TAC / whatever

There's probably more.

It's a wide range of behaviors and semantics.  More than a few such
behaviors == confusing to everyone else (and even ourselves).  Picking
one or two to the exclusion of the others is probably unrealistic.
Assigning an evocative English-language name to each (or even just
two) of these behaviors is proving difficult.

I'd say: assign acronyms or "security levels" to each behavior.
Define these well in some RFC.  Spread the word, use.

Nico
--

---

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: 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: 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: 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: Nico Williams <[email-masked]>
Date: Wed, 12 Mar 2014 21:35:54 -0500

[Dropping DANE for now]

On Wed, Mar 12, 2014 at 9:27 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> defer the definition of what OE is until we have decided what to do and then
> decide that that is OE by definition.
>
>

Hmmm, no, some of the behaviors we need terms for are the DNSSEC/DANE
behaviors, which are hardly "faith-based".  And anyways, using the TLS
server PKI has been a bit of an exercise in faith, hasn't it?

Nico
--

---

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: Stephen Farrell <[email-masked]>
Date: Thu, 13 Mar 2014 12:54:16 +0000

(dropping dane)

Hi Paul,

On 03/13/2014 01:14 AM, Paul Lambert wrote:
> of a Œprincipal¹ when we are using public key based authentication. 

In this context we are not always doing public key based endpoint
or any authentication. So this is not a thread about spki-like
approaches no matter who likes or dislikes those.

> The

That's reasonable. Whatever terminology we end up with should be
applicable to the above I agree. I'm not sure that that's the
most important requirement though, given that we want terms that
work well for more immediate needs, e.g. the web and SMTP/TLS
between MTAs.

> model are compatible with a perspective of keys as identifiers of

Yes.

Cheers,
S.

> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Mar 2014 12:56:47 +0000

(dropping dane)

On 03/13/2014 07:59 AM, Olle E. Johansson wrote:
> 
> On 12 Mar 2014, at 21:02, Derek Atkins <[email-masked]> wrote:
> 
> 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.

That's maybe a fair point. But our first target here are
folks developing protocols I think. If need be, they can
figure out good marketing terms on a per-protocol basis.

> 
> 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.

I sort-of agree. I do think we need to say something about OE,
even if that's just along the lines of "its vague, but <here>
are ways it has been used and section X.Y has more precise
terminology that's better"

Cheers,
S.

> 
> 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: Stephen Farrell <[email-masked]>
Date: Thu, 13 Mar 2014 13:01:27 +0000

(dropping dane)

> use the term, though Microsoft Exchange does.

Just to highlight that this is not only about TLS and IPsec.

For example, one of the reasons I'm helping with [1] is to
try figure out if/how other protocols can usefully do the "OK"
trick. TCPcrypt [2] or whatever that morphs into might also
not use IPsec or TLS (or might, who knows).

So we want the definitions to not be TLS or IPsec specific.
(Or we'll do all this over yet again at some point in the
nearish future;-)

S.

[1] http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt
[2] http://tools.ietf.org/html/draft-bittau-tcp-crypt

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Mar 2014 09:33:02 -0400

Joe,

>     1. unauthenticated key exchange/use
Yes, we could refer to this as unauthenticated or anonymous.
> 'zero-touch' was intentional), and the second "zero-ID fallback".
As I noted earlier, I'm not wedded to using the term "opportunistic" or 
even "optimistic" but
I can't say that "zero-*" conveys the intent to me.
> because OE seems to me a lot more like "use this key and hope it 
> works", which isn't part of either case above.
In Michael's RFC, OE isn't a "hope it works" method. It's a combination 
of two things:
     - agreeing to establish an authenticated SA with a peer 
irrespective of SPD entries
     - using the DNS as a way to acquire the public key for the 
responder, preferably via DNSSEC

Steve

---

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

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

As a side note:

Cheers
/O

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Mar 2014 10:15:00 -0400

Paul,
> Your level of pain in a discussion is not a measure of a concepts validity
true, but the idea that a public key is a principal is long dead.
> information associated with the key in a X.509 or other form of
In a word, no. When a public key is used in a cert it is bound to
some data, typically for authentication and access control. The usual
model calls for the Subject name or SAN  to identify the principal. In 
some cases
the cert functions as an authorization credential, as in the RPKI. In 
that case
the relevant data is the RFC 3779 extension. We don't view the public 
key as the
principal in any of these cases. More generally, if we are to use 
ephemeral keys,
as suggested for PFS, then saying that the key is the principal is 
silly, because
the key changes for each new session.
> identifier of a principal which can then be usefully processed in a
not really. If a key changes very frequently, as is the case for ephemeral
D-H, then nobody would use these values for access control purposes, because
managing constantly changing ACL entries would infeasible.
> may include names, labels, group membership, etc.
The SPKI WG  would have been the right place to pursue this interest,
but it died over a decade ago.
> model are compatible with a perspective of keys as identifiers of
TOFU assumes an asserted/implied identity that, as the name suggests, is 
trusted
initially, despite the lack of a "high quality" credentials. TOFU is 
motivated by
a threat model in which an adversary is unlikely to be able to act as a 
MiTM for
the initial credential acquisition AND remain as a MiTM for every subsequent
crypto-protected session. That's a pretty reasonable threat model in 
many contexts,
especially within an enterprise environment (where SSH is most often 
used). So, I
disagree that TOFU posits the public key as an ID.
> would only be authorized for actions that have no restrictions on specific
Access controls don't usually focus on what a principal is authorized
to do when you can't identify the principal.

Steve

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 13 Mar 2014 10:38:13 -0400

> To get any movement in this area among developers and sysadmins, we need a language that any sysadmin or developer understands. 

+1!

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Mar 2014 07:52:54 -0700

> figure out good marketing terms on a per-protocol basis.

Disagree about the "first target". The first target is to get people to care about encrypting more: that will put pressure on developers to put that into their protocols and products. Given that, having a definition of "opportunistic encryption" that makes sense to users is more important.

> terminology that's better"

Disagree about us saying "it's vague". It's only vague if we make it that way.

I'm still confused about why we feel that the definition in an old Informational RFC that was barely deployed should be relevant to our discussion. We can define the term that everyone is using any way we want. And it seems we want to define it in a way that will get more OE everywhere. Let's do that.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Mar 2014 14:57:57 +0000

On 03/13/2014 02:52 PM, Paul Hoffman wrote:
>>>  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.
>> 
>> That's maybe a fair point. But our first target here are folks
>> developing protocols I think. If need be, they can figure out good
>> marketing terms on a per-protocol basis.
> 
> Disagree about the "first target". The first target is to get people
> to care about encrypting more: that will put pressure on developers
> to put that into their protocols and products. Given that, having a
> definition of "opportunistic encryption" that makes sense to users is
> more important.

Fair point, but I'm not convinced. Our audience is not users, but
implementers and those developing protocols. And for a lot of OK
protocols/implementations the user (if there is one) should see
nothing at all.

>>> 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.
>> 
>> I sort-of agree. I do think we need to say something about OE, even
>> if that's just along the lines of "its vague, but <here> are ways
>> it has been used and section X.Y has more precise terminology
>> that's better"
> 
> I'm still confused about why we feel that the definition in an old
> Informational RFC that was barely deployed should be relevant to our
> discussion. 

IMO, its relevant but not gospel.

> We can define the term that everyone is using any way we
> want. And it seems we want to define it in a way that will get more
> OE everywhere. Let's do that.

+1 to the goal whether we use OE or OK or something else.

S.

> 
> --Paul Hoffman _______________________________________________ saag
> mailing list [email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 13 Mar 2014 11:01:39 -0400

> Our audience is not users, but implementers and those developing protocols. And for a lot of OK protocols/implementations the user (if there is one) should see nothing at all.

I think it will be a marketing plus -- we first try to strongly encrypt all your traffic -- and that therefore it will get out to customers.  And that rather than invent a new term, the developers will toss the RFC to the documentation, marketing, advertising, folks and say "here, this is what we're doing (leave me alone now)"  I don't want to descend into "why joe sixpack can't encrypt" discussions, but I think you're wrong to think this term won't "escape", and therefore we should spend a little effort on grooming.

	/r$

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 13 Mar 2014 16:05:49 +0100

> protocols/implementations the user (if there is one) should see

We are going around in circles. I think we - the larger Internet Community -
ned to explain this and get everyone that manages a system, that configures
software to get aboard this ship.

The IETF may have another audience. We in the IETF needs to explain
this to everyone involved in the IETF and then get it out to developers
that can change their software.

> IMO, its relevant but not gospel.
Marketing terms are seldom exact and precise. ;-)

"Oppurtunistic encryption is a set of solutions that enable application
developers and protocol designers to activate encryption in more
communication than before. This will make it harder to monitor
communication on privat as well as public networks."

Or something like that. 

+1

/O

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Mar 2014 11:08:48 -0400

Paul Hoffman <[email-masked]> wrote:
    > discussion. We can define the term that everyone is using any way we
    > want. And it seems we want to define it in a way that will get more OE
    > everywhere. Let's do that.

As the author of that document, I say: +1.
Let "OE" be the vague marketing term, rather like "SSL VPN" is/was.

Let's avoid "opportunistic" in our precise terminology, and say exactly what
we mean.  I didn't know TOFU before, and it's great.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Mar 2014 15:10:22 +0000

> communication on privat as well as public networks."

I like that as a starting point.

So if we had a draft that defined good/new/precise terms (e.g. OK),
and that included the above text in its intro, and that had some
text about the history (4322 etc), would that sound like a plan
to folks?

Ta,
S.

---

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 13 Mar 2014 16:20:44 +0100

+1

/O

---

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

> Yes, we could refer to this as unauthenticated or anonymous.

Agreed on unauthenticated.

Anonymous is a little more complex - it could be inferred as providing 
anonymity, and proving that is a lot harder.

> I can't say that "zero-*" conveys the intent to me.

It depends on what you think the intent is ;-)

If it's avoiding identities, zero-ID is fairly direct.

If it's fallback that starts with IDs, then the more accurate term might be:

	zero-ID fallback

This has the advantage of a pithy acronym (ZIF).

> responder, preferably via DNSSEC

The "hope it works" part is the use of the DNS to get the keying info 
rather than the endpoint. The endpoint ID may have changed; rather than 
verifying that in advance, OE just uses what it finds. The default is to 
expect that it works - that's the "hopeful" part, IMO.

But ZIF ;-) is more about the fallback than the expectation that the 
first method - whatever it is - works.

Joe

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 13 Mar 2014 16:37:32 +0100

On 13 Mar 2014, at 16:32, Joe Touch <[email-masked]> wrote:

> Anonymous is a little more complex - it could be inferred as providing anonymity, and proving that is a lot harder.
> 
> The "hope it works" part is the use of the DNS to get the keying info rather than the endpoint. The endpoint ID may have changed; rather than verifying that in advance, OE just uses what it finds. The default is to expect that it works - that's the "hopeful" part, IMO.
> 
> But ZIF ;-) is more about the fallback than the expectation that the first method - whatever it is - works.

Zero-ID is one thing we do, but it is not the goal. The goal is more encryption in an opportunistic way.
I think Zero-ID is too far down the stack to use as a marketing term. It's catchy though. A good name
for OTR. :-)

/O

---

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

> Zero-ID is one thing we do, but it is not the goal. The goal is more encryption in an opportunistic way.

Again, we're back to "what does 'opportunistic' mean"?

Is it:

	- using keys before they're confirmed
		(this is how I think of OE)

	- having a fallback
		(lots of security protocols do this)

	- involving a method that doesn't use identities
		(this is what I proposed as Zero-ID)

	- involving a method that is anonymous
		this requires a lot more rigor to show
		not only a lack of traceability to a
		given ID, but also lack of traceability
		to prior uses without an ID

	- having a fallback that (in specific) doesn't use identities
		(IMO this is ZIF - Zero-ID fallback)

Of the above, IMO OE applies only to the first; I don't think there's 
anything 'opportunistic' (either in the sense of the English word, or in 
the sense of prior OE RFCs) about either of the latter.

Joe

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 13 Mar 2014 17:00:35 +0100

> Again, we're back to "what does 'opportunistic' mean"?
If I am acting as the marketeer, I would say all of the below mentioned (and a few more). I would
(with my simple marketing way of thinking) just group "all the sessions that previously was not
encrypted and can be without reconfiguration or user action" as opportunistic.

You see, it's fun to be in marketing. Come join the dark side!

/O
> Of the above, IMO OE applies only to the first; I don't think there's anything 'opportunistic' (either in the sense of the English word, or in the sense of prior OE RFCs) about either of the latter.
> 
> Joe

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Mar 2014 09:05:06 -0700

> text about the history (4322 etc), would that sound like a plan

Not to me. The "precise" terms such as OK is a distinction that will water down what we are trying to do. I would much prefer that we focus on the term people are already using, give it a general direction like Olle gave and a mediumly-precise definition that could be used across all protocols, and then give examples of its use in current usage (TLS and IPsec), saying that precise definitions might later be added in other RFCs. This will give people some possible excitement about doing the work instead of arguing about new terms.

--Paul Hoffman

---

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

> Not to me. The "precise" terms such as OK is a distinction that will water down what we are trying to do. I would much prefer that we focus on the term people are already using, give it a general d…

And with all of us and all the protocols and communication methods we have, defining a COMPLETE and EXACT terminology will take a lot of time. There's an urgency here too that we should not forget.

From the emails we have seen today, I think we have very good input with a lot of examples on what can be included under the generic "marketing term" umbrella, examples ranging from SIP and HTTP to IPsec.

/O

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Mar 2014 09:14:02 -0700

> encrypted and can be without reconfiguration or user action" as opportunistic.

Nothing new is going to work without reconfiguration (i.e., use of a new 
protocol or mode at least).

If I start with your definition, I would never guess "opportunistic" as 
applying, but I would guess "zero-touch" -- what you're describing is 
they ID management equivalent of network configuration.

Joe

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 13 Mar 2014 16:16:30 +0000

> Again, we're back to "what does 'opportunistic' mean"?

It is an adjective that modifies a noun.  The meaning depends on
the noun to which it is prepended.  The best we can hope for is
sane guidance on when this is an appropriate adjective.

To me "opportunistic foo" is "foo, when possible", because "foo"
is deployed incrementally, and while one would prefer to use "foo"
with all destinations, many or most may not yet support "foo".

To Tony's point, one could sometimes take the view that this is
mere negotiation of features, but when the feature in question is
the use vs. not use of a security protocol, rather than say choosing
between AES and RC4, I think it deserves a name.

The fact that things like "opportunistic TLS" also brush aside
authentication is a secondary feature.  When you're not even
sure the server supports TLS, and are willing to send in the
clear, authentication is a luxury.

Sometimes some form of authentication is still possible with
opportunistic modes, (with SMTP reasonably strong with DANE, none
for simple opportunistic TLS) and sometimes it is not.

Anyway, you may disagree with the specifics of my interpretation,
but I hope most will agree with the higher level viewpoint that we
should not attempt to define "opportunistic" as a noun is sound.

-- 
	Viktor.

---

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

On 13 Mar 2014, at 17:14, Joe Touch <[email-masked]> wrote:

> Nothing new is going to work without reconfiguration (i.e., use of a new protocol or mode at least).
SIP will work. We can - without changing a single row in the RFCs - change our software to prefer
TLS sessions. That's encrypting sessions that previously was not. No reconfiguration, just update
software and run as before. After that we need to convince server admins to activate more TLS
listeners...

> 
> If I start with your definition, I would never guess "opportunistic" as applying, but I would guess "zero-touch" -- what you're describing is they ID management equivalent of network configuration.

Maybe. 

/O

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Mar 2014 12:19:13 -0400

Let's please start with the protocol(s) and/or mechanism(s).
      ("running-code")

Let them be described precisely, and the terminology can flow.
Let's ban "opportunistic" from being a term of precision.

If we find that we have general terms, then will flow *afterwards*, not
before.

So, I'd like to have an ID (Informational, vendor-proprietary, like 4322)
document from the postfix authors on what *exactly* they do.
If UTA wants to adopt 2.0 of that, great.

---

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

> should not attempt to define "opportunistic" as a noun is sound.

I think Wikipedia made the decision for us. (and no, I'm not involved)
http://en.wikipedia.org/wiki/Opportunistic_encryption

/O

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Mar 2014 12:49:12 -0400

> protocol or mode at least).

yes/no.
the question isn't whether it can happen without (re)configuration.

The question is whether it can happen without *coordination*.  If I can just
turn it on at my and "hope" for the fax effect, then it's what we want.

In this sense, "optimistic encryption" is a rather good way to describe the philosophy.

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Mar 2014 10:44:40 -0700

...
> TLS sessions.

Until you change the software, nothing will work.

 > That's encrypting sessions that previously was not. No reconfiguration,

Changing defaults IS reconfiguration. It's not custom to each machine, 
but it's a change.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Mar 2014 10:55:06 -0700

On 3/13/2014 9:49 AM, Michael Richardson wrote:
> The question is whether it can happen without *coordination*.

Without per-endpoint (or endpoint-specific) (re)configuration.

 > If I can just

It really isn't.

OE was truly opportunistic in a few ways:
	- pre-deploying IDs in the DNS
	- using those IDs before they were confirmed between ends

Unauthenticated keying is not opportunistic in any sense of the term - 
English or RFC.

When I brought the concept to the IETF, I called it "AnonSec", which 
later was called "BTNS":
http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt

The point of AnonSec was to avoid the need to deploy IDs or to make any 
"opportunistic" guess as to what might work. That's exactly the sense in 
which it's used here.

---

So a good term depends on what we consider the important features:

	- avoiding IDs
		anonymous or zero-ID

	- opportunistic
		but there's no 'opportunistic' aspect to what
		I've seen discussed so far

	- fall-back
		which doesn't seem as notable as whether
		the 'last resort' is something you
		"hope" will work (OE) or something you
		*know* will work (anonymous/zero-ID)

	- avoiding per-endpoint configuration
	either at the endpoint or in the network

		the rest of the community - commercial
		and RFC - calls this "zero-config" or
		"zero-touch"

I agree we don't need to create a completely new and unfamiliar term, 
but let's please not apply one that is incorrect just because it's familiar.

Joe

---

From: Paul Lambert <[email-masked]>
Date: Thu, 13 Mar 2014 11:04:25 -0700

Steve,

>true, but the idea that a public key is a principal is long dead.

Perhaps in your world view of public key architectures. I suspect you may
also open your eggs on the large end.

The dogmatic definition of a ‘principal’ is not the point and we may never
reach agreement on such definitions when there are two dual but viable
world views.  Unique identifiers may be assigned to a key by an authority
(e.g. CA and name/identifier centric) … or a unique key may have
attributes assigned to it by an authority.

My preference is to use a public key as a unique identifier of a
principal.  Public keys are unique and do not require a third party to
coordinate the uniqueness of a name space.

Using any other unique identifier for a principal typically requires a
naming authority.

>some data, typically for authentication and access control.

So what. I am describing use of keys without certs and certs without
trusted bindings.  When my browser asks me to make an exception for a
certificate there is absolutely no value in any of the information in the
certificate.  The pinned certificate is binding a unique public key to a
specific usage.

We need architectural models for security that work without central naming
authorities.  X.509 was created in the 80’s and the world has changed.
There are applications that must support strong authentication and
authorization without naming authorities.

>The usual
>principal in any of these cases.

What do you mean we …  :-)

Yes, I agree that the model I describe is not aligned with the
architectural concepts documented X.509 and the many related RFCs.  I
consider this a feature.  We are using certificates in many ways that
violate the original vision of a single directory service in the sky. Self
signed certs, cert pinning, certificate transparency are all indications
that the X.509 architecture needs reexamination.

While not aligned, the perspective of a key as one type of principal
identifier can be mapped consistently into the use of X.509.  We are
already pinning keys which effectively is using the just the key for a
particular context.

This mapping to 509 is possible, but as mentioned before my current
project is non-509 ‘key centric’ security for consumer equipment.  Key
binding for a particular context is by a bootstrapping process that
enrolls or identifies a peer device with high assurances.  This is
sort-of-a TOFU++.  This might be considered the upper end of assurance for
OE/OK where local out-of-band validation of the peer binds the key to a
specific context.

>More generally, if we are to use
>ephemeral keys,

Pure ephemeral DH has no authentication and it does not matter what’s
considered the ‘principal’.  Authenticated ephemeral DH has multiple
public keys.  The longer term static keys used for authentication
(typically in the past carried in a X.509 cert) are the ‘principal
identifier’ that I am describing.

To be more precise, the public key used for authentication serves as a
unique identifier for the purpose of creating security policies.  This
does not exclude the assignment of other attributes that could be used to
describe other types of identifies or group membership.

>managing constantly changing ACL entries would infeasible.
How often do you change your X.509 cert used for authentication?

Ephemeral usage is a red-herring and irrelevant.  Other interesting usages
of changing public keys in DH exchanges still have no other ‘attributes’
to identify a principal and would be bound in a access control policy to
the original introducing key.

>but it died over a decade ago.
Yes, the working group and specific protocol died.  It left behind vacuum
for a well defined public key architecture than is not based on X.509.
SPKI did have it’s own limitations and problems.  We are left now with a
lack of even the basic terminology to describe the mechanisms we are
building (OK,OE, TOHU, whatever).  The adamancy to only use CA issued
names for ‘principals’ leaves us only with central authority based
architectures.

>disagree that TOFU posits the public key as an ID.

The asserted or implied Id may not be unique or meaningful for any purpose
but local administration.  The TOFU model, from my view of the id model,
is a example of SPKI-like local naming.  The implied identity is local and
can only be shared with other devices in the context of it’s own unique
name space … or simply as the unique identifier inherent in the key it’s
self.  Information about the key could come from other sources (e.g. DANE)
which would speak about the key and provide a binding to additional
attributes.   

>to do when you can't identify the principal.
My example is specifically that the remote principal is identified and
authenticated, but unknown.  I should not have mixed usage of ephemeral
for short term identity versus PFS usage in a protocol.

Paul

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Mar 2014 11:04:45 -0700

On 3/13/2014 9:16 AM, Viktor Dukhovni wrote:
> It is an adjective that modifies a noun.

I was asking for a definition of the adjective, FWIW.

 > The meaning depends on
> the noun to which it is prepended.

Dictionaries include definitions for adjectives too, and only some of 
the meanings are context-dependent. I don't mind if you want to define 
the whole term OE or just the O part.

...
> To me "opportunistic foo" is "foo, when possible",

+1

> because "foo"
> is deployed incrementally,...

I don't think how 'foo' is deployed matters. It could be incrementally 
deployed, optionally available, or have a different priority in preference.

> between AES and RC4, I think it deserves a name.

Agreed - and the name depends on whether we're focusing on the 
negotiation part, the fallback part, or the specific approach that 
avoids the need for IDs.

> authentication is a secondary feature.

Maybe not...

< When you're not even
> clear, authentication is a luxury.

If you're

	a) willing to send in the clear

	b) willing to accept that when security is running
	you might still not be talking to who you think you are

+1

I.e., the concept of "opportunistic" (as an adjective) is distinct from 
the particular variants considered. One of those variants is anonymous 
or zero-ID. (ZID?)

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Mar 2014 11:06:45 -0700

> http://en.wikipedia.org/wiki/Opportunistic_encryption

No wikipedia page is known correct. That page at one time also listed 
BTNS as an example of OE.

If there's something there you don't think is correct, edit it and make 
your case in the comment section of your edits.

Joe

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Mar 2014 14:21:53 -0400

Olle,

Since , as you said, you're a marketing guy, let me caution you about 
viewing
Wikipedia as a definitive source of info. In this case there are a number of
errors in its article on OE. Kathleen (the new SEC AD) and I have been 
discussing
how to fix it.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Mar 2014 14:22:35 -0400

Paul
> Not to me. The "precise" terms such as OK is a distinction that will water down what we are trying to do. I would much prefer that we focus on the term people are already using, give it a general d…
Giving a "mediumly precise" definition followed by examples suggests 
that we're incapable of
explaining what we're doing, which sends a bad message (maybe an 
accurate one, but still bad).

Steve

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 13 Mar 2014 20:10:26 +0100

On 13 Mar 2014, at 19:21, Stephen Kent <[email-masked]> wrote:

> Olle,
> 
> Since , as you said, you're a marketing guy, let me caution you about viewing
> errors in its article on OE. Kathleen (the new SEC AD) and I have been discussing
> how to fix it.

I was acting as one :-) And the wikipedia reference was more of a joke, I'm sorry
for forgetting the irony marker.

Yes, that page needs some work - but before that I think we should reach some
sort of agreement here.

/O

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 13 Mar 2014 19:20:16 +0000

> If UTA wants to adopt 2.0 of that, great.

Is there a broad desire for such a document?  Be careful what you
mean when ask for "exactly".  I could point you at the source code.
The next slightly less verbose level of detail is:

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

which is a fairly long document.

In terms of this discussion, the 50,000 foot view is a quick list
of the security levels with one line descriptions and links to
detailed text:

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

The limitations and reasoning behind the various levels are described
in:

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

The volunteer to write the DANE_README.html tutorial has not yet
produced a first draft.  The IETF draft for SMTP security via
opportunistic DANE TLS is largely complete, but may yet shed some
content that is not SMTP specific into the revived DANE SRV draft.

    git clone https://github.com/vdukhovni/ietf

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Mar 2014 12:45:34 -0700

On Mar 13, 2014, at 11:22 AM, Stephen Kent <[email-masked]> wrote:

> Giving a "mediumly precise" definition followed by examples suggests that we're incapable of
> explaining what we're doing, which sends a bad message (maybe an accurate one, but still bad).

I'm not sure what you mean as "bad message". If we could define OE protocol-by-protocol, we could do it quite precisely, but the other Stephen seems quite set against that. I think the message is "if you are describing this for more than one protocol or environment, it won't be maximally precise"; I doubt anyone will find that surprising.

--Paul Hoffman

---

From: Mouse <[email-masked]>
Date: Fri, 14 Mar 2014 22:23:08 -0400 (EDT)

Perhaps I'm just suffering from insufficient familiarity with something
relevant, but...

> We are going around in circles.  I think we - the larger Internet
> Community - ned to explain this and get everyone that manages a
> system, that configures software to get aboard this ship.

...I don't think that either will or should happen until encryption is
a right choice for every purpose, for every application.

I don't think that will ever be the case.

/~\ 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: Stephen Kent <[email-masked]>
Date: Tue, 18 Mar 2014 18:04:57 -0400

Paul,

I began generating a point-by-point response to your message, but I think
that's a bad use of everyone's time.

We will each participate in the WGs that are of interest to use, write I-Ds,
and propose mechanisms in support of countering PM.

There's not much point to debating the merits of public keys as 
principal IDs
the abstract, vs. in specific proposals.

Steve

---

From: Paul Lambert <[email-masked]>
Date: Tue, 18 Mar 2014 16:08:52 -0700

>the abstract, vs. in specific proposals.

Yes - specific usage and proposals have more merit than abstractions.
Also, thank you for the discussion .. it has helped
me see the subtle impact of the security abstractions we
create.  

Paul