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

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" <paul.hoffman@gmail.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Manger, James H" <James.H.Manger@team.telstra.com>; 
"ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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".
>
>
>On Wed, Nov 20, 2013 at 4:40 PM, Adrien de Croy <adrien@qbik.com> 
>wrote:
>>
>>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" <paul.hoffman@gmail.com>
>>To: "Manger, James H" <James.H.Manger@team.telstra.com>
>>Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
>>Sent: 21/11/2013 1:20:04 p.m.
>>Subject: Re: Getting our definitions of encryption straight for the 
>>HTTP/2 security discussion
>>>I agree that my earlier term  "authenticated encryption" would have 
>>>collisions with other technologies, and I updated the definitions to 
>>>match James' wording.
>