Re: [saag] new terminology ID posted

[Stephen Kent <[e-mail]>]

Nico,

> On Tue, Apr 01, 2014 at 02:46:43PM -0400, Stephen Kent wrote:
>> Thus it may not result in as much encryption as a mechanism which does not
>> impose that prerequisite. Folks will have to decide if we want to create a
>> different term for DANE-enabled TLS (and IPsec) sessions, or broaden the
>> definition of opportunistic security to encompass them. I'm happy to
>> generate text to accommodate whatever folks decide.
> Er, are you asking for a consensus call on this point?  I'm definitely
> for DANE-enabled TLS.  Who wouldn't be?  Can we hear some arguments
> against?  I'm curious about this.
I was not asking for a consensus call, yet. And, even if I were, the
issue is not whether DANE-enabled TLS is good or bad (I think it';s
very good) but whether it will be included in a definition of OS.
> Or, if we don't hear any such arguments, then I think we must have
> consensus on this point.
DANE-enabled TLS does not meet some of the posited requirements for
OS, e.g., PFS, and encrypt first and authenticate later. Gee, that sounds
a lot like "shoot first and ask questions later" now that I think about 
it :-).
> Until then, what's the harm in including "DANE-enabled TLS" in your I-D?
> How might we get feedback on that if you don't?
Include it as what? I have included notes on what I viewed as "legacy"
IETF security protocols. DANE-enabled TLS is rather new to be viewed
as one of those. I don't want to discuss all of the proposals that are
now on progress, lest we never complete this doc. In that sense DANE-enabled
TLS tends to fall in the middle. If folks feel it's important to mention,
then I will do so, but not as an example of OS.
> As to IPsec, I really think there are two "correct" approaches to making
> end-to-end IPsec work:
>
>   - Apps (or the OS libraries/kernel) lookup IPsec-equivalents of TLSA
>     RRsets for the desired host/service name (not IP addresses!), then
>     arrange for local IPsec policy to require the remote's ID/credentials
>     for the address found in the DNS to match those found in the IPsec
>     DANE.
>
> and/or
>
>   - Use IPsec connection latching and channel binding to IPsec channels
>     at the app layer.
>
> Note that the first effectively refers to connection latching.  The
> latter is only relevant when there's an app-layer authentication
> mechanism with various properties, making the first approach the only
> general one.

I think this level of detail is beyond what needs to be discussed in 
this doc
but, as above, let's see what other folks feel.

Steve