Subject: [Pearg] Call for adoption: draft-wood-pearg-website-fingerprinting-00

From: Sara Dickinson <[email-masked]>
Date: Mon, 13 Jan 2020 09:42:14 +0000

Hi All, 

A draft called ‘Network-Based Website Fingerprinting' (https://datatracker.ietf.org/doc/draft-wood-pearg-website-fingerprinting/) has been presented twice in PEARG meetings and received positive feedback at IETF 106. This email starts a two week Call for Adoption of this document.

Please review this draft to see if you think it is suitable for adoption by PEARG and send comments to the list, clearly stating your view.

This call for adoption ends on 27th January 2020.

Sara.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Jan 2020 12:01:31 +0000

Hiya,

On 13/01/2020 09:42, Sara Dickinson wrote:
> Hi All,
> 
> A draft called ‘Network-Based Website Fingerprinting'
> (https://datatracker.ietf.org/doc/draft-wood-pearg-website-fingerprinting/)
> has been presented twice in PEARG meetings and received positive
> feedback at IETF 106. This email starts a two week Call for Adoption
> of this document.
> 
> Please review this draft to see if you think it is suitable for
> adoption by PEARG and send comments to the list, clearly stating your
> view.
> 

I did a quick scan and very much support adoption. I plan
to give it a more thorough read at some point.

Three comments, none of which ought delay adoption:

1. I think it'd be good for the RG to have a discussion
about how one might develop section 8 further. That may
or may not mean more text for this draft or could result
in text that ends up in other drafts or in IETF drafts.
Not sure when it'd be best to try start that, but I'm
sure the chairs can figure that out.

2. A suggested addition to section 7: What mechanisms
to counter WF might make sense for generic libraries
(e.g. TLS/HTTP libraries) and HTTP servers? By "generic"
here I mean code that doesn't know anything about the
resources will be served/consumed. And in saying
"mechanisms" I include APIs and controls that turn on
or off or configure protocol-level anti-WF schemes.

3. Another suggestion for section 7: How might one
provide defenses that are effective for small hosters
(as opposed to mega-scale CDNs)? (Note that I didn't
follow the references yet, so that could already be
covered by some of the cited work - just ignore me
if so:-)

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Jan 2020 05:15:01 -0800

I am in favor of adoption.

On Mon, Jan 13, 2020 at 4:01 AM Stephen Farrell <[email-masked]>
wrote:

> > (
> https://datatracker.ietf.org/doc/draft-wood-pearg-website-fingerprinting/)
> --
> Pearg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/pearg
>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 14 Jan 2020 16:10:42 -0800

> This call for adoption ends on 27th January 2020.

I think this is a great document to push forward into documentation and
support adopting it.
-- 
Wes Hardaker
USC/ISI

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 20 Jan 2020 08:16:06 -0800

Hi Stephen,

Please see inline below.

> sure the chairs can figure that out.

Agreed. I'll spin up a new thread on this topic!

> or off or configure protocol-level anti-WF schemes.

I filed an issue for this: 

   https://github.com/chris-wood/ietf-fingerprinting/issues/2

Would you mind submitting a PR to address this?

> covered by some of the cited work - just ignore me

The references don't cover this area (well) -- they're mostly focused on what clients can do with little server assistance. I filed an issue for this:

   https://github.com/chris-wood/ietf-fingerprinting/issues/3

As above, would you be open to adding a PR for this?

Thanks for the review and feedback!

Best,
Chris

---

From: Amelia Andersdotter <[email-masked]>
Date: Tue, 21 Jan 2020 11:38:04 +0100

Hi all,

I support adoption. Bearing mind Stephen's comments from earlier, there
may some work already ongoing in IPSecME:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/

Abstract:

"This document describes a mechanism to enhance IPsec traffic flow
security by adding traffic flow confidentiality to encrypted IP
encapsulated traffic.  Traffic flow confidentiality is provided by
obscuring the size and frequency of IP traffic using a fixed-sized,
constant-send-rate IPsec tunnel.  The solution allows for congestion
control as well."

There's also a project in IEEE 802.1 (well, it's starting up at this
time) that tries to explore ways of mitigating web traffic
fingerprinting by ensuring packet length/timing etc. are homogeneous. It
will be covered eventually here: https://1.ieee802.org/security/

best regards,

Amelia

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 21 Jan 2020 08:32:05 -0800

> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/

Thanks for raising this, Amelia! I filed an issue to cite it accordingly:

   https://github.com/chris-wood/ietf-fingerprinting/issues/4

Best,
Chris