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

[Alan Johnston <[e-mail]>]

Paul,

Thanks for the reply.  See below for a few comments.

Also, I wanted to say that I really like this approach of using a short
draft that tries to define a term and says what it is and what it isn't..

- Alan -


On Mon, Feb 3, 2014 at 3:34 PM, Paul Hoffman <[e-mail]> wrote:

> On Feb 3, 2014, at 11:19 AM, Alan Johnston <[e-mail]>
> wrote:
>
> > I think this is the opportunisticky property that we need a good working
> definition.  However, in the next paragraph, sentences such as this, don't
> help:
> >
> >    When an application that supports opportunistic encryption negotiates
> >    TLS, that application might or might not authenticate the TLS server.
> >
> >
> > That is true, but it is irrelevant to the definition.
>
> Unfortunately not, because authentication is inherently part of TLS, so we
> have to call out what in TLS we are doing differently.
>
> > An opportunistic encryption system might also use PFS, do logging, cache
> keys, or any number of other things.
>
> All those are optional; authentication of the server by the client is not.
>

Help me understand.  You are saying authentication of the server by the
client in TLS is not optional.  I suspect you mean that the client must try
to authenticate the server.  If this authentication fails, this doesn't
automatically mean TLS will close the connection, right?  Or, when, for
example, a browser pops up a error message which can allow a user to click
yes, is this treated by TLS as a successful authentication?

I guess what I'm saying is that from a non-TLS expert's perspective, it
appears that authentication is optional by TLS, at least the way it is used
with web browsers.


>
> >   We need separate definitions for each of these, and not conflate them
> together. Otherwise, we can't make any sensible recommendations about
> opportunistic approaches, especially when different people conflate
> different things and use the same word.
>
> I'm definitely open to wording suggestions.
>

I guess this is the problem of trying to define opportunistic for a single
protocol, rather than trying to define the term generically and then apply
it to a given protocol.  For example, it is possible that TLS can only
support opportunistic encryption with PKI authentication, but this doesn't
mean that we should change what we mean by opportunistic encryption to fit
the particulars of how TLS is designed.

On the other hand, if the word opportunistic has too much baggage, then
maybe we just need to treat it as a generic feature name which mean
different things in different contexts.  In this case, we would need a new
term for the concept that you describe in the first sentence of your
definition, IMO.


>
> --Paul Hoffman