This is a review of The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect), draft-ietf-httpbis-rfc7238bis-02. I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is procedural only - it promotes the 308 redirect HTTP code from Experimental to Standards Track. The security considerations section refers to the section in RFC7231, which seems to be thorough. I was curious about one question that is general to all redirects, not this draft in particular. Suppose a server sent a redirect from a https secured URI to a http unsecured URI. What happens? Of course, the server is in a position to all sorts of evil stuff. But it seems that it would be worth a warning from the web browser to the user Answering my own question: From what I've found, I believe that redirects are included in the same-origin (RFC6454) and cross-origin CORS (see W3C doc) tests. A protocol change (https<->http) is enough to classify a request/redirect as cross-origin. (RFC7231 does not mention same-origin/cross-origin security concerns wrt the types of attacks/damage it considers. Perhaps the same-origin policy was so well-known as to be presumed.) Some sites say a cross-origin https->http redirect should fail. Some w3c sites I've seen indicate some inconsistency in the various browser CORS implementations, and a quick survey of colleagues indicates they see varying responses. And, of course, my quick survey could have led me astray as well. --Sandy Murphy P.S. Review another document, learn a little more. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail