From ietf@adambarth.com Thu Oct 7 20:40:37 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160C53A67E1 for ; Thu, 7 Oct 2010 20:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJN1QrX3tQux for ; Thu, 7 Oct 2010 20:40:35 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id A6C0E3A67E9 for ; Thu, 7 Oct 2010 20:40:32 -0700 (PDT) Received: by qyk7 with SMTP id 7so51051qyk.10 for ; Thu, 07 Oct 2010 20:41:36 -0700 (PDT) Received: by 10.229.249.198 with SMTP id ml6mr1540080qcb.117.1286509296155; Thu, 07 Oct 2010 20:41:36 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by mx.google.com with ESMTPS id nb14sm1248119qcb.24.2010.10.07.20.41.34 (version=SSLv3 cipher=RC4-MD5); Thu, 07 Oct 2010 20:41:35 -0700 (PDT) Received: by qyk7 with SMTP id 7so50969qyk.10 for ; Thu, 07 Oct 2010 20:41:34 -0700 (PDT) Received: by 10.229.221.131 with SMTP id ic3mr1515157qcb.152.1286509292127; Thu, 07 Oct 2010 20:41:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.72.205 with HTTP; Thu, 7 Oct 2010 20:41:01 -0700 (PDT) From: Adam Barth Date: Thu, 7 Oct 2010 20:41:01 -0700 Message-ID: To: websec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] git repository X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 03:40:37 -0000 Hi websec, I've created a public git repository that contains draft-abarth-origin and draft-abarth-mime-sniff for those of you who like to track documents up-to-the-lastest-commit: http://github.com/abarth/ietf-websec I'll be uploading new versions of those documents, hopefully later tonight. Kind regards, Adam From ietf@adambarth.com Thu Oct 7 23:00:27 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 885333A6838 for ; Thu, 7 Oct 2010 23:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEJGnq3pVIdS for ; Thu, 7 Oct 2010 23:00:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 864613A683E for ; Thu, 7 Oct 2010 23:00:24 -0700 (PDT) Received: by yxl31 with SMTP id 31so284669yxl.31 for ; Thu, 07 Oct 2010 23:01:25 -0700 (PDT) Received: by 10.151.28.10 with SMTP id f10mr2358963ybj.94.1286517683704; Thu, 07 Oct 2010 23:01:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id v9sm2722595yba.15.2010.10.07.23.01.22 (version=SSLv3 cipher=RC4-MD5); Thu, 07 Oct 2010 23:01:22 -0700 (PDT) Received: by iwn10 with SMTP id 10so950317iwn.31 for ; Thu, 07 Oct 2010 23:01:21 -0700 (PDT) Received: by 10.231.15.138 with SMTP id k10mr1907032iba.17.1286517681715; Thu, 07 Oct 2010 23:01:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.149.20 with HTTP; Thu, 7 Oct 2010 23:00:51 -0700 (PDT) From: Adam Barth Date: Thu, 7 Oct 2010 23:00:51 -0700 Message-ID: To: websec Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] draft-abarth-origin-08 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 06:00:27 -0000 I've uploaded a new version of draft-abarth-origin: http://www.ietf.org/id/draft-abarth-origin-08.txt Please let me know if you have any comments. Thanks, Adam From wwwrun@core3.amsl.com Tue Oct 12 10:21:56 2010 Return-Path: X-Original-To: websec@ietf.org Delivered-To: websec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 84BCD3A69A9; Tue, 12 Oct 2010 10:21:55 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20101012172155.84BCD3A69A9@core3.amsl.com> Date: Tue, 12 Oct 2010 10:21:55 -0700 (PDT) Cc: websec@ietf.org Subject: [websec] WG Action: Web Security (websec) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 17:21:56 -0000 A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. Web Security (websec) --------------------------------------------- Current Status: Active Working Group Chairs(s) Tobias Gondrom Applications Area Directors: Alexey Melnikov Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Security Area Advisor: Sean Turner Mailing Lists: General Discussion: websec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/websec Archive: http://www.ietf.org/mail-archive/web/websec/ Problem Statement Although modern Web applications are built on top of HTTP, they provide rich functionality and have requirements beyond the original vision of static web pages. HTTP, and the applications built on it, have evolved organically. Over the past few years, we have seen a proliferation of AJAX-based web applications (AJAX being shorthand for asynchronous JavaScript and XML), as well as Rich Internet Applications (RIAs), based on so-called Web 2.0 technologies. These applications bring both luscious eye-candy and convenient functionality, e.g. social networking, to their users, making them quite compelling. At the same time, we are seeing an increase in attacks against these applications and their underlying technologies. The list of attacks is long and includes Cross-Site-Request Forgery (CSRF)-based attacks, content-sniffing, cross-site-scripting (XSS) attacks, attacks against browsers supporting anti-XSS policies, clickjacking attacks, malvertising attacks, as well as man-in-the-middle (MITM) attacks against "secure" (e.g. Transport Layer Security (TLS/SSL)-based) web sites along with distribution of the tools to carry out such attacks (e.g. sslstrip). Objectives and Scope With the arrival of new attacks the introduction of new web security indicators, security techniques, and policy communication mechanisms have sprinkled throughout the various layers of the Web and HTTP. The goal of this working group is to compose an overall "problem statement and requirements" document derived from surveying the issues outlined in the above section ([1] provides a starting point). The requirements guiding the work will be taken from the Web application and Web security communities. The scope of this document is HTTP applications security, but does not include HTTP authentication, nor internals of transport security which are addressed by other working groups (although it may make reference to transport security as an available security "primitive"). See the "Out of Scope" section, below. Additionally, the WG will standardize a small number of selected specifications that have proven to improve security of Internet Web applications. Initial work will be the following topics: - Same origin policy, as discussed in draft-abarth-origin (see also Appendices A and B, below) - HTTP Strict transport security, as discussed in draft-hodges-strict-transport-sec - Media type sniffing, as discussed in draft-abarth-mime-sniff This working group will work closely with IETF Apps Area WGs (such as HYBI, HTTPstate, and HTTPbis), as well as appropriate W3C working group(s) (e.g. HTML, WebApps). Out of Scope As noted in the objectives and scope (above), this working group's scope does not include working on HTTP Authentication nor underlying transport (secure or not) topics. So, for example, these items are out-of-scope for this WG: - Replacements for BASIC and DIGEST authentication - New transports (e.g. SCTP and the like) Deliverables 1. A document illustrating the security problems Web applications are facing and listing design requirements. This document shall be Informational. 2. A selected set of technical specifications documenting deployed HTTP-based Web security solutions. These documents shall be Standards Track. Goals and Milestones Oct 2010 Submit "HTTP Application Security Problem Statement and Requirements" as initial WG item. Oct 2010 Submit "Media Type Sniffing" as initial WG item. Oct 2010 Submit "Web Origin Concept" as initial WG item. Oct 2010 Submit "Strict Transport Security" as initial WG item. Feb 2011 Submit "HTTP Application Security Problem Statement and Requirements" to the IESG for consideration as an Informational RFC. Mar 2011 Submit "Media Type Sniffing" to the IESG for consideration as a Standards Track RFC. Mar 2011 Submit "Web Origin Concept" to the IESG for consideration as a Standards Track RFC. Mar 2011 Submit "Strict Transport Security" to the IESG for consideration as a Standards Track RFC. Apr 2011 Possible re-chartering References [1] Hodges and Steingruebl, "The Need for a Coherent Web Security Policy Framework", W2SP position paper, 2010. http://w2spconf.com/2010/papers/p11.pdf Appendices A. Relationship between origin work in IETF WebSec and W3C HTML WG draft-abarth-origin defines the nuts-and-bolts of working with origins (computing them from URIs, comparing them to each other, etc). HTML5 defines HTML-specific usage of origins. For example, when making an HTTP request, HTML5 defines how to compute which origin among all the origins rendering HTML is the one responsible for making the request. draft-abarth-origin then takes that origin, serializes it to a string, and shoves it in a header. B. Origin work may yield two specifications There also seems to be demand for a document that describes the same-origin security model overall. However, it seems like that document ought to be more informative rather than normative. The working group may split draft-abarth-origin into separate informative and standards track specifications, the former describing same-origin security model, and the latter specifying the nuts-and-bolts of working with origins (computing them from URLs, comparing them to each other, etc). From hallam@gmail.com Tue Oct 12 11:19:56 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCEF73A6916 for ; Tue, 12 Oct 2010 11:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpycIFBfD6E1 for ; Tue, 12 Oct 2010 11:19:55 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 13B8F3A68E0 for ; Tue, 12 Oct 2010 11:19:51 -0700 (PDT) Received: by fxm17 with SMTP id 17so1309802fxm.31 for ; Tue, 12 Oct 2010 11:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=/FGJ2JI/1R/Hw/VCq6BHesDqWOPzwxjWdITKa/MnPSw=; b=FDlYJcsOI13e5S5p3gCed5IY3W9X8YV1GZ1KhxUuVJqCZC7N76CbYXQvYNdkM5hehA 9ZHbyjnvKNlRbTEnLESqtoUwRvAZlkIHsVZbtpwEUApUsG8+CGvJR5G5DL0+hNJrzfem KuCIG/ZV2E4z9iAdLk8vt1w8bz0G3fNCD7dss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=i7QskLnEAnSYoG1faBqd+dUnAvLJWRpG1c+fzLXWe91jiclNc3OqmVm+k9uZjP+3Qv AMU5XLqZ09fAIcbMVuOGEAosX3XS4kJkkwkp+6NsIOi48sBiuZB9QVQrZdUoKcpIaJhW 1pzs5tijQEhQL3dIx5xbHAaVgXtexBP2QW4+Q= MIME-Version: 1.0 Received: by 10.239.190.76 with SMTP id w12mr451623hbh.175.1286907665959; Tue, 12 Oct 2010 11:21:05 -0700 (PDT) Received: by 10.239.156.141 with HTTP; Tue, 12 Oct 2010 11:21:05 -0700 (PDT) Date: Tue, 12 Oct 2010 14:21:05 -0400 Message-ID: From: Phillip Hallam-Baker To: websec Content-Type: multipart/alternative; boundary=001485f1ebde49cc3e04926f8ae4 Subject: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 18:19:56 -0000 --001485f1ebde49cc3e04926f8ae4 Content-Type: text/plain; charset=ISO-8859-1 Has anyone (else) been considering the possible use of the DNS to signal a strict security requirement? While I like the idea of strict security, signaling by means of HTTP headers creates a circular dependency. I can only guarantee strict security after first achieving a secure connection. And anything that is done for HTTP becomes a one-off that cannot be applied to SMTP and other protocols. I am not arguing against doing the HTTP header approach. Given the attacks we are facing I do not want strict security to be dependent on successful DNSSEC deployment. But I would like to see a HTTP header approach that is consistent with eventual deployment of a DNSSEC based approach. -- Website: http://hallambaker.com/ --001485f1ebde49cc3e04926f8ae4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Has anyone (else) been considering the possible use of the DNS to signal a = strict security requirement?

While I like the idea of st= rict security, signaling by means of HTTP headers creates a circular depend= ency. I can only guarantee strict security after first achieving a secure c= onnection. And anything that is done for HTTP becomes a one-off that cannot= be applied to SMTP and other protocols.

I am not arguing against doing the HTTP header approach= . Given the attacks we are facing I do not want strict security to be depen= dent on successful DNSSEC deployment. But I would like to see a HTTP header= approach that is consistent with eventual deployment of a DNSSEC based app= roach.


--001485f1ebde49cc3e04926f8ae4-- From yngve@opera.com Tue Oct 12 12:02:51 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04BBC3A6A44 for ; Tue, 12 Oct 2010 12:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z52xQ-QJL-N9 for ; Tue, 12 Oct 2010 12:02:49 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 7A6073A6A38 for ; Tue, 12 Oct 2010 12:02:49 -0700 (PDT) Received: from lessa-ii.oslo.os (173-10-121-193-BusName-Washington.hfc.comcastbusiness.net [173.10.121.193]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9CJ3vr5006533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Oct 2010 19:04:01 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: websec , "Phillip Hallam-Baker" References: Date: Tue, 12 Oct 2010 21:04:04 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Organization: Opera Software ASA Message-ID: In-Reply-To: User-Agent: Opera Mail/10.62 (Win32) X-Scanned-By: MIMEDefang 2.64 on 213.236.208.81 Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:02:51 -0000 On Tue, 12 Oct 2010 20:21:05 +0200, Phillip Hallam-Baker wrote: > I am not arguing against doing the HTTP header approach. Given the > attacks > we are facing I do not want strict security to be dependent on successful > DNSSEC deployment. But I would like to see a HTTP header approach that is > consistent with eventual deployment of a DNSSEC based approach. I am not against the suggestion, and I recognize that there are problems with the bootstrapping process, but: Any such system would need to define an API akin to that specified by RFC 3493 (the APIs used to do namelookups for IPv6) that must be implemented in every Operating System. Anything else would require the client to implement full DNS(SEC) support, discover the network configuration, or go direct to deduced nameservers, and as a result cause at least potential interoperability problems and inefficiencies due to less use of DNS caching. Additionally, there is the problem with network configurations that does not allow any external network traffic except through an HTTP proxy. IOW: General DNS is not always available. A workaround for that might be a HTTP(s?) based webservice interface to DNS(SEC). -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From asteingruebl@paypal-inc.com Tue Oct 12 12:08:23 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 874C23A681E for ; Tue, 12 Oct 2010 12:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4DZbh-klC8W for ; Tue, 12 Oct 2010 12:08:22 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id 20F6D3A69FF for ; Tue, 12 Oct 2010 12:08:22 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=NW4SWuWC9CJqqgJXDRQf+ZNcZRTTNyPIcXPGpTkpEgBWgRN0W+P/ty5S wPLQtfiX/auxWvsID+qnpbsAXqCGBlmUc9dEcYl9V5jz0128JxUDBBGQk SQodoVgmbuTEvMM; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1286910577; x=1318446577; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Phillip=20Hallam-Baker=20, =20websec=20|Date:=20Tue,=2012=20Oct=202 010=2013:09:35=20-0600|Subject:=20RE:=20[websec]=20Use=20 of=20DNS/DNSSEC=20for=20strict=20security|Message-ID:=20< 5EE049BA3C6538409BBE6F1760F328ABEB0199FAE7@DEN-MEXMS-001. corp.ebay.com>|References:=20|In-Reply-To:=20< AANLkTikt4=3DdVbTf_tj8HHc=3DwhpU0S+Pv40LrBQHbK6yz@mail.gm ail.com>|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=rwjS7+rv3z6BAE0OC7FnlOOyz1NVHhOSXftITwRkXaU=; b=J/fnVCHfCvpm2I3iaVAw5cDe3C+lSr9g19ckPzEUZTzRy6NAnf1u4BFH 8HSombv6mUVeNgTkXstKvK8qWUZ17y0oLBXVRzNKabII3xWWBgvt8aqMe Gz0RnaiqM5tf01m; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.57,321,1283756400"; d="scan'208";a="72514433" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 12 Oct 2010 12:09:36 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Tue, 12 Oct 2010 13:09:36 -0600 From: "Steingruebl, Andy" To: Phillip Hallam-Baker , websec Date: Tue, 12 Oct 2010 13:09:35 -0600 Thread-Topic: [websec] Use of DNS/DNSSEC for strict security Thread-Index: ActqOkS+tcFOZT1FQ7ipj4nNbAnmbQABXLkg Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAE7@DEN-MEXMS-001.corp.ebay.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:08:23 -0000 > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf = Of Phillip Hallam-Baker > Sent: Tuesday, October 12, 2010 11:21 AM > To: websec > Subject: [websec] Use of DNS/DNSSEC for strict security > Has anyone (else) been considering the possible use of the DNS to signal = a strict security requirement? Yes. We've (Jeff and I) done a lot of thinking on this topic. I think th= e biggest discussion is around whether we need a global security policy fra= mework and STS can be advertised there, or whether we should just put up an= STS DNS indicator now and figure out the larger policy question later. Some of our thinking is based on: "Web Sites Should Not Need to Rely On Users" http://www.eecs.harvard.edu/~stuart/papers/w3c06.pdf and associated draft spec - http://lists.w3.org/Archives/Public/public-wsc-= wg/2007Apr/att-0332/http-ssr.txt Given the timeframe of getting HSTS deployed in web browsers (FF and Chrome= live, rumors of others being interested) I think we have some time to figu= re out all of the policies we'd like to convey during a bootstrapping proce= ss, and create a policy framework/language for it, and not just tackle STS = as a one-off. We didn't get into a real strong taxonomy in our paper - http://w2spconf.co= m/2010/papers/p11.pdf - but there are some policies that you'd like to secu= rely bootstrap over something like DNS(SEC) and others than can be delivere= d inline or via the same protocol (crossdomain.xml). Dan Kaminsky had a rough sketch of including STS indicators that he present= ed at BH this year. We haven't ourselves taken that forward in any way yet= . - Andy From asteingruebl@paypal-inc.com Tue Oct 12 12:10:20 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C403A6A3D for ; Tue, 12 Oct 2010 12:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYNtke2vdjlE for ; Tue, 12 Oct 2010 12:10:15 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id F18013A69FF for ; Tue, 12 Oct 2010 12:10:14 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=ozjm5Pz/DQyPkePdDQ4aZ03CRyqmF0MK33Y6ATQuncxrGfL8DFaqD/TT JU3JIr49LFA1rLYZItgH6ZeXwInJ5+uipgWmKc47vj+RvWYF+hwG68kYn IzgwWih8WSixN5E; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1286910690; x=1318446690; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20"Yngve=20N.=20Pettersen"=20, =20websec=20,=20Phillip=0D=0A=20Hallam-B aker=20|Date:=20Tue,=2012=20Oct=202010 =2013:11:28=20-0600|Subject:=20RE:=20[websec]=20Use=20of =20DNS/DNSSEC=20for=20strict=20security|Message-ID:=20<5E E049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.co rp.ebay.com>|References:=20=0D=0A=20|In-Reply-To:=20|Content-Transfer-Encoding:=20quoted-p rintable|MIME-Version:=201.0; bh=gPlIiCpxhHChsJWga+faSjR6POxCId1fIOUc+5LkSIM=; b=rWr9S6ljs92ID8oltWUG58UXItW5FZedcuiz3ME/2bY/eWTYJtvxw1kE F2/B/+QWkepKtujiqMj3fbrKDGhwp+BKESW+dMDEhyEuu/BZTUP5tAohc cFL6k7wqvVf/gyA; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.57,321,1283756400"; d="scan'208";a="72569693" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 12 Oct 2010 12:11:29 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Tue, 12 Oct 2010 13:11:29 -0600 From: "Steingruebl, Andy" To: "Yngve N. Pettersen" , websec , Phillip Hallam-Baker Date: Tue, 12 Oct 2010 13:11:28 -0600 Thread-Topic: [websec] Use of DNS/DNSSEC for strict security Thread-Index: ActqQFlz0cTiqmGJSw2cTvX58KrTwAAALf2g Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:10:20 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Yngve N. Pettersen > Sent: Tuesday, October 12, 2010 12:04 PM > To: websec; Phillip Hallam-Baker > Subject: Re: [websec] Use of DNS/DNSSEC for strict security >=20 >=20 > Any such system would need to define an API akin to that specified by RFC > 3493 (the APIs used to do namelookups for IPv6) that must be implemented > in every Operating System. >=20 > Anything else would require the client to implement full DNS(SEC) support= , > discover the network configuration, or go direct to deduced nameservers, > and as a result cause at least potential interoperability problems and > inefficiencies due to less use of DNS caching. Yep. This was pointed out pretty clearly by Dan in his BH talk. His soluti= on was to tunnel DNSSEC lookups over HTTP(S) since we know middleboxes will= pass that traffic.=20 Seems insane on the surface, but might be the only deployable solution in o= ur lifetimes :)=20 - Andy From hallam@gmail.com Tue Oct 12 13:45:13 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205993A6A87 for ; Tue, 12 Oct 2010 13:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLT0DQQYxubR for ; Tue, 12 Oct 2010 13:45:11 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E8E4C3A6A90 for ; Tue, 12 Oct 2010 13:45:10 -0700 (PDT) Received: by fxm17 with SMTP id 17so1406154fxm.31 for ; Tue, 12 Oct 2010 13:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=CCdlOEkWp4t2lNkD6T8IeGJrde0Nbo7DokDb/qjFIwE=; b=Wko8U1Yx3jpolq/BDdFbj7kYXiotHGPT5Mc3pEDz/3Fgu33WQvKjUrCtZxLKuto1JF mMkbZJEFrm+1uNWwBfcms3yjz/Q+Komd8By8HOT3fF/76Zw5YWayEUjt440rKjzmS3ZI IsDKJKlG90V4vEL7E4rBC1RaIkhqkY7LkxQXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ksc7eC0SO3JbBI1qYcEjjKGHNy/AbNEiDstUQZudb/ZDlKix3kSBFlN8kR6XrUfQpN S44B+qvvc3ELAQFMMtVt7FtiVrUV3znMWpMzO0R3Bq4C67TMHMXOhXz4ZsbpLp0oFKw8 twRWQrCf1XILClPKojwO/p8rRZw3DOqUvvO7o= MIME-Version: 1.0 Received: by 10.239.156.10 with SMTP id k10mr512118hbc.147.1286916384109; Tue, 12 Oct 2010 13:46:24 -0700 (PDT) Received: by 10.239.156.141 with HTTP; Tue, 12 Oct 2010 13:46:24 -0700 (PDT) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> Date: Tue, 12 Oct 2010 16:46:24 -0400 Message-ID: From: Phillip Hallam-Baker To: "Steingruebl, Andy" Content-Type: multipart/alternative; boundary=001485f89eecee357b04927191ab Cc: websec Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 20:45:13 -0000 --001485f89eecee357b04927191ab Content-Type: text/plain; charset=ISO-8859-1 An API is definitely required. Based on my experience of how changes turn out to be necessary in the light of PKI deployment, I do not want to be dependent on host processing. That is the deployment error that sank SET. I much prefer a model in which DNSSEC processing is performed at a recursive resolver that the host has established a trust relationship with. The attack model that is being considered in DNSSEC is the one where a malicious party modifies a DNS record. I am rather more concerned about the attack where the malicious party registered the DNS record. Just because someone has registered a domain does not mean I want my machine to connect to theirs. The idea of taking DNS service from an untrusted middlebox was always bogus. It might well be necessary to use some form of tunneling to route round malicious middleboxen as Dan described to get to a resolver we can trust. But I don't want to connect to the unedited DNS either. If APWG has a domain identified as a phishing site, chances are that I want to have that domain blocked rather than resolve. On Tue, Oct 12, 2010 at 3:11 PM, Steingruebl, Andy < asteingruebl@paypal-inc.com> wrote: > > -----Original Message----- > > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > > Behalf Of Yngve N. Pettersen > > Sent: Tuesday, October 12, 2010 12:04 PM > > To: websec; Phillip Hallam-Baker > > Subject: Re: [websec] Use of DNS/DNSSEC for strict security > > > > > > Any such system would need to define an API akin to that specified by RFC > > 3493 (the APIs used to do namelookups for IPv6) that must be implemented > > in every Operating System. > > > > Anything else would require the client to implement full DNS(SEC) > support, > > discover the network configuration, or go direct to deduced nameservers, > > and as a result cause at least potential interoperability problems and > > inefficiencies due to less use of DNS caching. > > Yep. This was pointed out pretty clearly by Dan in his BH talk. His > solution was to tunnel DNSSEC lookups over HTTP(S) since we know middleboxes > will pass that traffic. > > Seems insane on the surface, but might be the only deployable solution in > our lifetimes :) > > - Andy > -- Website: http://hallambaker.com/ --001485f89eecee357b04927191ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

An API is definitely required.=A0

Based o= n my experience of how changes turn out to be necessary in the light of PKI= deployment, I do not want to be dependent on host processing. That is the = deployment error that sank SET.

I much prefer a model in which DNSSEC processing is per= formed at a recursive resolver that the host has established a trust relati= onship with.=A0

The attack model that is being con= sidered in DNSSEC is the one where a malicious party modifies a DNS record.= I am rather more concerned about the attack where the malicious party regi= stered the DNS record. Just because someone has registered a domain does no= t mean I want my machine to connect to theirs.


The idea of taking DNS service from an u= ntrusted middlebox was always bogus. It might well be necessary to use some= form of tunneling to route round malicious middleboxen as Dan described to= get to a resolver we can trust. But I don't want to connect to the une= dited DNS either.

If APWG has a domain identified as a phishing site, cha= nces are that I want to have that domain blocked rather than resolve.
=


On Tue, Oct 12, 2010 at 3:11 PM, St= eingruebl, Andy <asteingruebl@paypal-inc.com> wrote:
> -----Original Messag= e-----
> From: websec-bounces@ietf.o= rg [mailto:websec-bounces@ie= tf.org] On
> Behalf Of Yngve N. Pettersen
> Sent: Tuesday, October 12, 2010 12:04 PM
> To: websec; Phillip Hallam-Baker
> Subject: Re: [websec] Use of DNS/DNSSEC for strict security
>
>
> Any such system would need to define an API akin to that specified by = RFC
> 3493 (the APIs used to do namelookups for IPv6) that must be implement= ed
> in every Operating System.
>
> Anything else would require the client to implement full DNS(SEC) supp= ort,
> discover the network configuration, or go direct to deduced nameserver= s,
> and as a result cause at least potential interoperability problems and=
> inefficiencies due to less use of DNS caching.

Yep. This was pointed out pretty clearly by Dan in his BH talk. =A0Hi= s solution was to tunnel DNSSEC lookups over HTTP(S) since we know middlebo= xes will pass that traffic.

Seems insane on the surface, but might be the only deployable solution in o= ur lifetimes :)

- Andy



--
Website: http://hallambaker.com/

--001485f89eecee357b04927191ab-- From asteingruebl@paypal-inc.com Wed Oct 13 13:43:43 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA8913A6A12 for ; Wed, 13 Oct 2010 13:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujW40YW1eFyS for ; Wed, 13 Oct 2010 13:43:42 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 519E43A69AB for ; Wed, 13 Oct 2010 13:43:42 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=ReUGTlpBVHq2V1ApEiZCA0xcNoWEKtMI4p/NH9Z2Ze4hSb3XXCvg00sT bTWsEdWD3ozBx4wEGAjBxlu0F+yb9Pkr27WcJAz0EAmpKCEoWyMDrqh+K n/+/ltjnOo0Fpgq; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1287002700; x=1318538700; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Phillip=20Hallam-Baker=20 |CC:=20"Yngve=20N.=20Pettersen"=20,=20we bsec=20|Date:=20Wed,=2013=20Oct=202010 =2014:44:57=20-0600|Subject:=20RE:=20[websec]=20Use=20of =20DNS/DNSSEC=20for=20strict=20security|Message-ID:=20<5E E049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.co rp.ebay.com>|References:=20=0D=0A=09=0D=0A=09<5EE049BA3C6538409BBE6F1 760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com>=0D=0A=20 |In-Reply-To:=20|Content-Transfer-Encoding:=20q uoted-printable|MIME-Version:=201.0; bh=U4MyDSAq7l4ci3xnUqvUFwhF6/BAu4e24PqAA7qga5E=; b=vHuyY99hTJGTqB9Knd6xdDxjckK69Bm3Usn1BZujK843va3slBIjDG6N 0NXQyKM1aA392bV4WZe3ZoHol9Ek0XZNmeYvDVveTymr91mbnyvrJHm9N jxcRqJZY26k/EiM; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.57,327,1283756400"; d="scan'208";a="72589602" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 13 Oct 2010 13:44:59 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Wed, 13 Oct 2010 14:44:58 -0600 From: "Steingruebl, Andy" To: Phillip Hallam-Baker Date: Wed, 13 Oct 2010 14:44:57 -0600 Thread-Topic: [websec] Use of DNS/DNSSEC for strict security Thread-Index: ActqTpS3YTfBM2scTHaEg0BmhBlPBQAx6oCQ Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: websec Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 20:43:43 -0000 > From: Phillip Hallam-Baker [mailto:hallam@gmail.com]=20 > Sent: Tuesday, October 12, 2010 1:46 PM > An API is definitely required.=A0 While I don't disagree that there may be room to have common API usage for = this, and have it potentially provided for by the OS/Platform rather than a= pplication, a lot of the current OS/Platform APIs don't easily allow the pa= ssing or this type of data. This potentially requires substantial rework a= nd timelag to get deployment. And, just as certain services come with spec= ific platforms, not all applications choose the use the OS versions and pro= vide their own. For example, Firefox always uses NSS even on platforms suc= h as Windows that provide their own versions. > Based on my experience of how changes turn out to be necessary in the lig= ht of PKI deployment, I do not want to be dependent on=20 > host processing. That is the deployment error that sank SET. In the case we're discussing, we're definitely going to be dependent on hos= t processing, unless I misunderstand what you mean. The current DNSSEC las= t-hop problem is real, and must be solved for successful deployment of any = of the technologies being contemplated. > I much prefer a model in which DNSSEC processing is performed at a recurs= ive resolver that the host has established a trust relationship with.=A0 OK, but as Kaminsky has demonstrated repeatedly this won't work over the DN= S protocol itself today, because of both malicious and clueless middleboxes= . > The attack model that is being considered in DNSSEC is the one where a ma= licious party modifies a DNS record. I am rather more concerned about=20 > the attack where the malicious party registered the DNS record. Just beca= use someone has registered a domain does not mean I want my machine > to connect to theirs. DNS response filtering is entirely unrelated to anything we're discussing h= ere, and I'd rather not muddy these waters with it. Deal with rogue hosts = in another context please, they are an entirely orthogonal problem. > The idea of taking DNS service from an untrusted middlebox was always bog= us. It might well be necessary to use some form of tunneling > to route round malicious middleboxen as Dan described to get to a resolve= r we can trust. But I don't want to connect to the unedited DNS either. The problem isn't just malicious middleboxes, it is broken ones. There are= a lot of devices currently deployed that make pure E2E DNSSEC impossible t= oday. =20 Now that I've written all of this though, I think this forum is more about = what problems we're solving, what policies need to exist and when (when in = a connection lifecycle/timeline) and then lastly we can worry about the dep= loyment concerns related to DNSSEC, etc. We can chase our tail for a long= time here on how to get DNSSEC values reliably to end-nodes, but I'd rathe= r not solve that problem in this forum, nor deal with other things like rog= ue hosts, hosting providers, etc. Those are entirely separate issues. - Andy From mail@samcaldwell.net Wed Oct 13 19:13:16 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9D43A69A3 for ; Wed, 13 Oct 2010 19:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iN6bQOPDVMd7 for ; Wed, 13 Oct 2010 19:13:14 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 5BB8F3A686A for ; Wed, 13 Oct 2010 19:13:14 -0700 (PDT) Received: by iwn10 with SMTP id 10so8776737iwn.31 for ; Wed, 13 Oct 2010 19:14:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.169.149 with SMTP id z21mr7850898iby.11.1287022471880; Wed, 13 Oct 2010 19:14:31 -0700 (PDT) Received: by 10.231.145.139 with HTTP; Wed, 13 Oct 2010 19:14:31 -0700 (PDT) X-Originating-IP: [67.78.39.190] Date: Wed, 13 Oct 2010 21:14:31 -0500 Message-ID: From: Sam Caldwell To: websec@ietf.org Content-Type: multipart/alternative; boundary=001636920b8b411f0e04928a458d Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: HTTP Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 02:13:16 -0000 --001636920b8b411f0e04928a458d Content-Type: text/plain; charset=ISO-8859-1 DNSSEC is a good start, but I would suggest that no amount of work on WEBSEC can truly secure the web until the integrity of the browser and server are guaranteed. It would seem that the focus of WEBSEC should not start with DNSSEC, as DNSSEC is but one front of the battle. Instead, I would suggest that WEBSEC should start by first requiring compliant web servers and web browsers (and their extensions) to be digitally signed by a mutually trusted certificate authority, and that thereafter the WEBSEC standard should provide a mechanism for validating these digital signatures. Over time, digitally signed browsers and servers can provide a mechanism for blacklisting known malicious servers AND malicious browsers. Further, each client-server relationship can be encrypted using PKI with a lower industry cost. --001636920b8b411f0e04928a458d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable DNSSEC is a good start, but I would suggest that no amount of work on WEBSE= C can truly secure the web until the integrity of the browser and server ar= e guaranteed. =A0It would seem that the focus of WEBSEC should not start wi= th DNSSEC, as DNSSEC is but one front of the battle. =A0Instead, I would su= ggest that WEBSEC should start by first requiring compliant web servers and= web browsers (and their extensions) to be digitally signed by a mutually t= rusted certificate authority, and that thereafter the WEBSEC standard shoul= d provide a mechanism for validating these digital signatures. =A0Over time= , digitally signed browsers and servers can provide a mechanism for blackli= sting known malicious servers AND malicious browsers. =A0Further, each clie= nt-server relationship can be encrypted using PKI with a lower industry cos= t. --001636920b8b411f0e04928a458d-- From tobias.gondrom@gondrom.org Sun Oct 24 10:05:46 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C4C3A68FC for ; Sun, 24 Oct 2010 10:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.588 X-Spam-Level: X-Spam-Status: No, score=-94.588 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, J_CHICKENPOX_12=0.6, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw2cYTJvtjmr for ; Sun, 24 Oct 2010 10:05:45 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 0D5B33A66B4 for ; Sun, 24 Oct 2010 10:05:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=YJ1w2z3AkAPvYyAp9v3I7jnvvmHfpsP6DXcTWIRNrKEr5IbbKp99PJseVqbTF0zuFIrOSlbTavsLHEAwxHNPyI+l7kFQlaowgbp90nVc1VikkTJVULJe1Ezzn2tdN0kL; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 32346 invoked from network); 24 Oct 2010 19:06:40 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Oct 2010 19:06:40 +0200 Message-ID: <4CC467AD.8090408@gondrom.org> Date: Sun, 24 Oct 2010 18:06:53 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 2 (High) X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [websec] agenda for Beijing: topics and presentation ideas? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 17:05:46 -0000 Hello dear fellow websec members, am currently working on the agenda for our meeting in Beijing. we have a session on Tuesday Nov-9, 1300-1500 (Afternoon Session) Please send proposals for presentations or agenda items to me or to the list ASAP! >From the past discussions on the list I could see there are a lot of topics to discuss: 1. requirements doc: please we still need at least a straw-man as basis for discussion - any volunteers please??? maybe s.th. based on Jeff and Andy's whitepaper (http://w2spconf.com/2010/papers/p11.pdf) 2. progress and discussion on - Origin: draft-abarth-mime-sniff - Media-Type Sniffing: draft-abarth-origin - Strict Transport Security: draft-hodges-strict-transport-sec (btw. if you haven't read the IDs yet, maybe now a good time to read them and post feedback on the list) 4. usage of DNSSEC for strict sec? 5. integrity of the browser and server? 6. overall framework: are there ideas how to fit our various points into an overarching concept? Any proposals, straw-man presentations - volunteers please? 7. X-FRAME-OPTIONS (or better FRAME-OPTIONS http header): any volunteer to throw a proposal in the ring? 8... ? Kind regards and please volunteers contact me ASAP (email, phone)! (I think we can also arrange for remote presentation facility using webex, if a presenter can't make it to Beijing.) Tobias Tobias Gondrom email: tobias.gondrom@gondrom.org mobile: +447521003005 From tobias.gondrom@gondrom.org Sun Oct 24 10:06:24 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70E03A66B4 for ; Sun, 24 Oct 2010 10:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.893 X-Spam-Level: X-Spam-Status: No, score=-94.893 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96wpbCXn6Bhp for ; Sun, 24 Oct 2010 10:06:23 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 63D003A68E1 for ; Sun, 24 Oct 2010 10:06:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=F7EsELYubOLt+bkS08m8UKaymBFDJAhkaMtOaU/tPGzSlT2pdZ+b8h3J1FNC/kPW0J5Z10acaOJ8Q9rrTXtHXcmLw0eYNnXTpifdHCMYqcCd7kXOL3pb+nds5SzwTnOU; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 1863 invoked from network); 24 Oct 2010 19:08:04 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Oct 2010 19:08:04 +0200 Message-ID: <4CC46802.4070403@gondrom.org> Date: Sun, 24 Oct 2010 18:08:18 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Steingruebl, Andy" , Phillip Hallam-Baker X-Priority: 4 (Low) References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 17:06:25 -0000 Having read all the comments, this looks worth investigating further. And to agree with Andy, we should probably start with thinking about what problem we're solving and work from there to DNSSEC for strict security and then deployment questions. Would anyone volunteer to maybe describe/write-up the underlying requirement for DNSSEC for strict security? We could then add this to the overall websec requirements doc or at least use it to guide the discussion? Many greetings, Tobias On 10/13/2010 09:44 PM, Steingruebl, Andy wrote: >> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >> Sent: Tuesday, October 12, 2010 1:46 PM >> An API is definitely required. > While I don't disagree that there may be room to have common API usage for this, and have it potentially provided for by the OS/Platform rather than application, a lot of the current OS/Platform APIs don't easily allow the passing or this type of data. This potentially requires substantial rework and timelag to get deployment. And, just as certain services come with specific platforms, not all applications choose the use the OS versions and provide their own. For example, Firefox always uses NSS even on platforms such as Windows that provide their own versions. > >> Based on my experience of how changes turn out to be necessary in the light of PKI deployment, I do not want to be dependent on >> host processing. That is the deployment error that sank SET. > In the case we're discussing, we're definitely going to be dependent on host processing, unless I misunderstand what you mean. The current DNSSEC last-hop problem is real, and must be solved for successful deployment of any of the technologies being contemplated. > >> I much prefer a model in which DNSSEC processing is performed at a recursive resolver that the host has established a trust relationship with. > OK, but as Kaminsky has demonstrated repeatedly this won't work over the DNS protocol itself today, because of both malicious and clueless middleboxes. > >> The attack model that is being considered in DNSSEC is the one where a malicious party modifies a DNS record. I am rather more concerned about >> the attack where the malicious party registered the DNS record. Just because someone has registered a domain does not mean I want my machine >> to connect to theirs. > DNS response filtering is entirely unrelated to anything we're discussing here, and I'd rather not muddy these waters with it. Deal with rogue hosts in another context please, they are an entirely orthogonal problem. > >> The idea of taking DNS service from an untrusted middlebox was always bogus. It might well be necessary to use some form of tunneling >> to route round malicious middleboxen as Dan described to get to a resolver we can trust. But I don't want to connect to the unedited DNS either. > The problem isn't just malicious middleboxes, it is broken ones. There are a lot of devices currently deployed that make pure E2E DNSSEC impossible today. > > Now that I've written all of this though, I think this forum is more about what problems we're solving, what policies need to exist and when (when in a connection lifecycle/timeline) and then lastly we can worry about the deployment concerns related to DNSSEC, etc. We can chase our tail for a long time here on how to get DNSSEC values reliably to end-nodes, but I'd rather not solve that problem in this forum, nor deal with other things like rogue hosts, hosting providers, etc. Those are entirely separate issues. > > - Andy > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From paul.hoffman@vpnc.org Sun Oct 24 12:23:36 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1DF3A679C for ; Sun, 24 Oct 2010 12:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.405 X-Spam-Level: X-Spam-Status: No, score=-101.405 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4HPsleXVeLE for ; Sun, 24 Oct 2010 12:23:36 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 04C173A6405 for ; Sun, 24 Oct 2010 12:23:35 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9OJPH3J048836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 24 Oct 2010 12:25:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4CC46802.4070403@gondrom.org> References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> <4CC46802.4070403@gondrom.org> X-Priority: 4 (Low) Date: Sun, 24 Oct 2010 12:25:16 -0700 To: websec From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 19:23:37 -0000 At 6:08 PM +0100 10/24/10, Tobias Gondrom wrote: > Having read all the comments, this looks worth investigating further. >And to agree with Andy, we should probably start with thinking about >what problem we're solving and work from there to DNSSEC for strict >security and then deployment questions. > >Would anyone volunteer to maybe describe/write-up the underlying >requirement for DNSSEC for strict security? Is there an agreed-to definition for "strict security"? So far, there has been: a) A statement that the responder for a particular application always has TLS/DTLS available b) (a) plus "with this particular crypto" c) (a) and maybe (b) plus "with this particular public key" d) (a) and maybe (b) plus "with a cert that chains to this particular trust anchor" e) A statement that the responder for a particular application always *requires* the use of TLS/DTLS (plus maybe some of the rest of above) f) A statement that a particular host always uses IPsec transport mode g) (f) plus "with this particular crypto" (and possibly the public key or the trust anchor) Even though I'm an IPsec kind of guy, I would rather that (f) and (g) not be what we discuss here. And, yes, I would be willing to do a presentation in Beijing on the result of this thread. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Sun Oct 24 13:47:39 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B693A67C2 for ; Sun, 24 Oct 2010 13:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sVlT8jDdrQn for ; Sun, 24 Oct 2010 13:47:38 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 599913A67B1 for ; Sun, 24 Oct 2010 13:47:38 -0700 (PDT) X-CheckPoint: {4CC499DD-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9OKnJ8c013323; Sun, 24 Oct 2010 22:49:20 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 24 Oct 2010 22:49:19 +0200 From: Yoav Nir To: Paul Hoffman Date: Sun, 24 Oct 2010 22:49:17 +0200 Thread-Topic: [websec] Use of DNS/DNSSEC for strict security Thread-Index: ActzvO2ANOIo5nVLTtG7IqCX+VwYtQ== Message-ID: <1CDF1971-4D10-48AC-8425-BEFD03B138B3@checkpoint.com> References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> <4CC46802.4070403@gondrom.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: websec Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 20:47:39 -0000 On Oct 24, 2010, at 9:25 PM, Paul Hoffman wrote: > Is there an agreed-to definition for "strict security"? So far, there has= been: >=20 > a) A statement that the responder for a particular application always has= TLS/DTLS available >=20 > b) (a) plus "with this particular crypto" >=20 > c) (a) and maybe (b) plus "with this particular public key" >=20 > d) (a) and maybe (b) plus "with a cert that chains to this particular tru= st anchor" >=20 > e) A statement that the responder for a particular application always *re= quires* the use of TLS/DTLS (plus maybe some of the rest of above) >=20 > f) A statement that a particular host always uses IPsec transport mode >=20 > g) (f) plus "with this particular crypto" (and possibly the public key or= the trust anchor) I think that (a) is sort of take-it-or-leave-it, so it's not "strict", even= if you add (b) through (d). (f) and (g) are not what we're discussing here. I think everybody's been ta= lking about (e). From hallam@gmail.com Mon Oct 25 05:10:21 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7813A67EC for ; Mon, 25 Oct 2010 05:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvw5vlRAXe2A for ; Mon, 25 Oct 2010 05:10:16 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 0A3733A69B1 for ; Mon, 25 Oct 2010 05:10:13 -0700 (PDT) Received: by gxk19 with SMTP id 19so826547gxk.31 for ; Mon, 25 Oct 2010 05:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fa7KEwuMUzxx/0TqQrtw3zY3OBTUFhspg91uMXR/NQw=; b=SYzttJzYJ4oPjJ6d8LHTHwDzvHzcmojdWgptH5QdmHJZFAcvWOhzVdulka1U91tcTI sTT3Lgp63gbZuseRcJ7YAR7V0Qyvh+Xa+gmzZBaa9WZOfGyy0S4UzsurA+zSlSgybCwh yZGd6pPH9jO+Nr9k/h9pumzcpAojEBTie04zs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lS9/RnbM8AMeEc9DB7cQUPfKsYkLHN7jKbpUI6BwamTvIeMd2q+KjIP9b/fiyUTQ+V 5/k8WZ6EQt2y/7nyTQqXdE2lTNINdr6d+kRt+l9jkibyQZIJHpC4pULf9h77Z6LOl5cW M62ZYUrQVVQHIK0HQjEWR8a914acboSorB+jI= MIME-Version: 1.0 Received: by 10.100.138.16 with SMTP id l16mr1649822and.121.1288008709602; Mon, 25 Oct 2010 05:11:49 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Mon, 25 Oct 2010 05:11:41 -0700 (PDT) In-Reply-To: <4CC46802.4070403@gondrom.org> References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> <4CC46802.4070403@gondrom.org> Date: Mon, 25 Oct 2010 08:11:41 -0400 Message-ID: From: Phillip Hallam-Baker To: Tobias Gondrom Content-Type: multipart/alternative; boundary=0016e6434ae89b394d04936fe502 Cc: websec Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 12:10:21 -0000 --0016e6434ae89b394d04936fe502 Content-Type: text/plain; charset=ISO-8859-1 I can do that. I discussed this issue with Tim Polk, the Security AD and he was thinking mostly in terms of 'experimental' as a first step here. Which is exactly what I would be asking for in his position. The DNS is unquestionably the right infrastructure to use to deploy security policy. But it is a difficult system to change and anyone who relies on use of DNSSEC is building on research. On Sun, Oct 24, 2010 at 1:08 PM, Tobias Gondrom wrote: > Having read all the comments, this looks worth investigating further. > And to agree with Andy, we should probably start with thinking about > what problem we're solving and work from there to DNSSEC for strict > security and then deployment questions. > > Would anyone volunteer to maybe describe/write-up the underlying > requirement for DNSSEC for strict security? > We could then add this to the overall websec requirements doc or at > least use it to guide the discussion? > > Many greetings, Tobias > > > > On 10/13/2010 09:44 PM, Steingruebl, Andy wrote: > >> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > >> Sent: Tuesday, October 12, 2010 1:46 PM > >> An API is definitely required. > > While I don't disagree that there may be room to have common API usage > for this, and have it potentially provided for by the OS/Platform rather > than application, a lot of the current OS/Platform APIs don't easily allow > the passing or this type of data. This potentially requires substantial > rework and timelag to get deployment. And, just as certain services come > with specific platforms, not all applications choose the use the OS versions > and provide their own. For example, Firefox always uses NSS even on > platforms such as Windows that provide their own versions. > > > >> Based on my experience of how changes turn out to be necessary in the > light of PKI deployment, I do not want to be dependent on > >> host processing. That is the deployment error that sank SET. > > In the case we're discussing, we're definitely going to be dependent on > host processing, unless I misunderstand what you mean. The current DNSSEC > last-hop problem is real, and must be solved for successful deployment of > any of the technologies being contemplated. > > > >> I much prefer a model in which DNSSEC processing is performed at a > recursive resolver that the host has established a trust relationship with. > > OK, but as Kaminsky has demonstrated repeatedly this won't work over the > DNS protocol itself today, because of both malicious and clueless > middleboxes. > > > >> The attack model that is being considered in DNSSEC is the one where a > malicious party modifies a DNS record. I am rather more concerned about > >> the attack where the malicious party registered the DNS record. Just > because someone has registered a domain does not mean I want my machine > >> to connect to theirs. > > DNS response filtering is entirely unrelated to anything we're discussing > here, and I'd rather not muddy these waters with it. Deal with rogue hosts > in another context please, they are an entirely orthogonal problem. > > > >> The idea of taking DNS service from an untrusted middlebox was always > bogus. It might well be necessary to use some form of tunneling > >> to route round malicious middleboxen as Dan described to get to a > resolver we can trust. But I don't want to connect to the unedited DNS > either. > > The problem isn't just malicious middleboxes, it is broken ones. There > are a lot of devices currently deployed that make pure E2E DNSSEC impossible > today. > > > > Now that I've written all of this though, I think this forum is more > about what problems we're solving, what policies need to exist and when > (when in a connection lifecycle/timeline) and then lastly we can worry about > the deployment concerns related to DNSSEC, etc. We can chase our tail for > a long time here on how to get DNSSEC values reliably to end-nodes, but I'd > rather not solve that problem in this forum, nor deal with other things like > rogue hosts, hosting providers, etc. Those are entirely separate issues. > > > > - Andy > > _______________________________________________ > > websec mailing list > > websec@ietf.org > > https://www.ietf.org/mailman/listinfo/websec > > -- Website: http://hallambaker.com/ --0016e6434ae89b394d04936fe502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I can do that.

I discussed this issue with Tim Polk, the= Security AD and he was thinking mostly in terms of 'experimental' = as a first step here. Which is exactly what I would be asking for in his po= sition.

The DNS is unquestionably the right infrastructure to u= se to deploy security policy. But it is a difficult system to change and an= yone who relies on use of DNSSEC is building on research.



On Sun, Oct 24, 2010 at 1:08 = PM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
=A0Having read all the comments, this looks worth investigating further. And to agree with Andy, we should probably start with thinking about
what problem we're solving and work from there to DNSSEC for strict
security and then deployment questions.

Would anyone volunteer to maybe describe/write-up the underlying
requirement for DNSSEC for strict security?
We could then add this to the overall websec requirements doc or at
least use it to guide the discussion?

Many greetings, Tobias



On 10/13/2010 09:44 PM, Steingruebl, Andy wrote:
>> From: Phillip Hallam-Baker [mailto:hallam@gmail.com]
>> Sent: Tuesday, October 12, 2010 1:46 PM
>> An API is definitely required.
> While I don't disagree that there may be room to have common API u= sage for this, and have it potentially provided for by the OS/Platform rath= er than application, a lot of the current OS/Platform APIs don't easily= allow the passing or this type of data. =A0This potentially requires subst= antial rework and timelag to get deployment. =A0And, just as certain servic= es come with specific platforms, not all applications choose the use the OS= versions and provide their own. =A0For example, Firefox always uses NSS ev= en on platforms such as Windows that provide their own versions.
>
>> Based on my experience of how changes turn out to be necessary in = the light of PKI deployment, I do not want to be dependent on
>> host processing. That is the deployment error that sank SET.
> In the case we're discussing, we're definitely going to be dep= endent on host processing, unless I misunderstand what you mean. =A0The cur= rent DNSSEC last-hop problem is real, and must be solved for successful dep= loyment of any of the technologies being contemplated.
>
>> I much prefer a model in which DNSSEC processing is performed at a= recursive resolver that the host has established a trust relationship with= .
> OK, but as Kaminsky has demonstrated repeatedly this won't work ov= er the DNS protocol itself today, because of both malicious and clueless mi= ddleboxes.
>
>> The attack model that is being considered in DNSSEC is the one whe= re a malicious party modifies a DNS record. I am rather more concerned abou= t
>> the attack where the malicious party registered the DNS record. Ju= st because someone has registered a domain does not mean I want my machine<= br> >> =A0to connect to theirs.
> DNS response filtering is entirely unrelated to anything we're dis= cussing here, and I'd rather not muddy these waters with it. =A0Deal wi= th rogue hosts in another context please, they are an entirely orthogonal p= roblem.
>
>> The idea of taking DNS service from an untrusted middlebox was alw= ays bogus. It might well be necessary to use some form of tunneling
>> to route round malicious middleboxen as Dan described to get to a = resolver we can trust. But I don't want to connect to the unedited DNS = either.
> The problem isn't just malicious middleboxes, it is broken ones. = =A0There are a lot of devices currently deployed that make pure E2E DNSSEC = impossible today.
>
> Now that I've written all of this though, I think this forum is mo= re about what problems we're solving, what policies need to exist and w= hen (when in a connection lifecycle/timeline) and then lastly we can worry = about the deployment concerns related to DNSSEC, etc. =A0 We can chase our = tail for a long time here on how to get DNSSEC values reliably to end-nodes= , but I'd rather not solve that problem in this forum, nor deal with ot= her things like rogue hosts, hosting providers, etc. =A0Those are entirely = separate issues.
>
> - Andy
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec




--
Website: http://hallambaker.com/

--0016e6434ae89b394d04936fe502-- From mail@samcaldwell.net Tue Oct 26 01:00:29 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4908E3A67A2 for ; Tue, 26 Oct 2010 01:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+CmTlSRpYD5 for ; Tue, 26 Oct 2010 01:00:27 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7DA843A67C3 for ; Tue, 26 Oct 2010 01:00:27 -0700 (PDT) Received: by iwn40 with SMTP id 40so5089208iwn.31 for ; Tue, 26 Oct 2010 01:02:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.30.68 with SMTP id t4mr6892620ibc.129.1288080134153; Tue, 26 Oct 2010 01:02:14 -0700 (PDT) Received: by 10.231.143.6 with HTTP; Tue, 26 Oct 2010 01:02:14 -0700 (PDT) X-Originating-IP: [67.78.39.190] Date: Tue, 26 Oct 2010 03:02:14 -0500 Message-ID: From: Sam Caldwell To: websec@ietf.org Content-Type: multipart/alternative; boundary=00032557563ad6b4f4049380869b Subject: [websec] WEBSEC and The Need for More Than DNSSEC X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 08:00:29 -0000 --00032557563ad6b4f4049380869b Content-Type: text/plain; charset=ISO-8859-1 Problem Statement: ------------------ Thus far the WEBSEC discussion appears to be focussed on DNSSEC. However, the more significant security issues surrounding the web are largely uncovered by this discussion. DNSSEC will help ensure that host A is connected to server B and that server B is in fact server B, but to borrow from one member of the mailing list, "Just because someone has registered a domain does not mean I want my machine to connect to theirs." For this reason, while DNSSEC is a welcome advance in Internet security, DNSSEC is a separate topic, and it should not obstruct the need for web-specific security measures to protect the public. Proposed Scope of WEBSEC: ------------------------- WEBSEC must be defined clearly as a scope separate from, though complementary to the DNSSEC sphere. This in mind, it is hereby proposed that WEBSEC be defined as follows: WEBSEC is a collection of standards and specifications aimed at ensuring the integrity of communications between two hosts over the HTTP and HTTP/S protocols through robust trust relationships. Given that most web clients (i.e. browsers) operate from behind a NAT link or otherwise appear to the web browser to have a dynamic IP identity, it is not realistic to use DNSSEC to represent any trust relationship. DNSSEC may potentially ensure the identity of the web server, but this does nothing to protect the integrity of the client-server relationship, as the identity and integrity of the client-side is wholly ignored. The Trust Relationship: ----------------------- WEBSEC must treat the client-server relationship as a whole. The integrity of the relationship is a direct function of the integrity of both the web server AND the web client. To this extent, WEBSEC must require the use of digital signatures to uniquely identify each web server and web browser, its many extensions and add-ons. However, WEBSEC must remain backward compatible in order to survive. To this end, WEBSEC compliance should be relative. If WEBSEC compliance were assigned some value relative to the current status quo, then today's existing web browsers and servers would be the baseline WEBSEC level zero (0). Some minimal standard of compliance, such as the use of digital signatures for the core components of the browser or server software might represent WEBSEC level one (1) compliance. Meanwhile where a browser or web server implements full digital signatures for core components as well as add-on modules, the same would meet WEBSEC level two (2) compliance. Additional features would likewise represent increased compliance. Relative compliance standards would allow a slow but stable transition from the status quo of today to the ideal security position of tomorrow. As new features of WEBSEC are implemented by the community, the average compliance rating should increase. Additionally, the use of such scores will allow both the end-user (through his/her browser preferences) and the web administrator (through his/her server configuration) to determine both their own individual WEBSEC compliance level as well as the minimum WEBSEC compliance level required to establish a trust relationship with one another. Thus, for example, a web browser with a WEBSEC level one (1) compliance, might reject any attempt to connect to web servers that do not meet level one (1) complaince standards. A web administrator might also configure his/her web servers to require no less than level two (2) complaince in order to connect to certain sensitive functions of the web server (i.e. e-commerce) so as to protect the organization from fraud. The use of digital signatures in establishing the integrity of the two sides of the client-server relationship can also be used to secure their communications. Where the client has a digital signature unique to its particular build, it has a public key shared by all other instances of the same software. This is not sufficient. Instead, each build of a particular software module must be signed by an instance-specific certificate which is itself signed by a build-specific certificate that belongs to a certificate chain whose root is the WEBSEC root certificate authority. The instance-specific certificate will allow each individual web client or server to be identified from all others uniquely (and also allow for secure communications), while the build-specific certificate will certify the particular software has a valid heritage. For example, a particular build of Mozilla Firefox for x86_64 packaged for Debian 5.04 would have a build- specific certificate. This certificate ensures that all parties to a client- server relationship involving the particular build of Firefox can verify its origins. However, the same browser must also be signed uniquely (using some host- and time-specific GUID). This is the instance-specific certificate, and it uniquely identifies the particular browser as a part of its host as well as a member of its browser family. Using the instance-specific certificate, WEBSEC may facilitate secure communications between client and server. Levels of Trust and Security ---------------------------- Given the above specifications for a WEBSEC using build-specific and instance- specific certificates, WEBSEC may establish levels of trust. Each level of trust represents a new level of assurance that client-server interactions are both legitimate and secure. The initial trust level ensures backward compatibility with the existing world. This state, or "trust level zero(0)," has no means of securing communications or ensuring the integrity of the players. However, trust level one (1) must provide at least build-specific certificates, as described earlier, which ensure the integrity of the players. It remains possible at trust level one (1) for a man-in-the-middle attack to commit some fraud. But this also requires a minimum initial investment on the part of web browser developers and web servers, and represents a significant step in the right direction. As trust level one (1) is adopted, trust level two (2) can begin to emerge. Under level two (2), the instance-specific certificates on both client (browser) and server sides are implemented. This trust level secures communication between client and server, boosting security further. When two WEBSEC-compliant parties connect, they may detect through the certificates each offers to the other, the highest level of trust possible and thereby make a determination as to whether or not they will continue their interactions. Instance-specific certificates to secure communication go further than DNSSEC to protect the integrity of the web. While DNSSEC can help to prevent spoofing of some domain by some third-party, WEBSEC as contemplated here, would help to secure the transmission of information betwen client and server, giving both the web administrator and the end user the power to better control these relationships and defeat would-be prying eyes. --00032557563ad6b4f4049380869b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Problem Statement:
------------------
Thus far the= WEBSEC discussion appears to be focussed on DNSSEC. =A0However, the
<= div>more significant security issues surrounding the web are largely uncove= red by
this discussion. =A0DNSSEC will help ensure that host A is connected t= o server B=A0
and that server B is in fact server B, but to borro= w from one member of the
mailing list, "Just because someone= has registered a domain does not mean I=A0
want my machine to connect to theirs." =A0For this reason, while = DNSSEC is a=A0
welcome advance in Internet security, DNSSEC is a = separate topic, and it should
not obstruct the need for web-speci= fic security measures to protect the public.

Proposed Scope of WEBSEC:
-------------------= ------
WEBSEC must be defined clearly as a scope separate from, t= hough complementary=A0
to the DNSSEC sphere. =A0This in mind, it = is hereby proposed that WEBSEC be=A0
defined as follows:

WEBSEC is a collection of standards= and specifications aimed at ensuring
the integrity of communications betwe= en two hosts over the HTTP and HTTP/S
proto= cols through robust trust relationships.

Given tha= t most web clients (i.e. browsers) operate from behind a NAT link or
<= div> otherwise appear to the web browser to have a dynamic IP identity, it is no= t
realistic to use DNSSEC to represent any trust relationship. = =A0DNSSEC may=A0
potentially ensure the identity of the web serve= r, but this does nothing to=A0
protect the integrity of the client-server relationship, as the identi= ty and
integrity of the client-side is wholly ignored.

The Trust Relationship:
-----------------------
WE= BSEC must treat the client-server relationship as a whole. =A0The integrity= of
the relationship is a direct function of the integrity of bot= h the web server
AND the web client. =A0To this extent, WEBSEC must require the use of = digital
signatures to uniquely identify each web server and web b= rowser, its many
extensions and add-ons. =A0However, WEBSEC must = remain backward compatible in=A0
order to survive. =A0To this end, WEBSEC compliance should be relative= .

If WEBSEC compliance were assigned some value re= lative to the current status
quo, then today's existing web b= rowsers and servers would be the baseline=A0
WEBSEC level zero (0). =A0Some minimal standard of compliance, such as= the use
of digital signatures for the core components of the bro= wser or server software
might represent WEBSEC level one (1) comp= liance. =A0Meanwhile where a browser or
web server implements full digital signatures for core components as w= ell as
add-on modules, the same would meet WEBSEC level two (2) c= ompliance. =A0Additional
features would likewise represent increa= sed compliance.

Relative compliance standards would allow a slow but st= able transition from=A0
the status quo of today to the ideal secu= rity position of tomorrow. =A0As new=A0
features of WEBSEC are im= plemented by the community, the average compliance=A0
rating should increase. =A0Additionally, the use of such scores will a= llow both=A0
the end-user (through his/her browser preferences) a= nd the web administrator
(through his/her server configuration) t= o determine both their own individual
WEBSEC compliance level as well as the minimum WEBSEC compliance level= required
to establish a trust relationship with one another. =A0= Thus, for example, a web
browser with a WEBSEC level one (1) comp= liance, might reject any attempt to=A0
connect to web servers that do not meet level one (1) complaince stand= ards. =A0A
web administrator might also configure his/her web ser= vers to require no less
than level two (2) complaince in order to= connect to certain sensitive functions
of the web server (i.e. e-commerce) so as to protect the organization = from=A0
fraud.

The use of digital signat= ures in establishing the integrity of the two sides of
the client= -server relationship can also be used to secure their communications.
Where the client has a digital signature unique to its particular buil= d, it has
a public key shared by all other instances of the same = software. =A0This is not=A0
sufficient. =A0Instead, each build of= a particular software module must be signed
by an instance-specific certificate which is itself signed by a build-= specific
certificate that belongs to a certificate chain whose ro= ot is the WEBSEC root
certificate authority. =A0The instance-spec= ific certificate will allow each=A0
individual web client or server to be identified from all others uniqu= ely (and
also allow for secure communications), while the build-s= pecific certificate will
certify the particular software has a va= lid heritage. =A0For example, a particular
build of Mozilla Firefox for x86_64 packaged for Debian 5.04 would hav= e a build-
specific certificate. =A0This certificate ensures that= all parties to a client-
server relationship involving the parti= cular build of Firefox can verify its
origins. =A0However, the same browser must also be signed uniquely (us= ing some=A0
host- and time-specific GUID). =A0This is the instanc= e-specific certificate, and
it uniquely identifies the particular= browser as a part of its host as well as
a member of its browser family. =A0Using the instance-specific certifi= cate,=A0
WEBSEC may facilitate secure communications between clie= nt and server.

Levels of Trust and Security
<= div> ----------------------------
Given the above specifications for a= WEBSEC using build-specific and instance-
specific certificates,= WEBSEC may establish levels of trust. =A0Each level of=A0
trust = represents a new level of assurance that client-server interactions are
both legitimate and secure. =A0The initial trust level ensures backwar= d
compatibility with the existing world. =A0This state, or "= trust level zero(0),"
has no means of securing communication= s or ensuring the integrity of the=A0
players. =A0However, trust level one (1) must provide at least build-s= pecific=A0
certificates, as described earlier, which ensure the i= ntegrity of the players.
It remains possible at trust level one (= 1) for a man-in-the-middle attack to=A0
commit some fraud. =A0But this also requires a minimum initial investm= ent on the
part of web browser developers and web servers, and re= presents a significant
step in the right direction. =A0As trust l= evel one (1) is adopted, trust level=A0
two (2) can begin to emerge. =A0Under level two (2), the instance-spec= ific=A0
certificates on both client (browser) and server sides ar= e implemented. =A0This
trust level secures communication between = client and server, boosting security
further. =A0When two WEBSEC-compliant parties connect, they may detect= through=A0
the certificates each offers to the other, the highes= t level of trust possible
and thereby make a determination as to = whether or not they will continue their=A0
interactions.

Instance-specific certificates = to secure communication go further than DNSSEC
to protect the int= egrity of the web. =A0While DNSSEC can help to prevent spoofing
of some domain by some third-party, WEBSEC as contemplated here, would help= to
secure the transmission of information betwen client and serv= er, giving both the
web administrator and the end user the power = to better control these=A0
relationships and defeat would-be prying eyes.
--00032557563ad6b4f4049380869b-- From paul.hoffman@vpnc.org Tue Oct 26 07:34:01 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2283A683F for ; Tue, 26 Oct 2010 07:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.422 X-Spam-Level: X-Spam-Status: No, score=-101.422 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7bLaJ-0gwAj for ; Tue, 26 Oct 2010 07:34:00 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E00CC3A67A1 for ; Tue, 26 Oct 2010 07:33:59 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9QEZkbJ077934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Oct 2010 07:35:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1CDF1971-4D10-48AC-8425-BEFD03B138B3@checkpoint.com> References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> <4CC46802.4070403@gondrom.org> <1CDF1971-4D10-48AC-8425-BEFD03B138B3@checkpoint.com> Date: Tue, 26 Oct 2010 07:35:44 -0700 To: websec From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 14:34:01 -0000 At 10:49 PM +0200 10/24/10, Yoav Nir wrote: >On Oct 24, 2010, at 9:25 PM, Paul Hoffman wrote: > >> Is there an agreed-to definition for "strict security"? So far, there has been: >> >> a) A statement that the responder for a particular application always has TLS/DTLS available >> >> b) (a) plus "with this particular crypto" >> >> c) (a) and maybe (b) plus "with this particular public key" >> >> d) (a) and maybe (b) plus "with a cert that chains to this particular trust anchor" >> >> e) A statement that the responder for a particular application always *requires* the use of TLS/DTLS (plus maybe some of the rest of above) >> >> f) A statement that a particular host always uses IPsec transport mode >> >> g) (f) plus "with this particular crypto" (and possibly the public key or the trust anchor) > >I think that (a) is sort of take-it-or-leave-it, so it's not "strict", even if you add (b) through (d). > >(f) and (g) are not what we're discussing here. I think everybody's been talking about (e). So far, only Yoav and Phill have chimed in. Doesn't anyone else on the list have an opinion on what "strict security" means? I'm fine if not (it will make the presentation much shorter), but am surprised given what I heard over the past few years. --Paul Hoffman, Director --VPN Consortium From hallam@gmail.com Tue Oct 26 08:43:17 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3623A6828 for ; Tue, 26 Oct 2010 08:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcCe74ZsDfFP for ; Tue, 26 Oct 2010 08:43:16 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 4C54F3A696B for ; Tue, 26 Oct 2010 08:43:11 -0700 (PDT) Received: by ywp6 with SMTP id 6so2558770ywp.31 for ; Tue, 26 Oct 2010 08:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=n6NCyVpVdHtFosEo9SWmoCKykNloGN/2DC+9suLzr7E=; b=tMlEcaei/G0lsRj0xpoRLDA2uZK54P6gqi/FJvEsLVLRqk6G/M9AjhxcyakwtVwuwn qPd/kHvnQjIluP8tKMKAcAfkbCu+C4BPrs5Am+f2HNd5GyGtRg8QVFZFb0tlpeof0HgJ SzrRkMDu+ZybOQdRb4E/FG/LEtFDdJS/BVNZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=F1F6jf8+k8b3NTyrG9sgb5O0zs52sx7WdBjYb53rxCwZJLeqdagF4cvY7UJftM55WQ VEm78635b6MxP8cRC1jryxvRPxbb0moK/ShfA0sB9ONJZQ4RsqaFM4R2SZwtbiLISdfa yxHz4xjyzbJHTFz3fF95AhKol7X6XSR2HYzKc= MIME-Version: 1.0 Received: by 10.100.106.19 with SMTP id e19mr6810085anc.78.1288107898485; Tue, 26 Oct 2010 08:44:58 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Tue, 26 Oct 2010 08:44:58 -0700 (PDT) In-Reply-To: References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> <4CC46802.4070403@gondrom.org> <1CDF1971-4D10-48AC-8425-BEFD03B138B3@checkpoint.com> Date: Tue, 26 Oct 2010 11:44:58 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e642d9d6b8bd02049386fde2 Cc: websec Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 15:43:17 -0000 --0016e642d9d6b8bd02049386fde2 Content-Type: text/plain; charset=ISO-8859-1 I see a hierarchy of potential security policy statements as follows: 1) example.com always offers TLS 2) example.com always offers TLS with minimum trust criteria 3) example.com always offers TLS with minimum trust criteria from a specific provider. Given that most Internet traffic is not encrypted at all, my first priority is to allow a site to prevent a downgrade attack and state that they either always offer or require the use of TLS . This is also the simplest form of security policy to specify. TLS has protocol protections against downgrade attacks once the TLS protocol is initiated but cannot protect against a downgrade attack on use of TLS itself. Levels (2) and (3) are important but more challenging. There is more than one way to achieve this level of policy. The feedback I have got from the ADs over several years is that they want to be convinced that any proposal will come to a successful conclusion. So I am willing to do (1) in advance of (2) and (3), but don't want to adopt any mechanism that forecloses the possibility of going beyond (1). A second aspect of policy is that it allows a site to state that its security requirements either suggest or require the use of a separate browser that is designed for security sensitive applications. I particularly like the work that Diane Smetters and others did at Xerox on this approach. The problem I have seen with trying to get strong security into regular browsers is that most users are only performing security sensitive tasks 2% of the time. The usability designers are optimizing the security experience for the other 98% of interactions. As a result every proposal to provide a strong security signal gets watered down by the usability people. My view of what a strong security signal would be is to freeze the entire UI of the machine for about three seconds on startup and display an interstatial page showing the user that they have entered the security mode and are now communicating securely with Paypal or Fidelity or whoever. After that point there would be a distinctive UI look and feel and a constant reminder that they are on the secure site. This is not something that end users could or should expect for their regular diet of facebook browsing, slashdot and porn. But it is a mode of use that has real value when security is essential. On Tue, Oct 26, 2010 at 10:35 AM, Paul Hoffman wrote: > At 10:49 PM +0200 10/24/10, Yoav Nir wrote: > >On Oct 24, 2010, at 9:25 PM, Paul Hoffman wrote: > > > >> Is there an agreed-to definition for "strict security"? So far, there > has been: > >> > >> a) A statement that the responder for a particular application always > has TLS/DTLS available > >> > >> b) (a) plus "with this particular crypto" > >> > >> c) (a) and maybe (b) plus "with this particular public key" > >> > >> d) (a) and maybe (b) plus "with a cert that chains to this particular > trust anchor" > >> > >> e) A statement that the responder for a particular application always > *requires* the use of TLS/DTLS (plus maybe some of the rest of above) > >> > >> f) A statement that a particular host always uses IPsec transport mode > >> > >> g) (f) plus "with this particular crypto" (and possibly the public key > or the trust anchor) > > > >I think that (a) is sort of take-it-or-leave-it, so it's not "strict", > even if you add (b) through (d). > > > >(f) and (g) are not what we're discussing here. I think everybody's been > talking about (e). > > So far, only Yoav and Phill have chimed in. Doesn't anyone else on the list > have an opinion on what "strict security" means? I'm fine if not (it will > make the presentation much shorter), but am surprised given what I heard > over the past few years. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ --0016e642d9d6b8bd02049386fde2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see a hierarchy of potential security policy statements as follows:
<= br>
1) example.com always offe= rs=A0TLS=A0
2) example.com alw= ays offers=A0TLS=A0with minimum trust criteria
3) example.com always offers=A0TLS= =A0with minimum trust criteria from a specific provider.

Given that most Internet traffic is not encrypted at all, my first p= riority is to allow a site to prevent a downgrade attack and state that the= y either always offer or require the use of=A0TLS=A0.

This is also the simplest form of security policy to sp= ecify. TLS has protocol protections against downgrade attacks once the TLS = protocol is initiated but cannot protect against a downgrade attack on use = of TLS itself.


Levels (2) and (3) are important but mor= e challenging. There is more than one way to achieve this level of policy.<= /div>

The feedback I have got from the ADs over several = years is that they want to be convinced that any proposal will come to a su= ccessful conclusion.

So I am willing to do (1) in advance of (2) and (3), bu= t don't want to adopt any mechanism that forecloses the possibility of = going beyond (1).


A second aspect o= f policy is that it allows a site to state that its security requirements e= ither suggest or require the use of a separate browser that is designed for= security sensitive applications. I particularly like the work that Diane S= metters and others did at Xerox on this approach.

The problem I have seen with trying to get strong secur= ity into regular browsers is that most users are only performing security s= ensitive tasks 2% of the time. The usability designers are optimizing the s= ecurity experience for the other 98% of interactions.=A0As a result every p= roposal to provide a strong security signal gets watered down by the usabil= ity people.=A0


My view of what a strong security signal would= be is to freeze the entire UI of the machine for about three seconds on st= artup and display an interstatial page showing the user that they have ente= red the security mode and are now communicating securely with Paypal or Fid= elity or whoever. After that point there would be a distinctive UI look and= feel and a constant reminder that they are on the secure site.

This is not something that end users could or should ex= pect for their regular diet of facebook browsing, slashdot and porn. But it= is a mode of use that has real value when security is essential.



On Tue, O= ct 26, 2010 at 10:35 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
At 10:49 PM +0200 10/24/10, Yoav Nir wrote:
>On Oct 24, 2010, at 9:25 PM, Paul Hoffman wrote:
>
>> Is there an agreed-to definition for "strict security"? = So far, there has been:
>>
>> a) A statement that the responder for a particular application alw= ays has TLS/DTLS available
>>
>> b) (a) plus "with this particular crypto"
>>
>> c) (a) and maybe (b) plus "with this particular public key&qu= ot;
>>
>> d) (a) and maybe (b) plus "with a cert that chains to this pa= rticular trust anchor"
>>
>> e) A statement that the responder for a particular application alw= ays *requires* the use of TLS/DTLS (plus maybe some of the rest of above) >>
>> f) A statement that a particular host always uses IPsec transport = mode
>>
>> g) (f) plus "with this particular crypto" (and possibly = the public key or the trust anchor)
>
>I think that (a) is sort of take-it-or-leave-it, so it's not "= strict", even if you add (b) through (d).
>
>(f) and (g) are not what we're discussing here. I think everybody&#= 39;s been talking about (e).

So far, only Yoav and Phill have chimed in. Doesn't anyone else o= n the list have an opinion on what "strict security" means? I'= ;m fine if not (it will make the presentation much shorter), but am surpris= ed given what I heard over the past few years.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________



--
Website: http://hallambaker.com/

--0016e642d9d6b8bd02049386fde2-- From asteingruebl@paypal-inc.com Tue Oct 26 09:49:51 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8193A689F for ; Tue, 26 Oct 2010 09:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.023 X-Spam-Level: X-Spam-Status: No, score=-5.023 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GM0E7FpfZZK for ; Tue, 26 Oct 2010 09:49:49 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id B79433A69A8 for ; Tue, 26 Oct 2010 09:49:42 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=cKqhcM9Q2JO8SShuKPTffIoceV5EQ8ztmR+J32vgFKGvqjGs2yNEKiy4 DetYDzsHIfjUAkNYDDW4c24T8gXu3VIWOu2oRcjmNjzEH1teElSLHeK2u WwhhRJoYz6NVrIP; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1288111895; x=1319647895; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Paul=20Hoffman=20,=20w ebsec=20|Date:=20Tue,=2026=20Oct=202010 =2010:51:29=20-0600|Subject:=20RE:=20[websec]=20Use=20of =20DNS/DNSSEC=20for=20strict=20security|Message-ID:=20<5E E049BA3C6538409BBE6F1760F328ABEB01D3A85C@DEN-MEXMS-001.co rp.ebay.com>|References:=20=0D=0A=09=0D=0A=09<5EE049BA3C6538409BBE6F1 760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com>=0D=0A=09 =0D=0A=09<5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1 @DEN-MEXMS-001.corp.ebay.com>=0D=0A=09<4CC46802.4070403@g ondrom.org>=20 |In-Reply-To:=20 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=eyKBnOARtIWGfOwNoRuik9YCGdICBYz+wtGz7FP4lkk=; b=Pcx8SIs/2SovjBFUig+9oJS6Z/em8R8gAkOnvJPMP3EOpUQ7NyjLVo91 +hSaDiWreBpkBzAahlBiRDMMNq2X1Big4FOflxfwMP4pgED0vImucEl4k VZTiqRdaK0/QrPt; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.58,242,1286175600"; d="scan'208";a="72770148" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 26 Oct 2010 09:51:30 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Tue, 26 Oct 2010 10:51:29 -0600 From: "Steingruebl, Andy" To: Paul Hoffman , websec Date: Tue, 26 Oct 2010 10:51:29 -0600 Thread-Topic: [websec] Use of DNS/DNSSEC for strict security Thread-Index: ActzsTTe767lKrAjRA+1RhBICfw55gBfJ36A Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB01D3A85C@DEN-MEXMS-001.corp.ebay.com> References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> <4CC46802.4070403@gondrom.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: ETX/InB8M1su0FQ2goVWgw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 16:49:51 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Paul Hoffman >=20 > Is there an agreed-to definition for "strict security"? So far, there has= been: >=20 >=20 > e) A statement that the responder for a particular application always > *requires* the use of TLS/DTLS (plus maybe some of the rest of above) I vote for (e). This is what HSTS currently does, and I think really what = we're discussing. STS generically is just about requiring TLS, I think oth= er mechanisms should be used for conveying any other policy statements such= as how keys are verified, etc.=20 - Andy From marsh@extendedsubset.com Tue Oct 26 10:53:24 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FC03A67F0 for ; Tue, 26 Oct 2010 10:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.164 X-Spam-Level: X-Spam-Status: No, score=-1.164 tagged_above=-999 required=5 tests=[AWL=-0.424, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPBBp3K-HhvM for ; Tue, 26 Oct 2010 10:53:21 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 146823A68EE for ; Tue, 26 Oct 2010 10:53:21 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PAnjo-000MTN-GF; Tue, 26 Oct 2010 17:55:08 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A321F633E; Tue, 26 Oct 2010 17:55:06 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18sYspj0TfqLkzVN6ugEm/1FpHsknSDT1E= Message-ID: <4CC715FA.9040602@extendedsubset.com> Date: Tue, 26 Oct 2010 12:55:06 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.14) Gecko/20101006 Thunderbird/3.0.9 MIME-Version: 1.0 To: Sam Caldwell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] WEBSEC and The Need for More Than DNSSEC X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 17:53:24 -0000 On 10/26/2010 03:02 AM, Sam Caldwell wrote: > DNSSEC will help ensure that host A is connected to > server B and that server B is in fact server B, but to borrow from > one member of the mailing list, "Just because someone has registered > a domain does not mean I want my machine to connect to theirs." Seeing as how DNS is the 'domain name service' for the internet, and to 'register a domain' is (by definition) to have the right to define DNS records for that domain, what does that statement actually mean? Presuming you actually want to use the internet, you will need to connect to other machines at some point. By what name will you identify the machine you actually do intend to connect to which does not involve a registered domain? Maybe you don't want to connect to evil-attack-site.com, but how does DNSSEC prevent that if you ask for it? > WEBSEC must treat the > client-server relationship as a whole. The integrity of the > relationship is a direct function of the integrity of both the web > server AND the web client. And is explicitly not dependent the network in between, which is presumed to be hostile. > To this extent, WEBSEC must require the > use of digital signatures to uniquely identify each web server and > web browser, its many extensions and add-ons. However, WEBSEC must > remain backward compatible in order to survive. To this end, WEBSEC > compliance should be relative. I don't like where this is going. What's a "web server"? What's a "web browser"? Seriously, if you are going to talk about requiring certificates for every specific set of hardware or software used for "the web", you'd better have a near-perfect definition of these terms. I don't think it can be done. > Some minimal standard of > compliance, such as the use of digital signatures for the core > components of the browser or server software might represent WEBSEC > level one (1) compliance. There have been innumerable code-signing schemes proposed and deployed over the years and I doubt any of them have increased security one bit. Instead, they are only useful for locking down computing hardware to prevent the hardware's owner from using it to perform computations not approved by the vendor. Of course, this has eventually failed every time it has been tried so only serves to delay the inevitable. > Meanwhile where a browser or web server > implements full digital signatures for core components as well as > add-on modules, the same would meet WEBSEC level two (2) compliance. > Additional features would likewise represent increased compliance. How would a digital signature for "core components" improve security? You might find some examples of trojaned installers somewhere, but realistically, of all the vulnerabilities and actual incidents involving web security, how many were due to users running nonstandard web browsers? > Relative compliance standards would allow a slow but stable > transition from the status quo of today to the ideal security > position of tomorrow. As new features of WEBSEC are implemented by > the community, the average compliance rating should increase. > Additionally, the use of such scores will allow both the end-user > (through his/her browser preferences) and the web administrator > (through his/her server configuration) to determine both their own > individual WEBSEC compliance level as well as the minimum WEBSEC > compliance level required to establish a trust relationship with one > another. Thus, for example, a web browser with a WEBSEC level one > (1) compliance, might reject any attempt to connect to web servers > that do not meet level one (1) complaince standards. A web > administrator might also configure his/her web servers to require no > less than level two (2) complaince in order to connect to certain > sensitive functions of the web server (i.e. e-commerce) so as to > protect the organization from fraud. > > The use of digital signatures in establishing the integrity of the > two sides of the client-server relationship can also be used to > secure their communications. Where the client has a digital signature > unique to its particular build, it has a public key shared by all > other instances of the same software. This is not sufficient. > Instead, each build of a particular software module must be signed by > an instance-specific certificate which is itself signed by a > build-specific certificate that belongs to a certificate chain whose > root is the WEBSEC root certificate authority. You seem to place a lot in using digital signatures to enforce "compliance", but haven't said yet how it will actually improve security. Yeah, it's actually really easy (and strangely appealing to some people) to design a top-down control system and imagine that it will solve all our problems. People have tried this kind of thing over and over again and it always either sucks so bad that it doesn't get deployed, or it gets deployed at huge expense and sucks for everyone who has to use it until it can be thrown out. In reality, people don't trust top-down. People trust in complex networks for subtle reasons that are often wrong. But for some reason, it's the top-down trust models that turn out to have the most catastrophic failure modes every time. > The instance-specific > certificate will allow each individual web client or server to be > identified from all others uniquely (and also allow for secure > communications), while the build-specific certificate will certify > the particular software has a valid heritage. For example, a > particular build of Mozilla Firefox for x86_64 packaged for Debian > 5.04 would have a build- specific certificate. Last time I used Debian as a client, they weren't permitted to build "Firefox" due to trademark issues. The thing they packaged was called "Iceweasel". Who is going to decide that "Debian Iceweasel" is or is not a "compliant web client" with a "valid heritage"? Stuxnet had free usage of not one, but two, valid code-signing certificates for a year or more. > This certificate > ensures that all parties to a client- server relationship involving > the particular build of Firefox can verify its origins. No, it doesn't actually work that way. In practice, any other piece of code running with that user's permissions, root permissions, outer virtual machine, or even write access to any number of filesystem locations has the ability to inject code into the iceweasel process. Signing some build package does absolutely nothing to prevent malicious code from running in the browser. > However, the > same browser must also be signed uniquely (using some host- and > time-specific GUID). This is the instance-specific certificate, and > it uniquely identifies the particular browser as a part of its host > as well as a member of its browser family. Using the > instance-specific certificate, WEBSEC may facilitate secure > communications between client and server. Oh I see now. Here we come down to it. In your vision of the secure web, everyone will be required to be running an approved, "compliant" browser and register their computer with some central authority. There were lots of networks run by telephone companies and such which implemented that kind of model. We using the internet that we have today precisely because every single one of those other models died out! They sucked, didn't scale, and were unequivocally rejected by the market. > Levels of Trust and Security ---------------------------- Given the > above specifications for a WEBSEC using build-specific and instance- > specific certificates, WEBSEC may establish levels of trust. Each > level of trust represents a new level of assurance that client-server > interactions are both legitimate and secure. The initial trust > level ensures backward compatibility with the existing world. This > state, or "trust level zero(0)," has no means of securing > communications or ensuring the integrity of the players. However, > trust level one (1) must provide at least build-specific > certificates, as described earlier, which ensure the integrity of the > players. It remains possible at trust level one (1) for a > man-in-the-middle attack to commit some fraud. But this also > requires a minimum initial investment on the part of web browser > developers and web servers, and represents a significant step in the > right direction. As trust level one (1) is adopted, trust level two > (2) can begin to emerge. Under level two (2), the instance-specific > certificates on both client (browser) and server sides are > implemented. This trust level secures communication between client > and server, boosting security further. When two WEBSEC-compliant > parties connect, they may detect through the certificates each offers > to the other, the highest level of trust possible and thereby make a > determination as to whether or not they will continue their > interactions. > > Instance-specific certificates to secure communication go further > than DNSSEC to protect the integrity of the web. While DNSSEC can > help to prevent spoofing of some domain by some third-party, WEBSEC > as contemplated here, would help to secure the transmission of > information betwen client and server, giving both the web > administrator and the end user the power to better control these > relationships and defeat would-be prying eyes. Giving some central ministry of information the authority to "approve" "compliant" softare and even require "licensed users" of some future supposedly-secure web. We've been down this road in the past. (The next shoe that drops is key escrow.) But you didn't explain how this grand scheme of "compliance" is going to prevent any of the current real-world security holes: Q: What will it do about the 10-100Ms of MS Windows client PCs (web clients) pwned with malware? Q: What will it do about Adobe PDF and Flash plugins that come preinstalled with dozens of exploitable security holes? Q: What will it do to prevent client systems from an innumerable number of root and intermediate CAs? Q: What will it do to prevent phishing? Q: What will it do about SQL, XSS, or other script injection? Q: What will it do about Debian signing a "compliant" server with no entropy in its cryptographic RNG? Q: What will it do to prevent users from using the same weak password everywhere? A: Nothing. And lest we forget: Q: What will it do to support individual privacy, anonymity, and control the leakage of their personal data and prevent marketers/credit bureaus/insurers/governments/attackers from tracking their every movement online? - Marsh From tobias.gondrom@gondrom.org Wed Oct 27 10:38:30 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875F13A6A15 for ; Wed, 27 Oct 2010 10:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.905 X-Spam-Level: X-Spam-Status: No, score=-94.905 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT82i+LEPCq8 for ; Wed, 27 Oct 2010 10:38:29 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 1843C3A69B8 for ; Wed, 27 Oct 2010 10:38:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=DwNaI6rBsUvuD/3Rk81vDJ4ltUioDxhmvay3hd1K1eNuIndEAnUt8BTp8PDuvfCuxEUc6msy7GMpTlrmPdu8fwikVxzcN5JenYYcAplRRNjSb2RLbsg8kFMKKP8KWp24; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 30316 invoked from network); 27 Oct 2010 19:39:23 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Oct 2010 19:39:22 +0200 Message-ID: <4CC863E1.5030302@gondrom.org> Date: Wed, 27 Oct 2010 18:39:45 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: websec@ietf.org References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> <4CC46802.4070403@gondrom.org> <5EE049BA3C6538409BBE6F1760F328ABEB01D3A85C@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB01D3A85C@DEN-MEXMS-001.corp.ebay.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 17:38:30 -0000 Definitely agree with (e). And maybe to go into this further: What of the options b,c,d, do we really need for that: b) plus "with this particular crypto" c) and maybe (b) plus "with this particular public key" d) and maybe (b) plus "with a cert that chains to this particular trust anchor" Would we need finer granularity? I think we definitely should include b to forbid outdated crypto and avoid attacks trying to sneak outdated crypto in. About (c) am not so sure whether we really need that granularity, but (d) would be good to offer the trust of the specific anchor. Other opinions? Tobias On 10/26/2010 05:51 PM, Steingruebl, Andy wrote: >> -----Original Message----- >> From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On >> Behalf Of Paul Hoffman >> >> Is there an agreed-to definition for "strict security"? So far, there has been: >> >> >> e) A statement that the responder for a particular application always >> *requires* the use of TLS/DTLS (plus maybe some of the rest of above) > I vote for (e). This is what HSTS currently does, and I think really what we're discussing. STS generically is just about requiring TLS, I think other mechanisms should be used for conveying any other policy statements such as how keys are verified, etc. > > - Andy > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From asteingruebl@paypal-inc.com Wed Oct 27 10:41:00 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B0B3A69C8 for ; Wed, 27 Oct 2010 10:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.043 X-Spam-Level: X-Spam-Status: No, score=-5.043 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRtRPsYolrLI for ; Wed, 27 Oct 2010 10:40:59 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id DCE4F3A6888 for ; Wed, 27 Oct 2010 10:40:58 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=FzSFU058TNCwXt5MKLquUASxZjBqPZDCmcG/ZeysOFuwWfCROzU8lu8s LoxDFeCaKNlAmA+bCaCOv+wxzN6iL/WL2cDtr/wu7n33DDbjUjAopa04a QodairH+U+TMvyy; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1288201369; x=1319737369; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Tobias=20Gondrom=20,=20"websec@ietf.org"=0D=0A=09|Date: =20Wed,=2027=20Oct=202010=2011:42:46=20-0600|Subject:=20R E:=20[websec]=20Use=20of=20DNS/DNSSEC=20for=20strict=20se curity|Message-ID:=20<5EE049BA3C6538409BBE6F1760F328ABEB0 1DE130A@DEN-MEXMS-001.corp.ebay.com>|References:=20=0D=0A=09=0D=0A=09 <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001 .corp.ebay.com>=0D=0A=09=0D=0A=09<5EE049BA3C6538409B BE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com>=0D =0A=09<4CC46802.4070403@gondrom.org>=09=0D=0A=09<5EE049BA3C6538409BBE6F1760F 328ABEB01D3A85C@DEN-MEXMS-001.corp.ebay.com>=0D=0A=20<4CC 863E1.5030302@gondrom.org>|In-Reply-To:=20<4CC863E1.50303 02@gondrom.org>|Content-Transfer-Encoding:=20quoted-print able|MIME-Version:=201.0; bh=p5mPxBcGajxcbJq1vwidG+orlZip+r+XFih3862ZyQw=; b=bHSRrZxk6McmkK0JRPdxLL1TuOezzAOcc+zKF489nLiHdt4T9PczHPEd wVgw5Pg5Y4HNbKGN7HM9w5lm7nJV9l+pXERWSJDhynadem8mwPf39fj2m bWyuO88bT23bFmw; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.58,247,1286175600"; d="scan'208";a="72734572" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 27 Oct 2010 10:42:48 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Wed, 27 Oct 2010 11:42:48 -0600 From: "Steingruebl, Andy" To: Tobias Gondrom , "websec@ietf.org" Date: Wed, 27 Oct 2010 11:42:46 -0600 Thread-Topic: [websec] Use of DNS/DNSSEC for strict security Thread-Index: Act1/hHc//fVolXFQIqzyOtWuw+5bwAABgLA Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB01DE130A@DEN-MEXMS-001.corp.ebay.com> References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> <4CC46802.4070403@gondrom.org> <5EE049BA3C6538409BBE6F1760F328ABEB01D3A85C@DEN-MEXMS-001.corp.ebay.com> <4CC863E1.5030302@gondrom.org> In-Reply-To: <4CC863E1.5030302@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: R2Ouwqs+8kKIgi77jcwr6g== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 17:41:00 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Tobias Gondrom > Sent: Wednesday, October 27, 2010 10:40 AM > To: websec@ietf.org > Subject: Re: [websec] Use of DNS/DNSSEC for strict security >=20 > Definitely agree with (e). >=20 > And maybe to go into this further: > What of the options b,c,d, do we really need for that: > b) plus "with this particular crypto" > c) and maybe (b) plus "with this particular public key" > d) and maybe (b) plus "with a cert that chains to this particular trust a= nchor" >=20 > Would we need finer granularity? > I think we definitely should include b to forbid outdated crypto and avoi= d > attacks trying to sneak outdated crypto in. It seems to me that the decision to use TLS, and then other specifications = of how to verify endpoints and establish that secure channel, aren't direct= ly in scope. Doesn't TLS already handle proper negotiation of all crypto p= roperties? What attack are you trying to protect against that TLS itself i= n normal operating modes doesn't protect against? =20 - Andy From paul.hoffman@vpnc.org Wed Oct 27 12:02:29 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89453A6844 for ; Wed, 27 Oct 2010 12:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.44 X-Spam-Level: X-Spam-Status: No, score=-101.44 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd5zYh15KmOB for ; Wed, 27 Oct 2010 12:02:28 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C1F8E3A682A for ; Wed, 27 Oct 2010 12:02:28 -0700 (PDT) Received: from [10.20.30.151] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9RJ49pR069562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2010 12:04:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4CC863E1.5030302@gondrom.org> References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> <4CC46802.4070403@gondrom.org> <5EE049BA3C6538409BBE6F1760F328ABEB01D3A85C@DEN-MEXMS-001.corp.ebay.com> <4CC863E1.5030302@gondrom.org> Date: Wed, 27 Oct 2010 12:04:07 -0700 To: Tobias Gondrom , websec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 19:02:29 -0000 At 6:39 PM +0100 10/27/10, Tobias Gondrom wrote: > Definitely agree with (e). > >And maybe to go into this further: >What of the options b,c,d, do we really need for that: >b) plus "with this particular crypto" >c) and maybe (b) plus "with this particular public key" >d) and maybe (b) plus "with a cert that chains to this particular trust >anchor" > >Would we need finer granularity? >I think we definitely should include b to forbid outdated crypto and >avoid attacks trying to sneak outdated crypto in. >About (c) am not so sure whether we really need that granularity, but >(d) would be good to offer the trust of the specific anchor. > >Other opinions? If we can come to agreement on (b), we will have done better than any other IETF WG in the past. DKIM spent years on it and then gave up. (c) and (d) are the likely topics of the possibly-soon-to-be KIDNS WG. --Paul Hoffman, Director --VPN Consortium From marsh@extendedsubset.com Wed Oct 27 13:15:09 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640F73A6912 for ; Wed, 27 Oct 2010 13:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML3+47+G4K5e for ; Wed, 27 Oct 2010 13:14:58 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 27D673A686C for ; Wed, 27 Oct 2010 13:14:56 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PBCQQ-000Pz8-9T; Wed, 27 Oct 2010 20:16:46 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C63926333; Wed, 27 Oct 2010 20:16:43 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/48JdMqzxJwivaYRHIcTFRiOTLjc/zlAI= Message-ID: <4CC888AD.9050504@extendedsubset.com> Date: Wed, 27 Oct 2010 15:16:45 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.14) Gecko/20101006 Thunderbird/3.0.9 MIME-Version: 1.0 To: "Steingruebl, Andy" References: <5EE049BA3C6538409BBE6F1760F328ABEB0199FAEC@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB01A53DA1@DEN-MEXMS-001.corp.ebay.com> <4CC46802.4070403@gondrom.org> <5EE049BA3C6538409BBE6F1760F328ABEB01D3A85C@DEN-MEXMS-001.corp.ebay.com> <4CC863E1.5030302@gondrom.org> <5EE049BA3C6538409BBE6F1760F328ABEB01DE130A@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB01DE130A@DEN-MEXMS-001.corp.ebay.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 20:15:09 -0000 On 10/27/2010 12:42 PM, Steingruebl, Andy wrote: > > It seems to me that the decision to use TLS, and then other > specifications of how to verify endpoints and establish that secure > channel, aren't directly in scope. Doesn't TLS already handle > proper negotiation of all crypto properties? Yes, that's the theory but only as long as the server's cert is properly validated and its private key has not been compromised. Specifying requirements for, say, the symmetric cipher in DNSSEC records would be redundant, that's already configurable (with some complexity) in the client and server applications. There are two main things protecting the security of the handshake. The server's public key and the Finished.verify_data hash. The algorithm for Finished.verify_data is critical for securing the entire handshake. It is not independently negotiated in the handshake, instead it is specified by the particular TLS version in use. If a problem were to be found in the algorithm for TLS 1.0 (MD5+SHA-1), it would likely require a new protocol version number. Therefore, it seems like the minimum acceptable TLS protocol version number would be an important thing to secure in the DNSSEC records. The Finished.verify_data hash also depends critically on the connection's master secret, which is derived from the premaster secret, which is usually generated by the client and encrypted to the server's public key. So the server's public key is critical, and the whole job of PKI is to provide trust in it. x509 certificates are the standard public key container and are more or less required by the definition of the TLS protocol, but this does not preclude the possibility of publishing a public key directly in DNSSEC. Apparently there are even some circumstances where multiple certs will use the same public/private key pair. I think the relevant spec refs are: http://tools.ietf.org/html/rfc5280#section-4.2.1.1 http://tools.ietf.org/html/rfc5280#section-4.2.1.2 In the case (D) of using DNSSEC to specify a particular trust anchor, this would identify a particular cert, right? Wouldn't this cert clearly define the requirements for its own signatures? (hash algorithm, asymmetric key length, etc) > a) A statement that the responder for a particular application always > has TLS/DTLS available > e) A statement that the responder for a particular application always > *requires* the use of TLS/DTLS (plus maybe some of the rest of > above) The term 'available' sounds a little weak to me. Isn't the point of this to state its usage is 'required'? If DNSSEC says to use TLS, when would you ever want the client to fall back to non-TLS? > b) (a) plus "with this particular crypto" I think we can define "particular crypto" with just "minimum TLS version number". A big part of TLS is stating all those other particulars securely. The rest of the parameters should be covered by C and D. > c) (a) and maybe (b) plus "with this particular public key" It would be nice to be able to generate a simple self-signed (or unsigned) x509 cert and fix the public key securely in DNSSEC. > d) (a) and maybe (b) plus "with a cert that chains to this particular > trust anchor" This would be nice too. Perhaps you wouldn't want to require such a "trust anchor" to be a self-signed "root-like" cert, it could be useful for an organization to sign all their servers with a cert that is also an intermediate (WRT some private organizational root cert). This could also take the form of a bare public key. Also, how about: h) "Server will never request a client cert over the null connection state". Perhaps this could prevent attacks where an attacker forces the client to transmit his client cert in the clear and possibly even sign with it before the client can fully authenticate the server. - Marsh From Jeff.Hodges@KingsMountain.com Thu Oct 28 16:03:16 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A673A67E4 for ; Thu, 28 Oct 2010 16:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGGgdfM8qIW5 for ; Thu, 28 Oct 2010 16:03:16 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id D37703A659C for ; Thu, 28 Oct 2010 16:03:15 -0700 (PDT) Received: (qmail 18013 invoked by uid 0); 28 Oct 2010 23:05:09 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 28 Oct 2010 23:05:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=CYA3bT+szIzHn2dBnmNPFp3h/BMHQ2KJX8NGqtVALxuAp5zFv8+BEXaqMBKOI+uxbLGOdHYgnjAG/nguiD5nQgBX49qt4X54yESpiopxadiEhek8TiJMwceH2XuuumI7; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.163]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PBbWt-0004be-Ur; Thu, 28 Oct 2010 17:05:08 -0600 Message-ID: <4CCA01A5.4030608@KingsMountain.com> Date: Thu, 28 Oct 2010 16:05:09 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: websec@ietf.org, Sam Caldwell Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] WEBSEC and The Need for More Than DNSSEC X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 23:03:16 -0000 > Some minimal standard of > compliance, such as the use of digital signatures for the core > components of the browser or server software might represent WEBSEC > level one (1) compliance. > ... > The use of digital signatures in establishing the integrity of the > two sides of the client-server relationship This is entirely out-of-scope for the websec wg. You should perhaps go investigate the work occuring in the NEA (network endpoint assessment) working group . Our chartered scope for websec is HTTP applications security (modulo some scope restrictions), in a protocol-specific on-the-wire sense. =JeffH From mnot@mnot.net Thu Oct 28 16:19:02 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76863A680E for ; Thu, 28 Oct 2010 16:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.565 X-Spam-Level: X-Spam-Status: No, score=-105.565 tagged_above=-999 required=5 tests=[AWL=-2.966, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHRJTXbD+jLR for ; Thu, 28 Oct 2010 16:19:01 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id AFC593A6801 for ; Thu, 28 Oct 2010 16:19:01 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.39.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 45458509D9; Thu, 28 Oct 2010 19:20:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Fri, 29 Oct 2010 10:20:45 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <873710DE-04B2-4131-81FB-C86A5326F8D5@mnot.net> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: websec Subject: Re: [websec] Use of DNS/DNSSEC for strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 23:19:03 -0000 I've been considering it for a slightly different purpose; serving the = key for signing HTTP responses. After talking to a lot of people about this, it seems like it's much = simpler just to host the key (and by extension, other policy information = for the transport) on SSL.=20 It's a bit of a pity, but there you go... Cheers, On 13/10/2010, at 5:21 AM, Phillip Hallam-Baker wrote: > Has anyone (else) been considering the possible use of the DNS to = signal a strict security requirement? >=20 > While I like the idea of strict security, signaling by means of HTTP = headers creates a circular dependency. I can only guarantee strict = security after first achieving a secure connection. And anything that is = done for HTTP becomes a one-off that cannot be applied to SMTP and other = protocols. >=20 > I am not arguing against doing the HTTP header approach. Given the = attacks we are facing I do not want strict security to be dependent on = successful DNSSEC deployment. But I would like to see a HTTP header = approach that is consistent with eventual deployment of a DNSSEC based = approach. >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec -- Mark Nottingham http://www.mnot.net/