Re: [hybi] -09: security considerations

Adam Barth <ietf@adambarth.com> Sat, 18 June 2011 06:31 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EFE11E8142 for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 23:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.281
X-Spam-Level:
X-Spam-Status: No, score=-3.281 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2Nv2mzrHeNl for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 23:31:09 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD0FA11E807C for <hybi@ietf.org>; Fri, 17 Jun 2011 23:31:09 -0700 (PDT)
Received: by gxk19 with SMTP id 19so2208315gxk.31 for <hybi@ietf.org>; Fri, 17 Jun 2011 23:31:01 -0700 (PDT)
Received: by 10.151.93.13 with SMTP id v13mr2231746ybl.266.1308378661568; Fri, 17 Jun 2011 23:31:01 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by mx.google.com with ESMTPS id c26sm3360198ana.21.2011.06.17.23.31.00 (version=SSLv3 cipher=OTHER); Fri, 17 Jun 2011 23:31:00 -0700 (PDT)
Received: by yie30 with SMTP id 30so2210802yie.31 for <hybi@ietf.org>; Fri, 17 Jun 2011 23:31:00 -0700 (PDT)
Received: by 10.90.197.15 with SMTP id u15mr3429602agf.148.1308378660076; Fri, 17 Jun 2011 23:31:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.65.13 with HTTP; Fri, 17 Jun 2011 23:30:30 -0700 (PDT)
In-Reply-To: <BANLkTinuHWwwbXs8b+K9=vN+M=2ZDyy0CQ@mail.gmail.com>
References: <4DFB8571.4090802@stpeter.im> <BANLkTinuHWwwbXs8b+K9=vN+M=2ZDyy0CQ@mail.gmail.com>
From: Adam Barth <ietf@adambarth.com>
Date: Fri, 17 Jun 2011 23:30:30 -0700
Message-ID: <BANLkTim+YUp20v9-8uQVoCV9--gMA4wqLA@mail.gmail.com>
To: ifette@google.com
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: security considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jun 2011 06:31:10 -0000

There's somewhat more to it than that, right?  For example, HTTP
doesn't use the origin security model, whereas WebSockets does.  Also,
HTTP punts on cross-protocol security issues, whereas WebSockets does
not.  Finally, HTTP has the benefit of being invented prior to the
deployment of much of today's network infrastructure.  That means the
network infrastructure needs to work around HTTP whereas WebSockets
needs to work around the network infrastructure.

Adam


2011/6/17 Ian Fette (イアンフェッティ) <ifette@google.com>:
> I would hope that the discussions don't need to be so long. The security
> model is based on that of HTTP. Whatever HTTP gives you WS gives you,
> whatever HTTPS gives you WSS gives you. WS is at its core a less hacky more
> performant version of what people are already doing today in javascript,
> it's not some totally new concept.
> -Ian
>
> On Fri, Jun 17, 2011 at 9:48 AM, Peter Saint-Andre <stpeter@stpeter.im>
> wrote:
>>
>> First, I am not a member of the security mafia.
>>
>> However, the security considerations section seems incomplete to me. I
>> suggest that the author and WG spend some quality time with RFC 3552
>> (and with other RFCs that have good discussions of security) to make
>> this section more robust and complete.
>>
>> Questions to ask and answer include (but are not limited to):
>>
>> 1. What is the threat model against the architecture assumed in this
>> document? (And to answer that question, it would help to more clearly
>> explain the architecture.)
>>
>> 2. How will the protocol address confidentiality?
>>
>> 3. How will the protocol address data integrity?
>>
>> 4. How will the protocol address peer entity authentication?
>>
>> 5. How does the protocol ensure strong security (RFC 3365)?
>>
>> 6. If certificates are to be used, how are they handled (RFC 6125 and
>> RFC 2818)?
>>
>> 7. What are the mandatory-to-implement TLS ciphersuites?
>>
>> 8. What are the security considerations related to technologies that are
>> reused in WebSocket (e.g., Base 64 and UTF-8)?
>>
>> 9. What information leaks are possible?
>>
>> 10. What denial of service attacks (RFC 4732) are possible and what
>> measures can be taken to prevent those attacks?
>>
>> 11. What is the relationship, if any, between the security of the
>> WebSocket protocol and the security of HTTP? In what ways does this
>> protocol build on HTTP from a security perspective, and in what ways
>> does it need additional security mechanisms?
>>
>> I'm sure the reviewer from the IETF Security Directorate will come up
>> with more questions than that, so we need to be prepared.
>>
>> A personal note: in revising RFC 3920 to produce RFC 6120, I put a great
>> deal of thought and time into writing the security considerations
>> section, which ended up being 20 pages long. That might be longer than
>> necessary here, but I think 2 pages is a bit shy of what we need.
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> https://stpeter.im/
>>
>>
>>
>>
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>