Last Call Review of draft-ietf-httpbis-rfc7238bis-02
review-ietf-httpbis-rfc7238bis-02-secdir-lc-murphy-2015-02-05-00

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