Re: New Version Notification for draft-thomson-http-encryption-00.txt

--------
In message <CABkgnnUfFJHXv6CLTu2MDWOmEihB=GEnH0ysXjxN4Mvg-yF6ew@mail.gmail.com>
, Martin Thomson writes:
>On 12 May 2015 at 10:50, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>> It's still the servers responsibility to enforce the overall policy
>> of encryption and laugh at such attacks.  (One logical reaction:
>> reply "use SSL instead then")
>
>That's a fair point, but the general view is that there might be
>clients that want to guarantee that upgrade when it is possible.  That
>is, the mutually agreed best option is chosen, even when an attacker
>is present.

I don't think that is a guarantee you can give, unless you reinvent
the entire SSL/TLS mess.

You'd have to have the server first send an encrypted response
saying "I saw you asking for these crypto parameters, does that
match what you sent ?" and you'd need to sign those messages
to ensure they're not forged etc.

There may be applications where that is worth the effort, but
if so it is way above our abstraction level (and crypto-skill).

For our purposes this is will have to be controlled by the guy
in uniform and his "crypto must be this tall to ride" sign on
the server.

So to summ up, this is what I think we should do:

   Accept-Encryption
	I can do these kinds of encryption
	For instance:  "rot13, aes128bla, aes256bla, keyid=ask_mom"

   We can explicitly make A-E advisory, so it is clear that the
   sender can try something stronger at the risk of failure.

   Content-Encryption
	This message is encrypted with these parameters
	For instance:  "aes128bla, keyid=ask_mom"

   And we should make it symmetric, so it can be used both for
   requests and responses.

   Vary: should match if the clients A-E contains all the fields of
   the responses C-E (but possibly ignoring salt= fields ?)

   Making Vary work this way would allow caching of pay-per-view video,
   and there are people who want that and who are hacking up stuff
   themselves for it these days.


PS: I fear that the double-encryption example will be misunderstood
as parallel encryption rather than serial encryption.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Tuesday, 12 May 2015 18:22:02 UTC