From igor@mir2.org Tue Oct 1 23:55:31 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25E521F9BC4 for ; Tue, 1 Oct 2013 23:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQv-9cBPB6U7 for ; Tue, 1 Oct 2013 23:55:21 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 6C35021E82C7 for ; Tue, 1 Oct 2013 23:54:41 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hj3so392258wib.13 for ; Tue, 01 Oct 2013 23:54:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=BfPoGzonUyj46WYJ+E9/gbrwxPk/5Lm1w+Yg7qh6EmU=; b=Mj962w0DMF5MknXMoPN78eAjAEpyqRuKvyQf+CB/dKR/eeKjypPe4pAz3C7kAHFUV3 geRNpUW+MrFV7SyVI/ddT7klTKBsFprcaTnei02DhaVeB/oYhyxAJIdBGrBufXXDTwu5 Xlgu8WO/J35i9A7T+snfXF2kp+GzfuW/vQjp2Dv4fnNtZdSE+3IrOTZQ8KuW8PA7FvlC lTq9r94wzzAHrH5xlHREGGdd59rfROong/SQGex9paC8Nj9rTlZQCJHrZEX0QdiJDRu1 CywJ3Qrr5niOtvFjsT6bhWU0OjVNNyd2J4blWnqWOikrpCHs4VxDdz58sALFPSG7itOo +Tyw== X-Gm-Message-State: ALoCoQmeFpkRwByRrXmtO7BpNbOdbjhUvHuC/kWAavVZ1wGRut8xA7aD/xAesC1GXtDHtNr/V+uO MIME-Version: 1.0 X-Received: by 10.180.73.40 with SMTP id i8mr22078481wiv.37.1380696880280; Tue, 01 Oct 2013 23:54:40 -0700 (PDT) Received: by 10.180.208.49 with HTTP; Tue, 1 Oct 2013 23:54:40 -0700 (PDT) Date: Wed, 2 Oct 2013 08:54:40 +0200 Message-ID: From: Igor Bukanov To: websec@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [websec] using passwords for certificate verification X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2013 07:18:02 -0000 The key pinning is a very good step in the direction of web security. However, it does raises the operational bar for web sites and is not helpful with new installations. Yet the observation here is that the reliable security is especially important for sites that authenticate the users. So why not to use the passwords that users have to verify the certificates? SRP [1] or J-PAKE [2] protocols allows *mutual* authentication of both client and server based on the shared secret. RFC5054 [3] even describes how to use SRP in TLS Authentication. The problem with these protocols is that they assumes a side channel for the distribution of the shared secret. In practice this translates into supporting both certificate-based HTTPS for the initial user registration and the new protocols for authenticated user sessions. This is rather costly operationally and perhaps the reason while the protocols remains outside mainstream browser/server implementations. Hence the suggestion to allow to use SRP/J-PAKE *only* for certificate verification. The idea is to provide hard to spoof yet customizable GUI in the browser where the user can assume that entering a password there is always safe. The browser then performs secure authentication using ordinary HTTP PUT requests. If it is OK, it uses the newly established encryption channel to verify the certificate for the subsequent connection. After that a normal HTTPS connection resumes. Compared with RFC5054 the key difference is that the server side in this case can be implemented as a part of web application without any changes in the server software/hardware to support the new protocol. This is possible as the authentication happens only once per session so computationally expensive J-PAKE/SRP exchange happens rarely and deployment of accelerators can be avoided even on busy sites. [1] http://srp.stanford.edu/ [2] http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling [3] http://tools.ietf.org/html/rfc5054 From trevp@trevp.net Wed Oct 2 11:58:32 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9143921F852A for ; Wed, 2 Oct 2013 11:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4raKsEwMWCqX for ; Wed, 2 Oct 2013 11:58:10 -0700 (PDT) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6337321F8E21 for ; Wed, 2 Oct 2013 11:52:19 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id w16so836511vbf.7 for ; Wed, 02 Oct 2013 11:52:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=pd+eQ4WwzqIRNgyFUQTgHxcU6yszV/5UnfCMd42TReA=; b=a5zKvu7XoR0V++bcybrXqMWjcrg1En7l82mBI0OsqW16PBdGxvTn2ahYvSivNlUzZU fihH/5q+0KU93YkX0OlbYxeBKcYuVyN6R1mOoBLaiqSClZAxo2KWafBSsmNAd5el9hXx p/nqYBk4S4Cmkd86lRqSw0Zt7UQzDUtPr9Eg7R77CnRr3Tmya2MnxnsYQlSRgNJA/faT oi0I/UDWc44OjyLD4f8Yk9Qsee1TAC0lpNUVeLFGzhC0Dhi99DWcytJCRwi1m1421fMl mPYAYX+bRMnKh7urjr9ByAuPYR1SjohUadVRcvi4F7ohfMJSaxY36cPQqb9QwgK8qgbA cscg== X-Gm-Message-State: ALoCoQk4RFXoBKMkINmcnKOeSYJi3r2+02JWAj0U9/TmIY9R8U020SnDJsONH00XPRCuEi9N2VbC MIME-Version: 1.0 X-Received: by 10.52.231.5 with SMTP id tc5mr193690vdc.36.1380739937696; Wed, 02 Oct 2013 11:52:17 -0700 (PDT) Received: by 10.220.213.133 with HTTP; Wed, 2 Oct 2013 11:52:17 -0700 (PDT) X-Originating-IP: [208.70.28.214] Date: Wed, 2 Oct 2013 11:52:17 -0700 Message-ID: From: Trevor Perrin To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] HPKP interaction between preloaded and dynamic pins X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2013 18:58:33 -0000 Hi websec, There was an item to discuss "interaction between pre-loaded and dynamic pins", and some earlier discussion: http://www.ietf.org/mail-archive/web/websec/current/msg01651.html http://www.ietf.org/mail-archive/web/websec/current/msg01833.html I think the current text in draft-08 section 2.7 is unclear about what preloaded and dynamic information the browser needs to store. Most of the draft is written as if the browser is only storing active, unexpired pins. But 2.7 seems to imply the browser stores timestamped "negative observations" such as max-age=0 observations, no-header observations, and expired pins, which will override less-recently-observed pins from different data sources (preloaded overriding dynamic, or vice versa). I could imagine simpler policies. One example: * The preload and dynamic lists contain only active, unexpired pins * The browser applies pins from both lists (i.e. if both a dynamic and preloaded pin exist for example.com, they are both applied) * The browser manufacturer can push an "override" which erases bad dynamic pins for particular hostnames. This wouldn't provide automatic overriding of (preloaded/dynamic) pins based on newer observations in a different source. But it *would* allow for explicit overriding of bad dynamic pins, which seems the most important type of overriding. It also seems much simpler. I suggest we allow such different and simpler policies. If people disagree, I'd like to hear a clearer statement of: * How exactly the current policy will work (i.e. what negative information needs to be stored and how it's used). * Why it's necessary to support automatic overriding of pins from different sources based on the newest observation? Trevor From y.oiwa@aist.go.jp Thu Oct 10 02:32:48 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D93921E80E6 for ; Thu, 10 Oct 2013 02:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.893 X-Spam-Level: X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90vRWOuPI3zv for ; Thu, 10 Oct 2013 02:32:43 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id ACD5321E8093 for ; Thu, 10 Oct 2013 02:32:41 -0700 (PDT) Received: from mail-vb0-f43.google.com ([209.85.212.43]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUlZ0OGlcTDdLjk9eDWvee59F/dg777Dt@postini.com; Thu, 10 Oct 2013 02:32:41 PDT Received: by mail-vb0-f43.google.com with SMTP id h11so1421801vbh.30 for ; Thu, 10 Oct 2013 02:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=hn6NfXY+ykOXXISMFjTcEEyGLGeTJoxs4NO/7bO05O4=; b=lV2X5ePiHNmwcT2byCygIbz8WSQ+UX8xPT7z06lLdnuwH7oy5uEbhRDIh1rkHtZ992 Ehw5Ss9lwuzEQ1aeg4eu/wD+2auDYwskjFYnuVScadUUq2FAPROEME/fFR21V1uMhrCs dk7zrTHtYK+kKL8xA2HOxWcwAl1eCwPs8+Ujc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=hn6NfXY+ykOXXISMFjTcEEyGLGeTJoxs4NO/7bO05O4=; b=WUkhPBp92T6dxV18tHJhEoiJaKq9wId5wTkAFKQz7msa8dOyqpF2HcTMiGl3AkNnyT PWGw04u4cDo+ki70QtE64aEsHU9besk/KyT3IyVj+q0uFu7GpcgcdW5WrhdEjZkUJZtt J9m+sRu+3fqN97oR9zZTbZp9DIkq+ImOMsN7i9NbSLa2MveUwX/yfkjKBTqxcIW99FGy TiieUKn8oRjCWbkTaAZdDfOlmuIiLpwzZfVynmvzC6gNHmRxwdBGvtMf4B2JlnPwNLrb 3h7Ab03D9MW6rGcBBpNCDVp5PfXDosL55pUadk4afeX8f8fQ/WDBC3QHR4wQamIAVaYu SHkg== X-Gm-Message-State: ALoCoQnDJBB9QY7Jnm8db58AN87vIAYOTYgqFtyQLeJ73koJCeNqeAXZf1SlegNfFOvRKuqFGnn7ZOVaOb7CJDOmX+jwujmU3my3uCwOBYgah+9MLBo5THmM1cgsnrYEGzu5kHbryvioo3P+TW/sxcR14EEf/7/7YQ== X-Received: by 10.221.23.72 with SMTP id qz8mr5071109vcb.66.1381397560459; Thu, 10 Oct 2013 02:32:40 -0700 (PDT) X-Received: by 10.221.23.72 with SMTP id qz8mr5071093vcb.66.1381397560360; Thu, 10 Oct 2013 02:32:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.144.144 with HTTP; Thu, 10 Oct 2013 02:32:19 -0700 (PDT) From: Yutaka OIWA Date: Thu, 10 Oct 2013 18:32:19 +0900 Message-ID: To: websec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] Leading zeros in port component of Web Origin X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 09:32:48 -0000 Dear all, I have some uncertainty about the definitions for the treatment of leading zeros in port component of the URI, regarding Web Origin Concept RFC (RFC 6454). RFC 3986 (URI) defines the port subcomponent as *DIGIT, permitting any leading zeros. (Trivia: interestingly, it rejects leading zeros in components of IPv4 addresses.) Section 4 of RFC 6454 says the uri-port element of Web Origin triple is "the port component of the URI". Section 5 says that for two origins to be the same, the ports must be identical. Section 6 (serialization) says that "a U+003A COLON code point (":") and the given port, in base ten" will be appended in the serialized string of origins. So question is about the "type" of the port: is it a string or an integer? I could not find a direct declaration for this. (searched for leading, zero, integer etc.) More specifically, 1) Are URIs http://www.example.com:8080/ and http://www.example.com:08080/ same-origin? 2) Will the string "http://www.example.com:08080/" be a valid output of the algorithm in Sections 6.1 and 6.2 for some input URIs? I want to have both "intended" answers and supporting definition rules, if any. [My guess for intended answers are 1) yes, and 2) no.] Background: I'm writing a draft in HTTPAUTH WG, and considering definition of the canonical string for scheme-host-port triple to be chabged in harmony with RFC 6454. I need a function which translates "http://www.example.com:08080/" into "http://www.example.com:8080". # The change "in harmony with RFC 6454" means to strip ":80" for http and ":443" for https. -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From derhoermi@gmx.net Thu Oct 10 03:01:05 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5814021E8131 for ; Thu, 10 Oct 2013 03:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.823 X-Spam-Level: X-Spam-Status: No, score=-0.823 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuudfUZ9NnkD for ; Thu, 10 Oct 2013 03:01:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id CBB5A21E812E for ; Thu, 10 Oct 2013 03:00:54 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.13.136]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0LlXnX-1W2Akt2uqV-00bHz5 for ; Thu, 10 Oct 2013 12:00:53 +0200 From: Bjoern Hoehrmann To: Yutaka OIWA Date: Thu, 10 Oct 2013 12:00:54 +0200 Message-ID: <37uc5990on2qlerhcdvpk96e4kgi7enbdr@hive.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:RODdcX4xHJdl72xnR6484BA5A507RWBIH/qBo1SRalsCaIbGhjF XzT1C5IXkHEpi19ipUCZNxI7sfycabrpvnu4L++bmaOl/BJ9a8fV9SKUe9GkQCCehJRfDS8 k3wZ6PD4Ngl9kA+shj2AFpFWKFd8fij2XjDQ0JNElABBWk80sUxyRczC8GibQQWWSvaF8gH uBaxTUdkXKq80w530uZFw== Cc: websec@ietf.org Subject: Re: [websec] Leading zeros in port component of Web Origin X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 10:01:05 -0000 * Yutaka OIWA wrote: >2) Will the string "http://www.example.com:08080/" be a valid output of the > algorithm in Sections 6.1 and 6.2 for some input URIs? It seems clear to me that "Append a U+003A COLON code point (":") and the given port, in base ten, to result." does not suggest to prepend an implementation-defined number of leading zeros. So, no. >Background: >I'm writing a draft in HTTPAUTH WG, and considering definition of the canonical >string for scheme-host-port triple to be chabged in harmony with RFC 6454. >I need a function which translates "http://www.example.com:08080/" >into "http://www.example.com:8080". Per http://www.ietf.org/mail-archive/web/websec/current/msg01512.html I would regard RFC 6454 as unsuitable for normative reference, but if you limit yourself to 'http' and 'https' things might not be that bad. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From wwwrun@rfc-editor.org Thu Oct 10 14:04:10 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1617621E8092; Thu, 10 Oct 2013 14:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v487PbrJa+5U; Thu, 10 Oct 2013 14:04:09 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4176711E80E2; Thu, 10 Oct 2013 14:04:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 77447B1E011; Thu, 10 Oct 2013 13:56:20 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131010205620.77447B1E011@rfc-editor.org> Date: Thu, 10 Oct 2013 13:56:20 -0700 (PDT) Cc: drafts-update-ref@iana.org, websec@ietf.org, rfc-editor@rfc-editor.org Subject: [websec] RFC 7034 on HTTP Header Field X-Frame-Options X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 21:04:10 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7034 Title: HTTP Header Field X-Frame-Options Author: D. Ross, T. Gondrom Status: Informational Stream: IETF Date: October 2013 Mailbox: dross@microsoft.com, tobias.gondrom@gondrom.org Pages: 14 Characters: 27263 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-websec-x-frame-options-12.txt URL: http://www.rfc-editor.org/rfc/rfc7034.txt To improve the protection of web applications against clickjacking, this document describes the X-Frame-Options HTTP header field, which declares a policy, communicated from the server to the client browser, regarding whether the browser may display the transmitted content in frames that are part of other web pages. This document is a product of the Web Security Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC