watch for increasing numbers of end users uploading significant amounts of content.  3. 3.1.

watch for increasing numbers of end users uploading significant amounts of content. <ins> 2.6. The causes of unpredictable usage described in sec-unpredictable were more or less the result of human choices, but we were reminded during a post-IETF 107 meeting that humans are not always in control, and forces of nature can cause enormous fluctuations in traffic patterns. In his talk, Sanjay Mishra Mishra reported that after the CoViD-19 pandemic broke out in early 2020, Comcast's streaming and web video consumption rose by 38%, with their reported peak traffic up 32% overall between March 1 to March 30 Comcast, AT&T reported a 28% jump in core network traffic (single day in April, as compared to pre stay-at-home daily average traffic), with video accounting for nearly half of all mobile network traffic, while social networking and web browsing remained the highest percentage (almost a quarter each) of overall mobility traffic ATT, and Verizon reported similar trends with video traffic up 36% over an average day (pre COVID-19) Verizon. We note that other operators saw similar spikes during this time period.  Craig Labowitz Labovitz reported Weekday peak traffic increases over 45%-50% from pre-lockdown levels, A 30% increase in upstream traffic over their pre-pandemic levels, and A steady increase in the overall volume of DDoS traffic, with amounts exceeding the pre-pandemic levels by 40%. (He attributed this increase to the significant rise in gaming-related DDoS attacks (LabovitzDDoS), as gaming usage also increased.) </ins> 3. 3.1.


Abstract This document provides an overview of operational networking issues <del> that pertain to quality of experience in delivery of video and other </del>  high-bitrate media over the internet. 1.

Ali, this PR looks nice. Two meta-issues (which we can talk about whenever). I changed my references in the draft to a more complete format (using ins: can result in odd formatting in the References section). We don't have to do that for all the references in -04, but that would be a good thing to do in an editorial pass. I see that you're making some terminology changes (from "delivery" to "streaming", stuff like that). I agree with the changes you made in this PR, but we may want to make sure that they are made globally, for consistency.
I was not sure about the reference format, normally I just use the casual format: Authors, "Title," Journal/Conference, Date. I saw the missing author names and realized "ins" would do the trick. By no means, I am tied to that format - don't know even know what "ins" stands for here :)
From URL : "as in the author list, ins is an abbreviation for "initials/surname";" I tend to think an editorial pass on references would be better as a separate commit, where they need cleaning. Anything that somehow made it in and breaks the "make" needs fixing, but others maybe later?
I suggest a definition along these lines: Streaming is transmission of a continuous content from a server to a client and its simultaneous consumption by the client. ("simultaneous" is the key here) This has two implications: 1) Server transmission rate (loosely or tightly) matches to client consumption rate. That is, no buffer overrun or underrun is desirable/acceptable. 2) Client consumption rate is also limited by real-time constraints as opposed to just bandwidth availability. That is, client cannot fetch the content not available yet.
+1, this sgtm. But this probably implies a refactor of the intro section and the abstract, to better focus on the relevant use case.
I can take a crack at this.
Ali has text for this, will create a PR for the issue.

Abstract This document provides an overview of operational networking issues  <ins> that pertain to quality of experience in streaming of video and other </ins> high-bitrate media over the internet. 1.


compound annual growth rate continuing at 34% (from Appendix D of CVNI).  In many contexts, video traffic can be handled transparently as generic application-level traffic.  However, as the volume of video traffic continues to grow, it's becoming increasingly important to

compound annual growth rate continuing at 34% (from Appendix D of CVNI). <ins> A substantial part of this growth is due to increased use of streaming video, although the amount of video traffic in real-time communications (for example, online videoconferencing) has also grown significantly.  While both streaming video and videoconferencing have real-time delivery and latency requirements, these requirements vary from one application to another.  For example, videoconferencing demands an end-to-end (one-way) latency of a few hundreds of milliseconds whereas live streaming can tolerate latencies of several seconds. This document specifically focuses on the streaming applications and defines streaming as follows: Streaming is transmission of a continuous media from a server to a client and its simultaneous consumption by the client.  Here, continous media refers to media and associated streams such as video, audio, metadata, etc.  In this definition, the critical term is "simultaneous", as it is not considered streaming if one downloads a video file and plays it after the download is completed, which would be called download-and-play. This has two implications.  First, server's transmission rate must (loosely or tightly) match to client's consumption rate for an uninterrupted playback.  That is, the client must not run out of data (buffer underrun) or take more than it can keep (buffer overrun) as any excess media is simply discarded.  Second, client's consumption rate is limited by not only bandwidth availability but also the real- time constraints.  That is, the client cannot fetch media that is not available yet. </ins> In many contexts, video traffic can be handled transparently as generic application-level traffic.  However, as the volume of video traffic continues to grow, it's becoming increasingly important to


further.  In this case, the immersive content is typically referred to as volumetric media.  One way to represent the volumetric media is to use point clouds, where streaming a single object may easily <del> require a bitrate of 30 Mbps or higher.  Refer to PCC for more details. </del>  2.2.

further.  In this case, the immersive content is typically referred to as volumetric media.  One way to represent the volumetric media is to use point clouds, where streaming a single object may easily  <ins> require a bitrate of 30 Mbps or higher.  Refer to MPEGI and PCC for more details. </ins> 2.2.


3.1. Adaptive BitRate (ABR) is a sort of application-level response <del> strategy in which the receiving media player attempts to detect the available bandwidth of the network path by experiment or by observing the successful application-layer download speed, then chooses a video bitrate (among the limited number of available options) that fits within that bandwidth, typically adjusting as changes in available bandwidth occur in the network or changes in capabilities occur in the player (such as available memory, CPU, display size, etc.). </del>  The choice of bitrate occurs within the context of optimizing for <del> some metric monitored by the video player, such as highest achievable video quality, or lowest rate of expected rebuffering events. </del>  3.2. <del> ABR playback is commonly implemented by video players using HLS </del>  RFC8216 or DASH DASH to perform a reliable segmented delivery of <del> video data over HTTP.  Different player implementations and receiving devices use different strategies, often proprietary algorithms (called rate adaptation or bitrate selection algorithms), to perform available bandwidth estimation/prediction and the bitrate selection. Most players only use passive observations, i.e., they do not generate probe traffic to measure the available bandwidth. </del>  This kind of bandwidth-measurement systems can experience trouble in several ways that can be affected by networking design choices.

3.1. Adaptive BitRate (ABR) is a sort of application-level response  <ins> strategy in which the streaming client attempts to detect the available bandwidth of the network path by observing the successful application-layer download speed, then chooses a bitrate for each of the video, audio, subtitles and metadata (among the limited number of available options) that fits within that bandwidth, typically adjusting as changes in available bandwidth occur in the network or changes in capabilities occur during the playback (such as available memory, CPU, display size, etc.). </ins> The choice of bitrate occurs within the context of optimizing for  <ins> some metric monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering (playback stall). </ins> 3.2.  <ins> ABR playback is commonly implemented by streaming clients using HLS </ins> RFC8216 or DASH DASH to perform a reliable segmented delivery of  <ins> media over HTTP.  Different implementations use different strategies ABRSurvey, often proprietary algorithms (called rate adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection.  Most clients only use passive observations, i.e., they do not generate probe traffic to measure the available bandwidth. </ins> This kind of bandwidth-measurement systems can experience trouble in several ways that can be affected by networking design choices.


9. <del> Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle Rose, Leslie Daigle, Lucas Pardue, Matt Stock, Alexandre Gouaillard, and Mike English for their very helpful reviews and comments. </del>  10.  References

We've been getting help from people, but the ACKs section hasn't changed much since -03 was submitted in November 2020.
I found like two names that we had missed, and added them to the ACKs section. I think we can merge this any time.

9.  <ins> Thanks to Alexandre Gouaillard, Aaron Falk, Dave Oran, Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Roni Even, and Will Law for very helpful suggestions, reviews and comments. (If we missed your name, please let us know!) </ins> 10.  References


errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a "taskid" member which contains the associated PPM task ID, encoded <del> with base64 RFC4648 (this value is always known, see task- configuration). </del>  In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For

Section 3.1 says to include the PPM task ID in a field on the problem details JSON object, but the task ID may be any 32 byte value, and may not be representable as a Unicode string. I propose that we base64-encode the task ID here to resolve this.

errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a "taskid" member which contains the associated PPM task ID, encoded  <ins> with base64 using the standard alphabet RFC4648 (this value is always known, see task-configuration). </ins> In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For


This protocol is extensible and allows for the addition of new cryptographic schemes that implement the VDAF interface specified in <del> I-D.draft-cfrg-patton-vdaf.  Candidates include: </del>  "prio3", which allows for aggregate statistics such as sum, mean, histograms, etc.  This class of VDAFs is based on Prio CGB17 and

Would be helpful to readers if this reference was fixed in the Editor's Copy: [I-D.draft-cfrg-patton-vdaf] " BROKEN REFERENCE ".
Maybe change each reference to ? That way it'll render like in the text, which reads a bit nicer.

This protocol is extensible and allows for the addition of new cryptographic schemes that implement the VDAF interface specified in  <ins> VDAF.  Candidates include: </ins> "prio3", which allows for aggregate statistics such as sum, mean, histograms, etc.  This class of VDAFs is based on Prio CGB17 and


client ever sees the values for individual clients. In order to address this problem, the aggregators engage in a secure, <del> multi-party computation specified by the chosen VDAF I-D.draft-cfrg- patton-vdaf in order to prepare a report for aggregation.  At the beginning of this computation, each aggregator is in possession of an input share uploaded by the client.  At the end of the computation, each aggregator is in posession of either an "output share" that is ready to be aggregated or an indication that a valid output share could not be computed. </del>  To facilitiate this computation, the input shares generated by the client include information used by the aggregators during aggregation

client ever sees the values for individual clients. In order to address this problem, the aggregators engage in a secure,  <ins> multi-party computation specified by the chosen VDAF VDAF in order to prepare a report for aggregation.  At the beginning of this computation, each aggregator is in possession of an input share uploaded by the client.  At the end of the computation, each aggregator is in posession of either an "output share" that is ready to be aggregated or an indication that a valid output share could not be computed. </ins> To facilitiate this computation, the input shares generated by the client include information used by the aggregators during aggregation


"vdaf_verify_param": The aggregator's VDAF verification parameter output by the setup algorithm computed jointly by the aggregators <del> before the start of the PPM protocol I-D.draft-cfrg-patton-vdaf). [OPEN ISSUE: This is yet to be specified.  See issue#161.] </del>  Finally, the collector is configured with the HPKE secret key corresponding to "collector_hpke_config".

"vdaf_verify_param": The aggregator's VDAF verification parameter output by the setup algorithm computed jointly by the aggregators  <ins> before the start of the PPM protocol VDAF).  [OPEN ISSUE: This is yet to be specified.  See issue#161.] </ins> Finally, the collector is configured with the HPKE secret key corresponding to "collector_hpke_config".


The following terms are used: <del> This document uses the presentation language of RFC8446. </del>  2.

The only language I can find in the document that prescribes serialization is in Section 1.2 (please point out if I missed anything): We intend this statement to be prescriptive, i.e., encoding/decoding of messages is as defined in RFC8446. Another valid interpretation might be "we define the fields of each message following the conventions of RFC8446, but leaving encoding/decoding unspecified". I think it would help to refine this statement a bit. WDYTA:
SGTM FWIW (this was our interpretation, and I think it makes sense to clarify)
Yeah, this seems like a fine clarification. I don't think it was under specified before, but more information for those unfamiliar with TLS-style encoding doesn't hurt.

The following terms are used:  <ins> This document uses the presentation language of RFC8446 to define messages in the PPM protocol.  Encoding and decoding of these messages as byte strings also follows RFC8446. </ins> 2.


6. <del> Prio assumes a powerful adversary with the ability to compromise an unbounded number of clients.  In doing so, the adversary can provide malicious (yet truthful) inputs to the aggregation function.  Prio also assumes that all but one server operates honestly, where a dishonest server does not execute the protocol faithfully as specified.  The system also assumes that servers communicate over secure and mutually authenticated channels.  In practice, this can be done by TLS or some other form of application-layer authentication. In the presence of this adversary, Prio provides two important properties for computing an aggregation function F: Privacy.  The aggregators and collector learn only the output of F computed over all client inputs, and nothing else. Robustness.  As long as the aggregators execute the input- validation protocol correctly, a malicious client can skew the output of F only by reporting false (untruthful) input.  The output cannot be influenced in any other way. There are several additional constraints that a Prio deployment must satisfy in order to achieve these goals: Minimum batch size.  The aggregation batch size has an obvious impact on privacy.  (A batch size of one hides nothing of the input.) Aggregation function choice.  Some aggregation functions leak slightly more than the function output itself. [TODO: discuss these in more detail.] </del>  6.1.  In this section, we enumerate the actors participating in the Prio system and enumerate their assets (secrets that are either inherently valuable or which confer some capability that enables further attack

This change is primarily editorial and includes the following changes: Replace references to "Prio" with references to a generic VDAF. (This section was written long ago when we had Prio in mind.) Elaborate on known issues for collect requests. Discuss Sybil attacks, including enumerating the different types ().
From dkg in Vienna:
It seems like there are a bunch of assumptions about Sybil attacks generally that are not well articulated yet. This would certainly help.
The list of attacks is really a list of things we ought to fix in the protocol, so I would not even bother including them in the security considerations. If we want to use this as an opportunity to identify open issues that need to be addressed before we consider the protocol secure, I would simply list the open issues and keep discussion in GitHub. (That is, the text here seems redundant with the issue )

6.  <ins> PPM assumes an active attacker that controls the network and has the ability to statically corrupt any number of clients, aggregators, and collectors.  That is, the attacker can learn the secret state of any party prior to the start of its attack.  For example, it may coerce a client into providing malicious input shares for aggregation or coerce an aggregator into diverting from the protocol specified (e.g., by divulging its input shares to the attacker). In the presence of this adversary, PPM aims to achieve the following high-level secure aggregation goals: Privacy.  Clients trust that some aggregator is honest.  That is, as long as at least one aggregator executes the protocol faithfully, the parties learn nothing beyond the aggregate result (i.e., the output of the aggregation function computed over the honest measurements). Correctness.  The collector trusts that the aggregators execute the protocol correctly.  That is, as long as the aggregators execute the protocol faithfully, a malicious client can skew the aggregate result only by reporting a false (untruthful) measurement.  The result cannot be influenced in any other way. Currently, the specification does not achieve these goals.  In particular, there are several open issues that need to be addressed before these goals are met.  Details for each issue are below. When crafted maliciously, collect requests may leak more information about the measurements than the system intends.  For example, the spec currently allows sequences of collect requests to reveal an aggregate result for a batch smaller than the minimum batch size.  [OPEN ISSUE: See issue#195.  This also has implications for how we solve issue#183.] Even benign collect requests may leak information beyond what one might expect intuitively.  For example, the Poplar1 VDAF VDAF can be used to compute the set of heavy hitters among a set of arbitrary bit strings uploaded by clients.  This requires multiple evaluations of the VDAF, the results of which reveal information to the aggregators and collector beyond what follows from the heavy hitters themselves.  Note that this leakage can be mitigated using differential privacy.  [OPEN ISSUE: We have yet not specified how to add DP.] The core PPM spec does not defend against Sybil attacks.  In this type of attack, the adversary adds to a batch a number of reports that skew the aggregate result in its favor.  For example: The result may reveal additional information about the honest measurements, leading to a privacy violation; or the result may have some property that is desirable to the adversary ("stats poisoning").  The upload sub-protocol includes an extensions mechanism that can be used to prevent -- or at least mitigate -- these types of attacks.  See upload-extensions.  [OPEN ISSUE: No such extension has been implemented, so we're not yet sure if the current mechanism is sufficient.] 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.  The core PPM spec does not specify such a mechanism beyond requiring server authentication for HTTPS sessions.  Note that clients are not required to authenticate themselves.  [OPEN ISSUE: It might be better to be prescriptive about leader authentication in leader- helper channels and collector authenticaiton in collector-leader channels.  For the latter we have issue#155.] </ins> 6.1. <ins> [OPEN ISSUE: This subsection is a bit out-of-date.] </ins> In this section, we enumerate the actors participating in the Prio system and enumerate their assets (secrets that are either inherently valuable or which confer some capability that enables further attack


To generate the report, the client begins by sharding its measurement into a sequence of input shares as specified by the VDAF in use.  To <del> encrypt an input share, the client first generates an HPKE RFC9180 context for the aggregator by running </del>  <del> where "pk" is the aggregator's public key and "server_role" is the Role of the intended recipient ("0x02" for the leader and "0x03" for the helper).  In general, the info string for computing the HPKE context is suffixed by two bytes, the first of which identifies the role of the sender and the second of which identifies the role of the intended recipient. "enc" is the HPKE encapsulated key and "context" is the HPKE context used by the client for encryption.  The payload is encrypted as where "input_share" is the aggregator's input share and "nonce" and "extensions" are the corresponding fields of "Report".  Clients MUST NOT use the same "enc" for multiple reports. </del>  The leader responds to well-formed requests to "[leader]/upload" with HTTP status code 200 OK and an empty body.  Malformed requests are

Specifically: Specify use of the "one-shot" HPKE APIs defined in RFC9180, replacing equivalent use of the "multi-shot" APIs. (This change is intended to be a clarification, not a functional change.) Move the task_id parameter from the "info" parameter to the "aad" parameter. This is intended to protect against key-commitment-related attacks[1]. (This is a functional change.) Clarify that the URL field is an encapsulated key, rather than an encryption context. (This is a clarification, not a functional change.) [1] See discussion in URL
Per URL section 8.1: PPM effectively uses the single-shot APIs; we should consider refactoring PPM's usage of HPKE to use only one of applicationinfo & AAD. Following the advice of the HPKE RFC, we would want to use applicationinfo. This would permit slightly simpler implementations. I am not sure how much it would simplify the HPKE computations.
Should we then formally use the single shot HPKE APIs from ?
That would be my recommendation (though, somewhat confusingly given the advice quoted above, those APIs still allow specifying both application info & AAD). Implementations can & do already use the single-shot APIs, so I strongly suspect specifying the single-shot APIs will be feasible. & .]
+1 to using single-shot APIs, though I'm not sure I agree that using either info or add (but not both) is simpler. What's the reasoning?
The reasoning is: a) it follows the advice of the HPKE spec (quoted above) b) AFAICT, in a single-shot setting, application info & AAD serve exactly the same purpose, so using both is arbitrary/confusing/a potential source of mistakes. (in a multi-shot setting, application info is bound to all encryptions/decryptions done by the same context; AAD is bound to a single encryption/decryption)
TBH I'm not sure I agree with the quoted guidance here. There is a concept in protocol design known as "domain separation", the goal of which is to provide some kind of binding of long-term secret key operations to the context in which they were used. Imagine, for example, that someone used an HPKE secret key for PPM and some other protocol. Suppose further that both are using the empty string for . Then the security of our PPM deployment depends on how the other protocol uses the derived AEAD key, since in both protocols may end up deriving the same AEAD key. One way to avoid creating this attack surface is to pick an string that no other application is likely to choose so that derived keys are guaranteed to not collide (except with some negligible probability). That said, I'd go for changing how we use and . Something like this might be simpler: Let be a fixed string that identifies the protocol. It would be good if this string were relatively long, say the SHA-256 hash of "ppm-00". Let encode the task ID, sender/receiver roles, etc.
I definitely agree that application info should include information allowing domain separation, for the reasons you mention. (Indeed, the current PPM spec includes the strings "ppm input share" or "ppm aggregate share" in its application infos, presumably for this purpose.) But I think that's orthogonal to the question of whether we should also use AAD, since the application info could also include information other than the "domain separation parameter". Picking one example to make things concrete, a client upload request sets its application info to and its AAD to . But it could just as easily set the application info to (i.e. the concatenation of the two previous strings) and not use AAD. (Or alternatively, it could place that string in the AAD and not use application info.) My argument is that it's simpler to use only one of the parameters, since in the single-shot setting that PPM is using HPKE, the two parameters serve exactly the same purpose (i.e. including additionally-authenticated data).
As I see it, our goal is to make sure that decryption only succeeds if the sender and receiver agree on the "context", i.e., the task ID, sender/receiver role, nonce, extensions, and so on. This way a MITM cannot force the aggregator to interpret an input share incorrectly. Does this sound reasonable to you? From the point of view of this threat model, I don't think it's immediately clear that sticking the context in or is equivalent. For example, if we stuff the context in , then it influences the derivation of the AEAD key; but depending on the AEAD, it might be feasible for an attacker to find a find two keys that decrypt the same ciphertext. (See URL) More analysis will be needed to say for sure whether this weakness in the AEAD amounts to an attack against our protocol. In the meantime, sticking the "context" in seems like a more conservative choice to me.
Given your concern, your approach SGTM. It sounds like this may be a concern worth raising with the folks working on the HPKE spec, given the advice to "use the Setup info parameter for specifying auxiliary authenticated information", but I'm not going to chase this down currently.
So I think there's two tasks for this issue: Move task ID from to Use single-shot APIs for HPKE Anything else?
Yep, I think that's it.
(reopening for now as the fix PR has been reverted temporarily)
Perfect, great work!

To generate the report, the client begins by sharding its measurement into a sequence of input shares as specified by the VDAF in use.  To  <ins> encrypt an input share, the client generates an HPKE RFC9180 ciphertext and encapsulated key for the aggregator by running </ins>  <ins> where "pk" is the aggregator's public key; "server_role" is the Role of the intended recipient ("0x02" for the leader and "0x03" for the helper); "task_id", "nonce", and "extensions" are the corresponding fields of "Report"; and "input_share" is the aggregator's input share. </ins> The leader responds to well-formed requests to "[leader]/upload" with HTTP status code 200 OK and an empty body.  Malformed requests are


report share as invalid with the error "hpke-unknown-config-id". Otherwise, it decrypts the payload with the following procedure: <del> where "sk" is the HPKE secret key, "task_id" is the task ID, "nonce" and "extensions" are the nonce and extensions of the report share respectively, and "server_role" is 0x02 if the aggregator is the leader and 0x03 otherwise.  If decryption fails, the aggregator marks the report share as invalid with the error "hpke-decrypt-error". Otherwise, it outputs the resulting "input_share". </del>  4.3.1.4.

report share as invalid with the error "hpke-unknown-config-id". Otherwise, it decrypts the payload with the following procedure:  <ins> where "sk" is the HPKE secret key, and "server_role" is the role of the aggregator ("0x02" for the leader and "0x03" for the helper).  If decryption fails, the aggregator marks the report share as invalid with the error "hpke-decrypt-error".  Otherwise, it outputs the resulting "input_share". </ins> 4.3.1.4.


"AggregateShareReq" is done as follows: where "pk" is the HPKE public key encoded by the collector's HPKE <del> key, and server_role is is "0x02" for the leader and "0x03" for a helper. </del>  The collector decrypts these aggregate shares using the opposite process.  Specifically, given an encrypted input share, denoted "enc_share", for a given batch interval, denoted "batch_interval", decryption works as follows: <del> where "sk" is the HPKE secret key, "task_id" is the task ID for a given collect request, and "server_role" is the role of the server that sent the aggregate share ("0x02" for the leader and "0x03" for the helper). </del>  4.4.5.

"AggregateShareReq" is done as follows: where "pk" is the HPKE public key encoded by the collector's HPKE  <ins> key, "server_role" is "0x02" for the leader and "0x03" for a helper. </ins> The collector decrypts these aggregate shares using the opposite process.  Specifically, given an encrypted input share, denoted "enc_share", for a given batch interval, denoted "batch_interval", decryption works as follows:  <ins> where "sk" is the HPKE secret key, "task_id" is the task ID for the collect request, and "server_role" is the role of the server that sent the aggregate share ("0x02" for the leader and "0x03" for the helper). </ins> 4.4.5.


"batch_interval" is the batch interval of the request.  "report_count" is the number of reports included in the aggregation. "checksum" is the checksum computed over the set of client reports. <del> "job_id" is the ID of the aggregation job. </del> 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

AggregateShareReq should have an aggregation parameter field instead of aggregation job ID.
Thanks NAME for spotting this!

"batch_interval" is the batch interval of the request. <ins> "agg_param", an aggregation parameter for the VDAF being executed. </ins> "report_count" is the number of reports included in the aggregation. "checksum" is the checksum computed over the set of client reports.  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


where "[leader]" is the first entry in the task's aggregator endpoints.  The payload is structured as follows: <del> This message is called the Client's report.  It consists of a "header" and the encrypted input share of each of the Aggregators. The header consists of the task ID and report "metadata".  The metadata consists of the following fields: </del>  A timestamp representing the time at which the report was generated.  Specifically, the "time" field is set to the number of

Align with the latest VDAF draft. This requires two minor protocol changes: 02 added a value called the "publicshare" to the VDAF syntax. This is to support Poplar1 (and likely other schemes that need a similar extractability property). To accommodate this, the publicshare field has been added to the Report and ReportShare structures and appended to the AAD for input share encryption. (This may end up being useful for privacy.) 02 added the report count to the aggregate result computation. This is already passed to the Collector in the CollectResp, so we just need to update the aggregate result computation in the draft to match.
Rebased and pushed a minor update: The public share in Report and ReportStore now both have the same length prefix.
Rebased.
This will be VDAF-02 or 03, depending on when we need to cut DAP-02.
VDAF-03 is out, I will send a PR by end of week. URL

where "[leader]" is the first entry in the task's aggregator endpoints.  The payload is structured as follows:  <ins> This message is called the Client's report.  It consists of the report metaata, the "public share" output by the VDAF's input- distribution algorithm, and the encrypted input share of each of the Aggregators.  The header consists of the task ID and report "metadata".  The metadata consists of the following fields: </ins> A timestamp representing the time at which the report was generated.  Specifically, the "time" field is set to the number of


4.4.1.3. Each report share has a corresponding task ID, report metadata <del> (timestamp, nonce, and extensions), and encrypted input share.  Let "task_id", "metadata", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, the aggregator looks up the HPKE config and corresponding secret key indicated by </del>  "encrypted_input_share.config_id".  If not found, then it marks the report share as invalid with the error "hpke-unknown-config-id". Otherwise, it decrypts the payload with the following procedure:

4.4.1.3. Each report share has a corresponding task ID, report metadata  <ins> (timestamp, nonce, and extensions), the public share sent to each Aggregator, and the recipient's encrypted input share.  Let "task_id", "metadata", "public_share", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, the aggregator looks up the HPKE config and corresponding secret key indicated by </ins> "encrypted_input_share.config_id".  If not found, then it marks the report share as invalid with the error "hpke-unknown-config-id". Otherwise, it decrypts the payload with the following procedure:


"vdaf_verify_key" is the VDAF verification key shared by the aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and <del> "0x01" for the helper); and "agg_param" is the opaque aggregation parameter distributed to the aggregtors by the collector. </del>  If either step fails, the aggregator marks the report as invalid with error "vdaf-prep-error".  Otherwise, the value "out" is interpreted

"vdaf_verify_key" is the VDAF verification key shared by the aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and  <ins> "0x01" for the helper); "agg_param" is the opaque aggregation parameter distributed to the aggregtors by the collector; "public_share" is the public share generated by the client and distributed to each aggregator; and "input_share" is the aggregator's input share. </ins> If either step fails, the aggregator marks the report as invalid with error "vdaf-prep-error".  Otherwise, the value "out" is interpreted


aggregate shares into an aggregate result using the VDAF's "agg_shares_to_result" algorithm.  In particular, let "agg_shares" denote the ordered sequence of aggregator shares, ordered by <del> aggregator index, and let "agg_param" be the opaque aggregation parameter.  The final aggregate result is computed as follows: </del>  4.5.4.

aggregate shares into an aggregate result using the VDAF's "agg_shares_to_result" algorithm.  In particular, let "agg_shares" denote the ordered sequence of aggregator shares, ordered by  <ins> aggregator index, let "report_count" denote the report count sent by the Leader, and let "agg_param" be the opaque aggregation parameter. The final aggregate result is computed as follows: </ins> 4.5.4.


participating clients or permit some attacks on robustness.  This auxiliary information could be removed by having clients submit reports to an anonymizing proxy server which would then use Oblivious <del> HTTP I-D.thomson-http-oblivious to forward inputs to the DAP leader, without requiring any server participating in DAP to be aware of whatever client authentication or attestation scheme is in use. </del>  7.4.

And while we're at it, update an obsolete reference to Oblivious HTTP, which has long since been adopted by its WG. VDAF-05 isn't expected until Monday 3/13, but we can get this change ready to go.
DAP-04 will need some routine changes: [x] Update version tags for HPKE to () [x] Bump VDAF-03 to 05 () [x] Update change log () [x] Run spell check ()

participating clients or permit some attacks on robustness.  This auxiliary information could be removed by having clients submit reports to an anonymizing proxy server which would then use Oblivious  <ins> HTTP I-D.draft-ietf-ohai-ohttp-07 to forward inputs to the DAP leader, without requiring any server participating in DAP to be aware of whatever client authentication or attestation scheme is in use. </ins> 7.4.


*Collect:* The collector makes one or more requests to the leader in order to obtain the final output of the protocol.  Before the output can be computed, the aggregators (i.e, the leader and <del> helpers) need to have verified and aggregated a sufficient number </del>  of inputs.  Depending on the PA protocol, it may be possible for the aggregators to do so immediately when reports are uploaded. (See prio.)  However, in general it is necessary for them to wait until (a) enough reports have been uploaded and (b) the collector has made a request.  (See hits.) <del> [TODO: Say that the protocol involves multiple helpers.  The downside of using secret sharing is that the protocol requires at least two servers to be online during the entire data aggregation process.  To ameliorate this problem, we run the protocol in parallel with multiple helpers.] </del> 3. This section specifies a protocol for executing generic PA tasks.

Partially addresses . (We also need to decide if/how to allow a particular PA protocol to use multiple helpers for privacy.) Right now, multiple helpers are used for redundancy in case one of the helpers dropped out. This removes this mechanism from the core protocol.
Squashed and rebased.
That's a good idea,
Hmm... Do we need to decide. Per our discussion on Wednesday, if the clients learn this out of band then we won't need this field at all because clients will get it separately and helpers don't need to know what the other helpers are, right?
My takeaway is that the parameters must contain all input needed to run the protocol, including the helpers. And all of this is configured out of band. You could punt everything except for the cryptographic goop out of the parameters structure, forcing clients to know the leader and helper and get their public keys out of band as well, which would be fine. It's just different. I think both work just fine, but I lean towards having params specify everything. It just seems simpler to me. That said... making public key discovery part of the client upload protocol here is more complex, I think. So, .
Squashed.
LGTM. Multiple helpers "for privacy" seems like it's inherently a per-protocol thing (Prio supports it, Hits does not). If and when we decide to address that, should we move this to the protocol-specific slot in PAParam?

*Collect:* The collector makes one or more requests to the leader in order to obtain the final output of the protocol.  Before the output can be computed, the aggregators (i.e, the leader and  <ins> helper) need to have verified and aggregated a sufficient number </ins> of inputs.  Depending on the PA protocol, it may be possible for the aggregators to do so immediately when reports are uploaded. (See prio.)  However, in general it is necessary for them to wait until (a) enough reports have been uploaded and (b) the collector has made a request.  (See hits.)  3. This section specifies a protocol for executing generic PA tasks.


"task": The PA task. <del> "helper_urls": The helpers' endpoint URLs. </del>  "collector_config": The HPKE configuration of the collector (described in hpke-config).  [OPEN ISSUE: Maybe the collector's

"task": The PA task.  <ins> "helper_url": The helpers endpoint URL. </ins> "collector_config": The HPKE configuration of the collector (described in hpke-config).  [OPEN ISSUE: Maybe the collector's


3.3.2. <del> For each URL "[helper]" in "PAUploadStartResp.helper_urls", the client sends a GET request to "[helper]/key_config".  The helper responds with status 200 and an "HpkeConfig" message.  Next, the client collects the set of helpers it will upload shares to.  It ignores a helper if: </del>  the client and helper failed to establish a secure, helper- authenticated channel;

3.3.2.  <ins> Let "[helper]" denote the helper URL encoded by "PAUploadStartResp.param.helper_url".  When a client sends a GET request to "[helper]/key_config", the helper responds with status 200 and an "HpkeConfig" message.  The client aborts if any of the following happen: </ins> the client and helper failed to establish a secure, helper- authenticated channel;


the key config specifies a KEM, KDF, or AEAD algorithm the client doesn't recognize. <del> If the set of supported helpers is empty, then the client aborts and alerts the leader with "no supported helpers".  Otherwise, for each supported helper the client issues a POST request to "[leader]/upload_finish" with a payload constructed as described below. </del> [OPEN ISSUE: Should the request URL encode the PA task?  This would be necessary if we make "upload_start" an idempotent GET per issue#48.]

the key config specifies a KEM, KDF, or AEAD algorithm the client doesn't recognize.  [OPEN ISSUE: Should the request URL encode the PA task?  This would be necessary if we make "upload_start" an idempotent GET per issue#48.]


that about a client?  I'm not sure, so I'd be inclined to remove this unless we have a concrete use case.] <del> The client begins by setting up an HPKE I-D.irtf-cfrg-hpke context for the helper by running </del>  where "pk" is the KEM public key encoded by "HpkeConfig.public_key". The outputs are the helper's encapsulated context "enc" and the

that about a client?  I'm not sure, so I'd be inclined to remove this unless we have a concrete use case.]  <ins> Next, the client issues a POST request to "[leader]/upload_finish". It begins by setting up an HPKE I-D.irtf-cfrg-hpke context for the helper by running </ins> where "pk" is the KEM public key encoded by "HpkeConfig.public_key". The outputs are the helper's encapsulated context "enc" and the


SetupBaseS() will be, as well as the aad for context.Seal().  The aad might be the entire "transcript" between the client and helper.] <del> [OPEN ISSUE: Is it safe to generate the proof once, then secret-share between each (leader, helper) pair?  Probably not in general, but maybe for Prio?] </del> [OPEN ISSUE: allow server to send joint randomness in UploadStartResp, and then enforce uniqueness via double-spend state or something else (see issue#48).]

SetupBaseS() will be, as well as the aad for context.Seal().  The aad might be the entire "transcript" between the client and helper.]  [OPEN ISSUE: allow server to send joint randomness in UploadStartResp, and then enforce uniqueness via double-spend state or something else (see issue#48).]


We sometimes refer to this message as the _report_. The message contains the "task" fields of the previous request.  In addition, it includes the time (in seconds since the beginning of UNIX time) at <del> which the report was generated, the helper's HPKE config id, endpoint URL, and the helper and leader shares.  The helper share has the following structure: </del>  Field "enc" encodes the helper's encapsulated HPKE context.  The remainder of the structure contains the share itself, the structure

We sometimes refer to this message as the _report_. The message contains the "task" fields of the previous request.  In addition, it includes the time (in seconds since the beginning of UNIX time) at  <ins> which the report was generated, the helper's HPKE config id, and the helper and leader shares.  The helper share has the following structure: </ins> Field "enc" encodes the helper's encapsulated HPKE context.  The remainder of the structure contains the share itself, the structure


3.4.2.1. The process begins with a PACollectReq.  The leader collects a <del> sequence of reports that are all associated with the same PA task, helper URL, and helper HPKE config id.  Let "[helper]" denote "PACollectReq.helper_url".  The leader sends a POST request to "[helper]/aggregate" with the following message: </del>  The structure contains the PA task, the helper's HPKE config id, an opaque _helper state_ string, and a sequence of _sub-requests_, each

3.4.2.1. The process begins with a PACollectReq.  The leader collects a  <ins> sequence of reports that are all associated with the same PA task. Let "[helper]" denote "PAParam.helper_url", where "PAParam" is the PA parameters structure associated "PAAggregateReq.task.id".  The leader sends a POST request to "[helper]/aggregate" with the following message: </ins> The structure contains the PA task, the helper's HPKE config id, an opaque _helper state_ string, and a sequence of _sub-requests_, each


The term "Remote Attestation" is a common expression and often associated or connoted with certain properties.  The term "Remote" in this context does not necessarily refer to a remote entity in the <del> scope of network topologies or the Internet.  It rather refers to a decoupled system or entities that exchange the payload of the </del>  Conceptual Message type called Evidence I-D.ietf-rats-architecture. This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system <del> components of the same Composite Device (a single RATS entity). Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf- rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device-attest. </del>  3.

Based on URL In Section 1, 3 Disambiguation About “these types of co-located environments”, The previous sentences are about the Verifier and Attester don’t need to be remote. So “these” is weird here, because here is about the attesting environment and target environment.
So, can this issue then be closed? Hi Henk, I've reviewed the reference interaction models I-D recently, I hope the comments below can help improve the draft before the IETF110 draft submission cut-off. Section 3 Disambiguation Comment > This section is talking about the disambiguation of terminology, so I suggest making it a sub-section of Section 2 Terminology. Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)). Comment > About "these types of co-located environments", The previous sentences are about the Verifier and Attester don't need to be remote. So "these" is weird here, because here is about the attesting environment and target environment. Section 5 Direct Anonymous Attestation Comment > I think it's better to move this section to the bottom of the draft. DAA doesn't introduce a new information elements, and only augments the scope/definition of Attester Identity and Authentication Secret IDs, describing it after the introduction of all the 3 basic interaction models would be better. Putting DAA in the middle makes me feel the basic interaction models rely upon DAA, but actually it's not. This document extends the duties of the Endorser role as defined by the RATS architecture with respect to the provision of these Attester Identity documents to Attesters. The existing duties of the Endorser role and the duties of a DAA Issuer are quite similar as illustrated in the following subsections. Comment > Without DAA, I think the Endorser also needs to provision the Attester Identity to Attesters. And as I understand, the DAA Issuer is a supply chain entity before the Attester being shipped, so it is the Endorser when DAA is used, right? If yes, then in the next sentence, the comparison between Endorser and DAA Issuer doesn't make sense to me. Section 5.1 Endorsers Comment > Does this section have difference with the definition of Endorser in architecture draft? If not, is it necessary to keep this section? Comment > This section only describes the Layered Attestation, but the scope of Endorsement is more than what's described here. Endorsement indicates the Attester's various capabilities such as Claims collection and Evidence signing. For other situations than Layered Attestation, the Endorser and Endorsement are also needed. So why only mention Layered Attestation here? I don't see any special relationship between DAA and Layered Attestation. Section 5.2 Endorsers for Direct Anonymous Attestation In order to enable the use of DAA, an Endorser role takes on the duties of a DAA Issuer in addition to its already defined duties. DAA Issuers offer zero-knowledge proofs based on public key certificates used for a group of Attesters [DAA]. Effectively, these certificates share the semantics of Endorsements, with the following exceptions: Comment > In the first sentence, I suggest saying that "a DAA Issuer takes on the role of an Endorser". o The associated private keys are used by the DAA Issuer to provide an Attester with a credential that it can use to convince the Verifier that its Evidence is valid. To keep their anonymity the Attester randomizes this credential each time that it is used. Comment > How to understand "Evidence is valid"? Does it mean the Evidence is sent from an authentic Attester and not tampered during the conveyance? Or does it mean the Evidence comes from a RoT and is trustable (although the Evidence can diverge from the Reference Values)? Comment > When saying "Attester randomizes this credential", how many credentials does an Attester have? 1) Can a DAA Issuer have multiple key pairs and use them for one Attester? 2) Can a DAA Issuer use one key pair to generate multiple credentials for one Attester? o A credential is conveyed from an Endorser to an Attester in combination with the conveyance of the public key certificates from Endorser to Verifier. Comment > Is there another way to convey the public key certificate, for example, can the public key certificates be conveyed from Endorser to Attester first and then from Attester to Verifier? The zero-knowledge proofs required cannot be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a trustable third entity - like an Endorser. Due to that semantic overlap, the Endorser role is augmented via the definition of DAA duties as defined below. This augmentation enables the Endorser to convey trustable third party statements both to Verifier roles and Attester roles. Comment > For "the definition of DAA duties as defined below", what is the definition of DAA duties? Comment > In the last sentence, the Endorsement with its original definition is the third party statement for Verifier and Attester, isn't it? So, "augmentation" isn't the correct expression. Section 6 Normative Prerequisites Attester Identity: The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. Comment > The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity? Comment > The TPM's AIK certificate is one kind of Attester Identity, right? Attestation Evidence Authenticity: Attestation Evidence MUST be correct and authentic. Comment > Is it appropriate to say "correct Evidence"? If saying so, I think it means that the Evidence satisfies the Attestation Policy for Evidence. Authentication Secret: An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS can take place. Comment > Does the Authentication Secret represent the identity of the Attesting Environment? Comment > How to understand the Authentication Secret, and is it necessary all the time? For example, in our implementation, during the router booting up, the BIOS measures the BootLoader and records the measured hash value into the TPM, and the BootLoader measures the OS Kernel and records the measured hash value into the TPM as well. From the Layered Attestation perspective, I think (BIOS + TPM) is the Attesting Environment and (BootLoader + TPM) is also the Attesting Environment. But the Claims (measured hash values) aren't protected separately, and they finally becomes the Evidence (TPM Quote) and it's only protected by the TPM's AIK. So, what is the Authentication Secret? Section 7 Generic Information Elements Attester Identity ('attesterIdentity'): mandatory A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. Comment > Previous section says "Attester Identity" is about "a distinguishable Attesting Environment", and here says it's about "a distinguishable Attester". Comment > How to understand "without accompanying evidence about its validity"? Attester Identity ('attesterIdentity'): mandatory In DAA, the Attester's identity is not revealed to the verifier. The Attester is issued with a credential by the Endorser that is randomized and then used to anonymously confirm the validity of their evidence. The evidence is verified using the Endorser's public key. Comment > I think here means the DAA credential represents the Attester Identity. Comment > There is ambiguity of "that is randomized", does it mean randomized Endorser or randomized credential? Comment > For "confirm the validity of their evidence", what does "their" refer to? And what does "the validity of evidence" mean? Authentication Secret IDs ('authSecID'): mandatory A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Evidence. Comment > Previous section says "Authentication Secret" is used to protect Claims, but here says it's used to protect Evidence. Comment > As I understand, if Authentication Secret represents the identity of Attesting Environment, then it's not mandatory, at least in our implementation. Authentication Secret IDs ('authSecID'): mandatory In DAA, Authentication Secret IDs are represented by the Endorser (DAA issuer)'s public key that MUST be used to create DAA credentials for the corresponding Authentication Secrets used to protect Evidence. In DAA, an Authentication Secret ID does not identify a unique Attesting Environment but associated with a group of Attesting Environments. This is because an Attesting Environment should not be distinguishable and the DAA credential which represents the Attesting Environment is randomised each time it used. Comment > In my understanding, here says that the DAA credential identities the Attesting Environment. Compared with the description in the "Attester Identity" part, what does the DAA credential represent actually? Reference Claims ('refClaims') mandatory Reference Claims are components of Reference Values as defined in [I-D.ietf-rats-architecture]. [Editor's Note: Definition might become obsolete, if replaced by Reference Values. Is there a difference between Claims and Values here? Analogously, why is not named Reference Claims in the RATS arch?] Comment > I suggest using Reference Values to keep consistent with the RATS arch. Reference Claims are used to appraise the Claims received from an Attester via appraisal by direct comparison. Comment > "Direct comparison" isn't the correct expression, the comparison can have other rules. Claim Selection ('claimSelection'): optional A statement that represents a (sub-)set of Claims that can be created by an Attester. Claim Selections can act as filters that can specify the exact set of Claims to be included in Evidence. An Attester MAY decide whether or not to provide all Claims as requested via a Claim Selection. Comment > The "all Claims" may be ambiguous, I'd like to double check, does it refer to all Claims that the Attester can create or refer to all Claims requested in the Claim Selection? Section 8.1 Challenge/Response Remote Attestation Comment > In the sequence diagram, some elements in the bracket are not defined in the "Information Elements" section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined? Section 9 Additional Application-Specific Requirements Depending on the use cases covered, there can be additional requirements. An exemplary subset is illustrated in this section. Comment > Here starts to talk about "additional requirements", but I wonder there is no other places in this draft talking about requirement, so what are the basic requirements? Regards & Thanks! Wei Pan

The term "Remote Attestation" is a common expression and often associated or connoted with certain properties.  The term "Remote" in this context does not necessarily refer to a remote entity in the  <ins> scope of network topologies or the Internet.  It rather refers to decoupled systems or entities that exchange the payload of the </ins> Conceptual Message type called Evidence I-D.ietf-rats-architecture. This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system  <ins> components of the same Composite Device (a single RATS entity).  Even if an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity.  Examples of such isolated environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf-rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device- attest. </ins> 3.


_mandatory_ <del> Reference Claims are components of Reference Values as defined in I-D.ietf-rats-architecture.  [Editor's Note: Definition might become obsolete, if replaced by Reference Values.  Is there a difference between Claims and Values here?  Analogously, why is not named Reference Claims in the RATS arch?] Reference Claims are used to appraise the Claims received from an Attester.  For example, Reference Claims MAY be Reference </del>  Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (see <del> Endorsements in I-D.ietf-rats-architecture).  Reference Claims </del>  typically represent (trusted) Claim sets about an Attester's intended platform operational state.

Based on URL I suggest using Reference Values to keep consistent with the RATS arch.
+1 for "Reference Values"
on it Hi Henk, I've reviewed the reference interaction models I-D recently, I hope the comments below can help improve the draft before the IETF110 draft submission cut-off. Section 3 Disambiguation Comment > This section is talking about the disambiguation of terminology, so I suggest making it a sub-section of Section 2 Terminology. Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)). Comment > About "these types of co-located environments", The previous sentences are about the Verifier and Attester don't need to be remote. So "these" is weird here, because here is about the attesting environment and target environment. Section 5 Direct Anonymous Attestation Comment > I think it's better to move this section to the bottom of the draft. DAA doesn't introduce a new information elements, and only augments the scope/definition of Attester Identity and Authentication Secret IDs, describing it after the introduction of all the 3 basic interaction models would be better. Putting DAA in the middle makes me feel the basic interaction models rely upon DAA, but actually it's not. This document extends the duties of the Endorser role as defined by the RATS architecture with respect to the provision of these Attester Identity documents to Attesters. The existing duties of the Endorser role and the duties of a DAA Issuer are quite similar as illustrated in the following subsections. Comment > Without DAA, I think the Endorser also needs to provision the Attester Identity to Attesters. And as I understand, the DAA Issuer is a supply chain entity before the Attester being shipped, so it is the Endorser when DAA is used, right? If yes, then in the next sentence, the comparison between Endorser and DAA Issuer doesn't make sense to me. Section 5.1 Endorsers Comment > Does this section have difference with the definition of Endorser in architecture draft? If not, is it necessary to keep this section? Comment > This section only describes the Layered Attestation, but the scope of Endorsement is more than what's described here. Endorsement indicates the Attester's various capabilities such as Claims collection and Evidence signing. For other situations than Layered Attestation, the Endorser and Endorsement are also needed. So why only mention Layered Attestation here? I don't see any special relationship between DAA and Layered Attestation. Section 5.2 Endorsers for Direct Anonymous Attestation In order to enable the use of DAA, an Endorser role takes on the duties of a DAA Issuer in addition to its already defined duties. DAA Issuers offer zero-knowledge proofs based on public key certificates used for a group of Attesters [DAA]. Effectively, these certificates share the semantics of Endorsements, with the following exceptions: Comment > In the first sentence, I suggest saying that "a DAA Issuer takes on the role of an Endorser". o The associated private keys are used by the DAA Issuer to provide an Attester with a credential that it can use to convince the Verifier that its Evidence is valid. To keep their anonymity the Attester randomizes this credential each time that it is used. Comment > How to understand "Evidence is valid"? Does it mean the Evidence is sent from an authentic Attester and not tampered during the conveyance? Or does it mean the Evidence comes from a RoT and is trustable (although the Evidence can diverge from the Reference Values)? Comment > When saying "Attester randomizes this credential", how many credentials does an Attester have? 1) Can a DAA Issuer have multiple key pairs and use them for one Attester? 2) Can a DAA Issuer use one key pair to generate multiple credentials for one Attester? o A credential is conveyed from an Endorser to an Attester in combination with the conveyance of the public key certificates from Endorser to Verifier. Comment > Is there another way to convey the public key certificate, for example, can the public key certificates be conveyed from Endorser to Attester first and then from Attester to Verifier? The zero-knowledge proofs required cannot be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a trustable third entity - like an Endorser. Due to that semantic overlap, the Endorser role is augmented via the definition of DAA duties as defined below. This augmentation enables the Endorser to convey trustable third party statements both to Verifier roles and Attester roles. Comment > For "the definition of DAA duties as defined below", what is the definition of DAA duties? Comment > In the last sentence, the Endorsement with its original definition is the third party statement for Verifier and Attester, isn't it? So, "augmentation" isn't the correct expression. Section 6 Normative Prerequisites Attester Identity: The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. Comment > The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity? Comment > The TPM's AIK certificate is one kind of Attester Identity, right? Attestation Evidence Authenticity: Attestation Evidence MUST be correct and authentic. Comment > Is it appropriate to say "correct Evidence"? If saying so, I think it means that the Evidence satisfies the Attestation Policy for Evidence. Authentication Secret: An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS can take place. Comment > Does the Authentication Secret represent the identity of the Attesting Environment? Comment > How to understand the Authentication Secret, and is it necessary all the time? For example, in our implementation, during the router booting up, the BIOS measures the BootLoader and records the measured hash value into the TPM, and the BootLoader measures the OS Kernel and records the measured hash value into the TPM as well. From the Layered Attestation perspective, I think (BIOS + TPM) is the Attesting Environment and (BootLoader + TPM) is also the Attesting Environment. But the Claims (measured hash values) aren't protected separately, and they finally becomes the Evidence (TPM Quote) and it's only protected by the TPM's AIK. So, what is the Authentication Secret? Section 7 Generic Information Elements Attester Identity ('attesterIdentity'): mandatory A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. Comment > Previous section says "Attester Identity" is about "a distinguishable Attesting Environment", and here says it's about "a distinguishable Attester". Comment > How to understand "without accompanying evidence about its validity"? Attester Identity ('attesterIdentity'): mandatory In DAA, the Attester's identity is not revealed to the verifier. The Attester is issued with a credential by the Endorser that is randomized and then used to anonymously confirm the validity of their evidence. The evidence is verified using the Endorser's public key. Comment > I think here means the DAA credential represents the Attester Identity. Comment > There is ambiguity of "that is randomized", does it mean randomized Endorser or randomized credential? Comment > For "confirm the validity of their evidence", what does "their" refer to? And what does "the validity of evidence" mean? Authentication Secret IDs ('authSecID'): mandatory A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Evidence. Comment > Previous section says "Authentication Secret" is used to protect Claims, but here says it's used to protect Evidence. Comment > As I understand, if Authentication Secret represents the identity of Attesting Environment, then it's not mandatory, at least in our implementation. Authentication Secret IDs ('authSecID'): mandatory In DAA, Authentication Secret IDs are represented by the Endorser (DAA issuer)'s public key that MUST be used to create DAA credentials for the corresponding Authentication Secrets used to protect Evidence. In DAA, an Authentication Secret ID does not identify a unique Attesting Environment but associated with a group of Attesting Environments. This is because an Attesting Environment should not be distinguishable and the DAA credential which represents the Attesting Environment is randomised each time it used. Comment > In my understanding, here says that the DAA credential identities the Attesting Environment. Compared with the description in the "Attester Identity" part, what does the DAA credential represent actually? Reference Claims ('refClaims') mandatory Reference Claims are components of Reference Values as defined in [I-D.ietf-rats-architecture]. [Editor's Note: Definition might become obsolete, if replaced by Reference Values. Is there a difference between Claims and Values here? Analogously, why is not named Reference Claims in the RATS arch?] Comment > I suggest using Reference Values to keep consistent with the RATS arch. Reference Claims are used to appraise the Claims received from an Attester via appraisal by direct comparison. Comment > "Direct comparison" isn't the correct expression, the comparison can have other rules. Claim Selection ('claimSelection'): optional A statement that represents a (sub-)set of Claims that can be created by an Attester. Claim Selections can act as filters that can specify the exact set of Claims to be included in Evidence. An Attester MAY decide whether or not to provide all Claims as requested via a Claim Selection. Comment > The "all Claims" may be ambiguous, I'd like to double check, does it refer to all Claims that the Attester can create or refer to all Claims requested in the Claim Selection? Section 8.1 Challenge/Response Remote Attestation Comment > In the sequence diagram, some elements in the bracket are not defined in the "Information Elements" section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined? Section 9 Additional Application-Specific Requirements Depending on the use cases covered, there can be additional requirements. An exemplary subset is illustrated in this section. Comment > Here starts to talk about "additional requirements", but I wonder there is no other places in this draft talking about requirement, so what are the basic requirements? Regards & Thanks! Wei Pan

_mandatory_  <ins> Reference Values as defined in I-D.ietf-rats-architecture.  This specific type of Claims is used to appraise Claims incorporated in Evidence.  For example, Reference Values MAY be Reference </ins> Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (see  <ins> Endorsements in I-D.ietf-rats-architecture).  Reference Values </ins> typically represent (trusted) Claim sets about an Attester's intended platform operational state.


signature, the Attester Identity, and the Handle, and then appraises the Claims.  Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference <del> Claims, such as Reference Integrity Measurements.  The final output </del>  of the Verifier are Attestation Results.  Attestation Results constitute new Claim Sets about the properties and characteristics of an Attester, which enables Relying Parties, for example, to assess an

signature, the Attester Identity, and the Handle, and then appraises the Claims.  Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference  <ins> Values, such as Reference Integrity Measurements.  The final output </ins> of the Verifier are Attestation Results.  Attestation Results constitute new Claim Sets about the properties and characteristics of an Attester, which enables Relying Parties, for example, to assess an


order to allow the inclusion of an optional suffix. The extended date/time format is described by the rule "date-time- <del> ext".  "date-time" is imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234. </del>  Note that a "time-zone" is syntactically similar to a "suffix-tag", but does not include an equals sign.  This special case is only

URL supports offset time zones, e.g. . For backwards compatibility, this RFC should support them too. This PR also adds clarifying text to several time-zone-related definitions.
Makes sense. Should I start one? Yep, we added these in Temporal primarily for compatibility with prior art in URL URL In Java (and currently in Temporal) a time zone ID can either be an IANA name or an offset. The ID is an index into a set of rules ( in Java, in Temporal) for converting between exact time and local time. If the ID is an offset, there's only one trivial rule because the offset is always the same. I don't have a strong opinion about the name of offset time zones.
NAME - Let me know if you have responses to the questions in my comment above, or how you'd like me to change this PR. Thanks!
I think we still need the mailing list discussion first. If we get to a certain state of clarity by March 18, we might be able to post yet another update of the draft right before IETF week.
Sounds good. I sent mail to the mailing list. Waiting for responses.
I plan to merge this within a couple of hours, so we have a merged draft to look at in Monday's WG meeting. Since the discussion hasn't concluded yet, I'll edit the merge so it is useful for those discussions; we can edit some more after Monday's meeting.
Sounds good to me. Based on your comments here and on the mailing list, I think we're in agreement on the important points.
Hi NAME - is the merged draft available? If not, I'm happy to make the edits you and NAME suggested here in this PR, but didn't want to step on changes you're making in parallel. Let me know how I can help. Thanks!
I merged the PR and made some edits in main. I included you in the contributor list; please advise if that is OK, the information is right and whether you want to include any more contact/affiliation information.
Great! Your edits look good to me. I may follow up after the meeting with minor text clarification PRs but nothing important. Info looks right. I'm a volunteer not working on behalf of my employer so no need for additional affiliation. Thanks!
The current ABNF for the time zone extension does not support offset time zones, e.g. . These zones are supported in URL, which is the prior art driving the bracketed time zone extension format. Therefore, I'm assuming that it makes sense for the standard to also allow offsets in brackets too. Current ABNF: URL Suggested ABNF for, where is imported from RFC 3339: Example of Java usage:
Please excuse my ignorance: What is the meaning of ? We'd need some text explaining the semantics.
This format asserts that derived timestamps (e.g. add one day) should also use the offset. It's mostly for backwards compatibility with URL It's not recommended for normal use. Heres the explanatory text I added in : >
I assume that conflicts between the timestamp offset and a bracketed offset (e.g. ) should be handled the same as other conflicts, per discussion in URL

order to allow the inclusion of an optional suffix. The extended date/time format is described by the rule "date-time-  <ins> ext".  "date-time" and "time-numoffset" are imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234. </ins> Note that a "time-zone" is syntactically similar to a "suffix-tag", but does not include an equals sign.  This special case is only


Each distinct instant in time can be represented in a descriptive text format using a timestamp, and ISO8601 standardizes a widely- <del> adopted timestamp format, which forms the basis of RFC3339.  However, this format only allows timestamps to contain very little additional relevant information, which means that, beyond that, any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. </del>  This is already a pressing issue for applications that handle each instant with an associated time zone name, to take into account

We need a name that people will use until they can say RFC9999 timestamps (and maybe even when they can).
"Extended Timestamps" or "Extended Internet Timestamps" ?
RFC 3339 says "Internet Date/Time Format". That is what sedate says at the moment as well, but that can't stay the same. So I'm considering moving to: Internet Date/Time Format Extended The alternative .... Extended Internet Date/Time Format sounds like a date/time format for the Extended Internet (EI is actually in use as "Extensible Internet", which this shouldn't be confused with). I'd rather call it Fritz, but I haven't found a way to retronym this...
Thanks

Each distinct instant in time can be represented in a descriptive text format using a timestamp, and ISO8601 standardizes a widely-  <ins> adopted timestamp format, which forms the basis of the Internet Date/ Time Format RFC3339.  However, this format only allows timestamps to contain very little additional relevant information, which means that, beyond that, any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. </ins> This is already a pressing issue for applications that handle each instant with an associated time zone name, to take into account


The format provides a generalized way to attach any additional information to the timestamp.  This document does not address extensions to the format where the semantic result is no longer a fixed timestamp that is referenced to a (past or future) UTC time.  For instance, it does not address:

The format provides a generalized way to attach any additional information to the timestamp. <ins> We refer to this format as the Internet Extended Date/Time Format (IXDTF). </ins> This document does not address extensions to the format where the semantic result is no longer a fixed timestamp that is referenced to a (past or future) UTC time.  For instance, it does not address:


For the format defined here, suffix tags are always : They can be added or left out as desired by the generator of the <del> string in Internet Date/Time Format.  (An application might require the presence of specific suffix tags, though.) </del>  Without further indication, they are also <del> : Even if included in the Internet Date/Time Format string, the recipient is free to ignore the suffix tag.  Reasons might include that the recipient does not implement (or know about) the specific suffix key, or that it does recognize the key but cannot act on the value provided. </del>  A suffix tag may also indicate that it is <del> : The recipient is advised that it MUST not act on the Internet Date/ Time Format string unless it can process the suffix tag as specified. A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see "critical-flag" in abnf). </del>  <del> Internet Date/Time Format strings such as: </del>  are internally inconsistent, as Europe/Paris does not use a time zone offset of 0 (which is indicated in the "Z", an abbreviation for

For the format defined here, suffix tags are always : They can be added or left out as desired by the generator of the  <ins> string in Internet Extended Date/Time Format (IXDTF).  (An application might require the presence of specific suffix tags, though.) </ins> Without further indication, they are also  <ins> : Even if included in the IXDTF string, the recipient is free to ignore the suffix tag.  Reasons might include that the recipient does not implement (or know about) the specific suffix key, or that it does recognize the key but cannot act on the value provided. </ins> A suffix tag may also indicate that it is  <ins> : The recipient is advised that it MUST not act on the Internet Extended Date/Time Format (IXDTF) string unless it can process the suffix tag as specified.  A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see "critical-flag" in abnf). </ins>  <ins> IXDTF strings such as: </ins> are internally inconsistent, as Europe/Paris does not use a time zone offset of 0 (which is indicated in the "Z", an abbreviation for


However, all have an internal inconsistency or an unrecognized suffix key/ <del> value, so a recipient MUST treat the Internet Date/Time Format string as erroneous. </del>  Note that this does not mean that an application is disallowed to perform additional processing on elective suffix tags, e.g., asking

However, all have an internal inconsistency or an unrecognized suffix key/  <ins> value, so a recipient MUST treat the IXDTF string as erroneous. </ins> Note that this does not mean that an application is disallowed to perform additional processing on elective suffix tags, e.g., asking


The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix. <del> The extended date/time format is described by the rule "date-time- ext". </del>  "date-time" and "time-numoffset" are imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234.

The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix.  <ins> The Internet Extended Date/Time Format (IXDTF) is described by the rule "date-time-ext". </ins> "date-time" and "time-numoffset" are imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234.


3.2. <del> Here are some examples of Internet extended date/time format. </del>  rfc3339-datetime represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC.  Note

3.2.  <ins> Here are some examples of Internet Extended Date/Time Format (IXDTF). </ins> rfc3339-datetime represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC.  Note


5.1. Configuration interfaces are used to configure the security protocols <del> before a handshake begins or the keys are negotiated. </del>  Identities and Private Keys (IPK): The application can provide its identity, credentials (e.g., certificates), and private keys, or

We got another Secdir review: Reviewer: Paul Wouters Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Has Nits Compared to my last review (-09) a lot of text has been removed, reducing the technical details and giving a briefer (but arguably cleaner) overview. I do still have a personal preference of dropping CurveCP and MinimalT as I don't really think these are anything but abandoned research items. I have never seen or heard of these being deployed. I would be more tempted to list openconnect (draft-mavrogiannopoulos-openconnect) which actually does see quite some deployment. If the intent is really to show different kind of API's, than there are other esoteric examples that could be included, such as Off-The-Record(OTR) or Signal, which are mostly encrypted chat programs, but with the ability to generate session keys for encrypted bulk transport (eg for video/audio or file transfer) Section 5.1 "Session Cache Management (CM):" which does not include IKEv2/IPsec, even though it does have session resumption (RFC 5723). I guess this is because the section limits itself to "the application" that can restart the session. But for IKEv2/IPsec the same could be said. An application that after a long idle period sends a packet, triggers a kernel ACQUIRE, which triggers an IKEv2 session resumption. WireGuard does not have this capability as there are no API/hooks for packet trigger tunnel events (AFAIK) "Pre-Shared Key Import (PSKI):" lists WireGuard, but AFAIK it does not support PSK based authentication - only public key based authentication. While I understand the IKEv2 entry (PSKs are used for authentication of peers), I am not sure the ESP entry should be here. ESP does not "authenticate peers", unless you call "being able to decrypt and authenticate packets" as an instance of "authenticating peer" Section 5.2 This states "This can call into the application to offload validation.". This "can" is only not supported by WireGuard, as all of this is happening inside the kernel. Maybe a note could be useful here? "Source Address Validation" - It is a little unclear why TCP based protocols are not listed here. They (implicitly) do source address validation. Perhaps the introduction in this paragraph can state this more explicitly. Eg "for those protocols that do not use TCP and therefor do not have builtin source address validation ......."
On which protocols to include, MinimalT and CurveCP have different feature sets and interfaces exposed, which I think warrants their inclusion. Things like Signal and OTR indeed have seen very wide deployment, though they're asynchronous, application-layer protocols akin to MLS, which I think is out of scope. I'd also not like to add draft-mavrogiannopoulos-openconnect, if for no other reason than to draw a line in the sand. (We run the risk of indefinitely delaying this while adding more protocols.) On Session Cache Management, this is an explicit interface, and the example Paul mentions, while correct, does not exercise such an explicit interface. On WireGuard and PSK import, WireGuard uses the IKpsk2 Noise pattern (see URL, and URL), in which a responder uses its PSK to additionally authenticate a connection. On ESP and PSK import, we note that importing a PSK can be used for "encrypting (and authenticating) communication with a peer," which remains true for IPsec. (Right NAME I'll address the issues in 5.2 in a PR!

5.1. Configuration interfaces are used to configure the security protocols  <ins> before a handshake begins or keys are negotiated. </ins> Identities and Private Keys (IPK): The application can provide its identity, credentials (e.g., certificates), and private keys, or


Identity Validation (IV): During a handshake, the security protocol will conduct identity validation of the peer.  This can <del> call into the application to offload validation. </del>  TLS

Identity Validation (IV): During a handshake, the security protocol will conduct identity validation of the peer.  This can  <ins> offload validation or occur transparently to the application. </ins> TLS


Source Address Validation (SAV): The handshake protocol may interact with the transport protocol or application to validate the address of the remote peer that has sent data.  This involves <del> sending a cookie exchange to avoid DoS attacks. </del>  DTLS

Source Address Validation (SAV): The handshake protocol may interact with the transport protocol or application to validate the address of the remote peer that has sent data.  This involves  <ins> sending a cookie exchange to avoid DoS attacks.  (This list omits protocols which depend on TCP and therefore implicitly perform SAV.) </ins> DTLS


5.2. <del> Cryptographic algorithm negotiation: Transport security protocols should permit applications to configure supported or enabled cryptographic algorithms. </del>  Transport dependency: None. Application dependency: Application awareness of supported or desired algorithms. <del> Application authentication delegation: Some protocols may </del>  completely defer endpoint authentication to applications, e.g., to reduce online protocol complexity.

WIP addressing . I don't want to pull this as-is: I just want comments on the format and usefulness of this. This closes the circle created by the list of protocol features in section 3, and indicates where we probably want more consistency and completeness in that list so the derivation of common optional features is more obvious.
Still a WIP. I have a bunch of comments as a result of doing this exercise: Feature availability for some protocol/feature combinations is not clear from the descriptions in the doc. Wireguard is IP encapsulation within UDP, but this is not stated anywhere in the doc. The set of features we list here should be called out or evident from the protocol features subsections under each protocol description. I think there's still some confusion in sections around symmetric authentication vs. signatures, i.e., AEAD-style authentication ("packets belong to this session") vs. PKI endpoint authentication ("this connection belongs to a peer I trust and is not being MITMed"). This may be a comment on the unfortunateness of the literature using "authenticated" for both.

Feature availability for some protocol/feature combinations is not clear from the descriptions in the doc. Can you give examples? Can you please open an issue to address this? See the other open pull request. :-) Where in particular are these things confused?
NAME ping!
Sorry, am away for the holiday weekend. The ones I have listed with a "?", for instance. I guessed on a few of the others, as well (e.g., configuration extensions for MinimalT). The right answer is for me to go back through this table and enumerate all the areas where the text isn't clear, and fix them. I'll file an issue. Will do. I'm not quite sure what I was thinking here. After reading it through again, I think I'm okay with how this is presented.
NAME can you please update this PR?
A few more questions: Is there any existing client puzzle/proof of work standardized for TLS or DTLS, or is URL as far as something's gotten? Same goes for IPsec; I can find no standardized version of any of these things. Should algorithms like TLS, DTLS, etc. that support native authentication but also can export a cryptographic channel binding be listed as supporting authentication delegation? My instinct is yes.
NAME None that I'm aware of! Yes, I think that's correct.
NAME Will you be able to complete this PR this week?
Yes, though I could use some guidance on the ?'s in the table, if you have enough context to resolve them. Otherwise, I will do some digging.
NAME IKEv2+ESP/AD: Yes, via EAP(-TLS). IKEv2+ESP/AFN: Yes, via vendor and configuration payloads. SRTP+DTLS/CM: No. ZRTP: Omit, since it's a variant? WireGuard/CM: No, connections are bound to IP addresses. WireGuard/SC: No, session resumption is not supported. WireGuard/LHP: Yes, for transport packets only. MinimalT/AD: No. MinimalT/AFN: No. MinimalT/LHP: Yes. CurveCP/AD: No.
RFR.
Ship it.
It's probably easier and more consumable to encode the matrix of protocols providing a particular feature as a table.
I'm assigning this to you, Kyle. Will you have time to take a stab at it?
Yep, I'll work on it this afternoon.

5.2.  <ins> Cryptographic algorithm negotiation (AN): Transport security protocols should permit applications to configure supported or enabled cryptographic algorithms. </ins> Transport dependency: None. Application dependency: Application awareness of supported or desired algorithms.  <ins> Application authentication delegation (AD): Some protocols may </ins> completely defer endpoint authentication to applications, e.g., to reduce online protocol complexity.


Application dependency: Application opt-in and policy for endpoint authentication <del> Mutual authentication: Transport security protocols should allow each endpoint to authenticate the other if required by the </del>  application. Transport dependency: None.

Application dependency: Application opt-in and policy for endpoint authentication  <ins> Mutual authentication (MA): Transport security protocols should allow each endpoint to authenticate the other if required by the </ins> application. Transport dependency: None.


Application dependency: Mutual authentication required for application support. <del> DoS mitigation: Transport security protocols may need to support volumetric DoS prevention via, e.g., cookies or initiator-side puzzles. </del>  Transport dependency: None. Application dependency: None. <del> Connection mobility: Sessions should not be bound to a network connection (or 5-tuple).  This allows cryptographic key material and other state information to be reused in the event of a connection change.  Examples of this include a NAT rebinding that occurs without a client's knowledge. </del>  Transport dependency: Connections are unreliable or can change due to unpredictable network events, e.g., NAT re-bindings. Application dependency: None. <del> Source validation: Source validation must be provided to mitigate server-targeted DoS attacks.  This can be done with puzzles or cookies. </del>  Transport dependency: Packets may arrive as datagrams instead of streams from unauthenticated sources. Application dependency: None. <del> Application-layer feature negotiation: The type of application using a transport security protocol often requires features configured at the connection establishment layer, e.g., ALPN RFC7301.  Moreover, application-layer features may often be used to offload the session to another server which can better handle the request.  (The TLS SNI is one example of such a feature.)  As such, transport security protocols should provide a generic mechanism to allow for such application-specific features and options to be configured or otherwise negotiated. </del>  Transport dependency: None. Application dependency: Specification of application-layer features or functionality. <del> Configuration extensions: The protocol negotiation should be </del>  extensible with addition of new configuration options. Transport dependency: None.

Application dependency: Mutual authentication required for application support.  <ins> DoS mitigation (DM): Transport security protocols may need to support volumetric DoS prevention via, e.g., cookies or initiator- side puzzles. </ins> Transport dependency: None. Application dependency: None.  <ins> Connection mobility (CM): Sessions should not be bound to a network connection (or 5-tuple).  This allows cryptographic key material and other state information to be reused in the event of a connection change.  Examples of this include a NAT rebinding that occurs without a client's knowledge. </ins> Transport dependency: Connections are unreliable or can change due to unpredictable network events, e.g., NAT re-bindings. Application dependency: None.  <ins> Source validation (SV): Source validation must be provided to mitigate server-targeted DoS attacks.  This can be done with puzzles or cookies. </ins> Transport dependency: Packets may arrive as datagrams instead of streams from unauthenticated sources. Application dependency: None.  <ins> Application-layer feature negotiation (AFN): The type of application using a transport security protocol often requires features configured at the connection establishment layer, e.g., ALPN RFC7301.  Moreover, application-layer features may often be used to offload the session to another server which can better handle the request.  (The TLS SNI is one example of such a feature.)  As such, transport security protocols should provide a generic mechanism to allow for such application-specific features and options to be configured or otherwise negotiated. </ins> Transport dependency: None. Application dependency: Specification of application-layer features or functionality.  <ins> Configuration extensions (CX): The protocol negotiation should be </ins> extensible with addition of new configuration options. Transport dependency: None.


Application dependency: Specification of application-specific extensions. <del> Session caching (and management): Sessions should be cacheable to enable reuse and amortize the cost of performing session </del>  establishment handshakes. Transport dependency: None. Application dependency: None. <del> Length-hiding padding: Applications may wish to defer traffic padding to the security protocol to deter traffic analysis </del>  attacks. Transport dependency: None. Application dependency: Knowledge of desired padding policies.  6. This section describes the interface surface exposed by the security

Application dependency: Specification of application-specific extensions.  <ins> Session caching and management (SC): Sessions should be cacheable to enable reuse and amortize the cost of performing session </ins> establishment handshakes. Transport dependency: None. Application dependency: None.  <ins> Length-hiding padding (LHP): Applications may wish to defer traffic padding to the security protocol to deter traffic analysis </ins> attacks. Transport dependency: None. Application dependency: Knowledge of desired padding policies. <ins> 5.3. The following table lists the availability of the above-listed optional features in each of the analyzed protocols.  "Mandatory" indicates that the feature is intrinsic to the protocol and cannot be disabled.  "Supported" indicates that the feature is optionally provided natively or through a (standardized, where applicable) extension. M=Mandatory S=Supported but not required U=Unsupported *=On TCP; MPTCP would provide this ability **=TCP provides SYN cookies natively, but these are not cryptographically strong +=For transport packets only </ins> 6. This section describes the interface surface exposed by the security


everything else is self-delimiting and is just a source of confusion (5) Replace PSK TODO with an open issue marker (6) use varints instead of remainder of message. Got a bit carried away

4.2.2.  <ins> [[OPEN ISSUE: Limiting this to one value would potentially save some bytes here, at the cost of generality.]] </ins> 4.3.