From nobody Fri Oct 13 07:17:36 2017 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F427120720; Fri, 13 Oct 2017 07:17:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trans@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150790425440.23830.13375991525677457495@ietfa.amsl.com> Date: Fri, 13 Oct 2017 07:17:34 -0700 Archived-At: Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-12.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 14:17:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency WG of the IETF. Title : Attack and Threat Model for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-12.txt Pages : 30 Date : 2017-10-13 Abstract: This document describes an attack model and discusses threats for the Web PKI context in which security mechanisms to detect mis-issuance of web site certificates are being developed. The model provides an analysis of detection and remediation mechanisms for both syntactic and semantic mis-issuance. The model introduces an outline of attacks to organize the discussion. The model also describes the roles played by the elements of the Certificate Transparency (CT) system, to establish a context for the model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-12 https://datatracker.ietf.org/doc/html/draft-ietf-trans-threat-analysis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-threat-analysis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 13 18:36:17 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD2C133158 for ; Fri, 13 Oct 2017 18:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EMsArrt8o2XE for ; Fri, 13 Oct 2017 18:36:14 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 3BF461332D4 for ; Fri, 13 Oct 2017 18:36:14 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id s75so1652427pgs.0 for ; Fri, 13 Oct 2017 18:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to; bh=4xL2kcy7TFNs2CQCO69EvNmTaZh6ELMjnDrYPR5MPtc=; b=WrFrL+JeJsCAXEC5MjLg2f2ALRqhNHBBbQOeVbNKG6AEpAtAFVFajS0hZxZU5vOgLo g/sqCnUzYZ2x2roG3ST92f15BpJGruwJZi4WlydNw0GXSMlat0EpKKay+28z3MvB+YFy N3gkunNAl15dceDGsbHzzRgGlvFji4lW4vMCA9pPc0QnWhllZgGGerK04xnfWAR5v3Fk Qcrj4U4+9VgLdJ37HdzXDaqxX+5yGxQxfR1SzFeCpaVKYlYQqEcns7DP8Y7AMKqsD5EM 5SHt4R0dyeIbUlJYP1EBkqLhMwnpHE1diAI65tl8LX0vEhbto/A1mMhxhCqv9GmNfasu 9aog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to; bh=4xL2kcy7TFNs2CQCO69EvNmTaZh6ELMjnDrYPR5MPtc=; b=MyTF6VVHxfAbWqqK6WtHNfZM02YA42kU2/HrxlyxzzVsaBz0wDjRKTrT9vWzgX+NWo PCm+S2NnQBSMSGtCrjovdNeP/rjG1IlNg+aROglUpcW062y2Yaj8XyECTn0Acu9lrqn3 r3+6IRhQouq7824J4jtmPvBn4kSweavsSddy9eE7w5kfZ5StzwzNa6bl18vk275l57UF iT155j1IUpHiUTOM6e1Xu58zr7Bg+HgsfUYLg6/O333bZvy41+W6rx1jk1+0FXMXV4n+ elZKB0H+JqsaGh/IF1aI2gt1ZplZl0vA+xkWE0i60xqjLXtXQpKOX2TFCtXYVTYr3ohy wQSA== X-Gm-Message-State: AMCzsaVcV9Qqa/lW+5yV02C6Qt7pvdx0c4TwNHLGDaaZU6hZ8/VA1Ng3 /E8UsI/VS/CLSAWnxjWXiwIGTIdS X-Google-Smtp-Source: AOwi7QBGELOfM7B2cmKuAUECt5fNyFaNlG9RhHJ/x5r6wqOoKHJwO4fr6yBNyyUnDtjktkqI2D9TRQ== X-Received: by 10.98.135.71 with SMTP id i68mr2882934pfe.79.1507944973315; Fri, 13 Oct 2017 18:36:13 -0700 (PDT) Received: from aspen.local (216-67-48-209-radius.dynamic.acsalaska.net. [216.67.48.209]) by smtp.gmail.com with ESMTPSA id h1sm4359581pgf.54.2017.10.13.18.36.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Oct 2017 18:36:12 -0700 (PDT) References: <150793243285.5131.14801510313772265693.idtracker@ietfa.amsl.com> To: "trans@ietf.org" From: Melinda Shore X-Forwarded-Message-Id: <150793243285.5131.14801510313772265693.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 13 Oct 2017 17:36:06 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <150793243285.5131.14801510313772265693.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AoO1vmp5q847kDWNg1XBfROdfMt2cnVtJ" Archived-At: Subject: [Trans] Fwd: IETF 100 Preliminary Agenda X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 01:36:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AoO1vmp5q847kDWNg1XBfROdfMt2cnVtJ Content-Type: multipart/mixed; boundary="9iAmODNCIAr7fC3djILSeBDfnmcP82Sgx"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: Subject: Fwd: IETF 100 Preliminary Agenda References: <150793243285.5131.14801510313772265693.idtracker@ietfa.amsl.com> In-Reply-To: <150793243285.5131.14801510313772265693.idtracker@ietfa.amsl.com> --9iAmODNCIAr7fC3djILSeBDfnmcP82Sgx Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, all: The preliminary agenda for IETF 100 has been posted. Note that it is subject to change, and could well do so. We are tentatively scheduled for Monday afternoon. Now is a very good time to be identifying issues that would benefit from face-to-face discussion and that will need time during the meeting. As always, things that have been discussed on the mailing list take priority over those that haven't when it comes to creating the meeting agenda. Please let Paul and me know if you're going to be requesting a session slot. Melinda -------- Forwarded Message -------- Subject: IETF 100 Preliminary Agenda Date: Fri, 13 Oct 2017 15:07:12 -0700 From: IETF Secretariat Reply-To: ietf@ietf.org, IETF Agenda To: IETF Announcement List CC: 100all@ietf.org, recentattendees@ietf.org, ietf@ietf.org IETF 100 Singapore November 11-17, 2017 Host: Cisco The IETF 100 Preliminary Agenda has been posted. The final agenda will be published on Friday, October 20, 2017. https://datatracker.ietf.org/meeting/100/agenda.html https://datatracker.ietf.org/meeting/100/agenda.txt IETF 100 Information: https://ietf.org/meeting/100/index.html Register online at: https://ietf.org/meeting/register.html Don=E2=80=99t forget to register for these exciting IETF 100 events! Social Event Date: Tuesday, 14 November 2017 Time: 19:00 - 22:00 Cost: $35 USD per ticket, limit two per attendee. Hosted by: Cisco Location: S.E.A. Aquarium, Resorts World Sentosa More information: https://www.ietf.org/meeting/100/social-event.html Link to purchase Social Tickets: https://www.ietf.org/registration/ietf100/eventticket.py Hackathon Signup: https://www.ietf.org/registration/ietf100/hackathonregistration.py More information: http://ietf.org/hackathon/100-hackathon.html Keep up to date by subscribing to: https://www.ietf.org/mailman/listinfo/hackathon Code Sprint Signup: https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF100SprintSignU= p More information: https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF100Sprint --9iAmODNCIAr7fC3djILSeBDfnmcP82Sgx-- --AoO1vmp5q847kDWNg1XBfROdfMt2cnVtJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ4WoHAAoJELiGRpM6HoEubK4QAIsFMAW0wgyIPyCY7yp3awRy Z62Ra0LdD/EIx7hg9KHW5XS+COYg8Gkvp0vzlTn4VeCRDDNVFugubcYS9hr1NPvz /z8d45EKmJq/TIyKX/Znv5cXqeooq4xKojPQvPq3jNCq+iVHjacq5nwU8nKuZXVn sQAtarAg0Hvo8XvTojKRJOa3T3v8VNVu1v3N5NxTQiQroEhbAGn97S7s/DBkAtTG 5GLN/0geaYfuYNoBGxAXiiH+fsHljDFw83769Wa+glftf0iV07dE6jCJaZUM1yIN X1JHYwvuaaOejbn8gR4gHIvti0O0oJI7pIe4tODFg8rt+Plb1/MytcifDNIzCK5q qX/8mjmEhMk7NHHknBd37Kgz1JONTapDRPKpgJZDMSsp7IHzM/ih1xonTJoJlz/g Cpg7vjrbbUqYG+8lmUX3SAiaJgm66sTJ1tcHHsxFbJrt7GWWV6X/ymG7gwZpXhw1 P3rPYrWTSqPwsJnUyg6tPgrQZFPxc+hEEldRvQkUl6U8xoYAM8FrPH3ZDlJmd+AN 2+2jWekEwG7mYx927BC49WYnr57mhTvVtnBN7myS/pg5cajFtajgExSnkBBU1KTg 2URX6Dh9D0t2RMCHs/2NKoUua58BY6xbgYa/9/crPDIfKfUQFdYiMoJMro0unJWz 21O0MAxjraeXVJdiHBM7 =Is83 -----END PGP SIGNATURE----- --AoO1vmp5q847kDWNg1XBfROdfMt2cnVtJ-- From nobody Sat Oct 14 17:04:23 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03AF120724 for ; Sat, 14 Oct 2017 17:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 88FMjGlN-T1o for ; Sat, 14 Oct 2017 17:04:19 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 B5223124239 for ; Sat, 14 Oct 2017 17:04:18 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id z28so23175832qtz.13 for ; Sat, 14 Oct 2017 17:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=XlWHkN/YP4EkjqZuRK0dkmcv9X8elDZpdqEFDvSOfnE=; b=YvCuNhOM2n75EAGjbqyy3PzSO6NJZM4eXBUeZa+rdjGAaTi8DJVStmtgYYH7GnlPuC t/xg04cGb8ZF8Fc0lHbOhkLAfE/2EANFsLUYKDKpALUBCZOTJFV9d3A3ZhbPW7r4zBoh /Ed4K+IUnlkep/CJXsejZCMbflO8Vl0Rwi8fG0qRNg6PycgRW3ddxJH/UJ9n+DVUjDTF 447MmxTqHXqJUMoBqjMWWOXv7Kt/a+xLcq9nLbW1Q/tBFjvfELmjjf1T0bS4WpzW2Fg9 t581o75pATdjR1vd7QeUj/F6nnhpXXR1PfCWfsfMPRZ5T/0hSSBmo8peli58dbysKFdq CAqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XlWHkN/YP4EkjqZuRK0dkmcv9X8elDZpdqEFDvSOfnE=; b=E3TP6P75E3O77yfcKS1ZbSspRR/C4ZmS5YQCjbhIWUEP6Ackpx30/jdtsrIV8dSmJV y1Q1QYpfuzY8IlMwJ22/jmMsi+HGTvtCPyhb4uMMlW+5Hms4nT/lq7yKHLvhDRqfbQWl IraOeE+/sAQqHxYasicX5sk7cfN7fMLXf7aDavovgIAGNp1+gDBWuaE6gsCerSik8CGn o48bptqA5Y09sJcII+XLPNXacsJ8SpWWdRbWlVTGe19lZTWGGi73EkL0KCuSUyAFoa+R mpnGfH14p7dYNnstR7lQGDer8MZPZEgnTMQJOTymCmZjwJ+mqP8U6bv4RGOVnLQ/R/h9 B2Ag== X-Gm-Message-State: AMCzsaV4hwmkXgx4WZ5V16vCYzhmyfBtBCiXFRpRxDhv5o16URmAO+Dr OFRdEDj2o+X4edtT3KVRwhdFwjFAntI7qxu/lp/HurKiWS8= X-Google-Smtp-Source: ABhQp+THoFkoaTlpfDOEYz8ifJLgsIqO3C0ShDLzwvyBpkyyYMWRaHIWIsnzA16FkuJi6OUeSgAXT2idiYRzKMkxDcY= X-Received: by 10.37.45.83 with SMTP id s19mr1404505ybe.400.1508025857586; Sat, 14 Oct 2017 17:04:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sat, 14 Oct 2017 17:03:36 -0700 (PDT) From: Eric Rescorla Date: Sat, 14 Oct 2017 17:03:36 -0700 Message-ID: To: trans@ietf.org, draft-ietf-trans-gossip@tools.ietf.org Content-Type: multipart/alternative; boundary="f4030435b0108dcf38055b8aa1e6" Archived-At: Subject: [Trans] AD Review: draft-ietf-trans-gossip-04 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2017 00:04:22 -0000 --f4030435b0108dcf38055b8aa1e6 Content-Type: text/plain; charset="UTF-8" I reviewed this document on Phabricator. A richer version of this review can be found at: https://mozphab-ietf.devsvcdev.mozaws.net/D14 I'm reviewing this draft against an Experimental standard. For the reasons indicated in this review, I do not believe that this actually represents a set of viable mechanisms for ensuring that CT is publicly verifiable. In addition, I have marked a number of places where I believe changes are required. *INLINE COMMENTS* View Inline draft-ietf-trans-gossip.txt:166 We want some side of the partitioned tree, and ideally both sides, to see the other side. Note: there can be any number of partitions. View Inline draft-ietf-trans-gossip.txt:169 Disseminating information about a log poses a potential threat to the privacy of end users. Some data of interest (e.g. SCTs) is linkable to specific log entries and thereby to specific websites, which makes , after e.g. View Inline draft-ietf-trans-gossip.txt:202 corresponding to the SCT. This is because the site's logs would already indicate that the client is accessing that site. In this way a site can accumulate records of SCTs that have been issued by This is not necessarily the case. Consider the situation where I contact a site from location A, retrieve an SCT, and then when I start my browser in location B, don't visit the site, but send the SCT. This links the two locations. You need to also restrict the delivery of SCT Feedback to organic connections to the site. The text doesn't seem to contemplate non-organic feedback but it doesn't prohibit it either. View Inline draft-ietf-trans-gossip.txt:271 | + SCT -> +----------+ | v | Cert [& SCT] +----------+ | Why not inclusion proofs and STHs. This seems permitted by 6962-bis. View Inline draft-ietf-trans-gossip.txt:364 remaining SCTs together with a locally constructed certificate chain which is trusted (i.e. terminated in a pre-loaded or locally installed Trust Anchor) in an sct_feedback object or equivalent data , after i.e.. View Inline draft-ietf-trans-gossip.txt:373 example.com.) They MUST NOT be sent to any Subject Alternate Names specified in the certificate. In the case of certificates that validate multiple domain names, the same SCT is expected to be stored IMPORTANT: I don't understand what this means from an HTTP perspective. What does "sent" refer to? SNI? Host: header? Suppose I have SCTs for a.example.com and I connect to b.example.com which presents a certificate with SANs for {a, b}.example.com. I would ordinarily be permitted to send requests to a.example.com per http://httpwg.org/specs/rfc7540.html#reuse. Is it permitted to send them that way here? View Inline draft-ietf-trans-gossip.txt:413 Gossip would be performed normally for third party domains only when the user revisits the first party domain. In lieu of 'double- Is this supposed to be the result of following the previous advice to double-key? View Inline draft-ietf-trans-gossip.txt:417 treats other security mechanisms that can enable tracking (such as HSTS and HPKP.) What is that manner? As far as I can tell, it's "do nothing special" View Inline draft-ietf-trans-gossip.txt:434 The data sent in the POST is defined in Section 8.1.1. This data SHOULD be sent in an already-established TLS session. This makes it hard for an attacker to disrupt SCT Feedback without also disturbing See above about the privacy implications of creating a new connection. View Inline draft-ietf-trans-gossip.txt:441 empty body if it was able to process the request. An HTTPS client who receives any other response SHOULD consider it an error. s/who/which/ View Inline draft-ietf-trans-gossip.txt:443 Some clients have trust anchors or logs that are locally added (e.g. by an administrator or by the user themselves). These additions are , after e.g. View Inline draft-ietf-trans-gossip.txt:468 actually preserve user privacy. The Issuer field in the certificate describes the signing certificate. And if the certificate is being submitted at all, it means the certificate is logged, and has SCTs. describes, yes, but doesn't uniquely identify. View Inline draft-ietf-trans-gossip.txt:544 the HTTPS server SHOULD perform an additional check in the more advanced mode: It would be clearer if you merged these paragraphs, and started this sentence with "Instead"... View Inline draft-ietf-trans-gossip.txt:655 concerns explained below. Suggestions for the policy can be found in Section 11.3. Also by central push. View Inline draft-ietf-trans-gossip.txt:673 validity window not to be personally identifiable data, and STHs outside this window to be personally identifiable. 14 just seems like a random number here. There's nothing that makes these STHs personally identifiable other than that you told everyone else not to save after 14, right? View Inline draft-ietf-trans-gossip.txt:688 attempt any heuristic to detect a shutdown. Instead the client MUST be informed about the shutdown from a verifiable source (e.g. a software update). The client SHOULD be provided the final STH issued , after e.g. Is a final STH from the log a verifiable source? View Inline draft-ietf-trans-gossip.txt:733 Anonymity networks such as Tor also present a mechanism for a client to anonymously retrieve a proof from an auditor or log. IMPORTANT: Neither of these mechanisms is generally usable, so I don't think this SHOULD is reasonable View Inline draft-ietf-trans-gossip.txt:799 browser that is "logged in to" a provider of various internet services. Another equivalent arrangement is a trusted party like a corporation to which an employee is connected through a VPN or by What's an example of this? Just because I'm logged into (say) Google doesn't mean I'm providing them with my browsing data. View Inline draft-ietf-trans-gossip.txt:804 proofs from that third party could be considered reasonable from a privacy perspective. The HTTPS client may also do its own auditing and might additionally share SCTs and STHs with the trusted party to Why would this be the case? View Inline draft-ietf-trans-gossip.txt:907 be able to attack all users of the webserver (who do not have a Trusted Auditor relationship) with impunity. Additionally, users who wish to have the strongest measure of privacy protection (by IMPORTANT: This seems like kind of a dealbreaker, given that pretty much the whole rest of CT has been designed under the assumption that servers will do basically nothing (hence SCTs in certs and OCSP). I get that this is an experimental draft, but it seems like the TRANS WG needs to have a common understanding of what servers will and will not do View Inline draft-ietf-trans-gossip.txt:932 Unlike SCT Feedback, the STH Pollination mechanism is not hampered if only a minority of HTTPS servers deploy it. However, it makes an assumption that an HTTPS client performs Proof Fetching (such as the I'm not sure that this is true. Say that only one server deploys it. Maybe you meant that there is still ecosystem value. View Inline draft-ietf-trans-gossip.txt:951 Servers who did not deploy SCT Feedback could be attacked without risk of detection. Well, as long as there wasn't some other mechanism such as the one Richard proposed. View Inline draft-ietf-trans-gossip.txt:991 The interactions of the mechanisms is thus outlined: This whole section seems to assume that this is the exhaustive set of transparency mechanisms, but that's not true. It needs to somehow be rewritten to make clear that this is in the absence of doing anything else. I've noted several places below, but it's not the whole list. View Inline draft-ietf-trans-gossip.txt:994 HTTPS clients can be attacked without risk of detection if they do not participate in any of the three mechanisms. This isn't true. For instance, the client could in theory download the entire log. View Inline draft-ietf-trans-gossip.txt:996 HTTPS clients are afforded the greatest chance of detecting an attack when they either participate in both SCT Feedback and STH Pollination "greatest chance" isn't that encouraging. Please actually quantify this in some way. View Inline draft-ietf-trans-gossip.txt:1000 (Participating in SCT Feedback is required to prevent a malicious log from refusing to ever resolve an SCT to an STH, as put forward in Section 10.1). Additionally, participating in SCT Feedback enables This isn't true. Again see above about downloading the entire log. View Inline draft-ietf-trans-gossip.txt:1027 of the log to the two most recent STHs and then force the log to present a consistency proof. (Which it cannot.) This attack can be detected by CT auditors participating in STH Pollination, as long as Again, not the only way. You could download the whole log, etc. View Inline draft-ietf-trans-gossip.txt:1137 on a client or server. They would be interested in flushing that data, i.e. tricking the target into gossiping or pollinating the incriminating evidence with only attacker-controlled clients or , after i.e. View Inline draft-ietf-trans-gossip.txt:1160 be in addition to the expected set, and will be evidence of the attack. Why can't an attack add a lot of STHs to the cache? View Inline draft-ietf-trans-gossip.txt:1210 The below Deletion Algorithm Section 11.3.2 is recommended to make it more difficult for the attacker to perform a flushing attack. "in Section 11.3.2" View Inline draft-ietf-trans-gossip.txt:1237 information in any other than the following two channels: to the server associated with the SCT itself; or to a Trusted Auditor, if one exists. As above, what does it mean to be "the server" View Inline draft-ietf-trans-gossip.txt:1283 from a CT log that it doesn't accept SCTs from. An HTTPS client SHOULD regularly request an STH from all logs it is willing to accept, even if it has seen no SCTs from that log. Is any HTTPS client actually planning to do this? View Inline draft-ietf-trans-gossip.txt:1321 STHs it can issue. It must 'save' one of its STHs each MMD to perform the attack. This only applies to a compliant log. View Inline draft-ietf-trans-gossip.txt:1400 Clients, HTTPS servers, and CT auditors. It is not a requirement for technique of implementation, so long as privacy considerations established above are obeyed. "as the privacy considerations" View Inline draft-ietf-trans-gossip.txt:1431 SHOULD send gossip data in an already established TLS session. This can be done through the use of HTTP Pipelining, SPDY, or HTTP/2. My understanding is that almost nobody currently does pipelining. View Inline draft-ietf-trans-gossip.txt:1533 with SCTs received from other clients, and act upon them at some period of time This all seems pretty vague. Do you provide specific algorithms? View Inline draft-ietf-trans-gossip.txt:1716 indexes.insert(r) } IMPORTANT: This algorithm does not terminate if the number of STHs inside the validity window is < MAX_STH_TO_GOSSIP and is extremely inefficient if you have a total of MAX_STH_TO_GOSSIP entries in the list. View Inline draft-ietf-trans-gossip.txt:1752 && now() - sth.timestamp > LOG_MMD && sth.proof_attempts != UINT16_MAX // Only fetch a proof is we have never received a proof What does this check do? View Inline draft-ietf-trans-gossip.txt:2081 if(r not in indexes) indexes.insert(r) } IMPORTANT: This algorithm has terrible performance when len(indexes) == MAX_SCT_RECORDS_TO_GOSSIP View Inline draft-ietf-trans-gossip.txt:2142 num_feedback_loop_failures = 0 if(num_submissions_succeeded != UINT16_MAX ) num_submissions_succeeded++ Is this because the limit might be as high as UINT16_MAX View Inline draft-ietf-trans-gossip.txt:2377 uint rndIndex1 = rand() % all_sct_stores.length uint rndIndex2 = rand() % all_sct_stores[rndIndex1].observed_records.length IMPORTANT: state that rand() has to be a CSPRNG. *REPOSITORY* rIETFREVIEW ietf-review *REVISION DETAIL* https://mozphab-ietf.devsvcdev.mozaws.net/D14 *EMAIL PREFERENCES* https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/ *To: *ekr-moz, ekr --f4030435b0108dcf38055b8aa1e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I reviewed this document on Pha= bricator. A richer version of this review can be found at:

https://mozphab-ietf.devsvcdev.mozaws.= net/D14

I'm re= viewing this draft against an Experimental standard. For the reasons indica= ted in this review, I do not believe that this actually represents a set of= viable mechanisms for ensuring that CT is publicly verifiable. In addition= , I have marked a number of places where I believe changes are required.


INLINE COMMENTS
View Inlinedraft-ietf-trans-gossip.txt:166
We want some side of the partitioned tree, and ideally both sides= , to
see the other side.

Note: there can be any number of partitions.


View Inlinedraft= -ietf-trans-gossip.txt:169
Disseminating information about a log poses a potential threat to= the
privacy of end users. Some data of interest (e.g. SCTs) is = linkable
to specific log entries and thereby to specific websites, whi= ch makes

, after e.g.


View Inlinedraft-ietf-trans-gossip.txt:202
corresponding to the SCT. This is because the site's logs wo= uld
already indicate that the client is accessing that site. In = this way
a site can accumulate records of SCTs that have been issued b= y

This is not necessarily the case. Consider the situation where I co= ntact a site from location A, retrieve an SCT, and then when I start my bro= wser in location B, don't visit the site, but send the SCT. This links = the two locations. You need to also restrict the delivery of SCT Feedback t= o organic connections to the site. The text doesn't seem to contemplate= non-organic feedback but it doesn't prohibit it either.


View Inlinedraft-ietf-trans-gossip.txt:271
| + SCT -> +----------+ |
v | Cert [& SCT]
+----------+ |

Why not inclusion proofs and STHs. This seems permitted by 6962-bis= .


View Inlinedraft-ietf-trans-gossip.txt:364
remaining SCTs together with a locally constructed certificate ch= ain
which is trusted (i.e. terminated in a pre-loaded or locally
installed Trust Anchor) in an sct_feedback object or equivale= nt data

, after i.e..


View Inlinedraft-ietf-trans-gossip.txt:373<= /span>
example.com.= ) They MUST NOT be sent to any Subject Alternate Names
specified in the certificate. In the case of certificates th= at
validate multiple domain names, the same SCT is expected to b= e stored
IMPORT= ANT: I don't understand what this means from an HTTP perspective= . What does "sent" refer to? SNI? Host: header? Suppose I have SC= Ts for a.example.com= and I connect to b.exam= ple.com which presents a certificate with SANs for {a, b}.example.com. I would ordinarily be = permitted to send requests to a.example.com per http://httpwg.org/specs/rfc7540.html#reuse. = Is it permitted to send them that way here?

View I= nlinedraft-ietf-tr= ans-gossip.txt:413
Gossip would be performed normally for third party domains only w= hen
the user revisits the first party domain. In lieu of 'do= uble-

Is this supposed to be the result of following the previous advice = to double-key?


View Inlinedraft-ietf-trans-gossip.txt:417<= /div>
treats other security mechanisms that can enable tracking (such a= s
HSTS and HPKP.)

What is that manner? As far as I can tell, it's "do nothin= g special"


View Inlinedraft-ietf-trans-gossip.txt:434=
The data sent in the POST is defined in Section 8.1.1. This data
SHOULD be sent in an already-established TLS session. This m= akes it
hard for an attacker to disrupt SCT Feedback without also dis= turbing

See above about the privacy implications of creating a new connecti= on.


View Inlinedraft-ietf-trans-gossip.txt:441
empty body if it was able to process the request. An HTTPS clien= t
who receives any other response SHOULD consider it an error.

s/who/which/


View Inlinedraft-ietf-trans-gossip.txt:443
Some clients have trust anchors or logs that are locally added (e= .g.
by an administrator or by the user themselves). These additi= ons are

, after e.g.


View Inlinedraft-ietf-trans-gossip.txt:468
actually preserve user privacy. The Issuer field in the certific= ate
describes the signing certificate. And if the certificate is= being
submitted at all, it means the certificate is logged, and has= SCTs.

describes, yes, but doesn't uniquely identify.

<= br>
View Inline= draft-ietf-trans-gossip.txt:544
the HTTPS server SHOULD perform an additional check in the more
advanced mode:

It would be clearer if you merged these paragraphs, and started thi= s sentence with "Instead"...


Also by central push.


View Inlinedraft-ietf-trans-gossip.= txt:673
validity window not to be personally identifiable data, and STHs
outside this window to be personally identifiable.

14 just seems like a random number here. There's nothing that m= akes these STHs personally identifiable other than that you told everyone e= lse not to save after 14, right?


View Inlinedraft-ietf-trans-gossip.txt:688
attempt any heuristic to detect a shutdown. Instead the client M= UST
be informed about the shutdown from a verifiable source (e.g.= a
software update). The client SHOULD be provided the final ST= H issued

, after e.g.

Is a final STH from the log a verifiabl= e source?


View Inlinedraft-ietf-trans-gossip.txt:733
Anonymity networks such as Tor also present a mechanism for a cli= ent
to anonymously retrieve a proof from an auditor or log.
IMPORT= ANT: Neither of these mechanisms is generally usable, so I don't= think this SHOULD is reasonable

View Inlinedraft-ietf-trans-gossip.= txt:799
browser that is "logged in to" a provider of various in= ternet
services. Another equivalent arrangement is a trusted party = like a
corporation to which an employee is connected through a VPN o= r by

What's an example of this? Just because I'm logged into (sa= y) Google doesn't mean I'm providing them with my browsing data.


<= div style=3D"color:rgb(116,119,125);background:rgb(239,242,244);padding:6px= 8px;overflow:hidden">View Inlinedraft-ietf-trans-gossip.txt:804
proofs from that third party could be considered reasonable from = a
privacy perspective. The HTTPS client may also do its own au= diting
and might additionally share SCTs and STHs with the trusted p= arty to

Why would this be the case?


View Inline<= span style=3D"color:rgb(75,77,81);font-weight:bold">draft-ietf-trans-gossip= .txt:907
be able to attack all users of the webserver (who do not have a
Trusted Auditor relationship) with impunity. Additionally, u= sers who
wish to have the strongest measure of privacy protection (by
IMPORT= ANT: This seems like kind of a dealbreaker, given that pretty much t= he whole rest of CT has been designed under the assumption that servers wil= l do basically nothing (hence SCTs in certs and OCSP). I get that this is a= n experimental draft, but it seems like the TRANS WG needs to have a common= understanding of what servers will and will not do

View Inlinedraft= -ietf-trans-gossip.txt:932
Unlike SCT Feedback, the STH Pollination mechanism is not hampere= d if
only a minority of HTTPS servers deploy it. However, it make= s an
assumption that an HTTPS client performs Proof Fetching (such= as the

I'm not sure that this is true. Say that only one server deplo= ys it. Maybe you meant that there is still ecosystem value.

=
View Inlinedraft-ietf-trans-gossip.txt:951
Servers who did not deploy SCT Feedback could be attacked without
risk of detection.

Well, as long as there wasn't some other mechanism such as the = one Richard proposed.


View Inlinedraft-ietf-trans-gossip.txt:991<= /span>
The interactions of the mechanisms is thus outlined:

This whole section seems to assume that this is the exhaustive set = of transparency mechanisms, but that's not true. It needs to somehow be= rewritten to make clear that this is in the absence of doing anything else= . I've noted several places below, but it's not the whole list.

=

View Inlinedraft-ietf-trans-gossip.txt:994
HTTPS clients can be attacked without risk of detection if they d= o
not participate in any of the three mechanisms.

This isn't true. For instance, the client could in theory downl= oad the entire log.


View Inlinedraft-ietf-trans-gossip.txt:996
HTTPS clients are afforded the greatest chance of detecting an at= tack
when they either participate in both SCT Feedback and STH Pol= lination

"greatest chance" isn't that encouraging. Please actu= ally quantify this in some way.


View Inlinedraft-ietf-trans-gossip.txt:1000
(Participating in SCT Feedback is required to prevent a malicious= log
from refusing to ever resolve an SCT to an STH, as put forwar= d in
Section 10.1). Additionally, participating in SCT Feedback e= nables

This isn't true. Again see above about downloading the entire l= og.


View Inlinedraft-ietf-trans-gossip.txt:1027
of the log to the two most recent STHs and then force the log to
present a consistency proof. (Which it cannot.) This attack= can be
detected by CT auditors participating in STH Pollination, as = long as

Again, not the only way. You could download the whole log, etc.

=

View Inlinedraft-ietf-trans-gossip.txt:1137
on a client or server. They would be interested in flushing that
data, i.e. tricking the target into gossiping or pollinating= the
incriminating evidence with only attacker-controlled clients = or

, after i.e.


View Inlinedraft-ietf-trans-gossip.txt:1160<= /span>
be in addition to the expected set, and will be evidence of the
attack.

Why can't an attack add a lot of STHs to the cache?


=
View Inlinedraft-ietf-trans-gossip.txt:1210
The below Deletion Algorithm Section 11.3.2 is recommended to mak= e it
more difficult for the attacker to perform a flushing attack.

"in Section 11.3.2"


As above, what does it mean to be "the server"

<= /div>
View Inlinedraft-ietf-trans-gossip.txt:1283
from a CT log that it doesn't accept SCTs from. An HTTPS cli= ent
SHOULD regularly request an STH from all logs it is willing t= o
accept, even if it has seen no SCTs from that log.

Is any HTTPS client actually planning to do this?

View Inlined= raft-ietf-trans-gossip.txt:1321
STHs it can issue. It must 'save' one of its STHs each M= MD to
perform the attack.

This only applies to a compliant log.


View I= nlinedraft-ietf-tr= ans-gossip.txt:1400
Clients, HTTPS servers, and CT auditors. It is not a requirement= for
technique of implementation, so long as privacy consideration= s
established above are obeyed.

"as the privacy considerations"


<= a style=3D"float:right;text-decoration:none" href=3D"https://mozphab-ietf.d= evsvcdev.mozaws.net/D14#inline-416" rel=3D"noreferrer" target=3D"_blank">Vi= ew Inlinedraft-iet= f-trans-gossip.txt:1431
SHOULD send gossip data in an already established TLS session. T= his
can be done through the use of HTTP Pipelining, SPDY, or HTTP= /2.

My understanding is that almost nobody currently does pipelining.


=
View Inlinedraft-ietf-trans-gossip.txt:1533
with SCTs received from other clients, and act upon them at so= me
period of time

This all seems pretty vague. Do you provide specific algorithms?


<= div style=3D"color:rgb(116,119,125);background:rgb(239,242,244);padding:6px= 8px;overflow:hidden">View Inlinedraft-ietf-trans-gossip.txt:1716
indexes.insert(r)
}
IMPORT= ANT: This algorithm does not terminate if the number of STHs inside = the validity window is < MAX_STH_TO_GOSSIP and is extremely inefficient = if you have a total of MAX_STH_TO_GOSSIP entries in the list.

=
View Inlinedraft-ietf-trans-gossip.txt:1752
&& now() - sth.timestamp > LOG_MMD
&& sth.proof_attempts !=3D UINT16_MAX
// Only fetch a proof is we have never received a pr= oof

What does this check do?


View Inlinedraft-ietf-trans-gossip.txt:2081
if(r not in indexes)
indexes.insert(r)
}
IMPORT= ANT: This algorithm has terrible performance when
len(indexe=
s) =3D=3D MAX_SCT_RECORDS_TO_GOSSIP

View I= nlinedraft-ietf-tr= ans-gossip.txt:2142
num_feedback_loop_failures =3D 0
if(num_submissions_succeeded !=3D UINT16_MAX )
num_submissions_succeeded++

Is this because the limit might be as high as UINT16_MAX

<= /div>
View Inlinedraft-ietf-trans-gossip.txt:2377
uint rndIndex1 =3D rand() % all_sct_stores.length
uint rndIndex2 =3D rand() % all_sct_stores[rndIndex1].o= bserved_records.length
IMPORT= ANT: state that rand() has to be a CSPRNG.

REPOSITORY
rIETFREVIEW ietf-review
<= br>

To: ekr-moz, ekr
<= /div>

--f4030435b0108dcf38055b8aa1e6-- From nobody Mon Oct 16 14:41:28 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4ED134588 for ; Mon, 16 Oct 2017 14:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 KTN9PLS2Dsq8 for ; Mon, 16 Oct 2017 14:41:10 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 E745A132025 for ; Mon, 16 Oct 2017 14:41:09 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id i124so72644wmf.3 for ; Mon, 16 Oct 2017 14:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uv0I8E7BY95wO7AJz6csgsp4sLO9ju8X8bh73BAnpzs=; b=mMIIdkCwIWJ3JTtEMnPWAUCgukfuBITei3z0eZ/8UHkQpAB5j7iJuCwL7bHhOVurmV XohmI86HdVAfvLwmHxifB0xybohhICTxgu4Lb09lS1GaVuohfNHL3uwpWgaMDoT+zH57 HRqCm/1GJ3OWMPQ8YM2qDFCmloKrJr+DZj6o6BL5/MpOiRXW8/W2rge2znYVBdvO3c14 1t7aCO4hYcZ5yxUleYBoylJTNeSlvsnMy/m4IftvRlhZCc0B2ZxNKr4OwejFyUf+sDIE OthrTjdKZj8xQHEWEumCaUPg++c3t4LQlq3KhOTtIiIi+QVe+gSJy6A4RF3N0zPDl3o2 UOqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uv0I8E7BY95wO7AJz6csgsp4sLO9ju8X8bh73BAnpzs=; b=H3NiLh33Acp/IatkOgEyrfsRitr7WsRoRdQELeOc2kk29Ayk0jqPsVnjv6KpxjPO22 s4HJYnWT7pa2no0p7eIjIeTlECaHJZWG1jtH095QsY4qgax6jjdZ7mQRFj/cyJT+jlYn STrmXmhSI50/BgcHEUhvAt+6JcnKStXFodFYeTzqoCYx6ANqj5a6yWhj7GKyRCyt7Qei XR/wXopX6ub45uLpC3ZW/zeEouYnPDfwgzLJhKUPJgMY0JaRmvUiIsHDz3KW2jVbkCmK VSejH7OO8LsoLpwKV83WtWEJWx/ZEs7o0MHNtIk7RRmb8m8p8r94qjE5mFu4gFYTPSpn VtfA== X-Gm-Message-State: AMCzsaUkFqlVFyHvGTdCJmRi3MCGFXeb42W2uydbkZR78h6kRUad4AFo qL/u+ZlGNb83c7X0ETW+k44OhIRsIY+4Z3s5f/ZBOQ== X-Google-Smtp-Source: ABhQp+TVOocboP4Z0L/fSt9RQewC4nNrxHOcPlWk8wypXgJx4prLoFDeODaQ6HNSJcmy2GSKP+11HI8bem4AXIbRQRE= X-Received: by 10.28.69.91 with SMTP id s88mr1800419wma.19.1508190068162; Mon, 16 Oct 2017 14:41:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.210 with HTTP; Mon, 16 Oct 2017 14:41:07 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Mon, 16 Oct 2017 17:41:07 -0400 Message-ID: To: Eric Rescorla Cc: Trans , draft-ietf-trans-gossip@tools.ietf.org Content-Type: multipart/alternative; boundary="94eb2c0723a6444e2d055bb0ddf8" Archived-At: Subject: Re: [Trans] AD Review: draft-ietf-trans-gossip-04 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 21:41:26 -0000 --94eb2c0723a6444e2d055bb0ddf8 Content-Type: text/plain; charset="UTF-8" Hey all, EKR asked me to take a look at this document in preparation for IETF LC and IESG processing. Full comments below. tl;dr: The document is pretty scattered right now, and could benefit from a tighter focus. --Richard ===== Overall, it's hard to evaluate this document without a clearer idea of what it's supposed to cover. The intro sections seem to be pretty clear (detecting split views and MMD violations), but then there's a bunch of other stuff that gets raised later (e.g., STH vetting, benefits to servers). Let's start from the top and talk about what the overall transparency system needs. 6962bis already gives auditors the ability to verify that a log is presenting a single consistent history to that auditor, and gives clients the ability to verify that SCTs and STHs come from a log. That leaves us a few additional things to assure: 1. That the log gives the same history to all auditors (so that there is a single canonical sequence of STHs) 2. That every inclusion proof the client sees is to an STH on the main sequence 3. That every SCT the client sees is covered by an STH within the MMD Note that the server benefits allegedly provided by SCT feedback are already provided by CT monitors. Or, if we want to provide that benefit via feedback, we should just skip the log and SCT and send the cert chain. --- How do the mechanisms presented square against these requirements? - SCT feedback is a pretty OK way to address (3) - STH pollination is kind of the right shape for (1), but should run between auditors instead of client/server - TAR is a huge privacy cost to address (3); might have some utility for (2) assuming STH discipline For (1), all you really need is a way for auditors to talk to each other. STH pollination accomplishes that, but only probabilistically, and only if a lot of other people do work. Why not just make this deterministic? For example, if every auditor pings every other one on a fixed schedule, it's very easy to detect when one of them is impaired. The STH pollination endpoint as described could support this use case, but of course you would want to actually describe its use in this way, and the resulting security properties. For (2), you need a way for the client to vet the STHs it gets with an auditor, whether it gets them via TransItems or fetching. Ideally this could be done real-time, so that the client could abort the handshake. For example, you could send the client the entire history of STHs, or do some OCSP-like check. The former seems possible if "STH discipline" is implemented for 6962bis, but this document makes no mention of the possibility. For off-line, ecosystem protection, STH discipline would make TAR more acceptable, since the constraints on STHs would make them less of a privacy risk. For (3), you need some way to smuggle SCTs back to an auditor. TAR with SCTs is not really plausible outside of the Googlebot use case, and once you remove that, TAR ~= STH pollination. As far as SCT feedback, note that the privacy issues here (around server tracking) are unnecessary to meet the need here -- only the auditor needs to see the SCTs, not the server. If you had a way for clients to encrypt SCTs to specific auditors, you would no longer have an issue with server tracking. --- Net of those considerations, I would be happiest if this doc got refactored to more directly address the needs: 1. Repurpose STH pollination as a way for auditors to send STHs to each other 1.a. Adapt the STH pollination endpoint so that it can provide feedback on the validity of the STH 1.b. Add some notes about how real-time STH checking can be done 2. Add a through-encryption modality for SCT feedback 3. Constrain TAR to only be used for STHs, and only for logs that implement STH discipline On Sat, Oct 14, 2017 at 8:03 PM, Eric Rescorla wrote: > I reviewed this document on Phabricator. A richer version of this review > can be found at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D14 > > I'm reviewing this draft against an Experimental standard. For the reasons > indicated in this review, I do not believe that this actually represents a > set of viable mechanisms for ensuring that CT is publicly verifiable. In > addition, I have marked a number of places where I believe changes are > required. > > *INLINE COMMENTS* > View Inline > draft-ietf-trans-gossip.txt:166 > We want some side of the partitioned tree, and ideally both sides, to > see the other side. > > Note: there can be any number of partitions. > > View Inline > draft-ietf-trans-gossip.txt:169 > Disseminating information about a log poses a potential threat to the > privacy of end users. Some data of interest (e.g. SCTs) is linkable > to specific log entries and thereby to specific websites, which makes > > , after e.g. > > View Inline > draft-ietf-trans-gossip.txt:202 > corresponding to the SCT. This is because the site's logs would > already indicate that the client is accessing that site. In this way > a site can accumulate records of SCTs that have been issued by > > This is not necessarily the case. Consider the situation where I contact a > site from location A, retrieve an SCT, and then when I start my browser in > location B, don't visit the site, but send the SCT. This links the two > locations. You need to also restrict the delivery of SCT Feedback to > organic connections to the site. The text doesn't seem to contemplate > non-organic feedback but it doesn't prohibit it either. > > View Inline > draft-ietf-trans-gossip.txt:271 > | + SCT -> +----------+ | > v | Cert [& SCT] > +----------+ | > > Why not inclusion proofs and STHs. This seems permitted by 6962-bis. > > View Inline > draft-ietf-trans-gossip.txt:364 > remaining SCTs together with a locally constructed certificate chain > which is trusted (i.e. terminated in a pre-loaded or locally > installed Trust Anchor) in an sct_feedback object or equivalent data > > , after i.e.. > > View Inline > draft-ietf-trans-gossip.txt:373 > example.com.) They MUST NOT be sent to any Subject Alternate Names > specified in the certificate. In the case of certificates that > validate multiple domain names, the same SCT is expected to be stored > IMPORTANT: I don't understand what this means from an HTTP perspective. > What does "sent" refer to? SNI? Host: header? Suppose I have SCTs for > a.example.com and I connect to b.example.com which presents a certificate > with SANs for {a, b}.example.com. I would ordinarily be permitted to send > requests to a.example.com per http://httpwg.org/specs/rfc7540.html#reuse. > Is it permitted to send them that way here? > > View Inline > draft-ietf-trans-gossip.txt:413 > Gossip would be performed normally for third party domains only when > the user revisits the first party domain. In lieu of 'double- > > Is this supposed to be the result of following the previous advice to > double-key? > > View Inline > draft-ietf-trans-gossip.txt:417 > treats other security mechanisms that can enable tracking (such as > HSTS and HPKP.) > > What is that manner? As far as I can tell, it's "do nothing special" > > View Inline > draft-ietf-trans-gossip.txt:434 > The data sent in the POST is defined in Section 8.1.1. This data > SHOULD be sent in an already-established TLS session. This makes it > hard for an attacker to disrupt SCT Feedback without also disturbing > > See above about the privacy implications of creating a new connection. > > View Inline > draft-ietf-trans-gossip.txt:441 > empty body if it was able to process the request. An HTTPS client > who receives any other response SHOULD consider it an error. > > s/who/which/ > > View Inline > draft-ietf-trans-gossip.txt:443 > Some clients have trust anchors or logs that are locally added (e.g. > by an administrator or by the user themselves). These additions are > > , after e.g. > > View Inline > draft-ietf-trans-gossip.txt:468 > actually preserve user privacy. The Issuer field in the certificate > describes the signing certificate. And if the certificate is being > submitted at all, it means the certificate is logged, and has SCTs. > > describes, yes, but doesn't uniquely identify. > > View Inline > draft-ietf-trans-gossip.txt:544 > the HTTPS server SHOULD perform an additional check in the more > advanced mode: > > It would be clearer if you merged these paragraphs, and started this > sentence with "Instead"... > > View Inline > draft-ietf-trans-gossip.txt:655 > concerns explained below. Suggestions for the policy can be found in > Section 11.3. > > Also by central push. > > View Inline > draft-ietf-trans-gossip.txt:673 > validity window not to be personally identifiable data, and STHs > outside this window to be personally identifiable. > > 14 just seems like a random number here. There's nothing that makes these > STHs personally identifiable other than that you told everyone else not to > save after 14, right? > > View Inline > draft-ietf-trans-gossip.txt:688 > attempt any heuristic to detect a shutdown. Instead the client MUST > be informed about the shutdown from a verifiable source (e.g. a > software update). The client SHOULD be provided the final STH issued > > , after e.g. > > Is a final STH from the log a verifiable source? > > View Inline > draft-ietf-trans-gossip.txt:733 > Anonymity networks such as Tor also present a mechanism for a client > to anonymously retrieve a proof from an auditor or log. > IMPORTANT: Neither of these mechanisms is generally usable, so I don't > think this SHOULD is reasonable > > View Inline > draft-ietf-trans-gossip.txt:799 > browser that is "logged in to" a provider of various internet > services. Another equivalent arrangement is a trusted party like a > corporation to which an employee is connected through a VPN or by > > What's an example of this? Just because I'm logged into (say) Google > doesn't mean I'm providing them with my browsing data. > > View Inline > draft-ietf-trans-gossip.txt:804 > proofs from that third party could be considered reasonable from a > privacy perspective. The HTTPS client may also do its own auditing > and might additionally share SCTs and STHs with the trusted party to > > Why would this be the case? > > View Inline > draft-ietf-trans-gossip.txt:907 > be able to attack all users of the webserver (who do not have a > Trusted Auditor relationship) with impunity. Additionally, users who > wish to have the strongest measure of privacy protection (by > IMPORTANT: This seems like kind of a dealbreaker, given that pretty much > the whole rest of CT has been designed under the assumption that servers > will do basically nothing (hence SCTs in certs and OCSP). I get that this > is an experimental draft, but it seems like the TRANS WG needs to have a > common understanding of what servers will and will not do > > View Inline > draft-ietf-trans-gossip.txt:932 > Unlike SCT Feedback, the STH Pollination mechanism is not hampered if > only a minority of HTTPS servers deploy it. However, it makes an > assumption that an HTTPS client performs Proof Fetching (such as the > > I'm not sure that this is true. Say that only one server deploys it. Maybe > you meant that there is still ecosystem value. > > View Inline > draft-ietf-trans-gossip.txt:951 > Servers who did not deploy SCT Feedback could be attacked without > risk of detection. > > Well, as long as there wasn't some other mechanism such as the one Richard > proposed. > > View Inline > draft-ietf-trans-gossip.txt:991 > The interactions of the mechanisms is thus outlined: > > This whole section seems to assume that this is the exhaustive set of > transparency mechanisms, but that's not true. It needs to somehow be > rewritten to make clear that this is in the absence of doing anything else. > I've noted several places below, but it's not the whole list. > > View Inline > draft-ietf-trans-gossip.txt:994 > HTTPS clients can be attacked without risk of detection if they do > not participate in any of the three mechanisms. > > This isn't true. For instance, the client could in theory download the > entire log. > > View Inline > draft-ietf-trans-gossip.txt:996 > HTTPS clients are afforded the greatest chance of detecting an attack > when they either participate in both SCT Feedback and STH Pollination > > "greatest chance" isn't that encouraging. Please actually quantify this in > some way. > > View Inline > draft-ietf-trans-gossip.txt:1000 > (Participating in SCT Feedback is required to prevent a malicious log > from refusing to ever resolve an SCT to an STH, as put forward in > Section 10.1). Additionally, participating in SCT Feedback enables > > This isn't true. Again see above about downloading the entire log. > > View Inline > draft-ietf-trans-gossip.txt:1027 > of the log to the two most recent STHs and then force the log to > present a consistency proof. (Which it cannot.) This attack can be > detected by CT auditors participating in STH Pollination, as long as > > Again, not the only way. You could download the whole log, etc. > > View Inline > draft-ietf-trans-gossip.txt:1137 > on a client or server. They would be interested in flushing that > data, i.e. tricking the target into gossiping or pollinating the > incriminating evidence with only attacker-controlled clients or > > , after i.e. > > View Inline > draft-ietf-trans-gossip.txt:1160 > be in addition to the expected set, and will be evidence of the > attack. > > Why can't an attack add a lot of STHs to the cache? > > View Inline > draft-ietf-trans-gossip.txt:1210 > The below Deletion Algorithm Section 11.3.2 is recommended to make it > more difficult for the attacker to perform a flushing attack. > > "in Section 11.3.2" > > View Inline > draft-ietf-trans-gossip.txt:1237 > information in any other than the following two channels: to the > server associated with the SCT itself; or to a Trusted Auditor, if > one exists. > > As above, what does it mean to be "the server" > > View Inline > draft-ietf-trans-gossip.txt:1283 > from a CT log that it doesn't accept SCTs from. An HTTPS client > SHOULD regularly request an STH from all logs it is willing to > accept, even if it has seen no SCTs from that log. > > Is any HTTPS client actually planning to do this? > > View Inline > draft-ietf-trans-gossip.txt:1321 > STHs it can issue. It must 'save' one of its STHs each MMD to > perform the attack. > > This only applies to a compliant log. > > View Inline > draft-ietf-trans-gossip.txt:1400 > Clients, HTTPS servers, and CT auditors. It is not a requirement for > technique of implementation, so long as privacy considerations > established above are obeyed. > > "as the privacy considerations" > > View Inline > draft-ietf-trans-gossip.txt:1431 > SHOULD send gossip data in an already established TLS session. This > can be done through the use of HTTP Pipelining, SPDY, or HTTP/2. > > My understanding is that almost nobody currently does pipelining. > > View Inline > draft-ietf-trans-gossip.txt:1533 > with SCTs received from other clients, and act upon them at some > period of time > > This all seems pretty vague. Do you provide specific algorithms? > > View Inline > draft-ietf-trans-gossip.txt:1716 > indexes.insert(r) > } > IMPORTANT: This algorithm does not terminate if the number of STHs inside > the validity window is < MAX_STH_TO_GOSSIP and is extremely inefficient if > you have a total of MAX_STH_TO_GOSSIP entries in the list. > > View Inline > draft-ietf-trans-gossip.txt:1752 > && now() - sth.timestamp > LOG_MMD > && sth.proof_attempts != UINT16_MAX > // Only fetch a proof is we have never received a proof > > What does this check do? > > View Inline > draft-ietf-trans-gossip.txt:2081 > if(r not in indexes) > indexes.insert(r) > } > IMPORTANT: This algorithm has terrible performance when > > len(indexes) == MAX_SCT_RECORDS_TO_GOSSIP > > > View Inline > draft-ietf-trans-gossip.txt:2142 > num_feedback_loop_failures = 0 > if(num_submissions_succeeded != UINT16_MAX ) > num_submissions_succeeded++ > > Is this because the limit might be as high as UINT16_MAX > > View Inline > draft-ietf-trans-gossip.txt:2377 > uint rndIndex1 = rand() % all_sct_stores.length > uint rndIndex2 = rand() % all_sct_stores[rndIndex1].observed_records.length > > IMPORTANT: state that rand() has to be a CSPRNG. > > *REPOSITORY* > rIETFREVIEW ietf-review > > *REVISION DETAIL* > https://mozphab-ietf.devsvcdev.mozaws.net/D14 > > *EMAIL PREFERENCES* > https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/ > > *To: *ekr-moz, ekr > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --94eb2c0723a6444e2d055bb0ddf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

EKR asked me to take a look at this d= ocument in preparation for IETF LC and IESG processing.=C2=A0 Full comments= below. tl;dr: The document is pretty scattered right now, and could benefi= t from a tighter focus.

--Richard

=3D=3D=3D=3D=3D

Over= all, it's hard to evaluate this document without a clearer idea of what= it's supposed to cover.=C2=A0 The intro sections seem to be pretty cle= ar (detecting split views and MMD violations), but then there's a bunch= of other stuff that gets raised later (e.g., STH vetting, benefits to serv= ers).

Let's start from the top and talk about what the overall t= ransparency system needs.=C2=A0 6962bis already gives auditors the ability = to verify that a log is presenting a single consistent history to that audi= tor, and gives clients the ability to verify that SCTs and STHs come from a= log.=C2=A0 That leaves us a few additional things to assure:

1. Tha= t the log gives the same history to all auditors (so that there is a single= canonical sequence of STHs)
2. That every inclusion proof the client se= es is to an STH on the main sequence
3. That every SCT the client sees i= s covered by an STH within the MMD

Note that the server benefits all= egedly provided by SCT feedback are already provided by CT monitors.=C2=A0 = Or, if we want to provide that benefit via feedback, we should just skip th= e log and SCT and send the cert chain.

---

How do the mechani= sms presented square against these requirements?

- SCT f= eedback is a pretty OK way to address (3)
- STH pollination is kind of t= he right shape for (1), but should run between auditors instead of client/s= erver
- TAR is a huge privacy cost to address (3); might have some utili= ty for (2) assuming STH discipline

For (1), all you really need is a= way for auditors to talk to each other.=C2=A0 STH pollination accomplishes= that, but only probabilistically, and only if a lot of other people do wor= k.=C2=A0 Why not just make this deterministic?=C2=A0 For example, if every = auditor pings every other one on a fixed schedule, it's very easy to de= tect when one of them is impaired.=C2=A0 The STH pollination endpoint as de= scribed could support this use case, but of course you would want to actual= ly describe its use in this way, and the resulting security properties.
=
For (2), you need a way for the client to vet the STHs it gets with an = auditor, whether it gets them via TransItems or fetching.=C2=A0 Ideally thi= s could be done real-time, so that the client could abort the handshake.=C2= =A0 For example, you could send the client the entire history of STHs, or d= o some OCSP-like check.=C2=A0 The former seems possible if "STH discip= line" is implemented for 6962bis, but this document makes no mention o= f the possibility.=C2=A0 For off-line, ecosystem protection, STH discipline= would make TAR more acceptable, since the constraints on STHs would make t= hem less of a privacy risk.

For (3), you need some way to smuggle SC= Ts back to an auditor.=C2=A0 TAR with SCTs is not really plausible outside = of the Googlebot use case, and once you remove that, TAR ~=3D STH pollinati= on.=C2=A0 As far as SCT feedback, note that the privacy issues here (around= server tracking) are unnecessary to meet the need here -- only the auditor= needs to see the SCTs, not the server.=C2=A0 If you had a way for clients = to encrypt SCTs to specific auditors, you would no longer have an issue wit= h server tracking.

---

Net of those considerations, I would b= e happiest if this doc got refactored to more directly address the needs:
1. Repurpose STH pollination as a way for auditors to send STHs to ea= ch other
1.a. Adapt the STH pollination endpoint so that it can provide = feedback on the validity of the STH
1.b. Add some notes about how real-t= ime STH checking can be done
2. Add a through-encryption modality for SC= T feedback
3. Constrain TAR to only be used for STHs, and only for= logs that implement STH discipline


On Sat, Oct 14, 2017 at 8:03 PM,= Eric Rescorla <ekr@rtfm.com> wrote:
I reviewed this document = on Phabricator. A richer version of this review can be found at:

https://mozphab= -ietf.devsvcdev.mozaws.net/D14

I'm reviewing this draft against an Experimental stan= dard. For the reasons indicated in this review, I do not believe that this = actually represents a set of viable mechanisms for ensuring that CT is publ= icly verifiable. In addition, I have marked a number of places where I beli= eve changes are required.


INLINE COMMENTS
View Inlinedraft-ietf-trans-gossip.tx= t:166
We want some side of the partitioned tree, and ideally both sides= , to
see the other side.

Note: there can be any number of partitions.


View Inlinedraft= -ietf-trans-gossip.txt:169
Disseminating information about a log poses a potential threat to= the
privacy of end users. Some data of interest (e.g. SCTs) is = linkable
to specific log entries and thereby to specific websites, whi= ch makes

, after e.g.


View Inlinedraft-ietf-trans-gossip.txt:202
corresponding to the SCT. This is because the site's logs wo= uld
already indicate that the client is accessing that site. In = this way
a site can accumulate records of SCTs that have been issued b= y

This is not necessarily the case. Consider the situation where I co= ntact a site from location A, retrieve an SCT, and then when I start my bro= wser in location B, don't visit the site, but send the SCT. This links = the two locations. You need to also restrict the delivery of SCT Feedback t= o organic connections to the site. The text doesn't seem to contemplate= non-organic feedback but it doesn't prohibit it either.


View Inlinedraft-ietf-trans-gossip.txt:271
| + SCT -> +----------+ |
v | Cert [& SCT]
+----------+ |

Why not inclusion proofs and STHs. This seems permitted by 6962-bis= .


View Inlinedraft-ietf-trans-gossip.txt:364
remaining SCTs together with a locally constructed certificate ch= ain
which is trusted (i.e. terminated in a pre-loaded or locally
installed Trust Anchor) in an sct_feedback object or equivale= nt data

, after i.e..


View Inlinedraft-ietf-trans-gossip.txt:373<= /span>
example.com.= ) They MUST NOT be sent to any Subject Alternate Names
specified in the certificate. In the case of certificates th= at
validate multiple domain names, the same SCT is expected to b= e stored
IMPORTANT: I don't understand what this means fr= om an HTTP perspective. What does "sent" refer to? SNI? Host: hea= der? Suppose I have SCTs for a.example.com and I connect to b.example.com which presents a certificate with SANs fo= r {a, b}.example.com. = I would ordinarily be permitted to send requests to a.example.com per http://ht= tpwg.org/specs/rfc7540.html#reuse. Is it permitted to send them th= at way here?

View Inlinedraft-ietf-trans-gossip.txt:413<= /div>
Gossip would be performed normally for third party domains only w= hen
the user revisits the first party domain. In lieu of 'do= uble-

Is this supposed to be the result of following the previous advice = to double-key?


View Inlinedraft-ietf-trans-gossip.txt:417<= /div>
treats other security mechanisms that can enable tracking (such a= s
HSTS and HPKP.)

What is that manner? As far as I can tell, it's "do nothin= g special"


View Inlinedraft-ietf-trans-gossip.txt:434=
The data sent in the POST is defined in Section 8.1.1. This data
SHOULD be sent in an already-established TLS session. This m= akes it
hard for an attacker to disrupt SCT Feedback without also dis= turbing

See above about the privacy implications of creating a new connecti= on.


View Inlinedraft-ietf-trans-gossip.txt:441
empty body if it was able to process the request. An HTTPS clien= t
who receives any other response SHOULD consider it an error.

s/who/which/


View Inlinedraft-ietf-trans-gossip.txt:443
Some clients have trust anchors or logs that are locally added (e= .g.
by an administrator or by the user themselves). These additi= ons are

, after e.g.


View Inlinedraft-ietf-trans-gossip.txt:468
actually preserve user privacy. The Issuer field in the certific= ate
describes the signing certificate. And if the certificate is= being
submitted at all, it means the certificate is logged, and has= SCTs.

describes, yes, but doesn't uniquely identify.

<= br>
View Inline= draft-ietf-trans-gossip.txt:544
the HTTPS server SHOULD perform an additional check in the more
advanced mode:

It would be clearer if you merged these paragraphs, and started thi= s sentence with "Instead"...


Also by central push.


View Inlinedraft-ietf-trans-gossip.= txt:673
validity window not to be personally identifiable data, and STHs
outside this window to be personally identifiable.

14 just seems like a random number here. There's nothing that m= akes these STHs personally identifiable other than that you told everyone e= lse not to save after 14, right?


View Inlinedraft-ietf-trans-gossip.txt:688
attempt any heuristic to detect a shutdown. Instead the client M= UST
be informed about the shutdown from a verifiable source (e.g.= a
software update). The client SHOULD be provided the final ST= H issued

, after e.g.

Is a final STH from the log a verifiabl= e source?


View Inlinedraft-ietf-trans-gossip.txt:733
Anonymity networks such as Tor also present a mechanism for a cli= ent
to anonymously retrieve a proof from an auditor or log.
IMPORTANT: Neither of these mechanisms is generally = usable, so I don't think this SHOULD is reasonable
View Inlinedr= aft-ietf-trans-gossip.txt:799
browser that is "logged in to" a provider of various in= ternet
services. Another equivalent arrangement is a trusted party = like a
corporation to which an employee is connected through a VPN o= r by

What's an example of this? Just because I'm logged into (sa= y) Google doesn't mean I'm providing them with my browsing data.


<= div style=3D"color:rgb(116,119,125);background:rgb(239,242,244);padding:6px= 8px;overflow:hidden">View Inlinedraft-ietf-trans-gossip.txt:804
proofs from that third party could be considered reasonable from = a
privacy perspective. The HTTPS client may also do its own au= diting
and might additionally share SCTs and STHs with the trusted p= arty to

Why would this be the case?


View Inline<= span style=3D"color:rgb(75,77,81);font-weight:bold">draft-ietf-trans-gossip= .txt:907
be able to attack all users of the webserver (who do not have a
Trusted Auditor relationship) with impunity. Additionally, u= sers who
wish to have the strongest measure of privacy protection (by
IMPORTANT: This seems like kind of a dealbreaker, gi= ven that pretty much the whole rest of CT has been designed under the assum= ption that servers will do basically nothing (hence SCTs in certs and OCSP)= . I get that this is an experimental draft, but it seems like the TRANS WG = needs to have a common understanding of what servers will and will not do

View Inlinedraft-ietf-trans-gossip.txt:932
Unlike SCT Feedback, the STH Pollination mechanism is not hampere= d if
only a minority of HTTPS servers deploy it. However, it make= s an
assumption that an HTTPS client performs Proof Fetching (such= as the

I'm not sure that this is true. Say that only one server deplo= ys it. Maybe you meant that there is still ecosystem value.

=
View Inlinedraft-ietf-trans-gossip.txt:951
Servers who did not deploy SCT Feedback could be attacked without
risk of detection.

Well, as long as there wasn't some other mechanism such as the = one Richard proposed.


View Inlinedraft-ietf-trans-gossip.txt:991<= /span>
The interactions of the mechanisms is thus outlined:

This whole section seems to assume that this is the exhaustive set = of transparency mechanisms, but that's not true. It needs to somehow be= rewritten to make clear that this is in the absence of doing anything else= . I've noted several places below, but it's not the whole list.

=

View Inlinedraft-ietf-trans-gossip.txt:994
HTTPS clients can be attacked without risk of detection if they d= o
not participate in any of the three mechanisms.

This isn't true. For instance, the client could in theory downl= oad the entire log.


View Inlinedraft-ietf-trans-gossip.txt:996
HTTPS clients are afforded the greatest chance of detecting an at= tack
when they either participate in both SCT Feedback and STH Pol= lination

"greatest chance" isn't that encouraging. Please actu= ally quantify this in some way.


View Inlinedraft-ietf-trans-gossip.txt:1000
(Participating in SCT Feedback is required to prevent a malicious= log
from refusing to ever resolve an SCT to an STH, as put forwar= d in
Section 10.1). Additionally, participating in SCT Feedback e= nables

This isn't true. Again see above about downloading the entire l= og.


View Inlinedraft-ietf-trans-gossip.txt:1027
of the log to the two most recent STHs and then force the log to
present a consistency proof. (Which it cannot.) This attack= can be
detected by CT auditors participating in STH Pollination, as = long as

Again, not the only way. You could download the whole log, etc.

=

View Inlinedraft-ietf-trans-gossip.txt:1137
on a client or server. They would be interested in flushing that
data, i.e. tricking the target into gossiping or pollinating= the
incriminating evidence with only attacker-controlled clients = or

, after i.e.


View Inlinedraft-ietf-trans-gossip.txt:1160<= /span>
be in addition to the expected set, and will be evidence of the
attack.

Why can't an attack add a lot of STHs to the cache?


=
View Inlinedraft-ietf-trans-gossip.txt:1210
The below Deletion Algorithm Section 11.3.2 is recommended to mak= e it
more difficult for the attacker to perform a flushing attack.

"in Section 11.3.2"


As above, what does it mean to be "the server"

<= /div>
View Inlinedraft-ietf-trans-gossip.txt:1283
from a CT log that it doesn't accept SCTs from. An HTTPS cli= ent
SHOULD regularly request an STH from all logs it is willing t= o
accept, even if it has seen no SCTs from that log.

Is any HTTPS client actually planning to do this?

View Inlined= raft-ietf-trans-gossip.txt:1321
STHs it can issue. It must 'save' one of its STHs each M= MD to
perform the attack.

This only applies to a compliant log.


View I= nlinedraft-ietf-tr= ans-gossip.txt:1400
Clients, HTTPS servers, and CT auditors. It is not a requirement= for
technique of implementation, so long as privacy consideration= s
established above are obeyed.

"as the privacy considerations"


<= a style=3D"float:right;text-decoration:none" href=3D"https://mozphab-ietf.d= evsvcdev.mozaws.net/D14#inline-416" rel=3D"noreferrer" target=3D"_blank">Vi= ew Inlinedraft-iet= f-trans-gossip.txt:1431
SHOULD send gossip data in an already established TLS session. T= his
can be done through the use of HTTP Pipelining, SPDY, or HTTP= /2.

My understanding is that almost nobody currently does pipelining.


=
View Inlinedraft-ietf-trans-gossip.txt:1533
with SCTs received from other clients, and act upon them at so= me
period of time

This all seems pretty vague. Do you provide specific algorithms?


<= div style=3D"color:rgb(116,119,125);background:rgb(239,242,244);padding:6px= 8px;overflow:hidden">View Inlinedraft-ietf-trans-gossip.txt:1716
indexes.insert(r)
}
IMPORTANT: This algorithm does not terminate if the = number of STHs inside the validity window is < MAX_STH_TO_GOSSIP and is = extremely inefficient if you have a total of MAX_STH_TO_GOSSIP entries in t= he list.

View Inlinedraft-ietf-trans-gossip.txt:1752
&& now() - sth.timestamp > LOG_MMD
&& sth.proof_attempts !=3D UINT16_MAX
// Only fetch a proof is we have never received a pr= oof

What does this check do?


View Inlinedraft-ietf-trans-gossip.txt:2081
if(r not in indexes)
indexes.insert(r)
}
IMPORTANT: This algorithm has terrible performance w= hen
len(indexes) =3D=3D MAX_SCT_RECORDS_TO_GO=
SSIP

View Inlinedraft-ietf-trans-gossip.txt:2142
num_feedback_loop_failures =3D 0
if(num_submissions_succeeded !=3D UINT16_MAX )
num_submissions_succeeded++

Is this because the limit might be as high as UINT16_MAX

<= /div>
View Inlinedraft-ietf-trans-gossip.txt:2377
uint rndIndex1 =3D rand() % all_sct_stores.length
uint rndIndex2 =3D rand() % all_sct_stores[rndIndex1].observed_records.length
IMPORTANT: state that rand() has to be a CSPRNG.

REPOS= ITORY
rIETFREVIEW ietf-review



To: ekr-moz, ekr


_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans


--94eb2c0723a6444e2d055bb0ddf8-- From nobody Wed Oct 18 09:36:39 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7121321CB for ; Wed, 18 Oct 2017 09:36:37 -0700 (PDT) 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_20=-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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg 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 qhqF1_V10N2e for ; Wed, 18 Oct 2017 09:36:36 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 E57B1132031 for ; Wed, 18 Oct 2017 09:36:35 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id 1so11034764qtn.3 for ; Wed, 18 Oct 2017 09:36:35 -0700 (PDT) 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; bh=7dZpaZIiih125KJb7IUncmPePa7gYSIPvVS2WHIBMC4=; b=rOUWvAS6Wm//KqP5BYMgTIV5XgeerzwRt6s5WvTRDbLV6fNPp+qw/Itwq6WIbmRRWy mwgwNplExPiDlH/kLiNaWLulzC4+WZmRfyfkqfJPdMiWdHBpWwAecxL8rqkZqCU0MzHQ x3SarJX7QZXg0cobMYUw3DgtfXIszU138E7PI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7dZpaZIiih125KJb7IUncmPePa7gYSIPvVS2WHIBMC4=; b=S0rlsoucv1oPGjuStittLJx5blvlLVVPlzsueOTuCtYpV1yYIPgu89ywZVCtpq43P1 VNkEWSITarRQ/Zg2lnxxCjzhrbBR3NIaqP18brwAAbvKchWLnNgyVbwYCTW6jDFL+IUl J+MGdQdOFbBFRd9U7md4SMLUnUhI0BLjOrIOQSer0pzcZcETUipPsGMwyQf6jvHJWDBn ly7AnREC1s8pSlz9VIcd6+OGYStR2APK+bofN1VThURI2QENke9oFMLG7wKGa6jnBAUz tQ541HPqBwboWyWqgmbLlyAigeH1WCGrLgngR7W7UZbuTvEQE9gxIHbBXdRiminb0oDH pP8Q== X-Gm-Message-State: AMCzsaVNPB4yWRqIxqynSOzb3fwX3VqqX2TBAcGhZ7SeY2WVMVtG6INg cZj8DZF0OfJAA9X0Xim0Axd8lgQCUnLbuCOwy8W/V5j2 X-Google-Smtp-Source: ABhQp+SiGJ1c9CbEjv6hv5r/gW4bWaKTRNe/3fUX591Me9sMnkKcH67SOFUgnS4P+nRq2rZwGYNdQkIREHLfk5SDKvw= X-Received: by 10.237.63.129 with SMTP id s1mr4138365qth.89.1508344594874; Wed, 18 Oct 2017 09:36:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.53 with HTTP; Wed, 18 Oct 2017 09:36:14 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Wed, 18 Oct 2017 11:36:14 -0500 Message-ID: To: Richard Barnes Cc: Eric Rescorla , Trans , draft-ietf-trans-gossip@tools.ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Trans] AD Review: draft-ietf-trans-gossip-04 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 16:36:37 -0000 I just wanted to let the list know that Linus, dkg, and I saw these mails and are getting together to figure out next steps. -tom From nobody Fri Oct 20 17:31:09 2017 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D14134575; Fri, 20 Oct 2017 17:24:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ekr@rtfm.com, trans@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546979.20809.13594662005532414928.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:29 -0700 Archived-At: Subject: [Trans] trans - Requested session has been scheduled for IETF 100 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:30 -0000 Dear Melinda Shore, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. trans Session 1 (1:30:00) Monday, Afternoon Session II 1550-1720 Room Name: Orchard size: 50 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Public Notary Transparency Area Name: Security Area Session Requester: Melinda Shore Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: ipsecme tls dnsop Second Priority: curdle People who must be present: Eric Rescorla Melinda Shore Paul Wouters Resources Requested: Special Requests: --------------------------------------------------------- From hsheth2@gmail.com Sat Oct 28 15:21:00 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA38813FD85 for ; Sat, 28 Oct 2017 15:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6h9eXrGgjge4 for ; Sat, 28 Oct 2017 15:20:59 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 6813313FD81 for ; Sat, 28 Oct 2017 15:20:59 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id d9so12364518qtd.7 for ; Sat, 28 Oct 2017 15:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=V6yjnFA5WYr40BTfg6at83zgRHVo5MDUl9Yx70Hwdqw=; b=eucoY0jp6AmRzJ6ofb//ENqo+MYrNFAPjJ8YBzPvStn5CI0ligh1iOnlHpucgVxc5R 9GcP43GODxYTRGqCdSbRWlQ1lny1JdJCqbQAkZaVze1Q2sI7v4DPzXGiIGMKFXjsXZwv aUBiqLUdHIvFOt0nEDNdkCG8orF9O/jNGDVkL2A5NzCaAJOwZQpzECAfu8bjPaDHlnxX 6y3JiW7d11R0npeVBje9H4k5wrBlxZzVMLrQzKuolotyDgz90FbFfotqs//OC1Ao1+w0 sG6rrLFXKc5mfAZTGo6hAR+lATz9B4a8XWtxYHygWaXf1x0DGGiXsG4aEBWpFEEGewuv Z9iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=V6yjnFA5WYr40BTfg6at83zgRHVo5MDUl9Yx70Hwdqw=; b=qX8u5zZ1Uge5MllanLh6IkqzoP0Rqq3LRgJhF88vdGhQUteLf46KTUJxSBe9dlOzYH bryIql97oKdffvuoUmjGsGgmeho8VHsvTWtYpmBofNsjliOJXzlh4OYvVwoTRVzR4zKz 4+/E6CcUuFxeOUCyIDUe718r8JKYQC2yXY+MnzyWUp6WZu1QrOLEW5tVnjMDjFJNl/fF iTOuxmKHRZrqHYNIjMxRE4q2iDOIGMdtG/XhJ/8QCOH47TWqX7KaS9Sve6WIXhcAyXL9 NadNjgJLycceZPCtEk1mtHUN6i2zwEozfPurW6i2OeQGvBRtCHKuOO6WrZIdllmjMucO OVRQ== X-Gm-Message-State: AMCzsaWs7cgVNrTv986eJo71Wmv5Ucyb6hzfYhUiZLH8MqyFmUKBBmpQ EEROEXjI7ByXXszhHAAoYyP6VgRT9Vk= X-Google-Smtp-Source: ABhQp+QPg54k/GdAxrksd1WQ6s/r35+LvT+Zt8I/A8QPzZBkk2zyLEwIE0jatr4NVhJjKM4OZUIcWA== X-Received: by 10.200.48.54 with SMTP id f51mr7413651qte.39.1509229258240; Sat, 28 Oct 2017 15:20:58 -0700 (PDT) Received: from [192.168.1.177] (pool-173-76-171-121.bstnma.fios.verizon.net. [173.76.171.121]) by smtp.gmail.com with ESMTPSA id j48sm7738453qta.96.2017.10.28.15.20.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Oct 2017 15:20:57 -0700 (PDT) From: Harshal Sheth Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Message-Id: <97047FDF-70AC-423F-B242-850F0AAA1C80@gmail.com> Date: Sat, 28 Oct 2017 18:20:56 -0400 Cc: "Salz, Rich" , Paul Wouters , "melinda.shore@gmail.com" To: trans@ietf.org X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: [Trans] A CT Research Paper X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 22:22:55 -0000 We=E2=80=99d like to make this paper on CT, sponsored by Akamai, = available to the community at: https://harshalsheth.com/ct.pdf =46rom the abstract: =E2=80=9COver 120 million certificates contained = within such logs were analyzed to understand security trends and metrics = within the SSL ecosystem. In addition, these certificates were examined = with the end-goal of identifying suspicious certificates, as a = certificate monitor would do. A number of certificates were identified = as violating the CA/B Forum Baseline Requirements and using weak = cryptographic techniques such as MD5 and 512-bit RSA keys." Thanks, Harshal Sheth= From nobody Mon Oct 30 16:29:31 2017 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B687513FB0D; Mon, 30 Oct 2017 16:29:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trans@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940616370.28209.17088055948612201841@ietfa.amsl.com> Date: Mon, 30 Oct 2017 16:29:23 -0700 Archived-At: Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-27.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:29:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency WG of the IETF. Title : Certificate Transparency Version 2.0 Authors : Ben Laurie Adam Langley Emilia Kasper Eran Messeri Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-27.txt Pages : 55 Date : 2017-10-30 Abstract: This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-27 https://datatracker.ietf.org/doc/html/draft-ietf-trans-rfc6962-bis-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/