From nobody Thu Jan 1 21:21:45 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7E21A8724 for ; Thu, 1 Jan 2015 21:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBz154U6Q6NB for ; Thu, 1 Jan 2015 21:21:36 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3E11A871D for ; Thu, 1 Jan 2015 21:21:36 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so16173352iga.14 for ; Thu, 01 Jan 2015 21:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=OtyyZ+t2C4pffpA1k3/CwRBlp8wrlRB+4fks8ahUZBk=; b=MXniGSJfHCnIO11hAPnOxlG+KxCtU812MC0Dx05yh4Dnpk4dlFlORJZvdVqxDsqftz nzky56O0ge17oFjuzzlb5OLqmLnQM9cXs+Wa/B7i7Wfy2gLkEP/VM8Wl7Dugt4ZN8Umm ZggEXkgChzvqVTkiAOINyeOGD3uUdSGaLWzdDAJ0kcEsyqb5ghluFqJNKJtTLX+4rUgV zYBbbrp/J31hRkfpp/LcvpiwmlU/VGQL4RwKLSGZf37dOVqI2Q9jPDC4Mj+VNbmqoPCb ldp7Q/xzvhs/GmtuKNdQGNCD0e+ak8fui3KelCSOkM+Ambg0xhKyqNbHaWc4dZj4tgGY BOQw== MIME-Version: 1.0 X-Received: by 10.42.61.130 with SMTP id u2mr54857358ich.61.1420176093804; Thu, 01 Jan 2015 21:21:33 -0800 (PST) Received: by 10.107.134.170 with HTTP; Thu, 1 Jan 2015 21:21:33 -0800 (PST) Date: Fri, 2 Jan 2015 00:21:33 -0500 Message-ID: From: Jeffrey Walton To: IETF WebSec WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/WxnLpkFlAdT58L51fmWUtikUSDY Subject: [websec] Comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 05:21:42 -0000 I'd like to share some comments on https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21. Pubic key pinning is an effective security control and I'm glad to see the IETF moving forward with it. And I'm especially thankful to Palmer and Sleevi for taking the time to put it together and shepherd it through the process. ***** (1) ***** The title "Public Key Pinning Extension for HTTP" seems overly broad and misses the mark a bit. The Abstract states its for User Agents, but the title does not narrow focus. There are different problem domains where public key pinning can be utilized. Painting with a broad brush, I categorize them as "the general problem" where no 'a priori' knowledge exists, and various specific "instance problems", where 'a priori' does exits and can be leveraged. An example of the general problem is browsers, and an example of the instance problem is any custom software deployed by an organization. Suggestion: change the title to "Trust on First Use Pinsets and Overrides for HTTP" or "Pinsets and Overrides for HTTP in User Agents". There are a few reasons for the suggestion. First, the abstract effectively states its. Second, the proposed standard is a TOFU scheme used for the general problem. Third, the Introduction recognizes the two classes of problems when it discusses the pre-shared keys. Fourth, the embodiment described in the proposed standard is not a preferred solution for the many instances of the specific problems. Fifth, the overrides need to be highlighted since they are an integral and high impact part of the proposed standard. Above, when I said the "=E2=80=A6 is not a preferred solution for the many instances of the specific problems", I'm referring to pinning as described in Gutmann's Engineering Security [1], OWASP [2] or by Moxie Marlinspike [3] and others. ***** (2) ***** I think the document could benefit from a more comprehensive discussion of the goals. The abstract states "=E2=80=A6 [some] man-in-the-middle attacks due to compromised Certification Authorities". That wet my appetite and I'd like to read more. I think it would be more helpful to state what is trying to be achieved in terms of both operational goals and security goals. For example, I don't see any operational goals, like business continuity behind a proxy. And "some man-in-the-middle attacks due to compromised Certification Authorities" seems to be a somewhat underspecifed security goal. ***** (3) ***** I think the document could benefit from an enumeration of the threats the security control is intended to defend against (or a normative reference to the "Pinning Threat Model" stated in [4]). Taken in its totality (pinning + overrides), its not clear to me what the proposed standard defends against. The Abstract mentions it could defend against "[some] man-in-the-middle attacks due to compromised Certification Authorities." Because we don't know what the control is intended to protect against, we can't measure its effectiveness. Additionally, when public key pinning is used in a more traditional sense (like Gutmann's Engineering Security [1], OWASP [2] or Moxie Marlinspike [3]), then pinning defends against some things the proposed standard appears to allow. The lack of clarity means there are some significant operational differences between customary expectations and the proposed standard. The misunderstood differences will clearly lead to confusion, unexpected results and a false sense of security. ***** (4) ***** >From the 1. Introduction: Key pinning is a trust-on-first-use (TOFU) mechanism. That may be true for the general problem, but its completely untrue when 'a priori' knowledge exists for a specific instance of the problem. Gutmann's Engineering Security [1], OWASP [2] or Moxie Marlinspike [3] have been providing the counter examples for years. ***** (5) ***** >From the 1. Introduction: A Pin is a relationship between a hostname and a cryptographic identity (in this document, 1 or more of the public keys in a chain of X.509 certificates). Pin Validation is the process a UA performs to ensure that a host is in fact authenticated with its previously- established Pin. I was a little confused the first time I read this because I parsed it incorrectly. Here's how I parsed the first time: only the server or end-entity certificate has a hostname, so only that certificate can contribute a public key to a pinset. The other certificates (intermediate and ca) can't contribute to a pinset because they don't have a hostname. Perhaps something like "A Pin is a mapping of a hostname to a set (one or more?) of public keys that can be used to cryptographically certify the site's identity... The public keys can be any of (1) the host's public key (2) any intermediate or ca public key...". Also, 2.4 Semantics of Pins, offers a slightly different definition (it includes an algorithm, which appears to be missing from this definition). So maybe the definition above should be expanded to include "contextual information" that can later be ratified. ***** (6) ***** The document might also consider introducing the term "Pinset". I think Kenny Root or the Android Security Team introduced the term at Google I/O a couple of years ago. They were probably using the term internally before then. ***** (7) ***** >From the 1. Introduction: ... UAs apply X.509 certificate chain validation in accord with [RFC5280].) Typo: accord -> accordance. ***** (8) ***** >From 2.1. Response Header Field Syntax: The "Public-Key-Pins" and "Public-Key-Pins-Report-Only" header... The naming of the fields appear to indicate they are mutually exclusive (Report Only seems to indicate anything other than reporting is prohibited). But 2.3.2 allows them both, so it might be a good idea to make a quick statement that both are allowed in 2.1, and then detail it in 2.3.2. Or drop the "Only" from "Public-Key-Pins-Report-Only". ***** (10) ***** >From 2.2.2. HTTP Request Type: Pinned Hosts SHOULD NOT include the PKP header field in HTTP responses conveyed over non-secure transport. UAs MUST ignore any PKP header received in an HTTP response conveyed over non-secure transport. There could be some confusion here. What about anonymous protocols that provide confidentiality only? Is it allowed or not allowed? ***** (11) ***** >From 2.3.3. Noting a Pinned Host - Storage Model: Known Pinned Hosts are identified only by domain names, and never IP addresses. This is kind of interesting. This document specifies behavior for browsers and other UAs, but browsers follow the CA/B. The CA/B does not prohibit a CA from issuing certificates for an IP address except in the case of an an IANA reserved address (see the Baseline Requirements, section 11.1.2 Authorization for an IP Address). Additionally, RFC 5280 allows IP addresses in section 4.2.1.6 Subject Alternative Name. So its not clear to me why a more restrictive policy is called out. I also understand an IP address for a host can change. But in the case a public IP address has been previously bound to a public key by way of an authority, it again seems more restrictive. *If* the proposed standard is trying to guard against some threats posed by the Domain Name System, IANA reserved addresses, RFC 1918 addresses and similar, then that should be listed under Goals and/or Threats. ***** (12) ***** >From 2.6. Validating Pinned Connections: =E2=80=A6 It is acceptable to allow Pin Validation to be disabled for some Hosts according to local policy. For example, a UA may disable Pin Validation for Pinned Hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform). OK, this is the reason for the proposed title change in (1). This is also the reason for the list of goals and threats in (2) and (3). Its just not clear to me (at the moment) how a known good pinset can be broken to facilitate proxying/interception in a proposed standard for a security control that's supposed to stop that kind of funny business. Also, as far as document flow is concerned, I think the sentences quoted above should be removed from the second paragraph and placed as the last stand alone paragraph in that section. I think it should be moved because it breaks the flow of the discussion of "what to do" with a discussion of the related topic of "not doing what you should be doing". ***** (13) ***** >From 2.6. Validating Pinned Connections: UAs send validation failure reports only when Pin Validation is actually in effect. Pin Validation might not be in effect e.g. because the user has elected to disable it, or because a presented certificate chain chains up to a user-defined trust anchor. In such cases, UAs SHOULD NOT send reports. If I am reading/parsing this correctly: adversaries want to be able to surreptitiously MitM the channel, and they don't want a spotlight shone on them while doing it. As worded, the last two sentences are a tremendous blow to transparency. The users and the site owner who are being proxy'd/intercepted have a right to know what's occurring on his/her [supposed] secure channel. In addition, the community has a right to know how widespread potential problems are. Users and sites have a right to know because non-trivial data is sometimes traversing the channel, like site passwords and confidential company information. Some organizations and verticals have auditing and compliance requirements, so reporting a breach/loss of that data is required. The community has a right to know so the breadth of the problem can be ascertained, and plans of action can be formulated and action taken. Some proxying/interception performed by third parties or externalities could be illegal in some jurisdictions, so the user or site will need the evidence if they desire to have it addressed more formally. In the US, I believe the law is the Computer Fraud and Abuse Act. The perceived risk of a lawsuit could help stop some of the unauthorized proxying/interception because some organizations will weigh the risk with the reward. Considering this proposal is a security control to stop unauthorized proxying/interception, that's a win-win. IETF leadership: Carl Sagan once asked, who speaks for the Earth. Who here speaks for the users and sites? Does it *really* sound like a good idea to suppress evidence of validation failures and unauthorized overrides for a security control that's specifically designed to contend with the threats? ***** (14) ***** 2.7. Interactions With Preloaded Pin Lists: The effective policy for a Known Pinned Host that has both built-in Pins and Pins from previously observed PKP header response fields is implementation-defined. In the name of transparency, the site should receive at least one report detailing the issue. The site should be able to specify the frequency of the reports so it can assess the breadth of the reported issue. ***** (15) ***** 2.8. Pinning Self-Signed End Entities Kudos for this section. I think it fits nicely with Viktor Dukhovni's Opportunistic Security. ***** (16) ***** Overrides are mentioned once in section 2.7. They effectively allow an adversary to break known good pinsets and subvert the secure channel. Section 4. Security Considerations does not discuss the impact of an override. The impact of overrides should be discussed so that sites and software architects can ensure the security control meets expectations and properly assess risk. In addition, for browsers (which the proposed standard appears to target), discarding the user's wishes is a violation in Priority of Constituencies [5]; and violates the user and site's expectation of Secure By Design [6]. So its not clear to me how useful the proposal will be for browsers and other UAs that follow the W3C's Design Principles. But I think things can be improved so that the proposed standard does satisfy them. In the above, I claim the user typing HTTPS (or a site redirecting to HTTPS) is an indicator that a secure connection to a site is desired, and not a connection to folks who would like to proxy the connection for them. By not delivering what they asked, the proposal falls short of both Priority of Constituencies and Secure By Design. ***** (17) ***** There is no consideration for a site to set policy on overrides. That is, a site should be able to determine whether it wants to allow proxying/interception, and not an externality. Sites offering HTTPS, and other security controls like HSTS or CSP, are strong indicators that sites care about these things. Sites should be allowed to set policy on overrides, just like they can set HSTS or CSP policy. IETF leadership: Who here speaks for the users and sites? *************** Sorry for the long post, and thanks for taking the time for consideration. Jeffrey Walton *************** [1] https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf [2] https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning [3] http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your= -app-ha/ [4] https://www.ietf.org/mail-archive/web/websec/current/msg02261.html [5] http://www.w3.org/TR/html-design-principles/#priority-of-constituencies [6] http://www.w3.org/TR/html-design-principles/#secure-by-design From nobody Fri Jan 2 04:26:45 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822231A1A51 for ; Fri, 2 Jan 2015 04:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLuNSf23mU-A for ; Fri, 2 Jan 2015 04:26:40 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CE31A1A22 for ; Fri, 2 Jan 2015 04:26:39 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id w61so4410229wes.7 for ; Fri, 02 Jan 2015 04:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HsS7OmpJlg5gWYPnqp+60cFaeYq49uGg71htofqQtlg=; b=v5d2v3KsL1bmxu2sfoR4mqbOcgCXkj5Jugskrp//+A7Db6qHcxqI4oQJwqfzEBHCyD TlkH8pfuoMjRF99FFXQEKChGCIDgxOLrb72vPq/l7gWpGvJXNL9Tsozsc4poPwViUJ5v cIEywTNZ5P478qbQE9erwzzJ35pKc5brrWZoKDe4Uas1nrho+SrxTEJgrJqPcSm39DuR fMqPMtxo2u+OBFsJWKDTEXUkGUqkvZOhMSzSzaiKncxxZQdI+KqxgLlUsmq9ptAODuB9 pnk/GSoDvHXTRRpIjhzLXNfn2HPzIWxkHia5cVwSlfSDmwiSrgzC/dDLMTACvvR6ngpq l/EQ== X-Received: by 10.180.98.42 with SMTP id ef10mr62185923wib.46.1420201598665; Fri, 02 Jan 2015 04:26:38 -0800 (PST) Received: from [192.168.1.102] (IGLD-84-228-227-214.inter.net.il. [84.228.227.214]) by mx.google.com with ESMTPSA id qd2sm53960109wic.19.2015.01.02.04.26.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Jan 2015 04:26:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: Date: Fri, 2 Jan 2015 14:26:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E436DD1-8EFB-4270-81CA-717B0FDD9A4F@gmail.com> References: To: noloader@gmail.com X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/s6dkqfdxbZsDn_K7At_juWTeKFQ Cc: IETF WebSec WG Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 02 Jan 2015 12:26:43 -0000 Hi, Jeffrey Thanks for the review. However, if you look at the datatracker link ([1]), you=E2=80=99ll see = that this draft has been approved by the IESG 2.5 months ago. Its = publication as RFC is only waiting for a referenced document to be = published. I=E2=80=99m afraid it=E2=80=99s too late now. Yoav [1] = https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/history/ > On Jan 2, 2015, at 7:21 AM, Jeffrey Walton wrote: >=20 > I'd like to share some comments on > https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21. >=20 > Pubic key pinning is an effective security control and I'm glad to see > the IETF moving forward with it. And I'm especially thankful to Palmer > and Sleevi for taking the time to put it together and shepherd it > through the process. >=20 > ***** (1) ***** >=20 > The title "Public Key Pinning Extension for HTTP" seems overly broad > and misses the mark a bit. The Abstract states its for User Agents, > but the title does not narrow focus. >=20 > There are different problem domains where public key pinning can be > utilized. Painting with a broad brush, I categorize them as "the > general problem" where no 'a priori' knowledge exists, and various > specific "instance problems", where 'a priori' does exits and can be > leveraged. An example of the general problem is browsers, and an > example of the instance problem is any custom software deployed by an > organization. >=20 > Suggestion: change the title to "Trust on First Use Pinsets and > Overrides for HTTP" or "Pinsets and Overrides for HTTP in User > Agents". >=20 > There are a few reasons for the suggestion. First, the abstract > effectively states its. Second, the proposed standard is a TOFU scheme > used for the general problem. Third, the Introduction recognizes the > two classes of problems when it discusses the pre-shared keys. Fourth, > the embodiment described in the proposed standard is not a preferred > solution for the many instances of the specific problems. Fifth, the > overrides need to be highlighted since they are an integral and high > impact part of the proposed standard. >=20 > Above, when I said the "=E2=80=A6 is not a preferred solution for the = many > instances of the specific problems", I'm referring to pinning as > described in Gutmann's Engineering Security [1], OWASP [2] or by Moxie > Marlinspike [3] and others. >=20 > ***** (2) ***** >=20 > I think the document could benefit from a more comprehensive > discussion of the goals. The abstract states "=E2=80=A6 [some] > man-in-the-middle attacks due to compromised Certification > Authorities". That wet my appetite and I'd like to read more. >=20 > I think it would be more helpful to state what is trying to be > achieved in terms of both operational goals and security goals. For > example, I don't see any operational goals, like business continuity > behind a proxy. And "some man-in-the-middle attacks due to compromised > Certification Authorities" seems to be a somewhat underspecifed > security goal. >=20 > ***** (3) ***** >=20 > I think the document could benefit from an enumeration of the threats > the security control is intended to defend against (or a normative > reference to the "Pinning Threat Model" stated in [4]). >=20 > Taken in its totality (pinning + overrides), its not clear to me what > the proposed standard defends against. >=20 > The Abstract mentions it could defend against "[some] > man-in-the-middle attacks due to compromised Certification > Authorities." Because we don't know what the control is intended to > protect against, we can't measure its effectiveness. >=20 > Additionally, when public key pinning is used in a more traditional > sense (like Gutmann's Engineering Security [1], OWASP [2] or Moxie > Marlinspike [3]), then pinning defends against some things the > proposed standard appears to allow. >=20 > The lack of clarity means there are some significant operational > differences between customary expectations and the proposed standard. > The misunderstood differences will clearly lead to confusion, > unexpected results and a false sense of security. >=20 > ***** (4) ***** >=20 >> =46rom the 1. Introduction: >=20 > Key pinning is a trust-on-first-use (TOFU) mechanism. >=20 > That may be true for the general problem, but its completely untrue > when 'a priori' knowledge exists for a specific instance of the > problem. Gutmann's Engineering Security [1], OWASP [2] or Moxie > Marlinspike [3] have been providing the counter examples for years. >=20 > ***** (5) ***** >=20 >> =46rom the 1. Introduction: >=20 > A Pin is a relationship between a hostname and a cryptographic > identity (in this document, 1 or more of the public keys in a chain > of X.509 certificates). Pin Validation is the process a UA performs > to ensure that a host is in fact authenticated with its previously- > established Pin. >=20 > I was a little confused the first time I read this because I parsed it > incorrectly. Here's how I parsed the first time: only the server or > end-entity certificate has a hostname, so only that certificate can > contribute a public key to a pinset. The other certificates > (intermediate and ca) can't contribute to a pinset because they don't > have a hostname. >=20 > Perhaps something like "A Pin is a mapping of a hostname to a set (one > or more?) of public keys that can be used to cryptographically certify > the site's identity... The public keys can be any of (1) the host's > public key (2) any intermediate or ca public key...". >=20 > Also, 2.4 Semantics of Pins, offers a slightly different definition > (it includes an algorithm, which appears to be missing from this > definition). So maybe the definition above should be expanded to > include "contextual information" that can later be ratified. >=20 > ***** (6) ***** >=20 > The document might also consider introducing the term "Pinset". I > think Kenny Root or the Android Security Team introduced the term at > Google I/O a couple of years ago. They were probably using the term > internally before then. >=20 > ***** (7) ***** >=20 >> =46rom the 1. Introduction: >=20 > ... UAs apply X.509 certificate chain validation in accord > with [RFC5280].) >=20 > Typo: accord -> accordance. >=20 > ***** (8) ***** >=20 >> =46rom 2.1. Response Header Field Syntax: >=20 > The "Public-Key-Pins" and "Public-Key-Pins-Report-Only" header... >=20 > The naming of the fields appear to indicate they are mutually > exclusive (Report Only seems to indicate anything other than reporting > is prohibited). But 2.3.2 allows them both, so it might be a good idea > to make a quick statement that both are allowed in 2.1, and then > detail it in 2.3.2. Or drop the "Only" from > "Public-Key-Pins-Report-Only". >=20 > ***** (10) ***** >=20 >> =46rom 2.2.2. HTTP Request Type: >=20 > Pinned Hosts SHOULD NOT include the PKP header field in HTTP > responses conveyed over non-secure transport. UAs MUST ignore any > PKP header received in an HTTP response conveyed over non-secure > transport. >=20 > There could be some confusion here. What about anonymous protocols > that provide confidentiality only? Is it allowed or not allowed? >=20 > ***** (11) ***** >=20 >> =46rom 2.3.3. Noting a Pinned Host - Storage Model: >=20 > Known Pinned Hosts are identified only by domain names, and never IP > addresses. >=20 > This is kind of interesting. This document specifies behavior for > browsers and other UAs, but browsers follow the CA/B. The CA/B does > not prohibit a CA from issuing certificates for an IP address except > in the case of an an IANA reserved address (see the Baseline > Requirements, section 11.1.2 Authorization for an IP Address). > Additionally, RFC 5280 allows IP addresses in section 4.2.1.6 Subject > Alternative Name. So its not clear to me why a more restrictive policy > is called out. >=20 > I also understand an IP address for a host can change. But in the case > a public IP address has been previously bound to a public key by way > of an authority, it again seems more restrictive. >=20 > *If* the proposed standard is trying to guard against some threats > posed by the Domain Name System, IANA reserved addresses, RFC 1918 > addresses and similar, then that should be listed under Goals and/or > Threats. >=20 > ***** (12) ***** >=20 >> =46rom 2.6. Validating Pinned Connections: >=20 > =E2=80=A6 It is acceptable to allow Pin > Validation to be disabled for some Hosts according to local policy. > For example, a UA may disable Pin Validation for Pinned Hosts whose > validated certificate chain terminates at a user-defined trust > anchor, rather than a trust anchor built-in to the UA (or underlying > platform). >=20 > OK, this is the reason for the proposed title change in (1). This is > also the reason for the list of goals and threats in (2) and (3). Its > just not clear to me (at the moment) how a known good pinset can be > broken to facilitate proxying/interception in a proposed standard for > a security control that's supposed to stop that kind of funny > business. >=20 > Also, as far as document flow is concerned, I think the sentences > quoted above should be removed from the second paragraph and placed as > the last stand alone paragraph in that section. I think it should be > moved because it breaks the flow of the discussion of "what to do" > with a discussion of the related topic of "not doing what you should > be doing". >=20 > ***** (13) ***** >=20 >> =46rom 2.6. Validating Pinned Connections: >=20 > UAs send validation failure reports only when Pin Validation is > actually in effect. Pin Validation might not be in effect e.g. > because the user has elected to disable it, or because a presented > certificate chain chains up to a user-defined trust anchor. In such > cases, UAs SHOULD NOT send reports. >=20 > If I am reading/parsing this correctly: adversaries want to be able to > surreptitiously MitM the channel, and they don't want a spotlight > shone on them while doing it. >=20 > As worded, the last two sentences are a tremendous blow to > transparency. The users and the site owner who are being > proxy'd/intercepted have a right to know what's occurring on his/her > [supposed] secure channel. In addition, the community has a right to > know how widespread potential problems are. >=20 > Users and sites have a right to know because non-trivial data is > sometimes traversing the channel, like site passwords and confidential > company information. Some organizations and verticals have auditing > and compliance requirements, so reporting a breach/loss of that data > is required. The community has a right to know so the breadth of the > problem can be ascertained, and plans of action can be formulated and > action taken. >=20 > Some proxying/interception performed by third parties or externalities > could be illegal in some jurisdictions, so the user or site will need > the evidence if they desire to have it addressed more formally. In the > US, I believe the law is the Computer Fraud and Abuse Act. >=20 > The perceived risk of a lawsuit could help stop some of the > unauthorized proxying/interception because some organizations will > weigh the risk with the reward. Considering this proposal is a > security control to stop unauthorized proxying/interception, that's a > win-win. >=20 > IETF leadership: Carl Sagan once asked, who speaks for the Earth. Who > here speaks for the users and sites? Does it *really* sound like a > good idea to suppress evidence of validation failures and unauthorized > overrides for a security control that's specifically designed to > contend with the threats? >=20 > ***** (14) ***** >=20 > 2.7. Interactions With Preloaded Pin Lists: >=20 > The effective policy for a Known Pinned Host that has both built-in > Pins and Pins from previously observed PKP header response fields is > implementation-defined. >=20 > In the name of transparency, the site should receive at least one > report detailing the issue. The site should be able to specify the > frequency of the reports so it can assess the breadth of the reported > issue. >=20 > ***** (15) ***** >=20 > 2.8. Pinning Self-Signed End Entities >=20 > Kudos for this section. I think it fits nicely with Viktor Dukhovni's > Opportunistic Security. >=20 > ***** (16) ***** >=20 > Overrides are mentioned once in section 2.7. They effectively allow an > adversary to break known good pinsets and subvert the secure channel. > Section 4. Security Considerations does not discuss the impact of an > override. >=20 > The impact of overrides should be discussed so that sites and software > architects can ensure the security control meets expectations and > properly assess risk. >=20 > In addition, for browsers (which the proposed standard appears to > target), discarding the user's wishes is a violation in Priority of > Constituencies [5]; and violates the user and site's expectation of > Secure By Design [6]. So its not clear to me how useful the proposal > will be for browsers and other UAs that follow the W3C's Design > Principles. But I think things can be improved so that the proposed > standard does satisfy them. >=20 > In the above, I claim the user typing HTTPS (or a site redirecting to > HTTPS) is an indicator that a secure connection to a site is desired, > and not a connection to folks who would like to proxy the connection > for them. By not delivering what they asked, the proposal falls short > of both Priority of Constituencies and Secure By Design. >=20 > ***** (17) ***** >=20 > There is no consideration for a site to set policy on overrides. That > is, a site should be able to determine whether it wants to allow > proxying/interception, and not an externality. Sites offering HTTPS, > and other security controls like HSTS or CSP, are strong indicators > that sites care about these things. >=20 > Sites should be allowed to set policy on overrides, just like they can > set HSTS or CSP policy. >=20 > IETF leadership: Who here speaks for the users and sites? >=20 > *************** >=20 > Sorry for the long post, and thanks for taking the time for = consideration. >=20 > Jeffrey Walton >=20 > *************** >=20 > [1] https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf > [2] https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning > [3] = http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-ap= p-ha/ > [4] https://www.ietf.org/mail-archive/web/websec/current/msg02261.html > [5] = http://www.w3.org/TR/html-design-principles/#priority-of-constituencies > [6] http://www.w3.org/TR/html-design-principles/#secure-by-design >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From nobody Fri Jan 2 13:18:38 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B956C1A00E5 for ; Fri, 2 Jan 2015 13:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwLkU56YfRdw for ; Fri, 2 Jan 2015 13:18:34 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9481A00BB for ; Fri, 2 Jan 2015 13:18:34 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 1B648678058; Fri, 2 Jan 2015 13:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=BA/JktJAzKOJy7N9uAqkbgu6wy8=; b=ReJODSu7qqsUEA8dj 1cMNbWMLRA+3Dcinl0+LVenVGwfzg1+NNjcy73QkBSnxEK6iJeM+92LmoSXsGv3c u2XretM8RiBTTwFkZV9tFFv1ZSTOmVfg89viC0eVTYv2WeBX1+QjSPqKuzyb//tG PTr1YP/201NjJlPmsOYmVCbgx4= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id DDC84678057; Fri, 2 Jan 2015 13:18:33 -0800 (PST) Received: from 216.239.45.71 (proxying for 216.239.45.71) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 2 Jan 2015 13:18:34 -0800 Message-ID: In-Reply-To: References: Date: Fri, 2 Jan 2015 13:18:34 -0800 From: "Ryan Sleevi" To: noloader@gmail.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/AH1k1q2gYBQfEtJdTBOxkGeg3uE Cc: IETF WebSec WG Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 21:18:37 -0000 On Thu, January 1, 2015 9:21 pm, Jeffrey Walton wrote: > I'd like to share some comments on > https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21. Hi Jeffrey, Though I see Yoav has already mentioned that these comments are well beyond the IETF LC phase, thus will not result in any changes to the document, I do want to take the time to reply to your comments and explai= n on a more substantive grounds why no changes are warranted, even if there were still opportunity for change. My fear is that this reply may encourage further discussion, and while I'= m certainly happy to provide further clarifications, I do think it is important to keep in mind Yoav's remarks on changes. > ***** (1) ***** > > The title "Public Key Pinning Extension for HTTP" seems overly broad > and misses the mark a bit. The Abstract states its for User Agents, > but the title does not narrow focus. This isn't so much a technical argument as quibbling over naming. I'm not sure why you feel that "User Agent" is somehow a narrowing of focus - anything that processes an HTTP header for a user is surely a User Agent, and anything not processing HTTP headers surely shouldn't care about HTTP headers. > > ***** (2) ***** > > I think the document could benefit from a more comprehensive > discussion of the goals. The abstract states "=E2=80=A6 [some] > man-in-the-middle attacks due to compromised Certification > Authorities". That wet my appetite and I'd like to read more. Useful feedback, and perhaps more could have been detailed that would hav= e avoided some apparent confusion over the goals, but as noted, not likely to result in substantive changes. I think the discussion on the mailing list on the document serves as a bi= t of a living discussion over the security goals, and I hope this message (and the contents below) will help further clarify the non-goals. > ***** (3) ***** I think these comments fall into the same as (2) > ***** (4) ***** > > >From the 1. Introduction: > > Key pinning is a trust-on-first-use (TOFU) mechanism. > > That may be true for the general problem, but its completely untrue > when 'a priori' knowledge exists for a specific instance of the > problem. Gutmann's Engineering Security [1], OWASP [2] or Moxie > Marlinspike [3] have been providing the counter examples for years. This seems merely a disagreement on terminology. It would be equivalent t= o say "Key pinning, as described in this document, is a ..." > > ***** (5) ***** While I understand that you were confused by this, I'm not sure I agree with the language being the source of the confusion or the proposed changes being useful to avoiding that confusion. > > ***** (6) ***** This seems to be minor textual quibbles and would not be something I thin= k would have been terribly useful to change. > ***** (7) ***** Possibly something to fix once it goes through the editor's queue fixing up typographic and grammatical issues, although I'm not sure. Thanks for highlighting this. > ***** (8) ***** > > >From 2.1. Response Header Field Syntax: > > The "Public-Key-Pins" and "Public-Key-Pins-Report-Only" header... Renaming the header would be a non-starter. Among other reasons, I would note the parallel here to Content-Security-Policy-Report-Only. While I can see how you reached your interpretation, it's also entirely reasonable to reach the correct conclusion from the text. As you note, th= e text certainly expounds upon its non-exclusivity, and nothing in the text (beyond your interpretation of the header name) supports your conclusion of mutual exclusivity. > ***** (10) ***** > > >From 2.2.2. HTTP Request Type: > > Pinned Hosts SHOULD NOT include the PKP header field in HTTP > responses conveyed over non-secure transport. UAs MUST ignore any > PKP header received in an HTTP response conveyed over non-secure > transport. > > There could be some confusion here. What about anonymous protocols > that provide confidentiality only? Is it allowed or not allowed? They're anonymous - e.g. they lack authenticity, aka a key binding. If you're binding a key, you're effectively authenticating the peer. Perhaps you're describing something like "opportunistic encryption", in which case, no, it would not be supported. The threat model in 4.5 hopefully makes it obvious why this would be bad. > ***** (11) ***** > > >From 2.3.3. Noting a Pinned Host - Storage Model: > > Known Pinned Hosts are identified only by domain names, and never I= P > addresses. > > This is kind of interesting. This document specifies behavior for > browsers and other UAs, but browsers follow the CA/B. Perhaps you meant the CA/Browser Forum's Baseline Requirements? In which case, no, browsers don't follow the BRs - the BRs follow the browsers. > The CA/B does > not prohibit a CA from issuing certificates for an IP address except > in the case of an an IANA reserved address (see the Baseline > Requirements, section 11.1.2 Authorization for an IP Address). > Additionally, RFC 5280 allows IP addresses in section 4.2.1.6 Subject > Alternative Name. So its not clear to me why a more restrictive policy > is called out. > > I also understand an IP address for a host can change. But in the case > a public IP address has been previously bound to a public key by way > of an authority, it again seems more restrictive. > > *If* the proposed standard is trying to guard against some threats > posed by the Domain Name System, IANA reserved addresses, RFC 1918 > addresses and similar, then that should be listed under Goals and/or > Threats. I think it's a reasonable critique that we did not expound upon why IP Addresses were forbidden from setting policy. As you note, currently the CA/Browser Forum Baseline Requirements (and the browser policies that the BRs are modeled after) permit publicly trusted certificates to IP addresses. This requirement is inherited from RFC 6797, which this document was originally proposed as an extension of, and is documented in Appendix A, Item 4 ( http://tools.ietf.org/html/rfc6797#appendix-A ) > > ***** (12) ***** > > >From 2.6. Validating Pinned Connections: > > =E2=80=A6 It is acceptable to allow Pin > Validation to be disabled for some Hosts according to local policy. > For example, a UA may disable Pin Validation for Pinned Hosts whose > validated certificate chain terminates at a user-defined trust > anchor, rather than a trust anchor built-in to the UA (or underlyin= g > platform). > > OK, this is the reason for the proposed title change in (1). This is > also the reason for the list of goals and threats in (2) and (3). Its > just not clear to me (at the moment) how a known good pinset can be > broken to facilitate proxying/interception in a proposed standard for > a security control that's supposed to stop that kind of funny > business. This is, as I understand it, your main point of contention. Rather than write a full rebuttal, I'd rather point you to http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-= key-pinning-interact-with-local-proxies-and-filters- which describes the design rationale. In short, what you describe is a tension between the server operator (who wishes to express a cryptographic policy) and the user (who wishes to use their machine however they see fit). In such battles, User Agents (aka things that processes requests for the user) implicitly and explicitly choose to favour the user (for whom they act for) rather than the server. > > ***** (13) ***** > > >From 2.6. Validating Pinned Connections: > > UAs send validation failure reports only when Pin Validation is > actually in effect. Pin Validation might not be in effect e.g. > because the user has elected to disable it, or because a presented > certificate chain chains up to a user-defined trust anchor. In suc= h > cases, UAs SHOULD NOT send reports. > > If I am reading/parsing this correctly: adversaries want to be able to > surreptitiously MitM the channel, and they don't want a spotlight > shone on them while doing it. Then no, you're not reading it properly. This is about protecting user privacy and their rights, rather than the server's goals. As discussed in this group in the past, it's quite silly to suggest that the server should be able to violate the users' rights or privileges with some header - as silly as setting an evil bit (RFC 3514) For example, consider popular anti-virus solutions that do local MITM for purposes of traffic inspection/protection. The user has chosen to grant this program the capability to do so (such as by installing its trust anchor), and derives great benefit from doing so. Such MITM software may (and often does) include the authorized users' nam= e and other personally identifying details (such as a license number) withi= n the certificate it uses to intercept. Under today's web security model, there is no way for the remote server t= o get access to this data, and that is a GOOD thing. Even if the certificat= e didn't contain any PII, the very key of the issuing certificate itself would represent a stable identifier that could be tracked across browsing sessions, since each key would be unique per user. This is not a "tremendous blow to transparency", as you note. This is about protecting users' privacy. This is not about violating the users right to know they're being proxy'd/intercepted - they're already aware of it, because only they coul= d have authorized it. If you're concerned that the user may not have authorized it, then I would remind you of the Immutable Laws of Security = - particularly 2 and 3. http://technet.microsoft.com/en-us/magazine/2008.10.securitywatch.aspx > IETF leadership: Carl Sagan once asked, who speaks for the Earth. Who > here speaks for the users and sites? Does it *really* sound like a > good idea to suppress evidence of validation failures and unauthorized > overrides for a security control that's specifically designed to > contend with the threats? This spec speaks for the users, by ensuring that local privacy rights trump remote server policy. If this spec failed to respect the users' right to privacy, and disclose to a remote server details that they would not otherwise have access to, then it would just be a silly little arms race where the end result was exactly what was specified - anyone doing this would block the reporting (and rightfully so), as it would offer persistent tracking of users. Remote policy requests CANNOT trump local security policy, full stop. > ***** (14) ***** > > 2.7. Interactions With Preloaded Pin Lists: > > The effective policy for a Known Pinned Host that has both built-in > Pins and Pins from previously observed PKP header response fields i= s > implementation-defined. > > In the name of transparency, the site should receive at least one > report detailing the issue. The site should be able to specify the > frequency of the reports so it can assess the breadth of the reported > issue. Implementation defined is implementation defined. > ***** (15) ***** > > 2.8. Pinning Self-Signed End Entities > > Kudos for this section. I think it fits nicely with Viktor Dukhovni's > Opportunistic Security. MAY is MAY. > ***** (16) ***** > I think all of what you said is wrong here, for reasons expounded upon in both (13) and in http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-= key-pinning-interact-with-local-proxies-and-filters- . That is, everything you site as arguments for your interpretation are exactly the same reasons why it does NOT do what you wish, and why it would be terrible to do so. The device owner has expressly authorized the interception. They are the first constituent. Your remote server operator has far less priority than them, nor can you argue that there is any way to protect users who are no= t the device owners - this is one of the immutable law of security. > ***** (17) ***** > This is just a restatement of (16) and (13). The users' wishes - including allowing interception - trump the remote servers wishes. Though the remote server may not wish to allow the users' anti-virus to protect them (and I can think of plenty hostile malware sites that would want such a control), the users' wishes trump all. From nobody Thu Jan 8 03:22:06 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0471A1A8C for ; Thu, 8 Jan 2015 03:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.899 X-Spam-Level: ** X-Spam-Status: No, score=2.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QH9epA25a-Xf for ; Thu, 8 Jan 2015 03:21:59 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCCC1A1BC3 for ; Thu, 8 Jan 2015 03:21:58 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 95F7932E534; Thu, 8 Jan 2015 20:21:10 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 4836_9a25_e5dc19aa_370f_4ae5_91a4_b31b6013296c; Thu, 08 Jan 2015 20:21:09 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id A2CE0BF540; Thu, 8 Jan 2015 20:21:09 +0900 (JST) Message-ID: <54AE6825.7010203@it.aoyama.ac.jp> Date: Thu, 08 Jan 2015 20:21:09 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Chris Evans , Chris Palmer , Ryan Sleevi References: <8E436DD1-8EFB-4270-81CA-717B0FDD9A4F@gmail.com> In-Reply-To: <8E436DD1-8EFB-4270-81CA-717B0FDD9A4F@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF WebSec WG Subject: [websec] Sites with Key Pinning Headers (not preloaded pins) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2015 11:22:01 -0000 Hello Chris, Chris, Ryan, and everybody, A student of mine is working on a small client-side implementation of key pinning. For testing, we would like to know sites that already send the respective headers (Public-Key-Pins and/or Public-Key-Pins-Report-Only). Any replies on the list or in private appreciated. Regards, Martin. From nobody Thu Jan 8 06:54:31 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA3E1A0270 for ; Thu, 8 Jan 2015 06:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iom6O_bcaZpX for ; Thu, 8 Jan 2015 06:54:27 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FD11A6F0A for ; Thu, 8 Jan 2015 06:54:26 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so3252473lbi.10 for ; Thu, 08 Jan 2015 06:54:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PZf7e9f/TZGVaa1R+Pmbx3TwI9xZuaskduXkPhk6/g8=; b=mUEFPgK4vuUDTxcfUqr7k2XXnNCiIjpMrEgwGYVILc+ppEeSySqhkVQoqGiGppqEeX ufydQgjM/JmZhDIEwBWDgy58g6KP993bumisJ7ojSlinFw7LR9MOlFUVG42YaQfiAFOc cYyN/JliBxZ2CIAPr6/TvLUDKvaqGfFA6rS3a3SKIZv3YLNA43pv8OZ22uWwlAm+qAFm Wl+lvbU6xsWfpa4HNwVxxIMuHMzNZ+nrlbUvgK0pKXGBAluBmHZ/KU2giy80aYgW/1Ym iL3OTF9t9KIEdzANbidImEyVrRiZstURwaSXjPvN/IrvG7/LqhI3dIrliLQF7I+x3Ihw nAHQ== X-Received: by 10.112.41.234 with SMTP id i10mr14491689lbl.25.1420728864281; Thu, 08 Jan 2015 06:54:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.11.69 with HTTP; Thu, 8 Jan 2015 06:54:04 -0800 (PST) In-Reply-To: <54AE6825.7010203@it.aoyama.ac.jp> References: <8E436DD1-8EFB-4270-81CA-717B0FDD9A4F@gmail.com> <54AE6825.7010203@it.aoyama.ac.jp> From: Joseph Bonneau Date: Thu, 8 Jan 2015 14:54:04 +0000 Message-ID: To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=001a1134593c471b9c050c253796 Archived-At: Cc: Chris Evans , IETF WebSec WG , Ryan Sleevi , "Michael J. Kranch" Subject: Re: [websec] Sites with Key Pinning Headers (not preloaded pins) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2015 14:54:29 -0000 --001a1134593c471b9c050c253796 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Martin, For our upcoming NDSS paper ( http://www.jbonneau.com/doc/KB15-NDSS-hsts_pinning_survey.pdf), we did a crawl of the top 1M Alexa Domains plus every domain in Chrome's preloaded list, we observed attempts to set PKP headers at the domains listed below. Note some of these are set incorrectly (see Section IV-F of the paper). Best of luck with your research. Joe amateurdumper.com amigogeek.net detectify.com forumdenge.com frederik-braun.com freenetproject.org freitag.de homemakinghacks.com kitapyurdu.eu segu-info.com.ar skysportsng.com steventress.com timtaubert.de tone-and-tighten.com webstars2k.com www.deagostini.jp www.ilireg.ir www.metrotimes.com www.mnot.net www.munsterrugby.ie www.pennydellpuzzles.com www.userstyles.org On Jan 8, 2015 11:22 AM, Martin J. D=C3=BCrst wrot= e: > Hello Chris, Chris, Ryan, and everybody, > > A student of mine is working on a small client-side implementation of key > pinning. For testing, we would like to know sites that already send the > respective headers (Public-Key-Pins and/or Public-Key-Pins-Report-Only). > Any replies on the list or in private appreciated. > > Regards, Martin. > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > --001a1134593c471b9c050c253796 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello Martin,

For our upcoming NDSS paper (http://= www.jbonneau.com/doc/KB15-NDSS-hsts_pinning_survey.pdf), we did a crawl= of the top 1M Alexa Domains plus every domain in Chrome's preloaded li= st, we observed attempts to set PKP headers at the domains listed below. No= te some of these are set incorrectly (see Section IV-F of the paper). Best = of luck with your research.

Joe

amateurdumper.com

amigogee= k.net

detectify.com

forumdenge.com

frederik-braun.com

freenetproject.org

frei= tag.de

homemakinghacks.com=

kitapyurdu.eu

segu-info.com.ar

skysportsng.com

steventress.com

timtaubert.de<= /a>

tone-and-tighten.com<= /p>

webstars2k.com

www.deagostini.jp

www.ilireg.ir

= www.metrotimes.com

www.mnot.net

www.munsterrugby.ie

=

www.pennydellpuzzles.com=

www.userstyles.org

O= n Jan 8, 2015 11:22 AM, Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> wrote:
=

Hello Chris, Chris, Ryan, a= nd everybody,

A student of mine is working on a small client-side implementation of key p= inning. For testing, we would like to know sites that already send the resp= ective headers (Public-Key-Pins and/or Public-Key-Pins-Report-Only). Any re= plies on the list or in private appreciated.

Regards,=C2=A0 =C2=A0Martin.

_______________________________________________
websec mailing list
websec@ietf.org = https://www.ietf.org/mailman/listinfo/websec
--001a1134593c471b9c050c253796-- From nobody Thu Jan 8 07:50:34 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87ACE1A8AAA for ; Thu, 8 Jan 2015 07:50:31 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4h3ZluoK1EZ for ; Thu, 8 Jan 2015 07:50:29 -0800 (PST) Received: from smtp1.hushmail.com (smtp1.hushmail.com [65.39.178.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B5A1A7005 for ; Thu, 8 Jan 2015 07:50:29 -0800 (PST) Received: from smtp1.hushmail.com (localhost [127.0.0.1]) by smtp1.hushmail.com (Postfix) with SMTP id 3489B402AD for ; Thu, 8 Jan 2015 15:50:35 +0000 (UTC) X-hush-tls-connected: 1 Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.hushmail.com (Postfix) with ESMTPS; Thu, 8 Jan 2015 15:50:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Pawel Krawczyk In-Reply-To: <54AE6825.7010203@it.aoyama.ac.jp> Date: Thu, 8 Jan 2015 15:50:23 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8E436DD1-8EFB-4270-81CA-717B0FDD9A4F@gmail.com> <54AE6825.7010203@it.aoyama.ac.jp> To: =?utf-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Chris Evans , IETF WebSec WG , Ryan Sleevi Subject: Re: [websec] Sites with Key Pinning Headers (not preloaded pins) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2015 15:50:31 -0000 27 of them found here = http://webcookies.org/http-headers/public-key-pins/ > On 8 Jan 2015, at 11:21, Martin J. D=C3=BCrst = wrote: >=20 > Hello Chris, Chris, Ryan, and everybody, >=20 > A student of mine is working on a small client-side implementation of = key pinning. For testing, we would like to know sites that already send = the respective headers (Public-Key-Pins and/or = Public-Key-Pins-Report-Only). Any replies on the list or in private = appreciated. >=20 > Regards, Martin. >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 --=20 Pawel Krawczyk pawel.krawczyk@hush.com +44 7879 180015 CISSP, OWASP From nobody Mon Jan 12 11:19:03 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993531ACD43 for ; Mon, 12 Jan 2015 11:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrQrjzTKbdgN for ; Mon, 12 Jan 2015 11:18:59 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564E31ACD40 for ; Mon, 12 Jan 2015 11:18:59 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id a3so21977724oib.5 for ; Mon, 12 Jan 2015 11:18:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=f17+sUEvUMYPvQlQPzhL3N6gtW459Yh2THt/KsLK4Ig=; b=S0xXAdc2S5BOEg0JZMNARmsToj/fOs3+I3/qfmooYe90qb5/2q04VEKBBAHejEG7pU zLyG1lx/kxM50Vz8iSEmkdADTAutXhbpOZ5eLDoooG1t+69Qlpzu0wDgXxwgFnIG6yKA Qc8uCzi0O0C0BW6Pu0XVrkCMTtEhKTS8CS3kA5mLSKqyZ4r2AidaePqy2t4rhhj4wCEE pFfmk2+e2BoAVD0pT2cXMD/eiyfgDfI7ndbjQ30/PCUMVdtmFM7NMG1zkwSiSiWTPGz9 movdtABdlLma9gEty2tZ1VPifkxyeI7nX97z6cK4ZAqa0iZ7rzkLXo0N4Px3cSh4ErHD S35w== MIME-Version: 1.0 X-Received: by 10.182.103.232 with SMTP id fz8mr18582565obb.59.1421090338620; Mon, 12 Jan 2015 11:18:58 -0800 (PST) Received: by 10.202.45.78 with HTTP; Mon, 12 Jan 2015 11:18:58 -0800 (PST) Date: Mon, 12 Jan 2015 11:18:58 -0800 Message-ID: From: Chris Hartmann To: websec@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 19:19:01 -0000 1) Bob trusts and does personal business with a.com. 2) a.com forms a business relationship with b.com to perform a business function on its behalf (payment processor, blog, whatever). The landing page is b.com/a 3) Bob visits b.com/a and notices that the page claims to be affiliated and owned by a.com 4) How can Bob, in absolute terms, trust that b.com/a is affiliated and a delegated service by a.com? (say, prior to submitting sensitive information) Is this a security problem? I think so. We=E2=80=99ve all had to make this decision one time or another on weak inferences and correlations. I=E2=80=99d imagine Phishers don=E2=80=99t min= d at all that there is an inability for the common internet user (looking at you grandma) to make the judgement call on web service affiliations. They=E2=80=99ve been conditioned with the best practice of looking at the address bar (and perhaps the DNS namespace) along with the lock icon to indicate trustworthiness, which may actually help the attacker in their act of misdirection. Inter-domain relationships model business relationships and trust. If web users could be armed with a new =E2=80=9Csense=E2=80=9D which proves these legitimate relationships (say cryptographically) then perhaps they would have more reason to be skeptical of those who cannot prove their affiliation. I=E2=80=99m not sayi= ng we can take human judgement completely out of the equation, but why not have a tool to help anchor this commonly needed and risky correlation. Eg: 5) https://c.com/a is a bad guy and claims the same thing as b.com/a . Now who to trust becomes a research project. (But c.com has the https lock icon, doesn=E2=80=99t that count for anything: NO) Use case a) Tim submits a payment to a redcross.org Paypal donation page he found via his favorite search engine. It was a scam. (We can argue a violation of "best practices" here, but that is besides the point) I suppose phishing isn=E2=80=99t the only example. It could apply to any ca= se where you want to logically group the identity of one entity across many domain boundaries owned by different parties. (eg. A popular band has many web points of presence for fans, etc). This same mechanism could =E2=80=9Ccertify=E2=80=9D that these web assets are under one umbrell= a, although they don=E2=80=99t exist under one domain hierarchy. Should we solve this? Is it solved already? Could use help gelling or junking this idea. I have a few ideas on how this could be improved/implemented. Cheers, Chris P.S. First post here, been lurking for a while now. From nobody Tue Jan 13 01:09:23 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302B71ACE38 for ; Tue, 13 Jan 2015 01:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M878QQEKXEgr for ; Tue, 13 Jan 2015 01:09:19 -0800 (PST) Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id C27271A8A43 for ; Tue, 13 Jan 2015 01:09:19 -0800 (PST) Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id 19550626074 for ; Tue, 13 Jan 2015 01:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=annevk.nl; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; s=annevk.nl; bh=KJv7f/B0nOTidV8cpMTQMrq7SjU=; b=An B6u986kx3Su+YQvkBdBTs2PexyzrQ84I0domoCADE1YPo5DlKJuqdEhOXVuC5tpW HaGRk0HxjBnYwJNZ658BZh2zZ6tj23Ayqi25Kgydwg4nbbIpOtfMm3jRKyCQ/2W3 dsTgfEnXKxCr33P07H1hwnPnUzFP96qlf+WmBsf+o= Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: annevk@annevk.nl) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id DC5B7626072 for ; Tue, 13 Jan 2015 01:09:18 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id n8so1222103qaq.4 for ; Tue, 13 Jan 2015 01:09:18 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.87.71 with SMTP id q65mr53685746qgd.67.1421140158316; Tue, 13 Jan 2015 01:09:18 -0800 (PST) Received: by 10.229.68.194 with HTTP; Tue, 13 Jan 2015 01:09:18 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Jan 2015 10:09:18 +0100 Message-ID: From: Anne van Kesteren To: Chris Hartmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: websec Subject: Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 09:09:21 -0000 On Mon, Jan 12, 2015 at 8:18 PM, Chris Hartmann wrote: > Should we solve this? Is it solved already? Could use help gelling or > junking this idea. > > I have a few ideas on how this could be improved/implemented. I'd be interested to hear them. E.g. at work we started using https://www.okta.com/ to login to a bunch of a services, including e.g. Google services. It felt extremely phishy to give credentials to okta.com to make use of a google.com service. -- https://annevankesteren.nl/ From nobody Tue Jan 13 02:40:51 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C9B1A8A8E for ; Tue, 13 Jan 2015 02:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Daz2nGeVfiRd for ; Tue, 13 Jan 2015 02:40:47 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A311A8836 for ; Tue, 13 Jan 2015 02:40:46 -0800 (PST) Received: from [192.168.0.103] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 86BF0F2952; Tue, 13 Jan 2015 02:40:45 -0800 (PST) Message-ID: <54B4F62C.4040901@mozilla.org> Date: Tue, 13 Jan 2015 10:40:44 +0000 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Chris Hartmann , websec@ietf.org References: In-Reply-To: OpenPGP: id=9DF43DBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 10:40:49 -0000 On 12/01/15 19:18, Chris Hartmann wrote: > 2) a.com forms a business relationship with b.com to perform a > business function on its behalf (payment processor, blog, whatever). > The landing page is b.com/a Would it not be reasonable to say that, when this sort of relationship is set up, best practice is to do DNS delegation so that the landing page is on b.a.com or some other subdomain of a.com? > 3) Bob visits b.com/a and notices that the page claims to be > affiliated and owned by a.com ...because then, both the DNS info and the claim would match. > 4) How can Bob, in absolute terms, trust that b.com/a is affiliated > and a delegated service by a.com? (say, prior to submitting sensitive > information) Because the domain used is a subdomain of a.com. Gerv From nobody Tue Jan 13 10:36:46 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE481A9080 for ; Tue, 13 Jan 2015 10:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLrPRQsvHICv for ; Tue, 13 Jan 2015 10:36:43 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 4DE3A1A904A for ; Tue, 13 Jan 2015 10:36:43 -0800 (PST) Received: (qmail 17174 invoked by uid 0); 13 Jan 2015 18:36:39 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 13 Jan 2015 18:36:39 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id fWcZ1p0072UhLwi01WccbG; Tue, 13 Jan 2015 11:36:38 -0700 X-Authority-Analysis: v=2.1 cv=VqmwXYGn c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=DrNGYBpgUcYA:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=SojtekhEa5wA:10 a=YNv0rlydsVwA:10 a=nS36O97Bj3wUElCrIrAA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; b=hC42/yQp66YqHtac6e1fZVcjwyNqK0uyhbTsxhOQX4kp/wUaU71HaPoa36gTKjxC+nbJtwLtD4o7dGTpHrwXu4m6V3DqJfgzV0s/utoNfZmWbNku2VKQySshmvE3x48U; Received: from [216.113.160.66] (port=47003 helo=[10.244.137.7]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YB6KP-0004nz-4A for websec@ietf.org; Tue, 13 Jan 2015 11:36:33 -0700 Message-ID: <54B565AD.1060605@KingsMountain.com> Date: Tue, 13 Jan 2015 10:36:29 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.160.66 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [websec] test pls ignore X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 18:36:45 -0000 test From nobody Tue Jan 13 12:31:02 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9717F1ACDBE for ; Tue, 13 Jan 2015 12:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4o7L5LfgSPt for ; Tue, 13 Jan 2015 12:30:59 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB451ACD87 for ; Tue, 13 Jan 2015 12:30:59 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id vb8so4597799obc.0 for ; Tue, 13 Jan 2015 12:30:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z2gEZ4H8trRmClX6STRzlGaMClxcLU4I/hXXgJ/KUtg=; b=z10GYA/4B/W/SvTUSOtO6WiKfuHJE3KD8Jg35VoW2GJOJzcLTzucZc4jVCfkRjg3eN n4wCr02qglZhe1BAu2DgOKmVqWuzwL/Idj5Iq0sZfU2JetRq9nCsZV5UQyDcIak50RK1 LksGz12w/inkfRd4/QKzOEnTXHnA28YGxXuIsWoHRqTJ0SJE4/8jtdqV7aJmwIEUSWi0 XFZ6ysX/neS1M7V4mz1LD8pXVLb2tiKhB6CUnVyZHeEr+RrNCDfJWNylu7aGgDXSYMhz iygBrTKd+XwU/JHh1CqdNaJ/Xrkrj77QCqpiIrGrtNggXght2h3+IZYh7jESp+bSzDT3 IFvw== MIME-Version: 1.0 X-Received: by 10.60.125.130 with SMTP id mq2mr206619oeb.50.1421181058254; Tue, 13 Jan 2015 12:30:58 -0800 (PST) Received: by 10.202.45.78 with HTTP; Tue, 13 Jan 2015 12:30:58 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Jan 2015 12:30:58 -0800 Message-ID: From: Chris Hartmann To: Anne van Kesteren Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: websec Subject: Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 20:31:01 -0000 Hi Anne/All, Thanks for the response. I think your use-case is slightly different then what I was going for, but perhaps I can extend my idea to cover a different aspect of yours. Just for clarity, if I understand correctly, the relationship between services like okta.com and google.com isn't what I'm addressing (sounds more OAuth'ish etc). Rather the relationship between you, your employer, and okta.com might be more in line with where I'm going, but still isn't really the primary case. Let me explain, in your case, you or your company IT department made a judgement call to trust okta.com with managing a business asset, business related accounts used for business purposes hosted by a third-party. Presumably your credentials to okta.com are a risk to the company if compromised. If a phisher sent you an email claiming to be okta.com with a link to a fake but believable hostname, say otka.com (see what I did there), you happen to click the link and are on the verge of providing your credentials, you are now in a situation where your perception of the hostname is the only indication to spark your skepticism and avoid compromise. Exactly the edge phishers hope for. My vague idea is that the user agent should have the capability to notify you, the end-user, that there is no relationship between yourcompany.com and otka.com (the bad guy), perhaps in a similar manner that browsers today indicate a lack of integrity with regards to https verification failures. Instead of the user-agent labeling the bad guy as bad, it would be the opposite. When yourcompany.com formed the business relationship with okta.com it could perhaps share a bit of digitally signed data, say digitally sign the url to the login page (www.okta.com/yourcompany) and embed that in response. Then the user-agent would be able to notify you each time you log in that yourcompany.com authorized www.okta.com/yourcompany in an obvious enough manner for you to notice it missing when you clicked the phishing link. In a sense my hope is to label the good relationships as truthfully good, the user-agent constantly labels it as such, and then the hope is that typical end users can then be skeptical when the "this is the good guy" label is missing, enhancing human perception of good vs. evil. All of this is very specific, but in general, at the core, I think as orgs continue the trend of "outsourcing IT" there needs to be a way on the web to describe and authenticate the relationships in a manner that end-users and user-agents can digest. Making a lot of assumptions and going out on a limb here, but a fun little thought experiment, and look forward to continuing the brainstorm. Chris On Tue, Jan 13, 2015 at 1:09 AM, Anne van Kesteren wrote: > On Mon, Jan 12, 2015 at 8:18 PM, Chris Hartmann wrote: >> Should we solve this? Is it solved already? Could use help gelling or >> junking this idea. >> >> I have a few ideas on how this could be improved/implemented. > > I'd be interested to hear them. E.g. at work we started using > https://www.okta.com/ to login to a bunch of a services, including > e.g. Google services. It felt extremely phishy to give credentials to > okta.com to make use of a google.com service. > > > -- > https://annevankesteren.nl/ From nobody Tue Jan 13 13:32:11 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3FD1B29A2 for ; Tue, 13 Jan 2015 13:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K3FNNn_pyvx for ; Tue, 13 Jan 2015 13:32:07 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87AE11AD49D for ; Tue, 13 Jan 2015 13:32:07 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id nt9so4848346obb.10 for ; Tue, 13 Jan 2015 13:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HyWUnTt7tHAY3F/1xjxhOlYoNT4LXKgnebEflkCyl/A=; b=EvS8zSA0VDyUDbDrGq3c6O3Z0ar1q1amlWPMpNp2/H3WcHAYNIdyFSyQLF39HciJdW V0wrHyn2gv4hmjStcxl+cbTFPFMEjPnkmtwY7pIExUdKL+JBFD0L3b1JZMrqUO0zQC4+ GSPGemkorUajZuCZ3gkyEkEfSVOwWt+e+zSxVrvAi4VAowSWFUsQkn2LWUy1nfkoG3PG AAPnJpAUPCHwIQ9XsSaKkTx2pb14G3Ypt6NXuswUrHWra2mtmZyGH9b7uTYSQKL8CNNM exdFus0dEeSFYUOEXP3q7z/wq2OY8TqZUYx5l1YQZ5yROSaA7aisHhc4zAgnZXOLFF5F wtaQ== MIME-Version: 1.0 X-Received: by 10.182.125.72 with SMTP id mo8mr300066obb.61.1421184726771; Tue, 13 Jan 2015 13:32:06 -0800 (PST) Received: by 10.202.45.78 with HTTP; Tue, 13 Jan 2015 13:32:06 -0800 (PST) In-Reply-To: <54B4F62C.4040901@mozilla.org> References: <54B4F62C.4040901@mozilla.org> Date: Tue, 13 Jan 2015 13:32:06 -0800 Message-ID: From: Chris Hartmann To: Gervase Markham Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: websec Subject: Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 21:32:10 -0000 On Tue, Jan 13, 2015 at 2:40 AM, Gervase Markham wrote: > On 12/01/15 19:18, Chris Hartmann wrote: >> 2) a.com forms a business relationship with b.com to perform a >> business function on its behalf (payment processor, blog, whatever). >> The landing page is b.com/a > > Would it not be reasonable to say that, when this sort of relationship > is set up, best practice is to do DNS delegation so that the landing > page is on b.a.com or some other subdomain of a.com? > Absolutely. However my impression is that isn't the common practice for two parties to integrate at this level consistently. For example a google search can show the organizations that presumably have web presence that is theirs, but how do I _know_ in an undeniable manner that they are a subsidy of their parent domain. https://www.google.com/webhp?#q=imagine+dragons+-site:imaginedragonsmusic.com https://www.google.com/search?q=cnn%20-site%3Acnn.com Yeah we all make conscious cross references here, which can give us a pretty good sense of correlation, and usually guessing wrong isn't catastrophic. Sometimes the third-parties do make efforts to assure users that the landing pages are "verified" as authentic, but that is pretty weak. My argument is that this doesn't have to be hearsay or a manual correlation effort, the user-agent be able to tell us the truth. This might seem trivial and unnecessary which is a valid argument in some cases, but my belief is that this is one of the core properties that makes phishing attempts more murky to end users for the corner cases that matter. This is what I would hope to fix. >> 3) Bob visits b.com/a and notices that the page claims to be >> affiliated and owned by a.com > > ...because then, both the DNS info and the claim would match. > >> 4) How can Bob, in absolute terms, trust that b.com/a is affiliated >> and a delegated service by a.com? (say, prior to submitting sensitive >> information) > > Because the domain used is a subdomain of a.com. > > Gerv From nobody Tue Jan 13 16:44:42 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D361ACE23 for ; Tue, 13 Jan 2015 16:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM6O0-nxLyUs for ; Tue, 13 Jan 2015 16:44:39 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F711ACE20 for ; Tue, 13 Jan 2015 16:44:38 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id hn15so19993126igb.1 for ; Tue, 13 Jan 2015 16:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=dEMN7/nbQ8+Jx/umaQrDDN8GzruXsb92Xcnl6u/rYsI=; b=UAuRsyp2jN3N9uQAeWR8FjYNhQW9Rm0stUhnpnqQnHCZe+m0WWKpcxpWTZtKPtBB+E QssXZBJGKbnp3+4h8BmRuxi70QDLvqjD6t8EYIO+zAdURKjHozFc2oM6a8z8+cwIP009 kC8iAMfE2alouyjAolDVDomgxCcN5DZ4+UWWYU/FSVUwOuESUlVbgEzB4OL0lfM7GMVb CZ9zI9Vg8r0i6dF1H5C3+NSiR1rGEXaASl45TT72ykDU/d2dXJUrd+86Kfv7aiX+PAml IUFcYCB8B1TjH2unEltrY1RSaiEQziskqyWFc5V98wb6HCsBuetaa1VEXxIsGYkrEObT vXSA== MIME-Version: 1.0 X-Received: by 10.50.66.171 with SMTP id g11mr1454949igt.49.1421196277943; Tue, 13 Jan 2015 16:44:37 -0800 (PST) Received: by 10.107.134.170 with HTTP; Tue, 13 Jan 2015 16:44:37 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Jan 2015 19:44:37 -0500 Message-ID: From: Jeffrey Walton To: Chris Hartmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 00:44:41 -0000 > Is this a security problem? I think so. Yes. Knowing the relationship would be helpful in a security context. > I have a few ideas on how this could be improved/implemented. Dbound is poking and prodding at related issues. And they are finalizing their charter now. You might consider reading some of the recent posts and commenting. https://www.ietf.org/mailman/listinfo/dbound. Jeff On Mon, Jan 12, 2015 at 2:18 PM, Chris Hartmann wrot= e: > 1) Bob trusts and does personal business with a.com. > > 2) a.com forms a business relationship with b.com to perform a > business function on its behalf (payment processor, blog, whatever). > The landing page is b.com/a > > 3) Bob visits b.com/a and notices that the page claims to be > affiliated and owned by a.com > > 4) How can Bob, in absolute terms, trust that b.com/a is affiliated > and a delegated service by a.com? (say, prior to submitting sensitive > information) > > Is this a security problem? I think so. > > We=E2=80=99ve all had to make this decision one time or another on weak > inferences and correlations. I=E2=80=99d imagine Phishers don=E2=80=99t m= ind at all > that there is an inability for the common internet user (looking at > you grandma) to make the judgement call on web service affiliations. > They=E2=80=99ve been conditioned with the best practice of looking at the > address bar (and perhaps the DNS namespace) along with the lock icon > to indicate trustworthiness, which may actually help the attacker in > their act of misdirection. Inter-domain relationships model business > relationships and trust. If web users could be armed with a new > =E2=80=9Csense=E2=80=9D which proves these legitimate relationships (say > cryptographically) then perhaps they would have more reason to be > skeptical of those who cannot prove their affiliation. I=E2=80=99m not sa= ying > we can take human judgement completely out of the equation, but why > not have a tool to help anchor this commonly needed and risky > correlation. > > Eg: > > 5) https://c.com/a is a bad guy and claims the same thing as b.com/a . > Now who to trust becomes a research project. (But c.com has the https > lock icon, doesn=E2=80=99t that count for anything: NO) > > > Use case a) Tim submits a payment to a redcross.org Paypal donation > page he found via his favorite search engine. It was a scam. (We can > argue a violation of "best practices" here, but that is besides the > point) > > > I suppose phishing isn=E2=80=99t the only example. It could apply to any = case > where you want to logically group the identity of one entity across > many domain boundaries owned by different parties. (eg. A popular band > has many web points of presence for fans, etc). This same mechanism > could =E2=80=9Ccertify=E2=80=9D that these web assets are under one umbre= lla, although > they don=E2=80=99t exist under one domain hierarchy. > > Should we solve this? Is it solved already? Could use help gelling or > junking this idea. > > I have a few ideas on how this could be improved/implemented. > > Cheers, > From nobody Wed Jan 14 01:15:37 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836AC1A89A8 for ; Wed, 14 Jan 2015 01:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EO3xOu5EI3bG for ; Wed, 14 Jan 2015 01:15:32 -0800 (PST) Received: from homiemail-a2.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 109481A6F96 for ; Wed, 14 Jan 2015 01:15:31 -0800 (PST) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 873FD280072 for ; Wed, 14 Jan 2015 01:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=annevk.nl; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; s=annevk.nl; bh=FM6t62pVVvGc+Cs8a3CrHGO0cEs=; b=ci eS2qROrSeC/Lpe2RYUuU/6jTxL4nYdjZZ4hb+EUoizSSP0dWFwdZRDcadpV8Snt7 DsOPFd66FOoFbgHSXkXFCnJ368/PuNrW7k2JhMGltUiocQPoeeJerMW0BLEHwJZs 5/3f8XddLjHwcVZgrmG+fZ1NZIlyTUpb2y5Ex6vCc= Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: annevk@annevk.nl) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPSA id 6BAC228006D for ; Wed, 14 Jan 2015 01:15:31 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i17so6323619qcy.4 for ; Wed, 14 Jan 2015 01:15:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.224.28.198 with SMTP id n6mr4750499qac.15.1421226930657; Wed, 14 Jan 2015 01:15:30 -0800 (PST) Received: by 10.229.68.194 with HTTP; Wed, 14 Jan 2015 01:15:30 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 10:15:30 +0100 Message-ID: From: Anne van Kesteren To: Chris Hartmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: websec Subject: Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 09:15:33 -0000 On Tue, Jan 13, 2015 at 9:30 PM, Chris Hartmann wrote: > If a phisher > sent you an email claiming to be okta.com with a link to a fake but > believable hostname, say otka.com (see what I did there), you happen > to click the link and are on the verge of providing your credentials, Yeah, that's the concern. > When yourcompany.com formed the business relationship with > okta.com it could perhaps share a bit of digitally signed data, say > digitally sign the url to the login page (www.okta.com/yourcompany) > and embed that in response. Given that the current address bar UI already has limited utility, it's not clear to me what making it more complicated will actually help users. -- https://annevankesteren.nl/ From nobody Wed Jan 14 04:17:02 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338601ACE44 for ; Wed, 14 Jan 2015 04:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.665 X-Spam-Level: X-Spam-Status: No, score=-96.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW2gWNp2YSv0 for ; Wed, 14 Jan 2015 04:16:58 -0800 (PST) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818881B2C65 for ; Wed, 14 Jan 2015 04:16:58 -0800 (PST) Received: from [192.168.43.211] (unknown [85.255.233.129]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 244156310A; Wed, 14 Jan 2015 13:16:55 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=KNLT6DhOIR3Rerl2cVsE1BlMvDRvIk60JltCSdzcT4Qp2Z6J5gb+9w7DCsDNEH+0w6vyqB3aUc2aThYAbVrmxnJaqro30rdGOarNITbROoVAEV8f/scLqHujMBPeiwAd/VJpbqbWbaBLdEBQD0adrxPtqs9IpWtdnm6prTmYyI8=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Message-ID: <54B65E34.2050909@gondrom.org> Date: Wed, 14 Jan 2015 12:16:52 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: noloader@gmail.com, cxhartmann@gmail.com References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: websec@ietf.org Subject: Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 12:17:01 -0000 Hi Chris, hi all, let me say, I can see a missing link here which would be nice to solve. Btw. another example coming to mind would be the connection with external payment services or increasing number of references to cloud based services (where it is not sure that a.com is indeed using b.com). E.g. e-commerce sites linking to paypal or Mastercard / Visa vericode (or whatever they call it) directly out of the e-commerce site... Some improvement in the trust chain could indeed be valuable here. Having said that, if another WG is already working in this area - Jeff mentioned dbound - then my recommendation would be to take the work there. WEBSEC is about to be closed, we are only waiting for the final release of our last document. Best regards, Tobias On 14/01/15 00:44, Jeffrey Walton wrote: >> Is this a security problem? I think so. > Yes. Knowing the relationship would be helpful in a security context. > >> I have a few ideas on how this could be improved/implemented. > Dbound is poking and prodding at related issues. And they are > finalizing their charter now. You might consider reading some of the > recent posts and commenting. > > https://www.ietf.org/mailman/listinfo/dbound. > > Jeff > > On Mon, Jan 12, 2015 at 2:18 PM, Chris Hartmann wrote: >> 1) Bob trusts and does personal business with a.com. >> >> 2) a.com forms a business relationship with b.com to perform a >> business function on its behalf (payment processor, blog, whatever). >> The landing page is b.com/a >> >> 3) Bob visits b.com/a and notices that the page claims to be >> affiliated and owned by a.com >> >> 4) How can Bob, in absolute terms, trust that b.com/a is affiliated >> and a delegated service by a.com? (say, prior to submitting sensitive >> information) >> >> Is this a security problem? I think so. >> >> We’ve all had to make this decision one time or another on weak >> inferences and correlations. I’d imagine Phishers don’t mind at all >> that there is an inability for the common internet user (looking at >> you grandma) to make the judgement call on web service affiliations. >> They’ve been conditioned with the best practice of looking at the >> address bar (and perhaps the DNS namespace) along with the lock icon >> to indicate trustworthiness, which may actually help the attacker in >> their act of misdirection. Inter-domain relationships model business >> relationships and trust. If web users could be armed with a new >> “sense” which proves these legitimate relationships (say >> cryptographically) then perhaps they would have more reason to be >> skeptical of those who cannot prove their affiliation. I’m not saying >> we can take human judgement completely out of the equation, but why >> not have a tool to help anchor this commonly needed and risky >> correlation. >> >> Eg: >> >> 5) https://c.com/a is a bad guy and claims the same thing as b.com/a . >> Now who to trust becomes a research project. (But c.com has the https >> lock icon, doesn’t that count for anything: NO) >> >> >> Use case a) Tim submits a payment to a redcross.org Paypal donation >> page he found via his favorite search engine. It was a scam. (We can >> argue a violation of "best practices" here, but that is besides the >> point) >> >> >> I suppose phishing isn’t the only example. It could apply to any case >> where you want to logically group the identity of one entity across >> many domain boundaries owned by different parties. (eg. A popular band >> has many web points of presence for fans, etc). This same mechanism >> could “certify” that these web assets are under one umbrella, although >> they don’t exist under one domain hierarchy. >> >> Should we solve this? Is it solved already? Could use help gelling or >> junking this idea. >> >> I have a few ideas on how this could be improved/implemented. >> >> Cheers, >> > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From nobody Wed Jan 14 13:34:59 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D181AC3EF for ; Wed, 14 Jan 2015 13:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKgJ5GsprPOr for ; Wed, 14 Jan 2015 13:34:56 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0431A90CC for ; Wed, 14 Jan 2015 13:34:55 -0800 (PST) Received: by mail-oi0-f54.google.com with SMTP id u20so9404588oif.13 for ; Wed, 14 Jan 2015 13:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XQcClvFxvd6jlqX7ytSjbR6KNxO6QQnk36+B5/wsJnE=; b=VMW0ORMF9YDsVfn/PjvbEn/hb6c2feDA9Uy6gROh38z2lc4ka3FDhpC/N/BkfwHaPs WhPUIlxmZqHUMCFKjdaVuKVBGyG/burb9kKgD36TMb2jWdmoKwpeCI1n8Yt8EtIDf1Cy Jl00kN9xScs7ZzdaRWe7QRwR1LTEd97cMpx+GNK0/J/xhuZLkFE940UoS6ongq7vrAIK 3sP58ProCjWoyDV7ENLeqkmBcXfh+iVG4cIeqldLnCmVf64rjbJMNfHpgPSryjftrg6n ssKmaf/dlPYkOPqkaNZJboDtSDc+4QcADWUE20uPPolGQ0sOkPiGx6/ax9657uTY4Ct3 Chhg== MIME-Version: 1.0 X-Received: by 10.60.125.130 with SMTP id mq2mr3929165oeb.50.1421271295087; Wed, 14 Jan 2015 13:34:55 -0800 (PST) Received: by 10.202.45.78 with HTTP; Wed, 14 Jan 2015 13:34:55 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 13:34:55 -0800 Message-ID: From: Chris Hartmann To: Anne van Kesteren Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: websec Subject: Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 21:34:57 -0000 On Wed, Jan 14, 2015 at 1:15 AM, Anne van Kesteren wrote: > On Tue, Jan 13, 2015 at 9:30 PM, Chris Hartmann wrote: >> If a phisher >> sent you an email claiming to be okta.com with a link to a fake but >> believable hostname, say otka.com (see what I did there), you happen >> to click the link and are on the verge of providing your credentials, > > Yeah, that's the concern. > > >> When yourcompany.com formed the business relationship with >> okta.com it could perhaps share a bit of digitally signed data, say >> digitally sign the url to the login page (www.okta.com/yourcompany) >> and embed that in response. > > Given that the current address bar UI already has limited utility, > it's not clear to me what making it more complicated will actually > help users. > Yeah, I also have the sense any proposed UA/UI change is going to be highly scrutinized and be a point of resistance. But I have yet to conclude how social engineering attacks can be comprehensively addressed without at least partially arming end users with something to help them make these important correlations. Trust by affiliation is a real thing that we do in the real world, although these affiliations are hard to verify, they work in general. In the digital world fortunately we can have machines verify these affiliations with an extremely high level of certainty, I'd argue people should be able to perceive these to formulate trust. > > -- > https://annevankesteren.nl/ From nobody Thu Jan 15 06:27:03 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78181B2BFF for ; Thu, 15 Jan 2015 06:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.721 X-Spam-Level: X-Spam-Status: No, score=0.721 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUfw7WHGKdo8 for ; Thu, 15 Jan 2015 06:26:57 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D051B2BFE for ; Thu, 15 Jan 2015 06:26:56 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so18177509wiw.4 for ; Thu, 15 Jan 2015 06:26:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xX3rB7IiVmmQWNtI0nz/G3MIDn+PQDfcQTO8VsFrUCc=; b=FwH4Rku5CUMkvKZQ8XBVDiyCV0PCNv+7DHICzSupss1iJ/vw0Hhfswfqu8ZrvQud1K qGOtqn877MbKJS4cVW6LFlQDmqclyk9d2iTGxwJNahfBIfMVAk+87V1kRiAA0bREcYoI tNN2f439N+VXSgFPm9ePvDwilquok3Y2DAcNuUuXGvGpNZoMikxzLqEBvMwoIJ7f/HYd BnsTsb4pbrEqG1rrLDG72E35xBpiVbDHFToae1E73ZOMUbYbWd4dh2pYnSKiWf5JWXLn Z2Q7M6e6LREDEbPVm7fIa2iUrlATUOWJIGlSaeoQyMPhf7VZTRmDZKgb5kWMViU969Z9 ygkg== X-Gm-Message-State: ALoCoQk/RLUWs2ZE2awImAzSWmbYzU4AWYxTzOl3LK2TSknjWMJh92cwtC8voRnASsf2yiv1+haX MIME-Version: 1.0 X-Received: by 10.194.236.200 with SMTP id uw8mr19131527wjc.10.1421332014596; Thu, 15 Jan 2015 06:26:54 -0800 (PST) Received: by 10.180.11.205 with HTTP; Thu, 15 Jan 2015 06:26:54 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Jan 2015 15:26:54 +0100 Message-ID: From: Igor Bukanov To: Chris Hartmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: websec Subject: Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 14:27:00 -0000 On 13 January 2015 at 21:30, Chris Hartmann wrote: > Presumably your credentials > to okta.com are a risk to the company if compromised. If a phisher > sent you an email claiming to be okta.com with a link to a fake but > believable hostname, say otka.com (see what I did there), you happen > to click the link and are on the verge of providing your credentials, > you are now in a situation where your perception of the hostname is > the only indication to spark your skepticism and avoid compromise. SRP [1] and J-Pake [2] protocols solved that problem long time ago - the idea is that one use a password not only to authenticate self to a host but also to verify that the host does know your password without reveling the password to the host. Unfortunately the browser support is lacking, so one needs a browser extension to support that. [1] - http://srp.stanford.edu/ [2] - http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling From nobody Mon Jan 19 09:56:13 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A55A1B2B2C for ; Mon, 19 Jan 2015 09:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byruQZKj_3YO for ; Mon, 19 Jan 2015 09:56:00 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67BAC1ACDB2 for ; Mon, 19 Jan 2015 09:56:00 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so12120611igb.3 for ; Mon, 19 Jan 2015 09:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:from:date:message-id:subject:to:content-type; bh=ObBLKzeX7FHblZZMjhzRarigjmcoU8NxzNG8AWaVFDM=; b=4tYoLUqmcAEQVEy7UzhGC4+62bi2EI69ReCe2LTzQfEL244t/BtDs+mkg1kZmgeINo lzSbW22dlG1yP5EfIw9YsxyorwqY5Y30VWS/nG1BynKU6SZ59EP023oY4bLdonj0nANU HnWTHJ0w3mFtLBfDdDf/1XvoYGSqgVrIYBhgM= 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=ObBLKzeX7FHblZZMjhzRarigjmcoU8NxzNG8AWaVFDM=; b=ftabosZEoOkqsLPnp84b24TdWiDmkUDHnIhETdERdcKXp0A4MfF2e0l4RVVOn+66gc h8YFoCnn3xYh86NjszeSmYJ7BfwuWE4ob7zakpJEJRthb1XFFNh28PerrRNutPuq0jiD 6ordKfP9L4c7Zcmq5WejgTY1XHOKgNA6wpsEEhvarmcvGegANoV5AtrvMNz471lPHjsY b7bGyIG/4L+q8NzTOtUAGMscUtEDAIGjhqYt8ZalBWTPHnTiUK9QTlus7NdeyTsrsNQP XonN/mmyz7KstlWcsQnh8m7dZtZFd9cSEKTnfrnM2Wox1q9juXsIhkNW7qm/1n+kCR8v rxpA== X-Gm-Message-State: ALoCoQk/jQ1AlIGP1SK7RyoQGKvEIIAMfzdDwLxrE/D3Ygs/q9KAm023ECtqdqMsy30VPEyuBBGl X-Received: by 10.50.43.229 with SMTP id z5mr20569560igl.19.1421690159414; Mon, 19 Jan 2015 09:55:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.136.209 with HTTP; Mon, 19 Jan 2015 09:55:39 -0800 (PST) From: Tom Ritter Date: Mon, 19 Jan 2015 11:55:39 -0600 Message-ID: To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Subject: [websec] Requiring OCSP Stapling as a directive in HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jan 2015 17:56:04 -0000 Hi all. I'd like to propose an idea: add an optional directive to the HSTS header that, when included, mandates any certificate received for a domain require OCSP Stapling. It would respect includeSubdomains and max-age. The threat model I'm trying to address is an attacker who can get a valid certificate misissued for a domain. Because of the revocation situation, the attacker can then MITM users with impunity, blocking revocation lookups if they occur. While UAs would receive a crlset or other push of revoked certificates, I believe that the UA will still work if that connection is blocked, and it's not clear how long that connection must be blocked before the UA stops working entirely. (If that happens at all.) Counting from the detection of the attack (which efforts like CT and Pinning help detect), requiring OCSP stapling changes the window of attack from {forever?, 30 days?, an unknown value?} to the OCSP staple's lifetime. (Assuming the attacker gets a OCSP signature right before revocation.) Why OCSP stapling and not require the UA to instead use 'hard-fail' revocation checking? Well, CRLs have all sorts of drawbacks: longer expiry times, large sizes, and they're pretty much being phased out everywhere. (I know about Delta-CRLs - developing a specification for them, implementing, and deploying them will take years, if ever, due to IPR stuff. This does not.) What about requiring OCSP querying? Browsers don't much care for that - it's slow, can timeout for non-security reasons, it's out of the control of the web site owner. That leaves us with OCSP Stapling - it's fast, implemented, deployed. While I'm not opposed to making the language say "Hard Fail Revocation Checking" I would expect UAs to interpret that as OCSP stapling, and would not want to delay implementation to account for unlikely-used corner cases. And if we say OCSP Stapling, there's no reason that down the road we could add a new directive for 'hard-fail-revocation' and let it encompass many different checks. As far as 'Where?' and why 'In HSTS'? I see four options: a HTTP Header, a TLS Extension, a DNSSEC record, and a Certificate Extension. Certificate Extension is being worked on (https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/) but I see it as a compliment to this. The certificate extension only dictates policy for this certificate. If we assume an attacker can get a misissued certificate for a domain, the cert extension is only useful when it is the default issuing status and an attacker must have additional privledges to circumvent it. And it doesn't make sense to have a certificate extension dictate policy for a whole domain, that's a very strange location to put this sort of data. A DNSSEC record has deployment problems, we can't retrieve it reliably. Fallback or soft-fail provides no security and is useless here. A TLS Extension makes a certain amount of sense. We're trying to dictate a policy for TLS connections, not HTTP. But it's more difficult to deploy TLS Extensions than HTTP headers, the TLS working group is tremendously busy, and technically this would fit more with the closed PKIX group. That leaves us with a HTTP Header. I think it makes more sense to put this as a directive on HSTS rather than making a new header. While I could imagine situations where one would want to require revocation checking (or pinning for example) without requiring TLS, I don't see it as a huge use case. Rather, putting it in HSTS is a small incremental upgrade that avoids redefining all the other stuff. Should the UA require a staple for all certs in the chain (Intermediates included) or just the leaf? I'm not religious about one or the other, I'd probably lean towards requiring all but I'd need to review the implementation and deployment status of multi-stapling. Just requiring the leaf is simpler from a deployment perspective I believe, and compromised intermediates cause immediate browser pushes anyway. Would there be support for this draft? -tom From nobody Mon Jan 19 11:17:21 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B9B1B2BF3 for ; Mon, 19 Jan 2015 11:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SAguwwfft5W for ; Mon, 19 Jan 2015 11:17:14 -0800 (PST) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A214A1B2BCB for ; Mon, 19 Jan 2015 11:17:14 -0800 (PST) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 5B5AA2005D822; Mon, 19 Jan 2015 11:17:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=vXwc4aQv6fmJRKaknjSZtReha6c=; b=dn2znulhTw0sG+fbz DTyNLyWglwMvaU8QzKC0PD+1yfm4qpiTnCbnuzPILWf04Dn6126mx7I8iGYqWsaT guCucvPB9vBP105ODeUXSXO0HKc274APgC898HErZM+RNWCpPY10WjgWHtF/LHxl i8Geoa6xoOGrJIUuhBE/JynFmo= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPA id EDDD72005D819; Mon, 19 Jan 2015 11:17:12 -0800 (PST) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Mon, 19 Jan 2015 11:17:14 -0800 Message-ID: <5be01b4b5decf27483668311b88520c9.squirrel@webmail.dreamhost.com> In-Reply-To: References: Date: Mon, 19 Jan 2015 11:17:14 -0800 From: "Ryan Sleevi" To: "Tom Ritter" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] Requiring OCSP Stapling as a directive in HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 19:17:16 -0000 On Mon, January 19, 2015 9:55 am, Tom Ritter wrote: > The threat model I'm trying to address is an attacker who can get a > valid certificate misissued for a domain. Because of the revocation > situation, the attacker can then MITM users with impunity, blocking > revocation lookups if they occur. While UAs would receive a crlset or > other push of revoked certificates, I believe that the UA will still > work if that connection is blocked, and it's not clear how long that > connection must be blocked before the UA stops working entirely. (If > that happens at all.) In this threat model, where does NTP fit? It seems like you're assuming the attacker can intercept both the target site and the UA's distribution mechanisms, so I would presume that they're also privileged enough to mount NTP attacks? > While I'm not opposed to making the language say "Hard Fail Revocation > Checking" I would expect UAs to interpret that as OCSP stapling, and > would not want to delay implementation to account for unlikely-used > corner cases. And if we say OCSP Stapling, there's no reason that > down the road we could add a new directive for 'hard-fail-revocation' > and let it encompass many different checks. To make sure this is clear: You're suggesting hard-fail OCSP checking whe= n the OCSP directive is present in the header (always), and you're just quibbling over the naming of that directive here, right? I'm just making sure, since soft-fail OCSP stapling doesn't seem to make = a lot of sense? > As far as 'Where?' and why 'In HSTS'? I see four options: a HTTP > Header, a TLS Extension, a DNSSEC record, and a Certificate Extension. You missed a fifth. A .well-known URI (RFC 5785) used to configure security-policy at the domain level. I don't suggest this as something that the browser would background fetch (although certainly, it could be induced so coupled with a header). Moreso, I'm suggesting that this be used to build such preload lists of security policy so that they can be distributed. The failure mode of a bad HSTS header is not too bad - you're stuck on TLS. If accidentally set / by an attacker / things really hit the fan, yo= u could stick one of the many CDNs in front of your site to handle the TLS to your unencrypted backend. The failure mode of a bad HPKP header is decidedly worse - total site denial if you do key rotation / change CAs. Preloading is one way to mitigate this (by providing some consistent view of effective policy), although even that can be botched (e.g. CryptoCat recently rotated CAs an= d thus committed pinning suicide, at least until Chrome 41). The security considerations of hostile pinning alone accounted for quite a bit of discussion. OCSP stapling I think falls somewhere in the middle here on the risk proposition - there's still a vast, depressing majority of server softwar= e that doesn't support OCSP stapling. What are the implications for server admins who botch it themselves or who are attacked? I'm much more concerned by the former, see it much more likely, and think it's much mor= e likely to result in self-inflicted DOS. For example, configuring ngingx t= o serve an OCSP response, but then forgetting to setup the cron job to rotate it =3D site inaccessible once the response expires (presuming hard fail, which I think is the sensible path) The advantage (or disadvantage, depending on your POV) of a .well-known URI + preloading allows some degree of curation of policy for sanity, which can't be expressed by a point-in-time snapshot of headers (at least for HPKP and for this hypothetical OCSP must staple) > > Certificate Extension is being worked on > (https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/) but I > see it as a compliment to this. The certificate extension only > dictates policy for this certificate. If we assume an attacker can > get a misissued certificate for a domain, the cert extension is only > useful when it is the default issuing status and an attacker must have > additional privledges to circumvent it. And it doesn't make sense to > have a certificate extension dictate policy for a whole domain, that's > a very strange location to put this sort of data. To be fair, the certificate extension is dictating policy for the certificate. You're absolutely correct, however, that misissuance without including that extension is undetectable from CA rollover. > A TLS Extension makes a certain amount of sense. We're trying to > dictate a policy for TLS connections, not HTTP. But it's more > difficult to deploy TLS Extensions than HTTP headers, the TLS working > group is tremendously busy, and technically this would fit more with > the closed PKIX group. Doesn't this suffer many of the attendant issues you raised with a certificate extension? Namely, that the MITM attacker who has obtained a fraudulent cert (since that would be the only reason I can think of to worry about OCSP stapling) would just not send the extension. Or are you implying that the extension would/should have a persistence la= yer? > That leaves us with a HTTP Header. I think it makes more sense to put > this as a directive on HSTS rather than making a new header. While I > could imagine situations where one would want to require revocation > checking (or pinning for example) without requiring TLS, I don't see > it as a huge use case. Rather, putting it in HSTS is a small > incremental upgrade that avoids redefining all the other stuff. I'm not sure this makes sense. You highlight early on the desire to make includeSubDomains and max-age behave the same, but I can also think of reasons why you would want them separable. > Should the UA require a staple for all certs in the chain > (Intermediates included) or just the leaf? I'm not religious about > one or the other, I'd probably lean towards requiring all but I'd need > to review the implementation and deployment status of multi-stapling. > Just requiring the leaf is simpler from a deployment perspective I > believe, and compromised intermediates cause immediate browser pushes > anyway. Only the leaf. Sending the intermediates is (generally) wasteful and redundant for the connection warm-up, and any intermediate misissuance (which, we should hope, is rare) is already a browser-level event. I note this is also consistent with Mozilla's past statements on revocation ( https://wiki.mozilla.org/CA:RevocationPlan ) - where intermediate revocations are managed by the browser and leaf certs are left for stapling. > Would there be support for this draft? > > -tom How does this proposal fit into a world where UAs might begin to _always_ require OCSP stapling? Perhaps only for some certs, at first, but say in = 5 years, would this be as relevant? https://groups.google.com/a/chromium.org/d/msg/security-dev/jmbbIgmGbdk/x= U8pR8fxYOYJ From nobody Mon Jan 19 16:58:23 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571A31A90D9 for ; Mon, 19 Jan 2015 16:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v6d191d6n7I for ; Mon, 19 Jan 2015 16:58:20 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58871B2C5A for ; Mon, 19 Jan 2015 16:58:18 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id tr6so4760715ieb.4 for ; Mon, 19 Jan 2015 16:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=u/kMZxuG8KTJSOxOGkrOv9CdP+8nUC4G+pLhjiz5SAQ=; b=uujPFRQzw+L9incv2PkWSuS4K4pHERc6Vyd2rTYWYa1kl6msJD9pOYf1kUZWwFTsyj rWYVqcFb8nB2omBS2kIVtJGEnmuOuEvMjTbPaXXNJw+i8M81ofX90mXz/C6isJRWlYqu Uy/dC25dQIXdZGddxCRVeTAWrlrSPJZwGv/Qk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=u/kMZxuG8KTJSOxOGkrOv9CdP+8nUC4G+pLhjiz5SAQ=; b=dG1oc5ZobNHQLq/0AOx65/ixKtCYGlF9HQw1l4KpNSOLNXMNS+tN30148PAiPK0VD6 P1F4soUrGuZY6iqLkPS9s3kvm2KoEdy9IK4ykDdFitRzDxhZp9IbO+ll06i0TuMFz3JZ jJ+Xujq5YT2PZHNzuh24TTIr2OYYhzOKUN6osDBYkhcGiKSQ5YCzUaiSnDCh6HjRKy5a 4kszj5CA9WpUU2E8RNJjMjp/GQkFr4YxEGU8IJIKvEdDUvJGa0A1q2hv6r4xNhWNDPgU /hsv5hsjUvyacuLpHv8zAbT31+P7co+KBEmQ8ZgPhjAT5rCE69scnx6JghbVKA18DKvH XKqg== X-Gm-Message-State: ALoCoQkN6fRBfJat8SY1zWC0jL6XvYI23fJhDfo0tfXsskibQWiQHuhDYnHhv8JJOGwRDHNysqE4 X-Received: by 10.42.12.147 with SMTP id y19mr31091294icy.80.1421715497881; Mon, 19 Jan 2015 16:58:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.136.209 with HTTP; Mon, 19 Jan 2015 16:57:57 -0800 (PST) In-Reply-To: <5be01b4b5decf27483668311b88520c9.squirrel@webmail.dreamhost.com> References: <5be01b4b5decf27483668311b88520c9.squirrel@webmail.dreamhost.com> From: Tom Ritter Date: Mon, 19 Jan 2015 18:57:57 -0600 Message-ID: To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] Requiring OCSP Stapling as a directive in HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jan 2015 00:58:22 -0000 On 19 January 2015 at 13:17, Ryan Sleevi wrote: > On Mon, January 19, 2015 9:55 am, Tom Ritter wrote: >> The threat model I'm trying to address is an attacker who can get a >> valid certificate misissued for a domain. Because of the revocation >> situation, the attacker can then MITM users with impunity, blocking >> revocation lookups if they occur. While UAs would receive a crlset or >> other push of revoked certificates, I believe that the UA will still >> work if that connection is blocked, and it's not clear how long that >> connection must be blocked before the UA stops working entirely. (If >> that happens at all.) > > In this threat model, where does NTP fit? It seems like you're assuming > the attacker can intercept both the target site and the UA's distribution > mechanisms, so I would presume that they're also privileged enough to > mount NTP attacks? That's true. It would be broken by NTP and an attacker attaching an older OCSP staple. (Similarly, an attacker could use an old staple and a previously compromised certificate, one since expired.) The best proposal I've heard for fixing NTP was using TLS (either in the protocol or an HTTP Date header) for broad resolution plus NTP for fine-grained skew. I'd love to see OSes and/or UAs adopt it. >> While I'm not opposed to making the language say "Hard Fail Revocation >> Checking" I would expect UAs to interpret that as OCSP stapling, and >> would not want to delay implementation to account for unlikely-used >> corner cases. And if we say OCSP Stapling, there's no reason that >> down the road we could add a new directive for 'hard-fail-revocation' >> and let it encompass many different checks. > > To make sure this is clear: You're suggesting hard-fail OCSP checking when > the OCSP directive is present in the header (always), and you're just > quibbling over the naming of that directive here, right? > > I'm just making sure, since soft-fail OCSP stapling doesn't seem to make a > lot of sense? I'm definitely not proposing soft-fail anything. I was dancing around options for what the directive would mean, trying not to be too religious about it: a) Call it "Require OCSP Stapling" b) Call it "Require Hard Fail Revocation Checking" and UAs really implement it as requiring a Staple c) Call it "Require Hard Fail Revocation Checking" and UAs implement it as requiring a CRL, Staple, or Successful OCSP query I like (a), followed by (b), and least of all (c). I think (c) is the most work and is going backwards from what UAs seem to want - so least likely to be implemented. >> As far as 'Where?' and why 'In HSTS'? I see four options: a HTTP >> Header, a TLS Extension, a DNSSEC record, and a Certificate Extension. > > You missed a fifth. > > A .well-known URI (RFC 5785) used to configure security-policy at the > domain level. > > I don't suggest this as something that the browser would background fetch > (although certainly, it could be induced so coupled with a header). I'm not sure I understand: there's a .well-known URL that says "Must Staple" _and_ a header? > Moreso, I'm suggesting that this be used to build such preload lists of > security policy so that they can be distributed. I'm not sure I understand you entirely, but if you're suggesting that the crawl + browser preload is the mechanism by which this is deployed, I'm kind of 'meh' on that. It relies on a site operator inducing a company to crawl their site and bake the policy into the software somehow. It feels like taking something that's two-party (site operator and user agent) and making it three (adding user agent infrastructure and crawling robots). > The failure mode of a bad HSTS header is not too bad - you're stuck on > TLS. If accidentally set / by an attacker / things really hit the fan, you > could stick one of the many CDNs in front of your site to handle the TLS > to your unencrypted backend. > > The failure mode of a bad HPKP header is decidedly worse - total site > denial if you do key rotation / change CAs. Preloading is one way to > mitigate this (by providing some consistent view of effective policy), > although even that can be botched (e.g. CryptoCat recently rotated CAs and > thus committed pinning suicide, at least until Chrome 41). The security > considerations of hostile pinning alone accounted for quite a bit of > discussion. > > OCSP stapling I think falls somewhere in the middle here on the risk > proposition - there's still a vast, depressing majority of server software > that doesn't support OCSP stapling. What are the implications for server > admins who botch it themselves or who are attacked? I'm much more > concerned by the former, see it much more likely, and think it's much more > likely to result in self-inflicted DOS. For example, configuring ngingx to > serve an OCSP response, but then forgetting to setup the cron job to > rotate it = site inaccessible once the response expires (presuming hard > fail, which I think is the sensible path) DoS is definitely something to be addressed in a section. I agree it's between HSTS and HPKP, but it feels like it's not a huge bump above HSTS. We would definitely want to mandate that the directive not be noted unless it was received over a connection that had an OCSP staple, similar to how HSTS or HPKP are noted. The 'worst case scenario' of getting it set and you can't support it is pretty similar to the worst case scenario of HSTS. You have to stick some sort of proxy or CDN in front of your site. If your site already handles HTTPS (e.g. no infinite redirects HTTP->HTTPS->HTTP->...) then it's even easier as you can terminate your TLS connection from your webservers and re-encrypt with your OCSP-providing proxy. > The advantage (or disadvantage, depending on your POV) of a .well-known > URI + preloading allows some degree of curation of policy for sanity, > which can't be expressed by a point-in-time snapshot of headers (at least > for HPKP and for this hypothetical OCSP must staple) It does, but only because you've moved the complexity from the User Agent to the crawler. One example of the complexity would be Trevor Perrin's ideas for TACK/HPKP where you first note it for X amount of time, and then if you see it again you note it for X*2, and so on. Another could be human-curation. >> A TLS Extension makes a certain amount of sense. We're trying to >> dictate a policy for TLS connections, not HTTP. But it's more >> difficult to deploy TLS Extensions than HTTP headers, the TLS working >> group is tremendously busy, and technically this would fit more with >> the closed PKIX group. > > Doesn't this suffer many of the attendant issues you raised with a > certificate extension? Namely, that the MITM attacker who has obtained a > fraudulent cert (since that would be the only reason I can think of to > worry about OCSP stapling) would just not send the extension. > > Or are you implying that the extension would/should have a persistence layer? Yes, it would only work if the TLS extension had a persistence layer. Which is awkward in TLS. >> That leaves us with a HTTP Header. I think it makes more sense to put >> this as a directive on HSTS rather than making a new header. While I >> could imagine situations where one would want to require revocation >> checking (or pinning for example) without requiring TLS, I don't see >> it as a huge use case. Rather, putting it in HSTS is a small >> incremental upgrade that avoids redefining all the other stuff. > > I'm not sure this makes sense. You highlight early on the desire to make > includeSubDomains and max-age behave the same, but I can also think of > reasons why you would want them separable. Yes, certainly. You may only want OCSP Stapling on for a hour while you test it out, you can't deploy it across all subdomains, etc. The most amount of flexibility would be to make it it's own header (or .well-known). HTTP 2.0's header compression may mean we don't care that much. I don't have a strong preference, I was trying to strike a middle ground. >> Should the UA require a staple for all certs in the chain >> (Intermediates included) or just the leaf? > > Only the leaf. Sure >> Would there be support for this draft? > > How does this proposal fit into a world where UAs might begin to _always_ > require OCSP stapling? Perhaps only for some certs, at first, but say in 5 > years, would this be as relevant? > > https://groups.google.com/a/chromium.org/d/msg/security-dev/jmbbIgmGbdk/xU8pR8fxYOYJ Well no, if UAs require OCSP Stapling for every site they visit it's not relevant at all. But I think 5 years is an impressively aggressive timeframe for getting to the point of throwing up a interstitial for lacking a staple across the whole internet. I recognise it's not just my work that would be made redundant, it would be many's, but still I would be happy to have it made redundant if in 4 years all popular UAs actually achieved that goal. It seems doubtful though, so I'm not willing to bank on it. -tom From nobody Mon Jan 19 17:22:56 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020DD1A8AB7 for ; Mon, 19 Jan 2015 17:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_BACKHAIR_33=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYre7G9r_zfR for ; Mon, 19 Jan 2015 17:22:51 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5752A1A8A05 for ; Mon, 19 Jan 2015 17:22:51 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id wp18so10602253obc.3 for ; Mon, 19 Jan 2015 17:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FgjVkrmJa0XXEvwOeXFqWr2/fV3HHngCox1gixifJag=; b=00ZPetqHm6z93rgAh5ud79sbJoBbO2DWfNBhnhDsw+5wy7PABU/v0VY4rBN3rNNNRc VtYeGKuXCGfnlXuLg2uWPtX/ahL0Fch8zBKnLmvUqVTdGGXz258v57cWgB1HIlfM7l/3 WAiTTKsGWGenoiYK/Hx1yt2FHV8LRQ9+t/gKVcdd6VJ1QQLUiOOTtzk4bDiEqSMdXNpz DUS97xJyt8CAPv+k5+PuXjdbi65PfSgmi/MigflqbagYKZft6ilf6PkaHzV3W7d2wfPF ZDLAwgMrUXM1K/fa5BTW4QZznOq8wXrkueRtVFOgW3VfBmM4WIPwuHwKv9rM+pwrCWtf a48Q== MIME-Version: 1.0 X-Received: by 10.202.225.214 with SMTP id y205mr19237879oig.60.1421716970548; Mon, 19 Jan 2015 17:22:50 -0800 (PST) Received: by 10.202.45.78 with HTTP; Mon, 19 Jan 2015 17:22:50 -0800 (PST) In-Reply-To: <54B65E34.2050909@gondrom.org> References: <54B65E34.2050909@gondrom.org> Date: Mon, 19 Jan 2015 17:22:50 -0800 Message-ID: From: Chris Hartmann To: Tobias Gondrom Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: websec Subject: Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jan 2015 01:22:53 -0000 Thanks Jeff, Tobias. Yes, dbound does seem to resonate pretty well with where I was going here. Ironic and fortunate to catch it now while it's still crystalizing. Although I believe there is room to contemplate extending the concept beyond pure DNS namespace relationships (I'd like to see URI<->URI), some of the core problems/principals seem to be the same, great. Chris On Wed, Jan 14, 2015 at 4:16 AM, Tobias Gondrom wrote: > Hi Chris, hi all, > > let me say, I can see a missing link here which would be nice to solve. > > Btw. another example coming to mind would be the connection with external > payment services or increasing number of references to cloud based servic= es > (where it is not sure that a.com is indeed using b.com). > E.g. e-commerce sites linking to paypal or Mastercard / Visa vericode (or > whatever they call it) directly out of the e-commerce site... > > Some improvement in the trust chain could indeed be valuable here. > > Having said that, if another WG is already working in this area - Jeff > mentioned dbound - then my recommendation would be to take the work there= . > WEBSEC is about to be closed, we are only waiting for the final release o= f > our last document. > > Best regards, Tobias > > > > > > On 14/01/15 00:44, Jeffrey Walton wrote: >>> >>> Is this a security problem? I think so. >> >> Yes. Knowing the relationship would be helpful in a security context. >> >>> I have a few ideas on how this could be improved/implemented. >> >> Dbound is poking and prodding at related issues. And they are >> finalizing their charter now. You might consider reading some of the >> recent posts and commenting. >> >> https://www.ietf.org/mailman/listinfo/dbound. >> >> Jeff >> >> On Mon, Jan 12, 2015 at 2:18 PM, Chris Hartmann >> wrote: >>> >>> 1) Bob trusts and does personal business with a.com. >>> >>> 2) a.com forms a business relationship with b.com to perform a >>> business function on its behalf (payment processor, blog, whatever). >>> The landing page is b.com/a >>> >>> 3) Bob visits b.com/a and notices that the page claims to be >>> affiliated and owned by a.com >>> >>> 4) How can Bob, in absolute terms, trust that b.com/a is affiliated >>> and a delegated service by a.com? (say, prior to submitting sensitive >>> information) >>> >>> Is this a security problem? I think so. >>> >>> We=E2=80=99ve all had to make this decision one time or another on weak >>> inferences and correlations. I=E2=80=99d imagine Phishers don=E2=80=99t= mind at all >>> that there is an inability for the common internet user (looking at >>> you grandma) to make the judgement call on web service affiliations. >>> They=E2=80=99ve been conditioned with the best practice of looking at t= he >>> address bar (and perhaps the DNS namespace) along with the lock icon >>> to indicate trustworthiness, which may actually help the attacker in >>> their act of misdirection. Inter-domain relationships model business >>> relationships and trust. If web users could be armed with a new >>> =E2=80=9Csense=E2=80=9D which proves these legitimate relationships (sa= y >>> cryptographically) then perhaps they would have more reason to be >>> skeptical of those who cannot prove their affiliation. I=E2=80=99m not = saying >>> we can take human judgement completely out of the equation, but why >>> not have a tool to help anchor this commonly needed and risky >>> correlation. >>> >>> Eg: >>> >>> 5) https://c.com/a is a bad guy and claims the same thing as b.com/a . >>> Now who to trust becomes a research project. (But c.com has the https >>> lock icon, doesn=E2=80=99t that count for anything: NO) >>> >>> >>> Use case a) Tim submits a payment to a redcross.org Paypal donation >>> page he found via his favorite search engine. It was a scam. (We can >>> argue a violation of "best practices" here, but that is besides the >>> point) >>> >>> >>> I suppose phishing isn=E2=80=99t the only example. It could apply to an= y case >>> where you want to logically group the identity of one entity across >>> many domain boundaries owned by different parties. (eg. A popular band >>> has many web points of presence for fans, etc). This same mechanism >>> could =E2=80=9Ccertify=E2=80=9D that these web assets are under one umb= rella, although >>> they don=E2=80=99t exist under one domain hierarchy. >>> >>> Should we solve this? Is it solved already? Could use help gelling or >>> junking this idea. >>> >>> I have a few ideas on how this could be improved/implemented. >>> >>> Cheers, >>> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec > > From nobody Mon Jan 19 17:30:43 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E7A1A898E for ; Mon, 19 Jan 2015 17:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.665 X-Spam-Level: X-Spam-Status: No, score=-95.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_BACKHAIR_33=1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXl-ZvEjGJhc for ; Mon, 19 Jan 2015 17:30:40 -0800 (PST) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E2BC1A8859 for ; Mon, 19 Jan 2015 17:30:40 -0800 (PST) Received: from [163.119.49.31] (unknown [163.119.49.31]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 029CE631BC; Tue, 20 Jan 2015 02:30:35 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=qMB8a9BL3JGOTzRDEuP/x+Jrc6ZumO5eq+35FNfL/KJfNAi3zhDTQ95AlakWOuw74lZ5Z99p7xpk2zzudMStBgevUGakQpcYNcNK2G1ujLJmAoYHxCtPplCQP6PYHECZn3zfwFzNYlEu2VUpw0CeFMB+3AC0hKWdFLoLRZr2VAk=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Message-ID: <54BDAFBB.50400@gondrom.org> Date: Tue, 20 Jan 2015 01:30:35 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: cxhartmann@gmail.com References: <54B65E34.2050909@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: websec@ietf.org Subject: Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jan 2015 01:30:42 -0000 Hi Chris, good to hear. And just to add: even without websec, if you think something that goes beyond DNS namespace relationships or the scope of the other WG is needed, at the IETF there is also the possibility for individual submissions. Downside with individual drafts is, it is much harder to get good community review and assemble a team working on the draft. But this option is available. All the best, Tobias On 20/01/15 01:22, Chris Hartmann wrote: > Thanks Jeff, Tobias. > > Yes, dbound does seem to resonate pretty well with where I was going > here. Ironic and fortunate to catch it now while it's still > crystalizing. Although I believe there is room to contemplate > extending the concept beyond pure DNS namespace relationships (I'd > like to see URI<->URI), some of the core problems/principals seem to > be the same, great. > > Chris > > On Wed, Jan 14, 2015 at 4:16 AM, Tobias Gondrom > wrote: >> Hi Chris, hi all, >> >> let me say, I can see a missing link here which would be nice to solve. >> >> Btw. another example coming to mind would be the connection with external >> payment services or increasing number of references to cloud based services >> (where it is not sure that a.com is indeed using b.com). >> E.g. e-commerce sites linking to paypal or Mastercard / Visa vericode (or >> whatever they call it) directly out of the e-commerce site... >> >> Some improvement in the trust chain could indeed be valuable here. >> >> Having said that, if another WG is already working in this area - Jeff >> mentioned dbound - then my recommendation would be to take the work there. >> WEBSEC is about to be closed, we are only waiting for the final release of >> our last document. >> >> Best regards, Tobias >> >> >> >> >> >> On 14/01/15 00:44, Jeffrey Walton wrote: >>>> Is this a security problem? I think so. >>> Yes. Knowing the relationship would be helpful in a security context. >>> >>>> I have a few ideas on how this could be improved/implemented. >>> Dbound is poking and prodding at related issues. And they are >>> finalizing their charter now. You might consider reading some of the >>> recent posts and commenting. >>> >>> https://www.ietf.org/mailman/listinfo/dbound. >>> >>> Jeff >>> >>> On Mon, Jan 12, 2015 at 2:18 PM, Chris Hartmann >>> wrote: >>>> 1) Bob trusts and does personal business with a.com. >>>> >>>> 2) a.com forms a business relationship with b.com to perform a >>>> business function on its behalf (payment processor, blog, whatever). >>>> The landing page is b.com/a >>>> >>>> 3) Bob visits b.com/a and notices that the page claims to be >>>> affiliated and owned by a.com >>>> >>>> 4) How can Bob, in absolute terms, trust that b.com/a is affiliated >>>> and a delegated service by a.com? (say, prior to submitting sensitive >>>> information) >>>> >>>> Is this a security problem? I think so. >>>> >>>> We’ve all had to make this decision one time or another on weak >>>> inferences and correlations. I’d imagine Phishers don’t mind at all >>>> that there is an inability for the common internet user (looking at >>>> you grandma) to make the judgement call on web service affiliations. >>>> They’ve been conditioned with the best practice of looking at the >>>> address bar (and perhaps the DNS namespace) along with the lock icon >>>> to indicate trustworthiness, which may actually help the attacker in >>>> their act of misdirection. Inter-domain relationships model business >>>> relationships and trust. If web users could be armed with a new >>>> “sense” which proves these legitimate relationships (say >>>> cryptographically) then perhaps they would have more reason to be >>>> skeptical of those who cannot prove their affiliation. I’m not saying >>>> we can take human judgement completely out of the equation, but why >>>> not have a tool to help anchor this commonly needed and risky >>>> correlation. >>>> >>>> Eg: >>>> >>>> 5) https://c.com/a is a bad guy and claims the same thing as b.com/a . >>>> Now who to trust becomes a research project. (But c.com has the https >>>> lock icon, doesn’t that count for anything: NO) >>>> >>>> >>>> Use case a) Tim submits a payment to a redcross.org Paypal donation >>>> page he found via his favorite search engine. It was a scam. (We can >>>> argue a violation of "best practices" here, but that is besides the >>>> point) >>>> >>>> >>>> I suppose phishing isn’t the only example. It could apply to any case >>>> where you want to logically group the identity of one entity across >>>> many domain boundaries owned by different parties. (eg. A popular band >>>> has many web points of presence for fans, etc). This same mechanism >>>> could “certify” that these web assets are under one umbrella, although >>>> they don’t exist under one domain hierarchy. >>>> >>>> Should we solve this? Is it solved already? Could use help gelling or >>>> junking this idea. >>>> >>>> I have a few ideas on how this could be improved/implemented. >>>> >>>> Cheers, >>>> >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >>