Re: [Privacy-pass] Francesca Palombini's Discuss on draft-ietf-privacypass-auth-scheme-12: (with DISCUSS)

[Francesca Palombini <[e-mail]>]

I just updated my ballot. Thank you again Martin, and thank you authors for the work!

Francesca

From: Tommy Pauly <[e-mail]>
Date: Tuesday, 12 September 2023 at 22:48
To: Tommy Pauly <tpauly=[e-mail]>
Cc: Francesca Palombini <[e-mail]>, The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Privacy-pass] Francesca Palombini's Discuss on draft-ietf-privacypass-auth-scheme-12: (with DISCUSS)
To follow up here, we’ve published a revision of the auth-scheme document to address the comments here:

https://www.ietf.org/archive/id/draft-ietf-privacypass-auth-scheme-13.html

Thanks!
Tommy


On Sep 6, 2023, at 9:49 AM, Tommy Pauly <tpauly=[e-mail]> wrote:

Hi Francesca,

We’ve been going through the various issues from Martin (and we’ve merged many of the smaller / editorial changes).

I did want to highlight a PR I just opened to address the main issues that your DISCUSS is based on:

https://github.com/ietf-wg-privacypass/base-drafts/pull/474<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-664591941691977b&q=1&e=fdac17ef-b264-4394-bb4f-18a69003d362&u=https%3A%2F%2Fgithub.com%2Fietf-wg-privacypass%2Fbase-drafts%2Fpull%2F474>

Specifically, this removes the web-specific considerations, and replaces the “user interaction” section with sections on “client behavior” and “origin behavior”. The pieces of the old text that still apply generally have been recontextualized and reorganized.

Thanks!
Tommy


On Aug 30, 2023, at 3:23 AM, Francesca Palombini via Datatracker <[e-mail]> wrote:

Francesca Palombini has entered the following ballot position for
draft-ietf-privacypass-auth-scheme-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-privacypass-auth-scheme/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work on this document.

Many thanks to Martin Thomson for his in-depth HTTPDIR review:
https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0156.html. Martin
brings up a number of very valid comments
(https://github.com/ietf-wg-privacypass/base-drafts/issues/created_by/martinthomson<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-0604b8bdedbd1d56&q=1&e=fdac17ef-b264-4394-bb4f-18a69003d362&u=https%3A%2F%2Fgithub.com%2Fietf-wg-privacypass%2Fbase-drafts%2Fissues%2Fcreated_by%2Fmartinthomson>)
some of which I think should be easily addressed. Some of these however seem
more important and I am looking forward to the authors replies.

Posting Martin's review below (and CC'ing him in), for archiving purposes.

--
This document describes a new authentication scheme for HTTP that enables
authorization via Privacy Pass.

I've been tracking this work at a high level, but I've never reviewed this
document in any detail until now.  After taking a closer look, I've found quite
a few problems.

https://github.com/ietf-wg-privacypass/base-drafts/issues<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-91fc6b10f156d872&q=1&e=fdac17ef-b264-4394-bb4f-18a69003d362&u=https%3A%2F%2Fgithub.com%2Fietf-wg-privacypass%2Fbase-drafts%2Fissues> lists 23 new issues.
https://github.com/ietf-wg-privacypass/base-drafts/pull/459<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-4f576d70bff73778&q=1&e=fdac17ef-b264-4394-bb4f-18a69003d362&u=https%3A%2F%2Fgithub.com%2Fietf-wg-privacypass%2Fbase-drafts%2Fpull%2F459> suggests some
editorial fixes on top of those.

A number of those issues are significant enough to suggest that the document is
not ready.  I expect that most will be easily handled, but there are a couple
of trickier ones.

https://github.com/ietf-wg-privacypass/base-drafts/issues/448<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-0625ca2cccc56b70&q=1&e=fdac17ef-b264-4394-bb4f-18a69003d362&u=https%3A%2F%2Fgithub.com%2Fietf-wg-privacypass%2Fbase-drafts%2Fissues%2F448> is serious enough
to draw special attention to.  In short, Section 3 of the document is very
problematic as it makes a lot of assumptions about a particular deployment
environment.  Some of those assumptions are -- I think -- bad.  It looks like
the intent of this section is to describe how this mechanism might be deployed
safely to the Web.  This raises a number of concerns:

1. This is an IETF document.  The W3C is probably in a better position to come
to conclusions about what is (or isn't) appropriate for deployment to the Web.

2. The bounds on user agent behaviour are not specified in sufficient detail.
There is definitely a case to be made for this to be deployed to the web as
envisaged, with different implementations making their own choices.  But if the
intent is to describe the nature of the risks involved in deployment to the
Web, then there is not enough detail to guide the successful implementation and
deployment of this feature.

3. There are a number of implicit assumptions throughout that are not
adequately explained.  For instance, there is discussion of use of this
mechanism across origins or sites, despite that violating established Web
norms.  There is discussion of that cross-site transfer occurring without user
involvement, which is a oft-used safeguard against such privacy leaks.  But the
necessary preconditions for that transfer are not articulated.  There are
potentially scenarios where this sort of transfer could be safe, but there are
great many where it is absolutely not.  The document seems to be assuming that
the token carries a very particular signal along with it, namely that the
client acts on behalf of an entity that the attester (and transitively, the
issuer) believe not to be abusive.

I've suggested in the issue that this section needs considerable revision.
There are general requirements on the use of the protocol that are currently
buried in amoungst Web-specific requirements.  Those will need to be teased
out.  It's possible that the accompanying architecture document could cover
this material, but I'm not seeing it there.

Then there are the Web-specific requirements that really belong in a
Web-specific document, which is probably something that the W3C is in a better
position to produce than the IETF.  Here, the precise set of safeguards will
probably be some mixture of client-specific policy and widely-agreed policy, so
getting that mix right will need careful consideration.

Despite all this, I'm generally supportive of this protocol.  It is a design
that should work well in a great many contexts, but getting this right for the
Web requires more than this document provides.





--
Privacy-pass mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/privacy-pass

--
Privacy-pass mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/privacy-pass