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

Sean Turner <> Mon, 19 April 2010 01:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 742CD3A6358 for <>; Sun, 18 Apr 2010 18:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.153
X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gK4kGSQ+w-WF for <>; Sun, 18 Apr 2010 18:21:44 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 103D53A6931 for <>; Sun, 18 Apr 2010 18:21:38 -0700 (PDT)
Received: (qmail 81350 invoked from network); 19 Apr 2010 01:21:28 -0000
Received: from thunderfish.local (turners@ with plain) by with SMTP; 18 Apr 2010 18:21:27 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: PG.2QHEVM1mJHIjLtnwKgBR9xBNhtgjUvK_Kh3YE2WLvo674xBFkZYdKdPbiSsLWrJYQs3SF5bZEj7lZ1hOkSWy0W.HZh1cSUjXJVpqRimDTcWQvusTNNZqmBds8Dl1A7uvgqfFthXdR_DTKLp42b1kGRqVCtQWSyJIIQh19xzAMoCSW8oMbOsKCaHRQ9DMGFLDDzQqCDkMdT4LkyPAIfXTjjw.Ldj72Kj7fPXe0c65AUHzWkmTJ5uJSoGolz2MC6fzOQPq8qVi1E7E6Mhw5oSBoJzo.0GneYuNbK5HFhPDes.E2Jx.S1fSfxGY5V_F7HjYrwuOcgNrLRfyfCd0Qi3wYxE_zpqXIpHTHYs0Vo1AGMLXr4E0ZDsyoSL1agf0vz4J4dRQ1J8XlUL1JjucwC_hm12PfDltoDtLblgxI1_7ui3.Pp_5.e5h3cQm9TvJDRBmt42W7v4nYR6MUobVQY5s9A1Y2SIUXf00-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Sun, 18 Apr 2010 21:21:27 -0400
From: Sean Turner <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: Mark Nottingham <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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:21:48 -0000

Mark Nottingham wrote:
> 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.

That would do it.  Thanks and sorry again for spacing so badly on 
getting back to you.


> Cheers,
>> 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