Re: [Uta] Proposed definition of opportunistic encryption using TLS: draft-hoffman-uta-opportunistic-tls-00.txt

[Stephen Farrell <[e-mail]>]

Hi Paul,

On 02/03/2014 04:43 PM, Paul Hoffman wrote:
> On Feb 3, 2014, at 4:45 AM, Stephen Farrell
> <[e-mail]> wrote:
> 
>> On this one, I don't really care which, if any, WG, ends up 
>> processing a draft defining these terms, but it is important that
>> the definitions related to the use of the term opportunistic and
>> crypto be ones that work for more than TLS, this WG and the apps
>> area, but are as well accepted for the entire IETF. For example,
>> IPsec and even MPLS folk should be able to use the same terms
>> without confusion arising.
> 
> That would be nice, but it is also impossible. 

Having one coherent set of definitions seems entirely possible
to me.

> What *is* possible is
> that each area's use of "opportunistic encryption using XYZ" felt
> similar enough to prevent confusion. If you insist that all possible
> definitions be in a single document, 

"insist"? Anyway what I'm asking for is a coherent set of
definitions documented sensibly however best that's done.
Seems quite far from insisting on anything to me.

> the understanding of specific
> use case (here, TLS) will be greatly diminished.
> 
> As you can see for this document, whatever the apps-with-TLS folks
> here in UTA do, we need to deal with terms for both "opportunistic
> encryption" *and* "unauthenticated TLS". For some of the other places
> that need to deal with "opportunistic encryption", the latter is not
> needed.

Similar issues arise elsewhere IMO.

> Assuming that there are approximately five definition documents,
> someone could write a short directory document that lists them and is
> updated when new ones are added.

That sounds wrong to me. I'd like to know why we can't have one
set of generic definitions used by many other documents.

>> Note also that there will be discussion on this topic at the STRINT
>> w/s before IETF-89 and I have some hope that we can get agreement
>> quickly enough between there and the following week of meetings
>> that it won't matter which WG "owns" the draft.
> 
> A different, and I hope better, conclusion from the workshop would be
> agreement about what areas need definitions of "opportunistic
> encryption using XYZ" and start coordination among them.

Not sure I agree. Minor point though.

>> On your draft Paul, I don't think it really covers that charter
>> work item since it only has some definitions. But that said, if we
>> conclude a WG document is better, I'm fine if this WG is the place
>> to write down the definitions so long as those are more broadly
>> accepted.
> 
> The charter item is limited to TLS. Are you saying you want the WG to
> ignore that and try to work with other encryption mechanisms as
> well?

No. I'm saying that the charter item was intended to allow the
WG to (if necessary) define a way to do unauthenticated TLS that
is not ANON-DH. Your draft does none of that (currently at
least).

>> And a few more near-random comments:
>> 
>> Ending up with substantively different definitions for the term
>> opportunistic e.g. when used with TLS and IPsec would be a dumb
>> outcome IMO.
> 
> Fully agree.
> 
>> At present we do have such confusion and we do need to fix that, so
>> a draft like Paul's that does define the terms is something we do 
>> want. I know that Steve Kent is also working on a different draft
>> that defines these terms, perhaps differently. I've not thought
>> about which of the two might be a better starting point, and
>> Steve's isn't yet published so others can't either. (Steve's text
>> will be published at the end of this week with other STRINT
>> submissions though.)
> 
> Steve let me see an early pre-draft of his draft. It is quite
> comprehensive and complicated. While it might be useful to security
> experts and academics, I don't think that is as helpful to protocol
> developers as a short, concise document such as this one.

Maybe. Or maybe not. Not sure yet myself. But again, I mostly
care about a coherent set of definitions that won't confuse
folks and a lot less about how we get that into an RFC.

S.

> 
> --Paul Hoffman _______________________________________________ Uta
> mailing list [e-mail] https://www.ietf.org/mailman/listinfo/uta
> 
>