Subject: Re: [Uta] [saag] [dane] Need better opportunistic terminology

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

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

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

(Ah, that explains where this email is coming from)

    > want us to end up with IPsec (or TLS) specific terminology.

I believe that we need some terminology which is both technology specific,
and technology agnostic.

Were I able to go back and suggest "Opportunistic IKEying" for RFC4322,
I think that I would so that. (damn, how to turn that into OINK?)

I think that the key (pardon the pun) point about the opportunistic
part is that this is a communication which one will do regardless of
the presence of the security.  It doesn't "failsafe", it fails-to-communication.

From a policy point of view *swan had a number of "step-ups" that were
partially described in 4322:
  1) private
  2) private-or-clear
  3) block
  4) clear

We never did implement private-to-lock (the "leap-of-faith"), where once you
communicate privately once, you remember the key and force it always.
We did implement a demo where it mattered if the DNSSEC had worked, and
we provided an API by which an application could ask if a socket was secured
by IPsec authenticated by DNSSEC (or not).  We had a swan dance/swim if so.
(Akin to KAME's turtle and IPv6).

I think that these are useful things to describe.

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Mar 2014 22:14:08 +0000

> (Ah, that explains where this email is coming from)

So it looks like folks prefer saag for this discussion
which is fine. (Hopefully they'll stop cc'ing dane soon;-)

S.

---

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

Stephen,
> want us to end up with IPsec (or TLS) specific terminology.
We disagree. We have an RFC that defines OE, vs. unauthenticated encryption,
and the former term is defined exclusively in the IPsec context. TLS defines
anonymous sessions, as well as server-only and client- and 
server-authenticated
sessions. Why should we reuse a well-defined term in a way that 
contradicts an
existing RFC,and which makes a meaningful distinction among different 
approaches
to keying?
> (And Pete Resnick likes the idea of OK protocols:-)
don't we all :-).
> we move the discussion there if that's ok just to try get
I don't think UTA is the best place for this discussion, since it
applies to IPsec too, maybe to MPLS-encryption, whatever MPTCP does, etc.
I think SAAG makes the most sense.

Steve

---

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

> anonymous sessions, as well as server-only and client- and

We have an Informational RFC for a vendor proprietary (even if open source)
system, that while widely reviewed, went through the Independant Queue.  It
says:

   Anonymous encryption: the process of encrypting a session without any
      knowledge of who the other parties are.  No authentication of
      identities is done.

   Opportunistic encryption: the process of encrypting a session with
      authenticated knowledge of who the other party is without
      prearrangement.

DANE/DNSSEC/TLSA certainly fits.

I think that if the terminology in 4322 is inconvenient ten years later, then
change it.

I also have said that we need precise technical definitions for our work
(and for Received: headers)  but that we need to allow for looser more
market/system-administrator friendly terms.

---

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.