On Wed, Mar 12, 2014 at 11:49 AM, Joe Touch <[email protected]> wrote: > On 3/12/2014 6:35 AM, Stephen Kent wrote: >>>> 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 ;-) >> >> yeah, I like OK (and I like IKE too, for those of us old enough to >> 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). > 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. 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.) > 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. 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 -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
