Subject: [Uta] Opportunistic encryption and authentication agility

From: Trevor Perrin <[email-masked]>
Date: Fri, 21 Mar 2014 18:37:45 -0700

A point I haven't seen in the recent debate:

Whether a TLS connection is "opportunistic" or "authenticated" depends
not just on the wire protocol but on the client's capabilities.

A client who possesses an HPKP or TACK pin, or is capable of querying
DANE or Convergence, might be able to authenticate a connection which
to a different client would be opportunistic.

So when we talk about OE at the protocol level, I think we're really
talking about whether to allow agility of authentication methods, or
mandate a specific method.

In the case of HTTPS, the Web PKI has been mandated.  A small site
that doesn't want to pay the costs of Web PKI but would be willing to
deploy cheaper methods (pinning; DNSSEC/DANE) cannot do so.

If opportunistic TLS was allowed, then we would have the ability to
deploy new auth methods without having to forever support whatever was
in vogue when the initial standard came out.

I think that argues in favor of opportunistic TLS, for HTTP and other protocols.

Trevor

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 22 Mar 2014 03:50:45 +0100

> mandate a specific method.
We should, yes. And we should get rid of the term "opportunistic". It
seems to me that a lot of people do mean different things by that. Not
necessarily on this ML: Just Google through blogs and search twitter.

But I certainly do not want to start up this discussion again. The thing
is, we need to be clear on what we define as "opportunistic".

> deploy cheaper methods (pinning; DNSSEC/DANE) cannot do so.
Common sense tells you that trust is not something you can buy. Trust
has to be earned, just like in the real world, and proven over and over
again.

I have repeated myself for the last couple of years on this issue, and
am repeating myself almost continuously since last summer: just get rid
of X.509 for trust on the internet. On local scale it might make sense,
it does not, however, on a widely dispersed and distributed system.

TACK is an elegant proposal that might in the end be able to fade out CA
bound trust as in use today. I hope it does get accepted and deployed,
as of today I cannot see any reason why it shouldn't be.

> in vogue when the initial standard came out.
+1

> I think that argues in favor of opportunistic TLS, for HTTP and other protocols.
+1

Aaron

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Mar 2014 22:51:28 -0400

> mandate a specific method.
Partly.   And again, I expect that the mandate will be different for 
different protocols.

Note that as far as I can tell, it will still be possible to implement a 
client that supports only OE; it just doesn't bother verifying the cert 
/ DNSSEC + TLSA record / pinned key / whatever.    Whether that client 
will conform to the recommendations that this group produces, is a 
different question.   But offhand I don't know of a way to keep such 
clients from working (though for new protocols, it might be nice if 
there were one).

Similarly, even if we require TLS for some protocols, it will still be 
possible for a server to supply a self-signed cert with no additional 
validation; then it becomes up to the client to decide what to do with 
that.   We can make recommendations (or "mandates"), but we can't force 
clients to behave in any particular way.     And of course there will be 
some protocols for which it's impractical to require TLS in the near 
term, or maybe ever; e.g. cleartext operation for SMTP mail relaying is 
so well-entrenched that it might be harder to transition to all-TLS SMTP 
than it has been to transition to all-IPv6.

So our task is to make recommendations that server operators and client 
implementors want to implement, but which still improve security in the 
near term - and (perhaps more importantly) which also leave room for 
security to get better in the future.   To me this says that to endorse 
bare OE for any particular application should be an absolute last 
resort.   There should always be _some_ way for clients to learn which 
servers can be expected to support authenticated encryption, even if 
that varies from one application/protocol to the next.

Another subtlety:  There can be a difference between what we "mandate" 
for client and server implementations, versus what we "mandate" for 
services.   Example:   If a web site that does nothing but supply free 
information to unauthenticated parties doesn't want to support 
authenticated encryption, maybe that's just fine.   We might still want 
to "mandate" authenticated encryption for web sites that provide access 
to sensitive information, or for which user authentication is otherwise 
necessary.   But independent of the requirement for services, web client 
implementations could still be required (maybe as a SHOULD) to support 
authenticated encryption (using server certs, TLSA, pinning, or whatever 
set of methods were deemed appropriate to mandate).

> deploy cheaper methods (pinning; DNSSEC/DANE) cannot do so.

Who has mandated the "Web PKI" as the only way to verify a server 
cert?   Is this carved in stone?

> I think that argues in favor of opportunistic TLS, for HTTP and other protocols.

I don't get it.  If the UTA WG can recommend that web clients permit OE, 
why can't it just as easily recommend that web clients treat OE (from a 
UI perspective) as no better than cleartext, but support pinning and/or 
DANE TLSA as alternative ways to verify a server cert to provide some 
indication to the user that the connection is secure?

Keith

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 21 Mar 2014 23:54:37 -0700

On Fri, Mar 21, 2014 at 7:51 PM, Keith Moore <[email-masked]> wrote:
> implementors want to implement, but which still improve security in the near
> term - and (perhaps more importantly) which also leave room for security to
> get better in the future.   To me this says that to endorse bare OE for any
> particular application should be an absolute last resort.

I'm not sure how much we disagree.  Of course authentication is better
than none.

But I disagree with the HTTPS approach of disallowing encryption
unless it can be done with an IETF-approved method of authentication
and signalled to the user as a secure connection.

I think we should have the ability to encrypt HTTP using new auth
methods which may or may not get signalled.  That would lower the bar
for experimenting with and deploying new methods.

> Who has mandated the "Web PKI" as the only way to verify a server cert?   Is
> this carved in stone?

I'm talking about mandates on the server.

The installed base mandates that any HTTPS URL requires a valid cert.
That pretty much *is* carved in stone.

> I don't get it.  If the UTA WG can recommend that web clients permit OE, why
> can't it just as easily recommend that web clients treat OE (from a UI
> perspective) as no better than cleartext, but support pinning and/or DANE
> TLSA as alternative ways to verify a server cert to provide some indication
> to the user that the connection is secure?

Sounds great, that's what I want.

Trevor

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Mar 2014 18:32:13 -0400

Keith Moore <[email-masked]> wrote:
    > client that supports only OE; it just doesn't bother verifying the cert /
    > DNSSEC + TLSA record / pinned key / whatever.    Whether that client will
    > conform to the recommendations that this group produces, is a different
    > question.   But offhand I don't know of a way to keep such clients from
    > working (though for new protocols, it might be nice if there were one).

Well, that's not really correct advice.
The correct advice is that:
   If the client is unable to verify the cert via (some set of methods,
   locally determined), that it treats the connection as if it was
   unencrypted, according the same level of (un)privileges.

This is the important part of OE (the spirit of 4322, if you like).
   It isn't that one doesn't verify, it's that one doesn't fail if
   one is unable to verify.

If you never verified any certificates, you'd never be able to know when you
have an actual priveledged connection.  For instance, doing authenticated
SMTP relaying (via certificate) is pretty important to many.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Eliot Lear <[email-masked]>
Date: Mon, 24 Mar 2014 07:00:26 +0800

Hi Michael,

>    unencrypted, according the same level of (un)privileges.

Perhaps I misread Keith's note, but I didn't take it as advice.  Rather
he's assessing the current situation. 

Your advice seems reasonably applicable for mail, at least at first
blush.  But different protocols have different anticipated environments,
and I took Trevor's email Keith's replies to be more general
statements.  My favorite example going the other way is SCIM, where you
would have to be crazy not to fully validate both ends.  I don't know if
it's in the UTA charter, but we discussed developing a general guidance
document in the STRINT workshop to at least help sort out the classes of
(at least envisaged) use.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Mar 2014 21:58:00 -0400

> he's assessing the current situation.

I read it as "this is how to implement OE". He wrote:

  keith> Note that as far as I can tell, it will still be possible to
  keith> implement a client that supports only OE; it just doesn't bother
  keith> verifying the cert / DNSSEC + TLSA record / pinned key / whatever.
  keith> Whether that client will

    > statements.  My favorite example going the other way is SCIM, where you

SCIM == System for Cross-domain Identity Management (?)
     http://datatracker.ietf.org/wg/scim/charter/
     (there are other options to expand that acronym)

Does SCIM have a mode where it is happy (and meaningful) to run unencrypted?
I see in the charter talk about HTTP vs HTTPS.
Reading three pages of the API document, it seems that one could run
LIST/RETRIEVE operations in the clear.

So, actually, I think that my advice is exactly correct.

If the certificates for HTTPS do not verify, then you should treat the
connection exactly as you would if it occured over HTTP.  If that
means that the client shouldn't trust what the server says, then
that's what the client should do.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eliot Lear <[email-masked]>
Date: Mon, 24 Mar 2014 15:00:36 +0800

> Does SCIM have a mode where it is happy (and meaningful) to run unencrypted?

Technically?  It might be possible.  Pragmatically, an implementer
should be loathe to offer such functionality.
> LIST/RETRIEVE operations in the clear.

Again, given the information that is being carried, while it is
possible, it wouldn't be advisable, due to potential for PII being
exposed (for instance).
> that's what the client should do.

I guess where we come together is that this has to be addressed based on
target use cases, including who is operating the tool, the scale of
deployment, and the sensitivity of the data, to name a few.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Mar 2014 08:31:38 -0400

> should be loathe to offer such functionality.

So, if it is never secure without HTTPS, then there is no point in talking
about any kind of opportunistic mode.

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Mar 2014 10:36:47 -0400

> Well, that's not really correct advice.

As Eliot Lear pointed out, it's not intended as advice; it's just a 
recognition of the inherent limitations of the situation that we face.  
However...

>     unencrypted, according the same level of (un)privileges.

The "correct" advice is highly dependent on the needs of each particular 
application, AND for existing applications, on the current expectations 
of users and the difficulty of changing those expectations.

>     It isn't that one doesn't verify, it's that one doesn't fail if

I strongly doubt that this is appropriate advice for all (or even most) 
applications or protocols.   In particular, if there's some reason to 
believe that a server intended to provide a verifiable cert, if that 
cert is in fact not verifiable, this is an error condition that 
shouldn't (inherently) be masked by silently treating the connection as 
if it were cleartext.

The biggest reason that cleartext is still so widely used today in some 
protocols that support TLS, is that in practice for those protocols, 
cleartext is sufficient to get clients to work without complaint.  If 
clients continue to work without complaint for sites that support TLS 
with self-signed certs, there will be no incentive for services to 
provide anything other than self-signed certificates.

Yes, it's more work and expense for a site to maintain valid CA-signed 
certs.  But if clients complain when they're not there, providing 
CA-signed certs becomes "part of the cost of doing business", just like 
maintaining DNS records, keeping software up-to-date, and so forth.  If 
clients don't complain when given invalid certs, providing CA-signed 
certs will widely be seen as an unnecessary nuisance.

We should of course realize that for some cases (perhaps ordinary web 
sites, or SMTP servers serving as mail exchangers) there is so much 
inertia around cleartext operation, and so little affinity between 
clients and servers, that it will be very difficult to do better than 
OE.  Perhaps in those cases treating TLS with a self-signed cert as 
equivalent to cleartext will be the best we can ever do, though even in 
these cases I think we should carefully consider other options.   But we 
should not lull ourselves into thinking that this is appropriate as a 
general rule, so that we fail to examine the potential alternatives for 
other situations or protocols.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Mar 2014 11:44:41 -0400

Keith Moore <[email-masked]> wrote:
    > applications or protocols.   In particular, if there's some reason to believe
    > that a server intended to provide a verifiable cert, if that cert is in fact
    > not verifiable, this is an error condition that shouldn't (inherently) be
    > masked by silently treating the connection as if it were cleartext.

If you have "some reason", then you must have pre-configuration of a
bilateral nature.    That clue can certainly be automatic; such as coming
From a DNS(SEC) DANE certificate of the right type, or an application
asserting some kind of channel binding.

    > Yes, it's more work and expense for a site to maintain valid CA-signed certs.

That is no longer the only option.

    > cleartext operation, and so little affinity between clients and servers, that
    > it will be very difficult to do better than OE.

I really think it's important that people not think of OE as a step towards
something else.

If plaintext is unacceptable, then it's not OE: it's DANE signaled
SMTP(STARTTLS), or ...

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Mar 2014 00:05:45 +0800

Michael

> about any kind of opportunistic mode.

Exactly.  Sometimes we have to "just say no".  Characterizing those
times is helpful, IMHO.  There is also the opposite side, where no
encryption should be used (think discovery & distress protocols).

Eliot

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Mar 2014 12:10:44 -0400

> asserting some kind of channel binding.

DANE isn't "pre-configuration of a bilateral nature" and no, "some 
reason" isn't limited to such pre-configuration.
> That is no longer the only option.

I didn't say it was.

> I really think it's important that people not think of OE as a step towards

I think it's silly to artificially limit the applicability of OE. We 
have few enough tools already without deliberately hampering our ability 
to use them.

Keith

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 24 Mar 2014 12:20:45 -0400

On 03/24/2014 10:36 AM, Keith Moore wrote:

> maintaining DNS records, keeping software up-to-date, and so forth.

I think you're making an argument about visibility to the user, not
about actual best practices.

I note that many large organizations regularly do *not* pay "the cost of
doing business", especially in terms of keeping software up-to-date,
witness the huge deployments of Windows XP and Windows Server 2003
expected to still be in use long after Microsoft's long-delayed
end-of-life of the OS.  Keeping software up-to-date is generally *not*
visible to the user, and thus isn't considered a "cost of doing business".

Keeping accurate DNS records *is* part of the cost of doing business,
because users can't see an organization's network services if they can't
find the address.

Since all of the "opportunistic" proposals i've seen indicate that the
use of opportunistic crypto will not be visible to the user, the
incentives for well-authenticated endpoints will remain the same as they
currently are: services which fail to get some flavor of strong
authentication (whether that's PKIX or DANE or something else) will not
get to see any "this connection is secure" UI decorations.  That is,
this *is* a visibilty-to-the-user issue, and the user sees the same old
insecure state.  So if "having a visibly secure connection" is the cost
of doing business, opportunistic encryption is not enough.

Users should *not* be told that communications are "secure" when they
are vulnerable to trivial active attack.

	--dkg

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Mar 2014 12:36:13 -0400

> about actual best practices.
I'm making multiple arguments.  One of them is that if users don't know 
the difference, there's less incentive for services to use encryption or 
upgrade their encryption.  Another is that user expectations (among 
other things of course) help determine the "cost of doing business" for 
services.

> visible to the user, and thus isn't considered a "cost of doing business".

You're talking about workstation software, I'm talking about the 
software used to run servers, so they're not the same thing.    In 
today's hostile network environment, if you don't bother keeping your 
servers up-to-date, you will be attacked (often, and often 
successfully), and for one reason or another, you will find it difficult 
to keep operating.   It's hard enough to cope with zero-day exploits, 
but if you don't cope with widely-documented exploits for which ready 
fixes exist you deserve to lose.

> because users can't see an organization's network services if they can't

Yup.   And so is keeping your servers running and not swamped by attacks 
of various kinds; hence the need to keep them up to date. Hope that 
helps clarify what I was talking about; sorry if I wasn't sufficiently 
clear earlier.

> are vulnerable to trivial active attack.
I certainly agree with the last sentence.

So, what's the incentive for either clients or servers to support OE if 
clients just silently accept it without any indication to the user?   
Just for the good of mankind?   While I agree that pervasive OE would be 
better than pervasive cleartext, and also agree that the use of OE 
shouldn't give users any indication that the connection is "secure", I 
think we should be realistic about the likelihood of clients 
implementing OE and services using it.   And while I'm sure that 
sometimes implementors and operators will do things "for the good of 
mankind", I suspect there's a limit to how much effort and expense 
they'll go to for this reason.   This doesn't mean "don't even bother 
recommending OE", but it seems like something we should keep in mind.

Keith

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 24 Mar 2014 12:51:32 -0400

On 03/24/2014 12:36 PM, Keith Moore wrote:

> Just for the good of mankind?

I'd say "to increase the cost of pervasive monitoring" and "to resist
surveillance by passive attackers"

> I think we should be realistic about the likelihood of clients

I think we want as much of this to happen automatically in software
without users or server administrators needing to fiddle with any
settings or noticing any changes.  If client software or server software
gets upgraded (in the usual course-of-doing-business as you suggest)
then these features should Just Work™ and it should take deliberate and
non-default action by server administrator or end user to *disable* them.

	--dkg

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 25 Mar 2014 13:09:41 -0700

> surveillance by passive attackers"

I'd go further - OE for HTTP could have strong auth added to it in the
future, such as pinning or DANE, which *could* be indicated to the
user.

So encryption-without-WebPKI is not just a step away from strong auth,
it's also a step towards
encryption-without-WebPKI-BUT-WITH-EASIER-STRONG-AUTH.

I think a lot of the concern around OE is about the "second-order"
effect of discouraging strong-auth ("it's encrypted, why do more?"),
but I think this a different second-order effect ("I can do pinning
without needing a cert!") which should be considered.

Trevor

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Mar 2014 16:24:17 -0400

> future, such as pinning or DANE, which *could* be indicated to the
Why wait?   Even if pinning, DANE, or whatever (as appropriate for that 
particular protocol) weren't required immediately, we might as well 
specify it now.

Maybe we could even recommend a transition schedule - e.g. clients could 
ignore the lack of AE for X years after adoption, after which they'd 
start providing some sort of warning indication if recommended form of 
AE were not present.  After Y years, they'd refuse to connect without 
AE.   Obviously the details and the assumed transition dates would have 
to vary according to the deployment considerations for that particular 
protocol, and they should perhaps even be implementation-configurable, 
but we might as well start encouraging implementation and testing now.   
Site developers could set the transition dates to sooner in order to 
test features in advance of users' clients actually complaining.

The point is: if you're going to install stepping stones, don't stop 
after placing the first stone and assume that the others will be placed 
eventually.   We have a rare opportunity in which there is considerable 
public interest in improving communications privacy. We should not 
squander it by specifying only that which is easiest to do.

Also: it is unlikely that we'll improve privacy in practice without also 
raising user expectations.

Keith

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 25 Mar 2014 13:24:46 -0700

> future, such as pinning or DANE, which *could* be indicated to the

Please be cautious about suggesting user indications. UI is complicated and
all that. More specifically in the browser case, even if you could strongly
authenticate a connection over which you request a http:// page, I wouldn't
want to give that page the https lock treatment. Note that https:// has
different semantics (referer semantics, mixed content, etc). If you are
loading http:// subresources like scripts over insecure connections, then
even though the page may have been loaded over a secure connection, it's
still insecure. I assume that OE for HTTP wouldn't opportunistically
upgrade a http:// page to https:// page semantics, as that would introduce
lots of web compatibility issues.

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

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 25 Mar 2014 13:47:26 -0700

On Tue, Mar 25, 2014 at 1:24 PM, William Chan (陈智昌)
<[email-masked]> wrote:
> different semantics (referer semantics, mixed content, etc).

Good points, thanks.  Maybe adding other auth methods to HTTP-over-TLS
would be best done silently, with no UI unless a security failure
occurs?

I think I like that, as I think catching "badness" is more useful than
indicating "goodness".  But these are hard Qs, I'm just trying point
out some possibilities at this point.

Trevor

---

From: Watson Ladd <[email-masked]>
Date: Tue, 25 Mar 2014 19:11:28 -0400

> would be best done silently, with no UI unless a security failure

Sadly this doesn't work. If I can imitate the website because of a
WebPKI failure, I can pretend to not support whatever additional auth
is done. It's the reason OCSP stapling doesn't work.

Furthermore, taking an economic perspective, authentication has a
winner-take-all aspect to it. A new client has to support the
authentication everyone already uses. But a site only has to support
the authentication the client accepts. Any new authentication
mechanism will only be adopted in domains where the existing one
doesn't work.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 25 Mar 2014 16:36:03 -0700

On Tue, Mar 25, 2014 at 4:11 PM, Watson Ladd <[email-masked]> wrote:
>> Maybe adding other auth methods to HTTP-over-TLS
> is done.

Not necessarily.

Consider pinning - the browser could remember some security policy for
a site, and apply it to future HTTP-over-TLS connections.

Or consider a plugin that performs online lookups to (Convergence /
Perspectives / DNSSEC etc) for HTTP-over-TLS sites, and raises an
error if the site's keys are suspicious, or the lookup server can't be
reached.

These are things that could be built on top of "opportunistic
encryption" for HTTP, so my point is that OE could be about more than
just passive eavesdropping.

Trevor

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Mar 2014 20:04:04 -0400

On 03/25/2014 04:47 PM, Trevor Perrin wrote:
>> >authenticate a connection over which you request ahttp://  page, I wouldn't
>> >want to give that page the https lock treatment. Note thathttps://  has
Please be cautious about suggesting user indications.  UI is complicated 
and all that.

Let me put that another way:  Off-the-cuff suggestions for what the 
HTTP-over-TLS UI should look like, in the absence of (a) analysis and 
(b) significant input from HTTP experts, will almost certainly be wrong.

For that matter, HTTP is a protocol, not an application or user 
interface.  A web browser is just one of many kinds of applications that 
use HTTP, and many of those applications aren't even interactive.   For 
this reason also, generalizations about what the HTTP-over-TLS UI should 
look like will also almost certainly be wrong.   Different applications 
using HTTP-over-TLS will need different ways of handling success or 
failure to negotiate AE.

For the specific case of web browsers:   I seriously doubt that adding 
other auth methods to web browsers using HTTP-over-TLS should be done 
silently, as then there would be no incentive for sites to provide the 
additional authentication information.

Keith