[secdir] secdir review of draft-ietf-httpbis-rfc7238bis-02

Sandra Murphy <sandy@tislabs.com> Mon, 02 February 2015 20:29 UTC

Return-Path: <sandy@tislabs.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E001A8AD4 for <secdir@ietfa.amsl.com>; Mon, 2 Feb 2015 12:29:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Level:
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPoC7NJkxavk for <secdir@ietfa.amsl.com>; Mon, 2 Feb 2015 12:29:42 -0800 (PST)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6381A03B3 for <secdir@ietf.org>; Mon, 2 Feb 2015 12:29:41 -0800 (PST)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 148A628B0053; Mon, 2 Feb 2015 15:29:41 -0500 (EST)
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id AA2271F8035; Mon, 2 Feb 2015 15:29:40 -0500 (EST)
From: Sandra Murphy <sandy@tislabs.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_6BFB66C8-015F-4533-B532-3EB0C821AC02"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Mon, 2 Feb 2015 15:29:40 -0500
Message-Id: <34030689-D361-42C6-8454-0FDC32A73731@tislabs.com>
To: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-httpbis-rfc7238bis@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Zohp5SDoaSZY0Q8QzK15tEerpQI>
Subject: [secdir] secdir review of draft-ietf-httpbis-rfc7238bis-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Feb 2015 20:29:43 -0000

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.