Draft: draft-ietf-ppm-dap

Commentary: Remove the requirement that implementations use with a fixed , pre - negotiated secret and instead allow any client auth scheme that is composable with HTTP ( which includes ) . Relevant to 
 I had to do a rebase to fix a trivial conflict with . These changes were approved about a week ago and there 's been no further comment , so I am merging . 
 contains a nice definition and discussion of the notions of privacy ( meaning protecting any individual client 's measurement from being seen ) and robustness ( meaning that the aggregates delivered to a collector are accurate aggregations over the inputs ) . DAP 's security considerations has definitions of privacy and correctness , and we refer to robustness and soundness in a few places . We should align our definitions with VDAF ( or just refer to VDAF 's definitions ) and consistently use the term " robustness " throughout DAP . 
 PR , please ! 
 I 'm going to get this done for draft-02 , hopefully early next week . 
 At IETF 114 , we discussed how contains inconsistent guidance and/or requirements on authentication . Some details can be found in , especially slide 7 . DAP should figure out what the security requirements are for each of the channels between the protocol participants , and then decide what if any prescriptions to make . 
 In my presentation at IETF 114 , I argued that DAP should say as little as possible about authentication , in order to allow organizations deploying DAP to use whatever authn mechanism they already support for their HTTP APIs ( e.g. , maybe a vendor already operates a bunch of other APIs using OAuth 2 and so using that for DAP makes it easy for them to fit it into their existing permissions model ) . suggested that we should reach out to the HTTP WG for guidance here ( which might prompt the HTTP WG to develop some guidance here ) . One clear precedent to look at here is ACME , which requires the use of JWT for authentication of requests . We should talk to ACME operators in the wild ( like Let 's Encrypt ) to see what they think . discusses one part of this problem . 
 I think it would be useful to minimizing security considerations language in the Message Security sections , but I do n't have a clear idea how . I think this is good enough for now , hence the approval , but let 's see if we can get more feedback before merging .
Paragraph (version A):
Communications between DAP entities are carried over HTTPS RFC2818.
HTTPS provides server authentication and confidentiality.  When
client authenticaiton is also required, the client uses the mechanism
described in https-sender-auth.
Paragraph (version B):
Communications between DAP participants are carried over HTTPS
RFC9110.  HTTPS provides server authentication and confidentiality.
Use of HTTPS is REQUIRED.
Paragraph (version B):
DAP is made up of several sub-protocols in which different subsets of
the protocol's participants interact with each other.
Paragraph (version B):
In those cases where a channel between two participants is tunneled
through another protocol participant, DAP mandates the use of public-
key encryption using HPKE to ensure that only the intended recipient
can see a message in the clear.
Paragraph (version B):
In other cases, DAP requires HTTPS client authentication.  Any
authentication scheme that is composable with HTTP is allowed.  For
example, OAuth2 credentials are presented in an Authorization HTTP
header, which can be added to any DAP protocol message, or TLS client
certificates are another viable solution.  This allows organizations
deploying DAP to use existing well-known HTTP authentication
mechanisms that they already support.  Discovering what
authentication mechanisms are supported by a DAP participant is
outside of this document's scope.
Paragraph (version A):
Some HTTP requests in the DAP protocol require the sender to
authenticate its request.  It does so as described here.
Paragraph (version A):
Prior to the start of the protocol, the sender and receiver arrange
to share a secret sender-specific API token, which MUST be suitable
for representation in an HTTP header.
Paragraph (version A):
For requests requiring authentication, the sender includes a "DAP-
Auth-Token" header in its HTTP request containing the API token.
Paragraph (version A):
To authenticate the request, the receiver looks up the token for the
sender as determined by the task configuration.  (See task-
configuration.)  If the value of the "DAP-Auth-Token" header does not
match the token, then the receiver MUST abort with error
"unauthorizedRequest" and HTTP status code 403 Forbidden.
Paragraph (version A):
The helper stores a bearer token used to authenticate HTTP requests
from the leader.  Likewise, the leader stores a bearer token to
authenticate HTTP request from the collector.  The authentication
mechanism is described in https-sender-auth.
Paragraph (version B):
The contents of each input share must be kept confidential from
everyone but the client and the aggregator it is being sent to.  In
addition, clients must be able to authenticate the aggregator they
upload to.
Paragraph (version B):
HTTPS provides confidentiality between the DAP client and the leader,
but this is not sufficient since the helper's report shares are
relayed through the leader.  Confidentiality of report shares is
achieved by encrypting each report share to a public key held by the
respective aggregator.  Clients fetch the public keys from each
aggregator over HTTPS, allowing them to authenticate the server.
Paragraph (version B):
Aggregators MAY require clients to authenticate when uploading
reports.  This is an effective mitigation against Sybil attacks in
deployments where it is practical for each client to have an identity
provisioned (e.g., a user logged into an online service or a hardware
device programmed with an identity).  If it is used, client
authentication MUST use a scheme that meets the requirements in
request-authentication.
Paragraph (version B):
In some deployments, it will not be practical to require clients to
authenticate (e.g., a widely distributed application that does not
require its users to login to any service), so client authentication
is not mandatory in DAP.
Paragraph (version A):
Let "[aggregator]" denote the helper's API endpoint.  The leader
sends a POST request to "[aggregator]/aggregate" with its
AggregateInitializeReq message as the payload.  The media type is
"message/dap-aggregate-initialize-req".  In addition, this request
MUST be authenticated as described in https-sender-auth.
Paragraph (version B):
Let "[aggregator]" denote the helper's API endpoint.  The leader
sends a POST request to "[aggregator]/aggregate" with its
AggregateInitializeReq message as the payload.  The media type is
"message/dap-aggregate-initialize-req".
Paragraph (version A):
For each aggregator endpoint "[aggregator]" in
"AggregateContinueReq.task_id"'s parameters except its own, the
leader sends a POST request to "[aggregator]/aggregate" with
AggregateContinueReq as the payload and the media type set to
"message/dap-aggregate-continue-req".  In addition, this request MUST
be authenticated as described in https-sender-auth.
Paragraph (version B):
For each aggregator endpoint "[aggregator]" in
"AggregateContinueReq.task_id"'s parameters except its own, the
leader sends a POST request to "[aggregator]/aggregate" with
AggregateContinueReq as the payload and the media type set to
"message/dap-aggregate-continue-req".
Paragraph (version B):
Aggregate sub-protocol messages must be confidential and mutually
authenticated.
Paragraph (version B):
The aggregate sub-protocol is driven by the leader acting as an HTTPS
client, making requests to the helper's HTTPS server.  HTTPS provides
confidentiality and authenticates the helper to the leader.
Paragraph (version B):
Leaders MUST authenticate their requests to helpers using a scheme
that meets the requirements in request-authentication.
Paragraph (version A):
This request MUST be authenticated as described in https-sender-auth.
To handle the leader's request, the helper first ensures that the
request meets the requirements for batch parameters following the
procedure in batch-validation.
Paragraph (version B):
To handle the leader's request, the helper first ensures that the
request meets the requirements for batch parameters following the
procedure in batch-validation.
Paragraph (version B):
Collect sub-protocol messages must be confidential and mutually
authenticated.
Paragraph (version B):
HTTPS provides confidentiality and authenticates the leader to the
collector.  Additionally, the leader encrypts its aggregate share to
a public key held by the collector.
Paragraph (version B):
Collectors MUST authenticate their requests to leaders using a scheme
that meets the requirements in request-authentication.
Paragraph (version B):
The collector and helper never directly communicate with each other,
but the helper does transmit an aggregate share to the collector
through the leader, as detailed in collect-aggregate.  The aggregate
share must be confidential from everyone but the helper and the
collector.
Paragraph (version B):
Confidentiality is achieved by having the helper encrypt its
aggregate share to a public key held by the collector.
Paragraph (version B):
These are both attacks on robustness, which we already assume to hold
only if both aggregators are honest, which puts these malicious-
leader attacks out of scope (see sec-considerations.
Paragraph (version A):
Attacks may also come from the network.  Thus, it is required that
the aggregators and collector communicate with one another over
mutually authenticated and confidential channels.