Re: [secdir] secdir review of draft-nottingham-http-link-header

Mark Nottingham <> Mon, 19 April 2010 01:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 681A93A6A5A for <>; Sun, 18 Apr 2010 18:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.199
X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-3.600, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eJmDxxOz03IT for <>; Sun, 18 Apr 2010 18:17:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6ED2E3A6846 for <>; Sun, 18 Apr 2010 18:17:56 -0700 (PDT)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 81323509B4; Sun, 18 Apr 2010 21:17:40 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <>
In-Reply-To: <>
Date: Mon, 19 Apr 2010 11:17:36 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Sean Turner <>
X-Mailer: Apple Mail (2.1078)
Cc:, "Julian F. F. Reschke" <>, secdir <>
Subject: Re: [secdir] secdir review of draft-nottingham-http-link-header
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Apr 2010 01:17:58 -0000

On 19/04/2010, at 4:45 AM, Sean Turner wrote:

> I pretty much full on dropped the ball on this.
> What I was hoping to see was some text that points to a mechanism that can be used to secure the Link header-entity field.

TLS/SSL is the only viable option here ATM (although people are making noises about separate integrity for HTTP, it's going to be a while). I can add a mention of this at the end of the first paragraph in Security Considerations.

> Also, (I stole these from RFC4287) I think you should point to security considerations of "stuff" used in this ID like IRIs, URIs, and HTTP headers.  Something like:
> The Link entity-header field makes extensive use of IRIs and URIs.  See [RFC3987] for security considerations relating to IRIs.  See [RFC3987] for security considerations relating to URIs.   See [RFC2616] for security considerations relating to HTTP headers.

I can add this at the end of Security Considerations.


> Mark Nottingham wrote:
>> Thanks, Sean.
>> I'm not sure how to incorporate your suggestion into the document; did you have specific mechanisms in mind, and/or specific placement in the draft?
>> Cheers,
>> On 30/07/2009, at 7:02 PM, Sean Turner wrote:
>>> 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.
>>> Document: draft-nottingham-http-link-header-06.txt
>>> Reviewer: Sean Turner
>>> Review Date: 2009-07-30
>>> IETF LC End Date: 2009-08-11
>>> IESG Telechat date: N/A
>>> Summary: This document specifies relation types for Web links, and defines a registry for them.  It also defines how to send such links in HTTP headers with the Link header-field.
>>> Comments: The security considerations are pretty clear: the content of the fields aren't secured in any way. I think some text should be added that says something like "[Mechanism XYZ] can be combined with [protocol ABC] to provide the following security service: 1, 2, 3."
>>> spt
>> -- 
>> Mark Nottingham

Mark Nottingham