- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 12 May 2015 17:50:08 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
-------- In message <CABkgnnXMjTueG1LXXUQkd-UTdyEsNBuw2wdrzEzxuUGzo=wJiw@mail.gmail.com> , Martin Thomson writes: >On 12 May 2015 at 10:17, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: >> Which is why we should think about "Accept-Encryption" > >I think that the problem you are concerned with is why the Key >draft [1] exists. > >In this context, I don't see responses actually varying based on the >Accept-Encoding header field. Servers will encrypt based on their >needs more so than in reaction to clients claiming support. Think Internet-Of-Junk. Not everybody may support the same crypto algorithms, for reason of size, cpu-power, electrical power or laws. Being able to tell the server what the client can (and is allowed to) cope with, the server can better pick the right algo. >In fact, if we were to rely solely on Accept-Encoding (or create >Accept-Encryption), then we create the potential for a downgrade >attack if we ever need to define an alternative encryption encoding to >address flaws in this one. 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") Also: Without Accept-Encryption (of some kind), we have no way to phase in new and stronger crypto later on. -- 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 17:50:31 UTC