Subject: Getting our definitions of encryption straight for the HTTP/2 security discussion

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Nov 2013 13:24:52 -0800

Greetings again. Over the past weeks, people are sometimes talking past
each other when they say they want to "always encrypt" HTTP/2 traffic. In
specific, many people have used the term "opportunistic encryption" in very
different ways without knowing it.

To help people at least understand what each other might be saying in the
future, I created a page with some definitions that hopefully everyone can
use. Comments are welcome.

http://trac.tools.ietf.org/wg/httpbis/trac/wiki/encryption-definitons

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Nov 2013 00:46:15 +0200

On 20/11/13 11:24 PM, Paul Hoffman wrote:
> Greetings again. Over the past weeks, people are sometimes talking 
> past each other when they say they want to "always encrypt" HTTP/2 
> traffic. In specific, many people have used the term "opportunistic 
> encryption" in very different ways without knowing it.
>
> To help people at least understand what each other might be saying in 
> the future, I created a page with some definitions that hopefully 
> everyone can use. Comments are welcome.
>
Too bad Authenticated Encryption has another meaning, but I think this 
terminology is clear enough.

But your 'best effort' and the one for 'opportunistic' seem to be such 
that encryption always happens, but it could be authenticated or 
unauthenticated. We need a term for a process where encryption may or 
may not happen, and if it does, it may or may not be authenticated.

Yoav

---

From: Michael Sweet <[email-masked]>
Date: Wed, 20 Nov 2013 18:02:59 -0500

My only comment is that current HTTP/1.1 supports opportunistic encryption via RFC 2817 (HTTP Upgrade to TLS).  Both the client and server can initiate an upgrade.

On Nov 20, 2013, at 4:24 PM, Paul Hoffman <[email-masked]> wrote:

> Greetings again. Over the past weeks, people are sometimes talking past each other when they say they want to "always encrypt" HTTP/2 traffic. In specific, many people have used the term "opportunistic encryption" in very different ways without knowing it.
> 
> To help people at least understand what each other might be saying in the future, I created a page with some definitions that hopefully everyone can use. Comments are welcome.
> 

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Nov 2013 23:06:30 +0000

> may not happen, and if it does, it may or may not be authenticated.

If we need to debate these terms before they're useful enough
for this wg, then I suggest we do that on the saag list so as
not to further confuse things here.

If however these are good enough for the httpbis wg's current
discussion, then I'd say let's just go with what Paul suggests.

And while I'd define things differently, I do think these are
good enough for here and now so I'd suggest just trying to
use 'me here (but adding more as needed) and after this wg
are done with this discussion we can take this to saag and
consider it in a broader context at more leisure.

S.

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 21 Nov 2013 10:54:26 +1100

> http://trac.tools.ietf.org/wg/httpbis/trac/wiki/encryption-definitons

“Authenticated Encryption” is a poor choice of term for server-authenticated TLS. “Authenticated Encryption” is already a well-defined term of art in the crypto community with a different meaning. There is even an Authenticated Encryption RFC [RFC 5116].

Perhaps better terms would be:
* Server-authenticated encryption — client authenticates server’s identity
* Better-than-nothing encryption — no server authentication 
* Best-effort encryption — client tries server-authenticated encryption, but falls back to better-than-nothing encryption if necessary
* Opportunistic encryption — client tries best-effort encryption, but falls back to no encryption if necessary

P.S. Better-than-nothing security (BTNS) is an unauthenticated mode of IPsec defined in RFC 5386.

--
James Manger

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Nov 2013 16:15:38 -0800

Does any major client/server support RFC 2817? I ignored it because I was
told it was not implemented, but if there is much use, it should be added.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Nov 2013 16:18:48 -0800

The idea of "try for encryption but fall back to clear text" has been
discussed many times in the IETF, usually ending in great acrimony against
the idea. Thus, I didn't include it.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Nov 2013 16:20:04 -0800

I agree that my earlier term  "authenticated encryption" would have
collisions with other technologies, and I updated the definitions to match
James' wording.

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 21 Nov 2013 00:40:36 +0000

Hi Paul

not sure I like much the text for the opportunistic.

STARTTLS in SMTP/IMAP works by the server firstly advertising 
availability of encryption.  This would only trigger a client to 
actually ask for it only if the client were so configured.  In many mail 
clients for instance, this won't actually cause any encryption to happen 
at all with default config.  So there's no contract about making any 
best effort to achieve crypto.  It can be no effort and no crypto and 
commonly is.

So maybe this doesn't describe what is meant by opportunistic encryption 
and we need another term, or do we change the meaning?

Adrien

------ Original Message ------
From: "Paul Hoffman" <[email-masked]>
To: "Manger, James H" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 21/11/2013 1:20:04 p.m.
Subject: Re: Getting our definitions of encryption straight for the 
HTTP/2 security discussion
>collisions with other technologies, and I updated the definitions to 
>match James' wording.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Nov 2013 11:54:08 +1100

Thanks Paul - that's helpful. I've moved it over to <https://github.com/http2/http2-spec/wiki/Encryption-Terminology> (since all of the other HTTP/2 material is there) and linked from the most relevant issue, <https://github.com/http2/http2-spec/issues/315>.

Would you agree that the distinction between better-than-nothing encryption and best-effort encryption is only important if someone chooses to do something with the information that server auth is or is not in place?

Keeping in mind that the "someone" is either going to be the UA (e.g., by changing its security indications to the user), or the origin server (and I *think* the only meaningful thing here would be to allow them to opt out of unauthenticated connections).

Mind you, I think it's OK if we specify best-effort and people use it just to get better-than-nothing encryption, provided it doesn't increase complexity too much; just making sure I understand the difference.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Nov 2013 17:04:22 -0800

You are right that the examples of STARTTLS do not match the definition;
I'll remove them. What is important for the definition is that
"opportunistic" match what it means in other protocols in the IETF, and I
believe that almost always is "try even if you weren't asked to".

On Wed, Nov 20, 2013 at 4:40 PM, Adrien de Croy <[email-masked]> wrote:

> STARTTLS in SMTP/IMAP works by the server firstly advertising availability
> of encryption.  This would only trigger a client to actually ask for it
> only if the client were so configured.  In many mail clients for instance,
> this won't actually cause any encryption to happen at all with default
> config.  So there's no contract about making any best effort to achieve
> crypto.  It can be no effort and no crypto and commonly is.
>
> Subject: Re: Getting our definitions of encryption straight for the HTTP/2
> security discussion
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Nov 2013 17:12:28 -0800

On Wed, Nov 20, 2013 at 4:54 PM, Mark Nottingham <[email-masked]> wrote:

> Thanks Paul - that's helpful. I've moved it over to <
> https://github.com/http2/http2-spec/wiki/Encryption-Terminology> (since
> all of the other HTTP/2 material is there) and linked from the most
> relevant issue, <https://github.com/http2/http2-spec/issues/315>.
>

Thanks

> Would you agree that the distinction between better-than-nothing
> encryption and best-effort encryption is only important if someone chooses
> to do something with the information that server auth is or is not in place?
>

No. Better-than-nothing is an end-state: definitely unauthenticated.
Best-effort is a process: try for server-encrypted but fall back to
better-than-nothing if that isn't possible. If there is a good way to
indicate that the first two definitions are end states, but the latter two
are processes, that would be great.

> Keeping in mind that the "someone" is either going to be the UA (e.g., by
> changing its security indications to the user), or the origin server (and I
> *think* the only meaningful thing here would be to allow them to opt out of
> unauthenticated connections).
>

I agree with the first part (what to show the end user for the end states)
is a good idea. I'm still very hesitant on the second part where the client
tells the server "I'm not authenticating you" and the server then stops the
connection. I would want to hear more use cases for that choice. It seems
to me that the server might want to do something different with the
connection, but "I'm just stopping" seems like a big change in our current
model.

> Mind you, I think it's OK if we specify best-effort and people use it just
> to get better-than-nothing encryption, provided it doesn't increase
> complexity too much; just making sure I understand the difference.
>
>
That's exactly my concern with the server stopping: that's a new state the
client needs to deal with. I don't want clients lying to the server about
authenticating just to keep the connection going.

--Paul Hoffman

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 21 Nov 2013 01:23:14 +0000

we may be missing a case from the list then.

If crypto is going to be truly a choice of the server operator whether 
they will deploy it etc, then the protocol would need to support:

* advertisement by server (or not)
* choice by client (or not)

E.g. basically the same as STARTTLS works today (which we have a fairly 
good amount of experience with).

Whether a client would choose crypto if advertised I would imagine 
should be a choice of the user.  Whether crypto is offered is a choice 
of the server operator.

Adrien

------ Original Message ------
From: "Paul Hoffman" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Manger, James H" <[email-masked]>; 
"[email-masked]" <[email-masked]>
Sent: 21/11/2013 2:04:22 p.m.
Subject: Re: Getting our definitions of encryption straight for the 
HTTP/2 security discussion
>You are right that the examples of STARTTLS do not match the 
>definition; I'll remove them. What is important for the definition is 
>that "opportunistic" match what it means in other protocols in the 
>IETF, and I believe that almost always is "try even if you weren't 
>asked to".
>
>
>>actually ask for it only if the client were so configured.  In many 
>>mail clients for instance, this won't actually cause any encryption to 
>>happen at all with default config.  So there's no contract about 
>>making any best effort to achieve crypto.  It can be no effort and no 
>>crypto and commonly is.
>>
>>So maybe this doesn't describe what is meant by opportunistic 
>>encryption and we need another term, or do we change the meaning?
>>
>>Adrien
>>
>>
>>
>>
>>
>>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Nov 2013 19:58:55 -0800

> are processes, that would be great.

That seems like an important distinction.  If you want to try writing
text up to address those points (process v. end state), I'm sure we
can get that up on the wiki.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Nov 2013 14:57:39 +1100

On 21/11/2013, at 12:12 PM, Paul Hoffman <[email-masked]> wrote:

> If there is a good way to indicate that the first two definitions are end states, but the latter two are processes, that would be great.

Done.

---

From: Michael Sweet <[email-masked]>
Date: Wed, 20 Nov 2013 23:23:17 -0500

CUPS has supported it for 10 years and it is required for AirPrint.

Sent from my iPad

> On Nov 20, 2013, at 7:15 PM, Paul Hoffman <[email-masked]> wrote:
> 
> Does any major client/server support RFC 2817? I ignored it because I was told it was not implemented, but if there is much use, it should be added.
> 
> --Paul Hoffman
>