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

From: Sean Turner <[email-masked]>
Date: Sun, 18 Apr 2010 14:45:39 -0400

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.

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.

spt

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     http://www.mnot.net/
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Apr 2010 11:17:36 +1000

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

> 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.

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

---

From: Sean Turner <[email-masked]>
Date: Sun, 18 Apr 2010 21:21:27 -0400

> 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.

spt