- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 04 Feb 2015 15:27:45 +0100
- To: Barry Leiba <barryleiba@computer.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
- CC: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, "httpbis-chairs@tools.ietf.org" <httpbis-chairs@tools.ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>, draft-ietf-httpbis-rfc7238bis@tools.ietf.org, The IESG <iesg@ietf.org>
On 2015-02-04 15:26, Barry Leiba wrote: >>> We *could* point out the problem, but then, there are so many other similar >>> problems applicable to non-encrypted HTTP that I really don't see why this >>> one deserves to be called specifically. >> >> The reason is that this draft is just about that feature. Since it's >> a risk not covered in the pointer, it should be in this draft. If we >> don't point these things out, stuff won't ever get better. I'm not >> asking for MUSTs, although I'd like it, I don't think it's practical. > > For what it's worth, my view as responsible AD: > > - Julian is right that this belongs in the HTTP spec, not in this > document, but... > > - This document is an available and reasonable place to make the > point, as an informative thing. > > I would not object, and I think it would be a good idea, to include a > very short paragraph that goes something like this: > > << Unsecured http is always subject to redirect attacks, in that a > "man in the middle" can replace any http response with a redirect > (such as to a malicious site or one benefiting the attacker). Such an > attack can use "permanent" redirect codes (301 or 308) to convince > clients or proxies to cache the malicious information. Secured https > is not subject to these sorts of attacks. >> > > I can't imagine that there'd be any controversy about text such as > that... and it only informs, and does not give any new requirements. > > Julian, Mark, others: what do you think? > > Barry LGTM. Best regards, Julian
Received on Wednesday, 4 February 2015 14:29:04 UTC