Re: content inspection in absence of media type, was: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p2-semantics-24

S Moonesamy <sm+ietf@elandsys.com> Wed, 30 October 2013 17:20 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCE021E8135; Wed, 30 Oct 2013 10:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.479
X-Spam-Level:
X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mdu+x0hSN4L; Wed, 30 Oct 2013 10:20:41 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1E021E8144; Wed, 30 Oct 2013 10:19:25 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.152.154]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9UHIkA3029683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 10:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383153558; bh=A/n87butjfDIZlcNwmpbdRVoqtHbz8fPDDMr+9w3j7g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=f42ZCWZl821lUInpn08KzEQjz1CV8UyySIT9/PsFaO3SM5Up2a93L3PQqEc656n3b RXzDOiIJzPRC3rZweDh/bbkxTI17cqk8EksnIfkjqAFZh0y/kzCZAxCnZDjHRVo7Wo lRL0sEEupWjYIOrmkgfhyikkDUC9UFP5ojA6v+4w=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383153558; i=@elandsys.com; bh=A/n87butjfDIZlcNwmpbdRVoqtHbz8fPDDMr+9w3j7g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=my0VGwurWxjiYI587ONFCZURDjsN4It3iZxegrvGnso76MmdI57gVlX/dNhCnEQp8 f6wXzeiYguI0Pbb/2MrKNexdBxBm2XfZ3kDRYJXYgH6RPDd1MTzFDo00ae88sGcmvT J+wfRaj5ZYnr7lmU9EVkLWNi99U9rqa8Qg1PBE38=
Message-Id: <6.2.5.6.2.20131030060359.0cb29068@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 30 Oct 2013 08:49:52 -0700
To: Julian Reschke <julian.reschke@gmx.de>, apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: content inspection in absence of media type, was: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p2-semantics-24
In-Reply-To: <526FC24D.7060704@gmx.de>
References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E8B9E.8030006@gmx.de> <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> <526FC24D.7060704@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: ietf-http-wg@w3.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2013 17:20:42 -0000

Hi Julian,
At 07:12 29-10-2013, Julian Reschke wrote:
>I consider that sentence to be useless - if I can't detect the type, 
>what else but "treating as arbitrary data" is left as an option anyway?

I'll comment below.

>I still don't get what the issue is :-)

My preference is not to generate material which create more work for 
you.  It's better not to pursue this one. :-)

>The subsequent text is:
>
>"In practice, resource owners do not always properly configure their 
>origin server to provide the correct Content-Type for a given 
>representation, with the result that some clients will examine a 
>payload's content and override the specified type. Clients that do 
>so risk drawing incorrect conclusions, which might expose additional 
>security risks (e.g., "privilege escalation"). Furthermore, it is 
>impossible to determine the sender's intent by examining the data 
>format: many data formats match multiple media types that differ 
>only in processing semantics. Implementers are encouraged to provide 
>a means of disabling such "content sniffing" when it is used."
>
>Do you think this is insufficient, or that it needs to move to a 
>different part of the spec?

The subsequent text is, to put it simply, about an operational issue 
and security considerations.  The recommendation in Section 3.1.1.5 
is to generate a Content-Type header field if the server knows the 
media type.  There are cases when the server does not know the media 
type.  In such cases the server sends the client 
"application/octet-stream".  There is where the user has to determine 
whether the server is operated by good person or a bad person (re. 
arbitrary data).  The user relies on the browser to perform some 
magic to determine that.  That magic does not always work well.

If it was my decision (and it is not) I would discuss about this 
under Security Considerations and mention that content sniffing can 
cause security problems.  Please note that there are different 
alternatives to tackle the issue.

Regards,
S. Moonesamy