
From nobody Tue Dec 13 10:11:08 2016
Return-Path: <allison.mankin@gmail.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CB1129463 for <perpass@ietfa.amsl.com>; Tue, 13 Dec 2016 10:11:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 uUFfyUrKBDev for <perpass@ietfa.amsl.com>; Tue, 13 Dec 2016 10:11:04 -0800 (PST)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 D02CD12946F for <perpass@ietf.org>; Tue, 13 Dec 2016 10:11:03 -0800 (PST)
Received: by mail-vk0-x229.google.com with SMTP id p9so73833602vkd.3 for <perpass@ietf.org>; Tue, 13 Dec 2016 10:11:03 -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; bh=z3Qtv8dQYEXhvH9XTbYrd33Xw0OLeD1VmhBKIb0MFrQ=; b=SD5PMvRRjmAC0xPSi53N57b8sbuVtaHlitiBMSn0knGMXrdXCPDnSFKGnHdHjx8OfY ALoFrhC0m8UL52HrvcWlSuXZftfHwkVhHsgUh7In4d44MhpdCEkSvBxy0dzwguiWAyxQ g7DK0bVh1pIFGxujmI0ILlGMqOj1qYM6FtisLsikL0/+Wvt/W1QwYluXOVwZk6S81gSw GjpLcT/A5arzVu15HFKxexHcMSBU3Kr4wlIM94tOt/tKZ3BBpCDmMAZG/x0vvdnYN8Ux U3eLvQHqLeki0fmGdGfvPd0NkuUGJRfffI88fsUjj7cqZ8XE3AHkNJP2xde2DyMzPa+n J8Bg==
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; bh=z3Qtv8dQYEXhvH9XTbYrd33Xw0OLeD1VmhBKIb0MFrQ=; b=VA7D3hpTXLhsGFPqd8sdgaXKYHgsxxMN3xhnxisPZtizCB0DS90teClW9DOB6EQAtK 7atz5dH2jj4cO5dhh3HLA6clvwGVVzCUt0OPYH09721/dUSwaQkU18nZBebzoo9tr/9j iwwo6ugOXkjPIdhoWSZJ3u9qWo2f7qnPaoU7zZ488vvKl20wfSrThZmg0Koe2rz6+fEN soTNM4bbVyyMe/f27pm1M63kb/qnlRkBLaCzK6RsqYk1fBSfYXrxqOO3GOz85tXKgU8F Yo2xZl1kQQWwAeL+ZCne1CRWehIrfo/vJl5uGWuMSeVEiBvg7giwbe9HiekZ2DTzk4Q9 svXA==
X-Gm-Message-State: AKaTC03SH4MxuYChj3ebJ+Sg5CZ4v1TM6iM+tVX+Xwhd6Xy3sieC3Q0nCjTZ2zSVIfuvp2FwvkYzGty1DSCF3g==
X-Received: by 10.176.69.195 with SMTP id u61mr23881172uau.165.1481652662725;  Tue, 13 Dec 2016 10:11:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.126.10 with HTTP; Tue, 13 Dec 2016 10:11:02 -0800 (PST)
In-Reply-To: <CAP8yD=vEeoM=ZhF1gaNwkc+DEQcST7GjFbWWwwMiYTgxG7QyJg@mail.gmail.com>
References: <CAP8yD=vEeoM=ZhF1gaNwkc+DEQcST7GjFbWWwwMiYTgxG7QyJg@mail.gmail.com>
From: Allison Mankin <allison.mankin@gmail.com>
Date: Tue, 13 Dec 2016 13:11:02 -0500
Message-ID: <CAP8yD=uGR0ptPX-RX_g_+-9-4pFnYBb6C3y+1Gv=s8MyhvRJsw@mail.gmail.com>
To: perpass@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c11be5ca474f205438e24c9
Archived-At: <https://mailarchive.ietf.org/arch/msg/perpass/7vIm-Y6jDVeCg9AsFwoT52Hx8P8>
Cc: Sara Dickinson <sara@sinodun.com>, ajm <allison.mankin@gmail.com>
Subject: [perpass] Fwd: Call for Papers: NDSS Workshop on DNS Privacy
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2016 18:11:06 -0000

--94eb2c11be5ca474f205438e24c9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=E2=80=8BDear PERPASS list,

Please consider submitting to the NDSS First Workshop on DNS Privacy
(DPRIV17).

The call for papers is here:   DPRIV17
<https://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017/=
dns-privacy-workshop-2017-call-papers>.


Elevator pitch:  DNS queries and domain names are metadata and there are
many new directions (and open questions) for mitigating privacy issues for
them.

Location and Important dates:
Workshop Location: San Diego, CA, USA

Workshop date: 2017-02-26 (co-located with NDSS 2017)

Submissions: 2017-01-09 anywhere-on-earth

Final date for notifications and invitations to present at the workshop:
2017-02-03
Submissions may be new papers, papers already published, Short Papers, or
Position Papers.  Also, please contact the TPC chairs if you want to
suggest a panel.

Allison and Sara
=E2=80=8B and Stephen (who said yes to our posting here)=E2=80=8B


------------
*Workshop on DNS Privacy DPRIV17 (#NoMoreCowbell)* BackgroundDNS Privacy
has been a growing concern of the IETF and others in the Internet
engineering community for the last few years.  Almost every activity on the
Internet starts with a DNS query (and often several).

   - Those queries can reveal not only what websites an individual visits
   but also metadata about other services such as the domains of email
   contacts or chat services.
   - Whilst the data in the DNS is public, individual DNS transactions made
   by an end user *should not* be public.
   - Today, however DNS queries are sent in *clear text* (using UDP or TCP)
   which means passive eavesdroppers can observe all the DNS lookups
   performed.
   - The DNS is a globally distributed system that crosses international
   boundaries and often uses servers in many different countries in order t=
o
   provide resilience.
   - It is well known that the NSA used the MORECOWBELL tool to perform
   mass surveillance of DNS traffic, and other surveillance techniques
   involving DNS almost certainly are in play today.
   - Some ISPs embed user information (e.g. a user ID or MAC address)
   within DNS queries that go to the ISP=E2=80=99s resolver in order to pro=
vide
   services such as Parental Filtering. This allows for fingerprinting of
   individual users.
   - Some CDNs embed user information (e.g. client subnets) in queries from
   resolvers to authoritative servers (to geo-locate end users). This allow=
s
   for correlation of queries to particular subnets.
   - Some ISPs log DNS queries at the resolver and share this information
   with third-parties in ways not known or obvious to end users.

The IETF's DPRIVE (*D*NS *PRIV*ate *E*xchange) Working Group has taken
initial protocol steps to address these concerns (with much of the early
work focussing on the stub to resolver problem), publishing DNS Privacy
Considerations (RFC 7626), Specification for DNS over Transport Layer
Security (RFC 7858), and The EDNS(0) Padding Option (RFC 7830), and DNS
Query Name Minimisation to Improve Privacy (RFC 7816). However because of
the great diversity of the DNS ecosystem, and the pervasive role of DNS and
domain names in Internet applications and security, much is not fully
understood or resolved.

The goal of this workshop is to bring together privacy and Internet
researchers with a diversity of backgrounds and views, to identify
promising long-term mitigations of the broad space of DNS privacy risks.

--94eb2c11be5ca474f205438e24c9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div style=3D"font-family:arial=
,helvetica,sans-serif" class=3D"gmail_default">=E2=80=8BDear PERPASS list,<=
br></div><br>Please consider submitting to the NDSS First Workshop on DNS P=
rivacy (DPRIV17).=C2=A0 <br><div dir=3D"ltr"><div style=3D"font-family:aria=
l,helvetica,sans-serif"><br></div><div style=3D"font-family:arial,helvetica=
,sans-serif">The call for papers is here: =C2=A0<a href=3D"https://www.inte=
rnetsociety.org/events/ndss-symposium/ndss-symposium-2017/dns-privacy-works=
hop-2017-call-papers" target=3D"_blank"> DPRIV17</a>.=C2=A0 <br><br>Elevato=
r pitch:=C2=A0 DNS queries and domain names are metadata and there are many=
 new directions (and open questions) for mitigating privacy issues for them=
.<br><br>Location and Important dates:<br>Workshop Location: San Diego, CA,=
 USA
<p>Workshop date: 2017-02-26 (co-located with NDSS 2017)=C2=A0</p>
<p>Submissions: 2017-01-09 anywhere-on-earth</p>
<p>Final date for notifications and invitations to present at the workshop:=
 2017-02-03</p>Submissions may be new papers, papers already published, Sho=
rt Papers, or Position Papers.=C2=A0 Also, please contact the TPC chairs if=
 you want to suggest a panel.<br><br></div><div style=3D"font-family:arial,=
helvetica,sans-serif">Allison and Sara<div style=3D"font-family:arial,helve=
tica,sans-serif;display:inline" class=3D"gmail_default">=E2=80=8B and Steph=
en (who said yes to our posting here)=E2=80=8B</div><br></div><div style=3D=
"font-family:arial,helvetica,sans-serif"><br>------------<br><h3><b>Worksho=
p on DNS Privacy DPRIV17 (#NoMoreCowbell)</b></h3>
<h3>Background</h3><h3><font size=3D"2"><span style=3D"font-weight:normal">=
DNS Privacy has been a growing concern of the IETF and others in the=20
Internet engineering community for the last few years.=C2=A0 Almost every=
=20
activity on the Internet starts with a DNS query (and often several).=C2=A0
</span></font></h3><ul><li>Those queries can reveal not only what websites =
an individual visits
 but also metadata about other services such as the domains of email=20
contacts or chat services. =E2=80=A8</li><li>Whilst the data in the DNS is =
public, individual DNS transactions made by an end user <b>should not</b> b=
e public.=E2=80=A8</li><li>Today, however DNS queries are sent in <b>clear =
text</b> (using UDP or TCP) which means passive eavesdroppers can observe a=
ll the DNS lookups performed.=E2=80=A8</li><li>The DNS is a globally distri=
buted system that crosses international=20
boundaries and often uses servers in many different countries in order=20
to provide resilience.=E2=80=A8</li><li>It is well known that the NSA used =
the MORECOWBELL tool to perform=20
mass surveillance of DNS traffic, and other surveillance techniques=20
involving DNS almost certainly are in play today. =C2=A0=E2=80=A8</li><li>S=
ome ISPs embed user information (e.g. a user ID or MAC address)=20
within DNS queries that go to the ISP=E2=80=99s resolver in order to provid=
e=20
services such as Parental Filtering. This allows for fingerprinting of=20
individual users.=E2=80=A8</li><li>Some CDNs embed user information (e.g. c=
lient subnets) in queries=20
from resolvers to authoritative servers (to geo-locate end users). This=20
allows for correlation of queries to particular subnets.=E2=80=A8</li><li>S=
ome ISPs log DNS queries at the resolver and share this information
 with third-parties in ways not known or obvious to end users.=C2=A0</li></=
ul>
<p>The IETF&#39;s DPRIVE (<b>D</b>NS <b>PRIV</b>ate <b>E</b>xchange)
 Working Group has taken initial protocol steps to address these=20
concerns (with much of the early work focussing on the stub to resolver=20
problem), publishing DNS Privacy Considerations (RFC 7626),=20
Specification for DNS over Transport Layer Security (RFC 7858), and The=20
EDNS(0) Padding Option (RFC 7830), and DNS Query Name Minimisation to=20
Improve Privacy (RFC 7816). However because of the great diversity of=20
the DNS ecosystem, and the pervasive role of DNS and domain names in=20
Internet applications and security, much is not fully understood or=20
resolved. =C2=A0</p>
<p>The goal of this workshop is to bring together privacy and Internet=20
researchers with a diversity of backgrounds and views, to identify=20
promising long-term mitigations of the broad space of DNS privacy risks.</p=
><br><br><br><br><br></div></div>
</div><br></div>

--94eb2c11be5ca474f205438e24c9--


From nobody Wed Dec 14 23:22:55 2016
Return-Path: <giovane.moura@sidn.nl>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FC5129863 for <perpass@ietfa.amsl.com>; Wed, 14 Dec 2016 23:22:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.197
X-Spam-Level: 
X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl
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 vtdUHNn8_IAw for <perpass@ietfa.amsl.com>; Wed, 14 Dec 2016 23:22:51 -0800 (PST)
Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF463129430 for <perpass@ietf.org>; Wed, 14 Dec 2016 23:22:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed;  h=to:from:subject:message-id:date:user-agent:mime-version:content-type:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=ptntoLBsGKExnkXTNIywe9rS9Og+NaV5lfnxhmcp4oI=; b=QCF1M/kYK7YtHmyiXujxq/q15Q61lUTbcMbKIBkPPoezVNysd0hFvaC96/COmKZnka7xShgYInYJR5rKu+gsTrtCpbkHbj+FxTOBM7wp3XOIght+jq6Fc76R3T+PevvxGnNB508PtVAzfHSq9v6Jbz2sVAm3n74WxQzEBXN8HR3bx3b8p70xJdNjVJrg4A5xjB3zKqxIx5534nvvT6I+I0nqA9u39R2yZtJrmXuCCIwuyHNCDRZryrrV6QjMsgVe/QfNWGQylWl5QQi7EB1PkT92TPerguqt0ldQplvLmO8ibISUopJKRJANoOidKvCGUplOxbvZ10RXj2VwZ5Ag6w==
Received: from ka-mbx02.SIDN.local ([192.168.2.178]) by arn2-kamx.sidn.nl  with ESMTP id uBF7MmFT023033-uBF7MmFV023033 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for <perpass@ietf.org>; Thu, 15 Dec 2016 08:22:48 +0100
Received: from [94.198.159.134] (94.198.159.134) by ka-mbx02.SIDN.local (192.168.2.178) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 15 Dec 2016 08:22:46 +0100
To: <perpass@ietf.org>
From: "Giovane C. M. Moura" <giovane.moura@sidn.nl>
Message-ID: <e104ac92-8b23-90c3-aa6f-ed2cc6730538@sidn.nl>
Date: Thu, 15 Dec 2016 08:22:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [94.198.159.134]
X-ClientProxiedBy: ka-hubcasn02.SIDN.local (192.168.2.172) To ka-mbx02.SIDN.local (192.168.2.178)
X-FEAS-SPF: 2 / 2, ip=94.198.159.134, helo=, mailFrom=giovane.moura@sidn.nl, headerFrom=giovane.moura@sidn.nl
Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of giovane.moura@sidn.nl designates 94.198.159.134 as permitted sender) smtp.mailfrom=giovane.moura@sidn.nl
Archived-At: <https://mailarchive.ietf.org/arch/msg/perpass/Ft0SH1Q6lMX7FUU6h5mH6sWd6GY>
Subject: [perpass] Paper on Let's Encrypt adoption
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2016 07:22:53 -0000

Hello folks,

We have this new paper that some of the list may find interesting. It's
about the adoption of Let's Encrypt[1]:

>From the paper [2]:

"Once [costs and complexity] are eliminated, it enables big hosting
providers to issue and deploy certificates for their customers in bulk,
thus quickly and automatically enable encryption across a large number
of domains. For example, we have shown that currently, 47% of LE
certified domains are hosted at three large hosting companies
(Automattic/wordpress.com, Shopify, and OVH)."

More discussion in [3][4].

Best,

/giovane


[1] https://letsencrypt.org
[2] https://arxiv.org/pdf/1612.03005.pdf
[3] https://www.schneier.com/blog/archives/2016/12/lets_encrypt_is.html
[4]
https://www.reddit.com/r/letsencrypt/comments/5hvt2v/lets_encrypt_filling_a_void_in_ca_industry/

