Well,
a) this doesn't help for non-HTTPS traffic, anb
b) in case of a captive portal intercepting https traffic, we would
expect a certificate error, no?
Anyway; this is not a security consideration specific to 511, but
applies to captive portals in general, no matter whether the new status
code is used or not. As such, it *could* be added to Appendix B.
Best regards, Julian
On 2012-01-30 16:22, Stephen Hanna wrote:
Yes
-Steve
-----Original Message-----
From: Julian Reschke [mailto:julian(_dot_)reschke(_at_)gmx(_dot_)de]
Sent: Monday, January 30, 2012 10:10 AM
To: Stephen Hanna
Cc: Mark Nottingham;
draft-nottingham-http-new-status(_at_)tools(_dot_)ietf(_dot_)org;
secdir(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: secdir review of draft-nottingham-http-new-status-03
On 2012-01-30 16:05, Stephen Hanna wrote:
Mark,
I don't want to rehash the discussion that we've already had.
Clearly, you prefer brevity while I would prefer education in
this instance.
I can live with your text for status codes 428, 429, and 431. For
511, I don't think it's adequate to just say that big security
issues already exist. You should at least give some suggestions
for how to deal with them. For example, you could point out that
most user agents include some indication of whether the server
has been authenticated. For captive portals, this indication will
generally not be displayed so the user receives some warning
that the response did not come from the requested URL.
Are you referring to HTTPS?
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf