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

From: Paul Hoffman <[email-masked]>
Date: Sun, 2 Feb 2014 21:03:21 -0800

Greetings again. One of the deliverables in our charter is:

   - Consider, and possibly define, a standard way for an application
     client and server to use unauthenticated encryption through TLS
     when server and/or client authentication cannot be achieved.

I think that wording was sloppy, and would like the WG to come up with a clear definition of what it is we want application protocols to possibly support in order to thwart pervasive monitoring. I put together my ideas in a very short draft.

If folks like the idea of this definition, I think it would be appropriate for a WG document.

--Paul Hoffman

Begin forwarded message:

> From: [email-masked]
> Subject: I-D Action: draft-hoffman-uta-opportunistic-tls-00.txt
> Date: February 2, 2014 at 8:59:10 PM PST
> To: [email-masked]
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : Opportunistic Encryption Using TLS
>        Author          : Paul Hoffman
> 	Filename        : draft-hoffman-uta-opportunistic-tls-00.txt
> 	Pages           : 5
> 	Date            : 2014-02-02
> 
> Abstract:
>   This document defines the term "opportunistic encryption using TLS"
>   as it applies to application protocols that use TLS.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hoffman-uta-opportunistic-tls/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-hoffman-uta-opportunistic-tls-00

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 3 Feb 2014 09:49:46 +0100

Paul,
First - thank you for writing this. I had only a vague understanding of the term "oppurtunistic encryption" before reading this as it has been used in many contexts. I would like to add a bit more complex scenario than HTTP client/server.

In the SIP protocol, a manager of a service can define by using NAPTR DNS records that all connections to my service has to use TLS to connect to the service. It's not really oppurtunistic since there is a requirement, but not from the user. It's surely authenticated. Your document only talks about user requirments, but here is a case of a server/service requirement that controls behaviour.

Now if w have a signalling path with multiple proxys between a user and an endpoint any of these servers could use oppurtunistic encryption for the next hop. In SIP we add a "TLS" transport marker to a via header - much like a received header in mail - when we use TLS. This to me marks an authenticated TLS connection. I wonder if there is any reason to separate this from the case where a middleman finds a TLS naptr or SRV records and sets up TLS just because it is possible, a matter of preference in the server, a proxy-controlled oppurtunistic encryption path. With TLS we have special requirements for the return path that may not apply to oppurtunistic TLS. We propably want to mark those connections as TCP and add some extra info that TLS was actually used. At this point I don't think we need an "OTLS" marker to suggest TLS if possible. That could be wrong. :-)

On a side note SIP has no error codes for telling a client that a remote connection (beyond the first proxy)  failed because of bad certificates or something else TLS-related, just "Connection failed, sorry" (like Javascript). I don't think that's because of any security concern, just a poor specification.

/O

On 03 Feb 2014, at 06:03, Paul Hoffman <[email-masked]> wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 03 Feb 2014 12:45:38 +0000

Hi Paul,

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.

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.

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.

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

So I think this is one to discuss in London.

S.

---

From: Alan Johnston <[email-masked]>
Date: Mon, 3 Feb 2014 09:28:07 -0600

Olle,

The way in which a SIP request can utilize TLS for subsequent proxy hops
even though the user has not requested it (e.g. using a secure SIP or sips
URI) seems within the spirit of Paul's definition.  A more complete
approach could choose TLS for the first hop as well.

I'm less certain if the presence of a "transport=tls" parameter in the SIP
message violates Paul's rule about not indicating that TLS has been used.
 I'd need more explanation to understand this rule anyway, along with the
rule that no user configuration be allowed. It is not clear to me how
either of these does the harm that is described in the Security
Considerations section.

For VoIP and video calling in general, there is also the issue of
encryption of the media - to use SRTP or use unencrypted RTP. For ZRTP, we
developed an approach that could be considered opportunistic in this
definition, although we described it "best effort encryption" (RFC 6189).
 But that is a discussion for another thread!

- Alan -

On Mon, Feb 3, 2014 at 2:49 AM, Olle E. Johansson <[email-masked]> wrote:

> Paul,
> First - thank you for writing this. I had only a vague understanding of
> the term "oppurtunistic encryption" before reading this as it has been used
> in many contexts. I would like to add a bit more complex scenario than HTTP
> client/server.
>
> In the SIP protocol, a manager of a service can define by using NAPTR DNS
> records that all connections to my service has to use TLS to connect to the
> service. It's not really oppurtunistic since there is a requirement, but
> not from the user. It's surely authenticated. Your document only talks
> about user requirments, but here is a case of a server/service requirement
> that controls behaviour.
>
> Now if w have a signalling path with multiple proxys between a user and an
> endpoint any of these servers could use oppurtunistic encryption for the
> next hop. In SIP we add a "TLS" transport marker to a via header - much
> like a received header in mail - when we use TLS. This to me marks an
> authenticated TLS connection. I wonder if there is any reason to separate
> this from the case where a middleman finds a TLS naptr or SRV records and
> sets up TLS just because it is possible, a matter of preference in the
> server, a proxy-controlled oppurtunistic encryption path. With TLS we have
> special requirements for the return path that may not apply to
> oppurtunistic TLS. We propably want to mark those connections as TCP and
> add some extra info that TLS was actually used. At this point I don't think
> we need an "OTLS" marker to suggest TLS if possible. That could be wrong.
> :-)
>
> On a side note SIP has no error codes for telling a client that a remote
> connection (beyond the first proxy)  failed because of bad certificates or
> something else TLS-related, just "Connection failed, sorry" (like
> Javascript). I don't think that's because of any security concern, just a
> poor specification.
>
> /O
>
>
> > I think that wording was sloppy, and would like the WG to come up with a
> clear definition of what it is we want application protocols to possibly
> support in order to thwart pervasive monitoring. I put together my ideas in
> a very short draft.
> >

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Feb 2014 08:30:38 -0800

On Feb 3, 2014, at 7:28 AM, Alan Johnston <[email-masked]> wrote:

> I'm less certain if the presence of a "transport=tls" parameter in the SIP message violates Paul's rule about not indicating that TLS has been used.

It does not violate the rule unless it is something that the user configures. If it is something set by the application developer (in this case, to follow the requirements of the protocol), but is not user-configurable, it's fine.

>  I'd need more explanation to understand this rule anyway, along with the rule that no user configuration be allowed. It is not clear to me how either of these does the harm that is described in the Security Considerations section.

Consider the HTTP / browser case. You have set up a TLS-accessible web site because security is good for the Internet, but you hate paying for and configuring a certificate for obvious reasons. If all common browsers let user say "always do TLS even for http: URLs, and ignore any server failure", you would configure your web server to do TLS with no certificate because that's good enough. That's a security reduction for the Internet.

> For VoIP and video calling in general, there is also the issue of encryption of the media - to use SRTP or use unencrypted RTP. For ZRTP, we developed an approach that could be considered opportunistic in this definition, although we described it "best effort encryption" (RFC 6189).  But that is a discussion for another thread!

Please, please note: "this definition" is only about TLS. I even called that out in the draft.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Feb 2014 08:43:22 -0800

> should be able to use the same terms without confusion arising.

That would be nice, but it is also impossible. 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, 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.

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.

> week of meetings that it won't matter which WG "owns" the

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. 

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

> would be a dumb outcome IMO.

Fully agree.

> At present we do have such

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.

--Paul Hoffman

---

From: Alan Johnston <[email-masked]>
Date: Mon, 3 Feb 2014 11:13:06 -0600

Paul,

Thanks for your reply - see a comment below.

- Alan -

On Mon, Feb 3, 2014 at 10:30 AM, Paul Hoffman <[email-masked]> wrote:

> > I'm less certain if the presence of a "transport=tls" parameter in the
> SIP message violates Paul's rule about not indicating that TLS has been
> used.
>
> It does not violate the rule unless it is something that the user
> configures. If it is something set by the application developer (in this
> case, to follow the requirements of the protocol), but is not
> user-configurable, it's fine.
>
> >  I'd need more explanation to understand this rule anyway, along with
> the rule that no user configuration be allowed. It is not clear to me how
> Consider the HTTP / browser case. You have set up a TLS-accessible web
> site because security is good for the Internet, but you hate paying for and
> configuring a certificate for obvious reasons. If all common browsers let
> user say "always do TLS even for http: URLs, and ignore any server
> failure", you would configure your web server to do TLS with no certificate
> because that's good enough. That's a security reduction for the Internet.
>

But it's the "ignore any server failure" part that is the security
reduction, and that is not OE by your definition but "unathenticated TLS"
that you describe in the Appendix, right?

Here's a real example:  The EFF's HTTP Everywhere browser extension (
https://www.eff.org/https-everywhere).  It finds HTTPS connections even
when I just try to visit the HTTP site.  Does the browser displaying the
padlock hurt anything?  How does this reduce security for the Internet?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 03 Feb 2014 12:29:08 -0500

> padlock hurt anything?  How does this reduce security for the Internet?

https-everywhere (HTTPS-E) deliberately only includes rules for sites
which are believed to have a non-expired, valid X.509 certificate that
was issued by a member of the CA cartel, using standard https://, and
for which the content served over http is expected to match the content
served over https.  HTTPS-E also *enforces* HTTPS access, so if the web
servers for the sites flagged by HTTPS-E were to stop listening on port
443 or to stop negotiating TLS in the first place, (or an MiTM were to
make it look this way), the browser's connections to those sites would
break.

In these contexts, where the user is not vulnerable to an MiTM,
displaying a lock is reasonable, and is *not* what Paul is warning
against, if i understand the draft correctly.

Opportunistic encryption as declared by the draft is encryption that
*will* fail against an active attacker or MiTM.  It would be bad for the
'net if our tools were to indicate that MiTM-able connections are
"secure" using the same UI as non-MiTM-able connections.

	--dkg

---

From: Leif Johansson <[email-masked]>
Date: Mon, 03 Feb 2014 18:34:56 +0100

On 2014-02-03 18:13, Alan Johnston wrote:
> On Mon, Feb 3, 2014 at 10:30 AM, Paul Hoffman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Feb 3, 2014, at 7:28 AM, Alan Johnston
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > I'm less certain if the presence of a "transport=tls" parameter
>     in the SIP message violates Paul's rule about not indicating that
>     TLS has been used.
>
>     configures. If it is something set by the application developer
>     (in this case, to follow the requirements of the protocol), but is
>     not user-configurable, it's fine.
>
>     >  I'd need more explanation to understand this rule anyway, along
>     with the rule that no user configuration be allowed. It is not
>     clear to me how either of these does the harm that is described in
>     the Security Considerations section.
>
>     Consider the HTTP / browser case. You have set up a TLS-accessible
>     web site because security is good for the Internet, but you hate
>     paying for and configuring a certificate for obvious reasons. If
>     all common browsers let user say "always do TLS even for http:
>     URLs, and ignore any server failure", you would configure your web
>     server to do TLS with no certificate because that's good enough.
>     That's a security reduction for the Internet.
>
>
> reduction, and that is not OE by your definition but "unathenticated
> TLS" that you describe in the Appendix, right?
>
> Here's a real example:  The EFF's HTTP Everywhere browser extension
> (https://www.eff.org/https-everywhere).  It finds HTTPS connections
> even when I just try to visit the HTTP site.  Does the browser
> displaying the padlock hurt anything?  How does this reduce security
> for the Internet?

Thats different though - in that case you have a "valid" TLS server
cert, you just didn't know to ask for it.

The OE case is (imo) when the all the server has is a (possibly)
un-authenticated key. Displaying the padlock in that case is ...
questionable.
>  
>
>
>     > For VoIP and video calling in general, there is also the issue
>     of encryption of the media - to use SRTP or use unencrypted RTP.
>     For ZRTP, we developed an approach that could be considered
>     opportunistic in this definition, although we described it "best
>     effort encryption" (RFC 6189).  But that is a discussion for
>     another thread!
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 03 Feb 2014 12:51:15 -0500

> If folks like the idea of this definition, I think it would be appropriate for a WG document.

Thanks for framing this, Paul.  I think it's clear that the
"Opportunistic" mode you describe is superior to leaving everything in
the clear;  and i appreciate your draft's insistence that it not present
itself to the user as a well-authenticated connection, due to the
difference in vulnerability to an active attacker.

I understand that the purpose of the draft is not to document technical
mechanisms for doing this opportunistic encryption, but i can't help
trying to think through how it would work for HTTPS (i note that SMTP
already has a mechanism, more people just need to turn it on).

It occurs to me that one possibility is that user agents could just
enable the use of the HTTP upgrade mechanism described in RFC 2817.  I
don't know of any major browser that does this, or of any common web
server that implements it either.  Perhaps this means it's ripe for use
in this context?

The RFC even specifically leaves open the level of security expected
from such an upgraded connection:

 https://tools.ietf.org/html/rfc2817#section-8.1

I'm imagining a WWW user agent that would have something like the
following logic:

-----------------

 0) store two tables of web sites with recent refresh times, both
initially empty, named "UPGRADABLE" and "NOUPGRADE".

 1) for each new http:// connection to a site not in either table,
include the "Upgrade: TLS/1.2\r\nConnection: Upgrade" header.

    1a) if the site offers an upgrade, negotiate TLS on that link
(without requiring server certificates to match).  If the TLS
negotiation succeeds, store the hostname in UPGRADABLE with the current
timestamp; if it fails, store the site in NOUPGRADE with the current
timestamp.

    1b) if the site does not offer an upgrade, do not store the site in
either table, and continue with the cleartext connection.

 2) for each new http:// connection to a site in NOUPGRADE, do not
include the Upgrade: TLS/1.2 header, and do not attempt the upgrade
(this avoids a loop to a misbehaving server)

 3) for each new http:// connection to a site in UPGRADABLE, do not emit
the normal HTTP request in the first place, but start with an OPTIONS *
HTTP/1.1 request, the "Mandatory Upgrade" described here:
https://tools.ietf.org/html/rfc2817#section-3.2 -- this is to avoid
leaking the rest of the HTTP headers.

    3a) if the TLS negotiation succeeds, update the timestamp for the
site in UPGRADABLE

    3b) if the TLS negotiation fails, remove the site from UPGRADABLE
and restart the connection.

 4) at regular intervals, clear all UPGRADABLE and NOUPGRADE table
entries older than some fixed time window (1 week?)

-----------------

Obviously, web servers shouldn't use the above logic to promote "normal"
https -- for that, web servers should use the standard HTTP 301 Moved
Permanently (Location: https://…), combined with
Strict-Transport-Security header on the subsequent https response.

Does the above logic seem plausible?  I worry a bit about browser
fingerprinting and history leaking that might result from the UPGRADABLE
and NOUPGRADE tables, but it doesn't seem significantly worse than many
existing pieces of data retained by browsers about the sites they visit,
and i think it would provide a real gain in privacy against ubiquitous
passive monitoring.

Do other folks have concerns or suggestions or other ways we could
implement this for HTTP?

	--dkg

---

From: Alan Johnston <[email-masked]>
Date: Mon, 3 Feb 2014 13:19:52 -0600

See below.

On Mon, Feb 3, 2014 at 11:29 AM, Daniel Kahn Gillmor
<[email-masked]>wrote:

> *will* fail against an active attacker or MiTM.

I don't think that is a good way to define opportunistic encryption.

In my view, the opportunistic property of encryption (whatever we decide it
is) should not be conflated with authentication via a PKI, or PFS, or any
other orthogonal security property.

We need a definition of opportunistic that distills it down to the minimum
so we can talk about it sensibly.  The first sentence of Section 2 of
Paul's draft is an excellent start to the definition.

   An application supports opportunistic encryption using TLS if the
   application attempts to perform TLS negotiation without the user who
   is running the application knowing whether or not TLS is in use.

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.  An opportunistic
encryption system might also use PFS, do logging, cache keys, or any number
of other things.  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.

- Alan -

>  It would be bad for the

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 03 Feb 2014 15:10:31 -0500

On 02/03/2014 02:19 PM, Alan Johnston wrote:
> On Mon, Feb 3, 2014 at 11:29 AM, Daniel Kahn Gillmor <[email-masked]>wrote:
>

You'll note that i'm not defining it according to any of these specific
properties.  In particular, it's possible that a remote peer can use
PFS, with a cartel-issued X.509 cert, using AES-GCM and TLS 1.2, and
still be considered opportunistic.  Why?  Because if the same connection
had *not* had any of the above properties, the local networked
application would have gone ahead with the connection without them (even
to the point of making the connection in cleartext).

>    is running the application knowing whether or not TLS is in use.

I think the more salient property for "opportunistic" encryption is that
it is not forced to "on", and that the connection would continue
(perhaps unencrypted) even in the presence of an active attacker.  As
such, i agree with Paul's assessment that it makes no sense to display
this state to the user -- even if they happen to be encrypted on the
current connection, a subsequent connection the same options/choices
could easily be forced to cleartext, so it is not "secure" in the
traditional sense.

If an opportunistically-encrypted HTTP client receives from the server
the following headers:

  301 Moved Permanently
  Location: https://example.org/foo

, then the server is signalling that it is moving out of opportunistic
mode, and all the normal (non-opportunistic) rules should apply to the
subsequent https:// connection, and therefore the user-facing signalling
can be displayed on these subsequent connections.

> people conflate different things and use the same word.

I disagree that this is an unnecessary distraction, given the current
state of TLS on the web.

Many web sites fail to deploy TLS today because of one of two reasons:

 0) they have multiple sites hosted on the same webserver or CDN,
sharing an IP address, and they cannot expect all clients to offer SNI
(thanks to IE and Safari on Windows XP).

 1) they have administrators who balk at the cost or confusion or
ongoing maintenance hassle of getting an X.509 certificate from a member
of the CA cartel.

It is useful to clarify that neither of these constraints should
necessarily limit deployment of opportunistic TLS for the web.

	--dkg

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Feb 2014 13:32:17 -0800

> *will* fail against an active attacker or MiTM.  

Nope. Opportunistic encryption using TLS, as it is defined in the -00 draft, will work just fine with an MITM.

The second paragraph of Section 2 is:

   When an application that supports opportunistic encryption negotiates
   TLS, that application might or might not authenticate the TLS server.
   It is expected that the common case is that applications that
   supports opportunistic encryption will not authenticate the TLS
   servers they connect to.  However, it is acceptable for an
   application that supports opportunistic encryption to only complete
   the TLS negotiation if the TLS server can be validated.

So, it *might* fail against an active attacker or an MITM, but only if the application does what is described in the third sentence. The large expectation is that developers will do what it says in the second sentence, namely continue without authentication.

> "secure" using the same UI as non-MiTM-able connections.

That's true, but it is also different than "failing".

If the WG adopts the draft and wants to change the definition, of course it can. But the current definition absolutely allows the opportunistic client to ignore the server's authentication information in order to help prevent a passive snooper from seeing the traffic.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Feb 2014 13:34:38 -0800

On Feb 3, 2014, at 11:19 AM, Alan Johnston <[email-masked]> 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:
> 
> 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.

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

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Feb 2014 13:38:31 -0800

> already has a mechanism, more people just need to turn it on).

The HTTP people should define "how it would work for HTTPS" (from the charter, HTTP 1.1 only), and the SMTP people should define "how it would work for SMTP".

The purpose of this document is to give them a single model of "opportunistic encryption using TLS" to work from for their definition.

> It occurs to me that one possibility is that user agents . . .

There are many possibilities, and at least one should be defined in this WG for each of the protocols listed in our charter (and maybe more). However, this document should not attempt to cover them all or it will literally never be finished.

--Paul Hoffman

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 03 Feb 2014 16:42:11 -0500

> Nope. Opportunistic encryption using TLS, as it is defined in the -00 draft, will work just fine with an MITM.

I think i wasn't clear enough about what i meant by "fail".  Thanks for
catching that.

By "fail" i meant "not protect the user's confidentiality or
authenticity".  I did not mean "cause the connection to fail".

My understanding is that an active attacker who interrupts or MiTMs an
opportunistic encryption will likely be able to succeed at reading the
content of the communication, whether it's because the peers are willing
to proceed without authentication, or because the peers are willing to
fall back to cleartext.

> That's true, but it is also different than "failing".

Right, and i think your specification declares this properly.

> If the WG adopts the draft and wants to change the definition, of course it can. But the current definition absolutely allows the opportunistic client to ignore the server's authentication informat…

Sure, i'm agreeing with you about this, i think.  I don't think i
proposed a change in the definition.  if you think we're in
disagreement, can you clarify where?

	--dkg

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Feb 2014 13:46:37 -0800

> authenticity".  I did not mean "cause the connection to fail".

Ah, good. That's exactly right. And it's also why I didn't talk about TLS failing in the document. :-)

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Feb 2014 00:47:19 +0000

Hi Paul,

On 02/03/2014 04:43 PM, Paul Hoffman wrote:
>> 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).

>> 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 [email-masked] https://www.ietf.org/mailman/listinfo/uta
> 
>

---

From: Alan Johnston <[email-masked]>
Date: Tue, 4 Feb 2014 09:02:34 -0600

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 <[email-masked]> wrote:

> Unfortunately not, because authentication is inherently part of TLS, so we
> have to call out what in TLS we are doing differently.
>

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Feb 2014 08:18:00 -0800

On Feb 4, 2014, at 7:02 AM, Alan Johnston <[email-masked]> wrote:

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

No, I mean that the TLS RFC says that the client must authenticate the server unless one of the anonymous ciphersuites is used.

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

Yes, exactly.

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

The IETF has a long history of trying to come up with new terms when the old ones get too confusing. I'm pretty sure every effort has been a failure.

--Paul Hoffman