I don't love a couple of the ways I phrased things here, so feel free to offer suggestions to improve it! modulo test vectors. (NAME it'll likely take some time to get those vectors. Do you think we should hold this document until that's done?)
This looks good modulo the open issue about incremental deployment. I don't think we need to hold the document up in order to get test vectors. Benjamin Kaduk has entered the following ballot position for draft-ietf-tls-external-psk-importer-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Sorry about the large volume of comments; this document is actually in pretty good shape, there are just a bunch of details that can be subtle to get exactly right. I specifically call out the note in Section 4.1 about which HKDF-Expand-Label is to be used, since that would affect the actual derived keys for DTLS 1.3 (and any hypothetical future TLS versions). Section 1 While there is no known way in which the same external PSK might produce related output in TLS 1.3 and prior versions, only limited analysis has been done. Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions. To mitigate against any interference, this document specifies a PSK Importer interface by which external PSKs may be imported and subsequently bound to a specific key derivation function (KDF) and hash function for use in TLS 1.3 [RFC8446] and DTLS 1.3 [DTLS13]. [...] IIRC the main target use cases for this mechanism are for existing external PSKs (violating the "SHOULD" from the first quoted paragraph), as well as deployments that are simplified by only needing to provision a single PSK. Does it make sense to include such clarifying description here? (Similarly, is it accurate to say that "[a]pplications SHOULD provision separate PSKs [...], but the mechanism defined in this document provides a partial mitigation for use when that is not possible"? Also, we only use the word "interference" twice in this document (this is the first instance), so it might be worth a couple more words to clarify the nature of the potential interference. Section 3 non-imported keys for TLS versions prior to TLS 1.3. Non-imported and imported PSKs are distinct since their identities are different on the wire. See Section 6 for more details. (side note?) I think the precise story here is a little subtle -- for any given key, the imported and non-imported identities are distinct, but in principle one could construct a non-imported identity that overlaps with an imported identity for a different key (and we say as much at the end of Section 7). This is vanishingly rare to happen by chance, but makes the statement as written not quite categorically true. That said, the change to the binder key derivation (§ 4.2) seems to obviate any potential consequences to such a collision (though the connection attempt would presumably fail). Endpoints which import external keys MUST NOT use either the external keys or the derived keys for any other purpose. Moreover, each IIUC, this is "MUST NOT use the keys that are input to the import process for any purpose other than the importer, and MUST NOT use the derived keys for any purpose other than TLS PSKs". Is it worth spelling it out explicitly like that? external PSK MUST be associated with at most one hash function, as per the rules in Section 4.2.11 from [RFC8446]. See Section 7 for more discussion. Does this requirement apply to the inputs to the importer process, the outputs, or both? Section 3.1 Imported PSK (IPSK): A PSK derived from an EPSK, External Identity, optional context string, target protocol, and target KDF. There is an "External Identity" that is contained within the EPSK itself; is the "External Identity" listed here distinct from that? Section 4.1 The PSK Importer interface takes as input an EPSK with External Identity "externalidentity" and base key "epsk", as defined in Section 3.1, along with an optional context, and transforms it into a set of PSKs and imported identities for use in a connection based on target protocols and KDFs. In particular, for each supported target protocol "targetprotocol" and KDF "targetkdf", the importer constructs an ImportedIdentity structure as follows: If I understand correctly the "targetkdf" is supposed to be the KDF associated with the cipher suite(s) the derived PSK will be usable for. This is something of a divergence from RFC 8446, where we assume that the KDF will be HKDF and associate only a hash function with the cipher suite. While discussing a more generic KDF concept seems reasonable (and is directly in line with the cryptographic principles that motivate this work), I'd recommend adding a few more words somewhere in this section to clarify the relationship between the targetkdf and the cipher suite(s), probably in the paragraph that starts "[e]ndpoints SHOULD generate a compatible 'ipskx' for each target ciphersuite they offer". struct { opaque externalidentity; opaque context; uint16 targetprotocol; uint16 targetkdf; } ImportedIdentity; Should we say that this is using the TLS presentation language? ImportedIdentity.context MUST include the context used to derive the EPSK, if any exists. For example, ImportedIdentity.context may (nit?) "derive" suggests a cryptographic key derivation process, but the rest of the prose suggests that this is more a process of "identification" or "determination". Is there a more appropriate word to use? Given an ImportedIdentity and corresponding EPSK with base key "epsk", an Imported PSK IPSK with base key "ipskx" is computed as follows: epskx = HKDF-Extract(0, epsk) ipskx = HKDF-Expand-Label(epskx, "derived psk", Hash(ImportedIdentity), L) I think we need to say that the HKDF-Expand-Label used (i.e., the URL prefix) is the one corresponding to ImportedIdentity.targetprotocol. L corresponds to the KDF output length of ImportedIdentity.targetkdf as defined in Section 9. For hash-based KDFs, such as HKDFSHA256(0x0001), this is the length of the hash function output, i.e., 32 octets. This is required for the IPSK to be of length (32 octets for SHA256, not all hash-based KDFs) The identity of "ipskx" as sent on the wire is ImportedIdentity, i.e., the serialized content of ImportedIdentity is used as the content of PskIdentity.identity in the PSK extension. The corresponding TLS 1.3 binder key is "ipskx". In RFC 8446, the "binderkey" is the output of the key schedule, but ipskx is an input to the key schedule. So I think we want to say something like "the corresponding PSK input for the TLS 1.3 key schedule is 'ipskx'". The hash function used for HKDF [RFC5869] is that which is associated with the EPSK. It is not the hash function associated with ImportedIdentity.targetkdf. If no hash function is specified, I predict that someone will mess up the hash function selection while implementing this. Perhaps we could provide test vectors for the full matrix of (EPSK Hash, targetkdf hash) pairs using SHA256/SHA384? SHA-256 [SHA2] MUST be used. Diversifying EPSK by I think we might be able to tolerate the protocol* having a strict requirement that the associated hash function is specified, and provide a recommended value that would be used by people deploying the protocol in the absence of other information. This might in some sense help future-proof the document for the scenario where SHA256 weakens or is broken and the default should change. KDFs, protocols, and context string(s) are known a priori. EPSKs MAY also be imported for early data use if they are bound to protocol settings and configurations that would otherwise be required for early data with normal (ticket-based PSK) resumption. Minimally, that means Application-Layer Protocol Negotiation [RFC7301], QUIC RFC 8446 does not limit 0-RTT data to resumption, so I think we just want "if they are bound to the protocol settings and configuration that are required for sending early data". Also, nit: I think we usually refer to the "ALPN value" instead of just "ALPN" being configured. Section 5 If a client or server wish to deprecate a hash function and no longer use it for TLS 1.3, they remove the corresponding KDF from the set of target KDFs used for importing keys. This does not affect the KDF operation used to derive Imported PSKs. Should we also include a paragraph about how to deprecate the Hash used in deriving Imported PSKs? (It's fixed per EPSK, so, "configure a new EPSK", basically.) Section 6 Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK. Thus, an EPSK may be used with the same KDF (and underlying HMAC hash algorithm) as TLS 1.3 with importers. However, critically, the derived PSK will not be the same since the importer differentiates the PSK via the identity and target KDF and protocol. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and thereby avoid cross-protocol collisions. [...] As I read this I recalled that up in Section 1 we say that applications "SHOULD provision separate PSKs for TLS 1.3 and prior versions". The scenario being described here sounds like it can only occur if that SHOULD is ignored, which might be worth reiterating. We also say in § 4.1 that "external PSKs MUST NOT be imported for (D)TLS or prior versions". In light of these two observations, my best interpretation of the quoted text is that it should be equivalent to: NEW: Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK. Accordingly, a given EPSK might be both used directly as a TLS 1.2 PSK and used with TLS 1.3 via the importer mechanism (noting that this configuration is not recommended, per Section 1), using the same KDF algorithm. However, because the TLS 1.3 importer mechanism includes an additional key-derivation step, the actual PSK used in the TLS 1.3 key schedule will be distinct from the one used in the TLS 1.2 key schedule, so there are no cross-protocol collisions possible. Note that this does not preclude endpoints from using non-imported PSKs for TLS 1.2. For some reason this line implies to me that endpoints might use imported PSKs for TLS 1.2, but this is forbidden by Section 4.1 (as quoted above). Perhaps "does not preclude endpoints from continuing to use TLS 1.2 and the non-imported PSKs it requires"? Section 7 We should probably note that any information placed in ImportedIdentity.context will be visible on the wire in cleartext, and thus that confidential identifiers from other protocols should either not be used or should be protected (e.g., by hashing) prior to use. Externally provisioned PSKs imported into a TLS connection achieve compound authentication of the provisioning process and connection. Context-free PSKs only achieve authentication within the context of a single connection. Do we need to use pskdhke to get the strong compound authentication property, or is it attainable with pskke as well? Section 10.1 I'm not sure why [QUIC] and RFC 5246 are listed as normative references. Appendix B The Selfie attack [Selfie] relies on a misuse of the PSK interface. The PSK interface makes the implicit assumption that each PSK is known only to one client and one server. If multiple clients or multiple servers with distinct roles share a PSK, TLS only authenticates the entire group. A node successfully authenticates its peer as being in the group whether the peer is another node or itself. I think it may be useful to call out that the "multiple clients" and "multiple servers" case can occur even when there are only two endpoints that know the key (that is, when they do not have predetermined client/server roles). struct { opaque clientmac; opaque server_mac; } Context; We may not need the whole 16k to hold a MAC address, especially since this is just an example. If an attacker then redirects a ClientHello intended for one node to a different node, the receiver will compute a different context string and the handshake will not complete. Similarly to the above, this could be "a different node (including the node that generated the ClientHello)".


NAME PTAL
LGTM - ‘twas just a comment anyway. W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf


4492bis includes some values we were marking as reserved and that's wrong. We also have 224-255 that we might also mark as reserved. Effectively, this closes these two registries.
NAME PTAL
NAME -- This looks good. I have a quick comment on: I presume this will or won't happen as the result of conversations in the WG? Also, I'll note -- for the (only) -- that only 224-253 are necessary to mark as reserved (or, really, since they were previously okay for private use, I think the term to use is "deprecated"), since 254 and 255 are in the TLS 1.3 "reserved for private use" range of 0xfe00-0xffff
I'm planning to forward the PR to the WG after I heard from you. I'll add in "deprecated" for those other values before sending it along.


Addressing this . NAME NAME PTAL
I am really growing to dislike these "here is the alert you must use" constructions. Are they necessary? A lot of this was born out of the deprecate TLS 1/1.1 RFC that spun this I-D off. I believe this is the thread back in mid-2019: URL spt


Good catch -- will fix. Good suggestion! We can certainly add this. As the extension is merely a hint to servers when deciding how many tickets to vend, I think this is out of scope for the document. It's intended to be once per session, and we'll add that. Also a good catch. Like other extensions that are not affected by the possibly updated ClientHello, it must not change. We need to specify the server side behavior, too. That seems reasonable to me.
Thanks! Approved pending


Require SETTINGSH3DATAGRAM and maxdatagramframe_size TP
Interesting thought. One way to do that replaces the entire section with this: This is certainly more concise, although it does also remove some of the explanations that help people understand the various layers involved. Or perhaps we should include those same additional details but just turn those paragraphs into bullets?
While technically true, I thought we'd said that we wanted to require all the features all of the time, but agreed, let's take that to an editorial issue if needed.
My point is that the server could support both regular HTTP and WebTransport. If a client comes in without webtransport settings and only sends GETs, that's fine. If a client comes in with webtransport settings and makes a webtransport request, that's fine. If a client comes in without webtransport settings and makes a webtransport request, that's not fine. In that case the server needs to reject the webtransport request, not kill the connection.
Ah, that makes more sense, thank you
Per discussion at IETF 114, we should explicitly require support for each layer of capabilities that are needed. There was also a discussion about whether or not we needed to require datagram support, since requiring capsules technically means that you could use a datagram capsule and implementations may exist that do not want to have datagram support at all. Documenting some of that discussion in replies to this issue, as well.
Specific to datagrams and capsules: WT supported means that capsule protocol is supported, thus you must always support capsules. Proposal: You need to have datagrams in order to do WT over HTTP/3 Adding additional signaling to negotiate datagram support introduces a lot of additional complexity and different configurations that may harm interoperability. Dropping a datagram is about as easy as doing any other error path HTTP Datagrams must already be supported in the receive direction for capsules (and you need capsules for WT) either way Intermediaries will need to be able to either translate for upstream or ensure that upstream can provide an equivalent feature set More generally: We want to explicitly call out dependencies/prerequisites so that we don't need to teach layers about other layers. For example, WT being supported doesn't mean that the layers that implement capsules, H3 datagrams, or QUIC datagrams should have any idea about the existence of WebTransport
Discussed at IETF 115, consensus in room to require all the relevant settings and transport parameters to be sent individually
So we need: HTTP Setting: SETTINGSH3DATAGRAM (0x33) with a value of 1 for HTTP datagrams QUIC TP: maxdatagramframesize with a value greater than 0 for QUIC datagrams Capsule protocol support is implicit in the upgrade token, as explicitly called out by RFC 9297 or we can require to be sent on every extended connect request as well. to be added to the existing HTTP Setting: SETTINGSENABLEWEBTRANSPORT = 1 HTTP Setting: SETTINGSWEBTRANSPORTMAXSESSIONS > 0 (although we may be removing SETTINGSENABLEWEBTRANSPORT)
SGTM I think we can skip mentioning Capsule-Protocol to match CONNECT-UDP
Would this be easier to process as a list rather than multiple separate requirements?The list text in that comment isn't correct - the server shouldn't close the connection because it's legal for the client to not support datagrams if it only sends GETs and POSTs. However, the text in this PR is correct. I propose we land the PR as-is and can make editorial changes later.


.
cc NAME NAME
Looks great!
For a simple application that wants to send "hello world" over a WebTransport stream, it would take a minimum of 2.5 round trips for the data to arrive on the server. This is still an improvement over WebSockets but I'm wondering if we could do better. If the client is able to create streams prior to receiving the CONNECT response, then it would remove a round trip. The server would need to buffer any data received on streams associated with an unknown WebTransport session. If the server responds with a non-200 status code, then these streams are discarded. I believe 0-RTT is disabled for WebTransport because CONNECT is not idempotent and would be subject to replay attacks. An idempotent CONNECT would remove a round trip when 0-RTT is used... although I'm not sure this is a good idea.
I think this is a reasonable optimization
The client requirement is odd in comparison to MASQUE / CONNECT-UDP which says "client can risk sending datagrams before getting a 200 response, a different response means that datagrams will be discarded". What is the motivation for the requirement in WebTransport? If you need some kind of ordering guarantees, then stream IDs provide that.
Discussed at IETF 110. There were no objections to buffering (with some limits), so I think we should go ahead and add it.
After the client initiates the WebTransport session by sending a CONNECT request, the server sends a 200 response and is free to create streams. This means that a server-initiated stream may arrive prior to the CONNECT response. Is the client able to infer that the session was successfully established, or does the client need to buffer this stream until it receives a proper response?
Since there are no ordering guarantees across streams on the receiver side, I'd say you have to buffer until the 200 is processed.
I agree with Lucas here. We also had a similar problem in QuicTransport (server has to buffer streams before checking the origin), and we handled it by buffering.
Discussed at IETF 110. There were no objections to buffering (with some limits), so I think we should go ahead and add it.


The H3 draft is light on error handling guidance. There are number of cases for bad session IDs: The session ID is not a client initiated bidirectional stream ID The session ID refers to a stream that did not perform a WebTransport handshake The session ID refers to a stream that has been closed or reset Presumably there is no error when a DATAGRAM arrives with a bad session id -- you just drop it? For streams, perhaps HTTPIDERROR is appropriate? Issues and both refer to cases where you receive a session ID that has not been created yet. Best to keep the discussion there, but it's likely we want to allow clients/servers to buffer some of these at their own discretion rather than require an error.
For 1, I think it should be an error. For 2, we may want to clarify that the headers should be already known at that point, but it should be an error. For 3, I am not sure how to enforce this without running into potential race conditions, so we may want to leave those as-is. As for the datagrams, I think h3-datagram draft should handle this.
Thinking about 2 more, I think there's also a race condition in which a data stream could be received between the stream being open and headers being processed. I'll write up a PR for 1.
I think for 2, I meant the ID refers to a stream where the headers were known but it was not a CONNECT stream.
Discussed at IETF 111. Sense of the room for MUST close for 1, MAY close in other scenarios.


Capsule design team output. Minimal changes to HTTP/3, which was already using capsules and is now joined by . Same content as draft PR, thank you to those who have already reviewed!
Does this actually with a no-op, or are we supposed to discuss that at 115? Otherwise LGTM.
It as a no-op with the exception of one bullet point that we did want to address, that got split out into , which we'll discuss at 115 separately from this PR.
Should the protocol share framing semantics with the HTTP/2 draft so that it is easy/easier to take datagrams or streams and put them on the CONNECT stream? Should it be possible to use that mechanism, or should it instead be forbidden? As much as possible, it would be desirable to have the forwarding logic be fairly uniform across different protocol versions. Right now, we have two almost completely different protocols.
I was discussing this with NAME and NAME What happens when an H3 WT server receives "version independent" WT framing on its CONNECT stream. Since WT over H3 requires H3 datagrams, then there is no need to fold datagrams into the CONNECT stream. There shouldn't be a need to fold streams either, unless you want to defeat QUIC stream limits :) Allowing this would also increase work to implement an H3 only WT client/server: you have to re-implement QUIC over an HTTP byte-stream just in case the peer decides to send you "version independent" WT. Right now I think they are totally different and never the twain shall meet. Proxies can convert between the two versions. If we did that, should we have different upgrade tokens?
Is this issue still relevant now that we have the outcome of HTTP Datagram Design Team?
NAME gentle ping
Actually never mind, this is blocked on the capsule design team - the output of that design team will decide on whether the h2 capsules are allowed in h3 or not
The H3 draft by its nature allows for the parallel processing of multiple WT sessions and also the intermixing of normal H3 request with WT. Server endpoints may wish to negotiate or disable this behavior. Clients can simply choose not to do either kind of pooling if they don't want to. There's already a PR open () with a design idea.
I'd like to propose a different model than the one in : The server sends the maximum WebTransport Session ID, or since 0 is a valid value, it's really the minimum invalid WebTransport Session ID. To indicate WT is not supported, server sends 0. To allow for only 1 session ever, server sends 4, and never updates it. To allow for only 1 session at a time, server sends 4, and updates it by 4 as each session closes/resets. To allow for N parallel sessions, server sends 4 * N. and updates as sessions close/reset. This mirrors H3 PUSH, and requires at least one more frame (MAXWTSESSIONID). Perhaps it would also require CANCELWT_SESSION? A client need only declare that it supports webtransport, and even that could be optional. The server will know if it receives a CONNECT with :protocol=webtransport.
I wanted to have a negotiation mechanism in , but my conclusion after talking with NAME about it was that we should not do negotiation, and servers should just reject extra streams with a 400 (or maybe even a RESET_STREAM) if they ever see more sessions than they expect; meaning it's on the clients to know if they can pool or not.
Though we may want a more specific 4XX error code so the client knows it should retry in a non-pooled connection
That's certainly a lot simpler than session credits ;) The cost of at least an RTT for a client that tries to pool against a server that can't handle it seems somewhat high. I guess it depends what the common client pooling strategies are and how many servers don't support pooling.
NAME since it's looking like the JavaScript API will provide a way to disable pooling, I expect that the scenario of pooling-attempted-but-rejected will be quite rare, so a round trip cost should be acceptable
I'm also considering use cases for WT which are not tied to the JS API.
NAME that's interesting - and those use-cases won't have a similar mechanism to disable pooling? I suspect they'll need a way to get the WT server's hostname somehow, and having config properties attached to that (such as disable_pooling) could be useful?
NAME : the opposite -- the clients may attempt pooling to servers that might or might not support it. You can't tell from a hostname if it supports pooling.
NAME how did the client get the hostname in the first place? I'm suggesting to carry pooling_support next to that.
Actually, let's go back to JS for a second. The people who write JS at Facebook are very unlikely to know if the edge server terminating their connection supports pooling, or that configuration could change over time.
(I appreciate the irony of me saying this as a Googler, but) should the JS people talk to the edge people? I agree that this shouldn't fail, but it being inefficient seems reasonable - these teams should talk if they're trying to reach good performance.
I think my main problem with is that most people who want to disallow pooling want to exclude not only other WebTransport sessions, but also general HTTP traffic. was written with that assumption in mind.
Ok, MAXWTSESSION_ID doesn't handle that case, so it may be an over-engineered solution to the wrong problem.
As I said in the meeting, I don't think that we should have any signals for dedicated connections from either client or server. Yutaka made the point that the client can decide to make a connection dedicated after seeing the server settings. It doesn't need to signal its intent (and signaling would have negative privacy consequences potentially). I agree with this observation. A server needs to support HTTP if we're using HTTP. So pooling with h3 is already a settled matter. If the server doesn't want to answer requests, it can use 406 or 421 or other HTTP mechanisms to tell the client to go away. More generally, the server can just not provide links to that server, such that it might have to respond to GET/OPTIONS/POST/etc. The question then becomes managing resource limits on the server. Having a way to limit the number of WebTransport sessions is a good thing and I believe that will be sufficient for this. Thus, I'm a supporter of option 3: MAXWTSESSIONS or similar.
I agree that we should have limits of how many WT can be active at the same time on a connection. It should also define what happens if the limit is exceeded. Should a client open another QUIC connection to the same server or should it fail? Probably it should be former, but that should also have limits defined (6 parallel QUIC connection, may be too much? HTTP/1.1 have the 6 parallel connection limit).
Chair: discussed at IETF 113, consensus in room to change the WT SETTING to carry the number of concurrent WT sessions allowed on this h3 connection
Note that all of the below works when you swap "server" and "client". I wanted to focus on a poor Javascript client implementation, but it's equally possible to run into these cases with a poor server implementation. Let's say that you have a Http3Transport session that shares a connection with HTTP/3 or another Http3Transport session. The client has limited buffer space and hypothetically advertises MAXDATA of 1MB for the connection. If the server pushes 1MB of unprocessed data over a Http3Transport session, then it will prevent the server from sending data over the connection, including HTTP/3 responses and other Http3Transport sessions. This can occur if the application does not accept all remote-created streams or does not fully read every stream. This will be VERY easy for a developer to mess up. It can also occur if the application can not process data faster than it is received. In my case, the server creates unidirectional streams and pushes a large amount of media over them. The flow control limit would be hit if the Javascript application: Only accepts bidirectional streams (ex. initialization) Does not accept a unidirectional stream (ex. error or teardown) Does not fully read or abort every stream (ex. parsing error) Is not able to parse the media fast enough (ex. underpowered). This is mostly intended behavior, otherwise these "bugs" would cause unbounded memory usage. However, the blast radius is bigger when sharing a connection. In my use-case, hitting the flow control limit would also block any HTTP/3 RPC calls or unrelated traffic on the connection. This introduces more scenarios for the connection to become deadlocked or generally stalled. HTTP/3 implementations use MAXSTREAMS to limit the number of simultaneous requests. This use-case no longer works when sharing a connection with a Http3Transport session, and HTTP/3 implementations must instead return explicit error status codes when this threshold is reached. The same issues with MAXDATA also apply to MAXSTREAMS. A Javascript application that fails to accept or read/abort every stream will consume flow control resources. This can manifest itself in strange ways, such as HTTP/3 being unable to create control streams, or simply being unable to create new request streams.
Thanks for the salient overview, it makes it easier to understand your concerns. My first comment would be that some of these points apply to QuicTransport too. Its just that their made worse by Http3Transport pooling allowing the mashing together of orthogonal protocols with no application-layer oversight. Just as you might interfere with a page load, a browser could easily interfere with your finely crafted application protocol. I would anticipate that, due to different browsers having different HTTP usage patterns, and different pages being composed differently by time, region, etc, one might find that Http3Transport apps subject to pooling would experience inconsistencies and transient issues. You rightly point out that the connection flow control is a shared resource. But the problems described seem to relate to stream flow control and overlooks the different flow control setting afforded by the Transport Parameters. A possible mitigation is to more tightly constrain the initial flow windows of server-initiated streams so that they can't interfere with requests. However, I still think that the notion of pooling together WebTransports in an uncoordinated fashion is going to manifest undesirable properties. The MAX_STREAMS observation is a good one. I think the competition between request streams and client bidirectional streams is going to be hard to resolve.
Yeah, and enforcing any per sort of per-session flow control might get difficult because you can only identify the protocol and session after you receive the first few bytes of each stream. For example, assume a brand new connection (for simplicity only) and you receive a STREAM frame with id=100, offset=16, and size=1000. You don't know yet which protocol or session created this stream or the 25 preceding it. And hopefully you eventually get those first few bytes for each stream...
Chair notes from IETF 112 meeting: this needs more discussion (on the issue or mailing list)
Chair: discussed at 113, consensus in room to: use a setting to limit number of WT sessions (see ) figure out MAXSTREAMS, a way to limit the number of streams within a session abandon MAXDATA as too hard, do not limit amount of data sent within a session (anyone can open a new issue to revisit this discussion if they have a concrete proposal on how to do this) let QUIC take care of MAXSTREAMDATA
Capsule DT is doing all of the above bullet points except the second one, for which I opened . Apologies for the extremely delayed response here, but hearing no objections we are declaring consensus and merging the PRs. David David Schinazi wrote:


In URL, it was suggested that 403 status code should be used when Origin verification fails.
Thank you for suggestions! Applied.
Thank you for reviews! If this looks good can someone merge this?
Looking good, thank you! Added a few suggestions to cause it to generate links to the actual sections referenced, even if it makes it a little more repetitive.Approved modulo one small change


Answer to issue
A first sentence says quasi-error-free is usually guarranteed thanks to redundancy, while the following sentence tends to say the opposite. Not very clear.The intro fails to clarify the targets. Among them there is "coding to recover from packet losses" (to avoid confusion with bit-error corrections), but also "coding to improve the usage of radio resource". You should also clarify better what is meant by coding: it's not a content coding (e.g., to compress a video flow) but rather a computation of linear combination of packets. Say since the begining you'll rely on RFC8406 whenever possible. Parts of the text currently in section 3 (1st paragraph) deserve to be moved here.Typo: s/to cope from/to cope with/
We have updated the introduction structure and changed the usage of coding in the whole document. We hope this is better. cf PR and PR
this is cherrypicking, not discussing link/channel FEC (Error) or ACK. the heading should really be 'of network coding schemes'. "to cover cases where where"? At the physical layer, FEC mechanisms can be exploited.-- Erasure or Error? "Based on public information, coding does not seem to be widely used at higher layers." it isn't, and that section can be reduced to just that sentence.
Vincent in item X1, 1st sentence, it suggests QUIC is a video streaming application. Change it.Fig. 2 raises a general question: it refers to upper applications that are by nature on the end-hosts. Everything is imaginable here and this is not specific to a SATCOM system. Why don't you limit yourself to the communication layers + middleware? I'm a bit confused.When you say: "Based on public information, coding does not seem to be widely used at higher layers." I guess you limit yourself to the "packetization UDP/IP + middleware" but do not consider upper applications. It's also confusing.
We think that these comments have been assessed with PR
"However, physical layer reliability mechanisms may not recover transmission losses (e.g. with a mobile user) and layer 2 (or above) re-transmissions induce 500 ms one-way delay with a geostationary satellite" Look, forward error coding (FEC) and link ACKs are complementary on a sliding scale depending on delay/channel quality, and this is talking solely about retransmissions. In fact, link or channel FEC do recover a large number of transmission bit/symbol losses without adding extra delay.
We have clarified this point in PR


I have no idea what this section means. Virtualised antennas? virtualised reflectors? Good luck with that. chin-nfvrg-cloud-5g-core-structure-yang referring to an expired -00 internet-draft does not add credibility.
MJM : But on the virtualization comment: we had presentations in the group on NFV (network virtualization) with NC for satellites. I am sure that the authors of this work could add to Lloyd’s comments on that section.
We have added a research challenge and changed the title of section in PR . The section aims at identifying research challenge related to the interaction between NC and virtualization (function chaining, buffer management, etc).


First sentence, the use of "these techniques" is ambiguous. Which techniques?
Thanks. Updated in PR


Reset stream doesn't cease retransmission.
retransmission of WTSTREAM frames on the identified stream. A receiver of WTRESET_STREAM can discard any data that it already received on that stream." This is using TCP and should not talk about ceasing retransmissions.
Very good point! Will clean up


As suggested by Éric Vyncke, mention that the new ciphertext record format provides ContentType encryption and per-record padding in both abstract and introduction.
URL Update from Éric re: Section 6
About "-- Section 3 --, DTLS / zero-length CID" "An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello." The "zero-length CID" therefore is mainly used for the very common cases, where only the clients are required to send such a CID, but not the server. Maybe adding a hint to RFC5246 7.4.1.4 will help?
About "-- Section 6 --" Yes, that's still very complex: First, processing the record seems to be easier (less restricted), than use a changed source address for sending data back. Using a changed source address for sending data back to, is not generally solved. There are some special case, e.g., if the data sent back is very small, there is no risk (at least, none has explained one). There may also be some upper-layer mechanisms, which helps out (e.g. for coap). And there is a idea of a general solution , but that will require more time. Because of the required time, the idea was to release this spec without RRC and postpone that general work (see also issue ).
also in the abstract ? Some initial attempt at this in
LGTM Éric Vyncke has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work put into this document. This specification addresses the IPv4-mainly issue of NAT binding and is still required. I am also trusted the security ADs for section 5. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- As an important part of this document is the padding, should it be mentioned also in the abstract ? -- Section 3 -- While I am not a DTLS expert, I find this section quite difficult to understand the reasoning behind the specification as little explanations are given about, e.g, what is the motivation of "A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID." -- Section 6 -- I am puzzled by the text: "There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No such strategy is defined in this specification." Does this mean that there is no way to update the peer IP address ? == NITS == -- Section 1 -- Please expand CID on first use outside of the abstract. -- Section 4 -- Suggest to add a short paragraph as a preamble to figure 3. Currently, it looks like figure 3 belongs to the 'zeros' field description.


Based on URL
Thanks!
Martin wrote: URL LGTM. I would strike ", if these privacy properties are important in a given deployment" from the acknowledgments section (which is an odd place for the accompanying statement. I would add an explicit note about the lack of CID update making this unsuitable for mobility scenarios. That's a common use case for this sort of mechanism, but this design lacks any defense against linkability. >


We incorrectly put a normative reference on the RRC draft in the DTLS 1.2 CID draft.
I lost somehow the track on that RRC and the discussion around it. The referred document mentions: and I would assume, that a on-path adversary could black hole traffic in both directions, even without CID. Not only message sent to a peer could be dropped, it would also be easy to drop a message sent back from that peer (at least, if the route back is on the same path). I would also assume, that a on-path adversary, which is able to change the source address, would also be able to change the destination address. So a simple traffic redirect will also be possible even without CID. In my opinion, the only threat left, which is caused by the usage of a CID, would be a DDoS attack using amplified traffic towards third party. For that it seems to be most important to throttle the traffic by limiting the number and size of messages until the address is verified. Though such a DDoS will be naturally less efficient, because the adversary has to wait for messages to change the sources-address, throttling would make it even more unattractive.


This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.


and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.


I am OK with this change. There are no normative changes in there because the normative text segment is only moved to a different paragraph.
I was referring to this added clause: "alternately it MAY report PMTU estimates minus the estimated expansion from the transport layer and DTLS record framing."
What is awkward here is that this is phrased as normative requirements on an API. Maybe worded as advice "an application that uses DTLS might need information from DTLS to allow it to estimate the PMTU; DTLS could report a PMTU estimate less any DTLS overheads, or it can report those overheads and allow the application to perform its own estimation"
There has historically been API language here, so I think we should keep it and just adjust it as here.
This one probably needs consensus given new normative language.


You don't want to age out before you get epoch 3 because otherwise you might be dropping when you have handshake packets.
For my understanding: what is the harm of keeping the 0-RTT keys around till the end of the handshake?
"Yes, the goal is to encourage people not to keep 0-RTT keys too long, because they might not have PCS. The replay risk is essentially a non-issue, except to the extent that it might already have been replayed."


It's possible to negotiate the CID extension but that you want to receive an empty CID (this is how you get asymmetrical CID lengths). The current text says: CID. If an implementation receives these messages when CIDs were not negotiated, it MUST abort the connection with an unexpected_message alert. But does this mean that (for instance) you can negotiate receiving an empty CID and then switch to a non-empty? I am tempted to say "no" as I recall QUIC did.
Doing what QUIC did seems prudent ... and if I didn't know what QUIC did I think I would also lean towards disallowing switching between empty and non-empty on a live connection.


Thanks for this document -- badly needed and easy to read. Thanks also to Bernard Adoba for his recent tsvart review. I support his comments. COMMENTS: Sec 2. It might be useful to introduce the term "epoch" in the glossary, for those who read this front to back. Sec 4.2.3: "The encrypted sequence number is computed by XORing the leading bytes of the Mask with the sequence number. Decryption is accomplished by the same process." The text is unclear if the XOR is applied to the expanded sequence number or merely the 1-2 octets on the wire. I presume it's the latter, but this should be clarified. Sec 4.2.3: It's implied here that the snkey rotates with the epoch. As this is different from QUIC, it's probably worth spelling out. Sec 5.1 is a bit vague about the amplification limit; why not at least RECOMMEND 3, as we've converged on this elsewhere? Sec 5.1. Reading between the lines, it's clear that the cookie can't be used as address verification across connections in the way that a NEWTOKEN token is. It would be good to spell this out for clients -- use the resumption token or whatever instead. Sec 7.2 "As noted above, the receipt of any record responding to a given flight MUST be taken as an implicit acknowledgement for the entire flight." I think this should be s/entire flight/entire previous flight? Sec 7.2 "Upon receipt of an ACK that leaves it with only some messages from a flight having been acknowledged an implementation SHOULD retransmit the unacknowledged messages or fragments." This language appears inconsistent with Figure 12, where Record 1 has not been acknowledged but is also not retransmitted. It appears there is an implied handling of empty ACKs that isn't written down anywhere in Sec 7.2 Sec 9. Should there be any flow control limits on newconnectionid? Or should receivers be free to simply drop CIDs they can't handle? It might be good to specify. Finally, a really weird one. Reading this document and references to connection ID prompted to me to think how QUIC-LB could apply to DTLS. The result is here: URL Please note the rather unfortunate third-to-last paragraph. I'm happy to take the answer that this use case doesn't matter, since I made it up today. But if it does, it would be very helpful if (1) DTLS 1.3 clients MUST include a connectionid extension in their ClientHello, even if zero length, and/or (2) this draft updated 4.1.4 of 8446 to allow the server to include connectionid in HelloRetryRequest even if the client didn't offer it. Thoughts? NITS: s/select(HandshakeType)/select(msg_type). Though with pseudocode your mileage may vary as to what's clearer. s/consitute/constitute Sec 5.7 In table 1, why include one ACK in the diagram but not the other? It's clear from the note, but the figure is a weird omission.
Addressed in URL


NAME here is another try at this.
I did not realize that the intent of your text was to allow out of order processing. IMO that's off the fairway and we shouldn't allow that any more than we let you reach into the TCP stack and pull out forward messages.
NAME I don't think the comparison with TCP works - the handshake protocol is internal. We should not force a particular implementation unless there's good reason to. In this case, as explained on the list, there's potential merit of allowing out of order processing of very large handshake messages with known structure. NAME What's your opinion?
Again, this is a last minute change during Auth48, so the bar is much higher than "potential merit"
This isn't motivated by security-related reasons like , so I agree with NAME that this does not raise to the level of an AUTH48 change. I propose we land this PR and close out .
Thanks NAME NAME for considering this in the first place. As I understood NAME since this does not impact the wire-format, we can revisit once the RFC has been finalized?
Once the RFC is finalized, it's final. Changes can be requested via the , or via a new document that updates the RFC in question.
Ok, thank you. I was referring to NAME comment on the list
Yes. What I was saying is that you could just write an RFC that said "you can process out of order"
corresponding to the next expected handshake message sequence number, it MUST buffer it until it has the entire handshake message. As discussed in URL The spec mandates buffering all handshake fragments, but some implementations (e.g. GnuTLS) choose to implement simpler reassembly schemes. It has been argued by Ekr that such should be discouraged because they aren't efficient. On the other hand, as Rich Salz remarks, the choice of reassembly mechanism isn't something the peer could tell (the effects of poor reassembly performance are more retransmissions, which could also be due to poor network reliability), so it does feel like we're overspecifying things here. Weakening the MUST to a SHOULD isn't good either as it allows dropping fragments altogether. There's a tension between the desire for a concrete operational guidance, which the current text clearly provides, and a more abstract formulation along the line of "implementations MUST use a reassembly scheme ensuring forward progress". As suggested by Ekr, taking this off the mailing list and continuing discussion here. To be clear: This has no bearing on the protocol itself, it's about how much implementation details the spec should enforce.
As mentioned on the list, I don't like the in-order qualification. I agree it's debatable whether there will be cases where it makes sense to process data out of order, but (see list again) it is not inconceivable, and I see no reason to exclude this here. I would therefore prefer to drop the in-order qualification. Hi all, Both DTLS 1.2 and DTLS 1.3 mandate: Can someone explain the underlying rationale? It seems that in the context of very large key material or certificate chains (think e.g. PQC), gradual processing of handshake messages (where possible) is useful to reduce RAM usage. Is there a security risk in doing this? It would also be useful for stateless handling of fragmented ClientHello messages. I'm sure this was discussed before but I don't remember where and who said it, but a server implementation could peek into the initial fragment of a ClientHello, check if it contains a valid cookie, and if so, allocate state for subsequent full reassembly. That wouldn't be compliant with the above MUST, though, as far as I understand it. Thanks! Hanno IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


The draft states in three places that DTLS use explicit sequence numbers, while this was true for DTLS 1.2, the sequence number in the DTLSCipherstructure is a mixture of implicit and explict. Maybe "Partly Explicit"?
Please provide me with a PR to add your name to acknowledgements.
Hi, I don’t know what PR is an abbreviation for but I guess it is not clear from my username who I am. I should probably update it, I did not intend to be anonymous :) John Mattsson, Ericsson, EMAIL


Suggested fix for
Karl: -- In Section 7.4 it says: "The Initiator and the Responder must make sure that unprotected data and metadata do not reveal any sensitive information." Should it be put in a less requirement-like form? For example: "unprotected data and metadata can reveal sensitive information and need to be selected with care."?
I agree that the metadata text should not be requirement form as much as it is now – there’s little that implementations can actually do about this, e.g., about the network name. Will make a PR.


I think this can be merged.
Fixed the problem with ':' in refs. Now merging.
Based on Stephens review
Referring to this in :
From the PR : "As explained by Krawczyk, any attack mitigated by the NIST requiment would mean that the KDF is fully broken and would have to be replaced anyway." I didn't understand "any attack mitigated by the NIST requirement", and how mitigation could imply that something is broken. As far as I understand, the statement is something like "if there is a problem deriving secret and non-secret material from the same KDF, then there is a problem with the KDF" Perhaps "an attack based on the violation of the NIST requirement is an attack on the KDF itself"?
Yes, it was likely meants to say "if any attack is mitigate" Let's reformulate according to your suggestion
I made a commit to correct spelling and grammar. I don't think we can give applications more guidance here. How to gererate e.g. private key in certificates are way outside of EDHOC, and it would anyway be hard to say something general as deployments might look very different.I did not want to say anything about randomly generated conenction ID as that is not how connection IDs is meant to be generated. They are intended to be as short as possible. An implentation is allowed to use long random bytestrings but is not recommended in general.
PR merged


There has been a lot of suggestions and discussion regarding the key derivation latelely. Below is an attempt to summarize all the current suggstions that currently seems relatively likely to be done. This is not an issue in itself but I think it is good to have somewhere to discucess the complete changes to the key derivation. Suggested to permute the order of element in the TH2 sequence to be more resistant to any future collision attacks in hash functions. Exact order unclear but suggested to put the random and unpredictable GY first. Suggested to use PLAINTEXT instead of CIPHERTEXT in transcript hashes to simplify formal verification. Endpoints agree on that they received the same plaintext rather then the same cipertext.Suggested to use a salt derived from PRK in Extract to avoid usign the PRK keys directly in both Extract and ExpandSuggested to use unsigned integer instead of text string for label to save memory.Suggestion to add a final key derivation PRKout and use that in the exporter. Note that the exporter would also have uint labelsSuggestion to base Key-Update on Expand instead of extract. The label would need IANA registration. hashlength is a new variable that the implementation needs to keep track of. Should considered whether using Exporter for KeyUpdate has any disadvantages. Suggested that more info on how an application protocol is supposed to use KeyUpdate and Exporter together is needed.The EDHOC internal key derivations (i.e., not using the Exporter) would then be something like below. The exact labels should be discussed. Note that that only some of the derivations actually need a label to avoid collisionIncluding KeyUpdate, the IANA registered exporter labels could be:
Looks good. I had different naming in mind of the salts: PRK3e2m = Extract( SALT3e2m, GRX ) PRK3m = Extract( SALT3m, GIY ) where SALT3e2m = EDHOC-KDF( PRK2e, TH2, 0, h'', hashlength ) SALT3m = EDHOC-KDF( PRK3e2m, TH3, 0, h'', hashlength ) With this the salts are named by its use rather than from what key they are derived.
The labels was just to illustrate the fact that they don't need to be separate. I think it is still better to just use 0-7. That makes it very easy for the reader to see that there are no collisions.
NAME Was this a comment on my proposed names of salts, or a separate comment? (I agree labels 0-7 is good.)
It was a separate comments. Your suggestion for salt naming is fine with me. Some other non-technical naming things that a hidden in my summary above I think keylength should use different terms in the derivation of K4 and OSCORE Master Secret. The current naming gives the idea that they are the same. I think the contexts in the MAC2 and MAC3 derivations should be given names. Should consider collection all the EDHOC-KDF derivations in a single place.
Might want to derive: K4 = EDHOC-KDF( PRK3m, TH4, 0, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 0, h'', ivlength ) to avoid that the applicaiton gets K4 and IV4. Another alternative is to use K4 = EDHOC-Exporter( 7, h'', keylength ) IV4 = EDHOC-Exporter( 8, h'', ivlength ) and forbid the application to use the labels for K4 and IV4
Editorial; should be: K4 = EDHOC-KDF( PRK3m, TH4, 1, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 2, h'', ivlength ) or, if we want all KDF labels distinct: K4 = EDHOC-KDF( PRK3m, TH4, 8, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 9, h'', ivlength ) Alternatively, application access to Exporter only allows uint with: K4 = EDHOC-Exporter( -1, h'', keylength ) IV4 = EDHOC-Exporter( -2, h'', ivlength )
Trying to compile the suggestions. These have a PR: Suggested to permute the order of element in the TH2 sequence … Suggested to use PLAINTEXT instead of CIPHERTEXT in transcript hashes … Suggestion to add a final key derivation PRKout and use that in the exporter The following needs to be addressed: Suggested to use a salt derived from PRK in Extract define salt derive salt Suggested to use unsigned integer instead of text string for label to save memory suggestion to base Key-Update on Expand consider whether using Exporter for KeyUpdate has any disadvantages. more info on how an application protocol is supposed to use KeyUpdate and Exporter together distinguish keylength in K3/K_4 and OSCORE Master Secret define contexts explicitly table of KDF derivations
Trying to put things together. Let's call this variant A, part 1. where and (edit: depending on method) New salts to avoid double use of PRK, named by its use. Same construction for K4/IV4 as K3/IV3, motivating the renaming of 3m in as 4e3m. The label in the KDF, third argument, is an uint, all distinct for simplicity.
Variant A, part 2: Distinct "transcript hash" in KeyUpdate and Exporter. Exporter does not give access to EDHOC internal keys. OSCORE key length separate from key_length. Edit: Not clear that 'context' is needed in the EDHOC-Exporter. Also, to be strict in labelling we could continue enumeration. Here is variant B, part 2 (B.1 = A.1):
Variant C.2 (C.1 = A.1): (edited:) Same as B.2 but with different labels. With variant C we have essentially: the internal KDF labels with current list: 0, ..., 9; and the IANA EDHOC Exporter Registry with current list: 0, 1.
NAME NAME NAME and all: Any implementation considerations or other comments on variant C above? We'll start with the PR(s) soon.
The last posts here are confusing.... I don't agree. These are separate. We should definitly not try to keep them separate. I.e. it should be Master Secret = EDHOC-Exporter( 0, h'', oscorekeylength ) Master Salt = EDHOC-Exporter( 1, h'', oscoresaltlength )
The above looks good to me with the following not so interesting options. order of the 0-9 labels use 10 or 0 label for Key-Update order of the h'00' and h'01' "transcripts"
I think we should maybe merge the "context" and "transcript hash" inputs. This simplifies things and avoids using h'00' and h''01' as "transcript hashes.
Alternatively
The latest version of the summary URL looks good.
Overview of main changes needed: Merge Rename PRK3m as PRK4e3m Section 4.1 update PRK definitions move section PRKout to 4.2 Section 4.2 Update EDHOC-KDF and info definition Update derivations Include derivations of salts and K4 / IV4 List EDHOC-KDF derivations with labels 0-9 Section 4.3 Update EDHOC-Exporter (use label 10 instead of 11) Remove derivation of K4 / IV4 Section 4.4 Update EDHOC-KeyUpdate (use label 11 instead of 10) Section 5.3.2 Define context2 Section 5.4.2 Define context3 Section 9.1 Update EDHOC Exporter labels Appendix A.1 Update Master Secret/Salt derivation
Additional updates: As noted in previous comment, a proposal to interchange labels 10 and 11 to enumerate labels in the order they appear in the specification. (Other proposal for assignment of integer labels is welcome.) Should we align / adapt definition of contextx and externalaad? Currently (for message2 and similar for message3): externalaad = > context2 = > Edit: Seems to be favourable to at least align this blobs, so changed context2 to > and similar for context_3, in 5464707a
PRKexporter is a key which we only introduce for simple distinction between different KDF applications. Perhaps an overkill? May open up for unnecessary discussion about properties of that key. Here is another variant: Edit: As commented before, Marco thinks a separate PRKExporter is preferred; less error prone etc.
Most old comments are now addressed, and there are quite a few changes, so it is a good time to merge PR . Remaining points: derivation of K4/ IV4 and text about key confirmation. Not clear if there is any difference in practice between K4 /IV4 being derived from PRK4e3m or PRKout, but the current text about explicit key confirmation is not valid in the former case. May alternatively tune down the key confirmation terminology. Suggested to make clearer distinction between key derivation for EDHOC processing, resulting in PRKout, and key derivation for application, i.e. making use of PRKout in EDHOC-Exporter and EDHOC-KeyUpdate. More guidance on the latter is also proposed.
Tried to address the remaining points in the previous comment with the latest two commits: 5d675ac and 95e35bb. More guidance on KeyUpdate may still be needed. Other points?
NAME What more guidance is needed on KeyUpdate?
Was a request from someone. Might be hard to understand how to use it. E.g. that you should alternate key update and exporter Exporter Key Update Exporter Key Update Exporter ...
Another guidance needed is how to manage overwrite of PRKout pending confirmation of the derived key from the other endpoint. When the Initiator is updating PRKout it needs both old and new derived keys to be able to communicate securely in lock-step the change to the new key.
Perhaps good to remark that the entire application contexts (including e.g. sequence numbers) need to be maintained before a transition is made.
see instead. The current discussion has very little to do with


Further security considerations about how message content is protected against manipulation. Perhaps something like this: "Manipulations of message1 may not be detected at reception since there is no MAC but, since message1 is included in TH2, if I and R disagree on message1 then subsequent PRKs and MACs will be different. Manipulations of other messages are detected at reception through the MACs, except for manipulation of the encrypted padding of message2, since PAD2 is not integrity protected."
I made a PR for this
I merged to prepare for submission on -15. is just a simple clarification.
The selfie attack mitigation implies that an initiator is stopping the exchange if it receives its own identity. An active attacker can then use this behavior to test if an initiator identity is the same one as a responder identity. In turn, it implies that the initiator anonymity does not hold against an active attacker when this mitigation is enabled. To judge if this is an issue in practice, the following question should be answered: Are there scenarios where an identity is shared between an initiator and a receiver, but the initiator identity should still be protected? One could maybe think about the case where multiple initiators and receivers are on the same server, sometimes sharing public keys and using distinct ports, but it is expected that the initiators identities are still protected. Possible actions: mention privacy loss due to the selfie attack mitigation. update the selfie attack mitigation, by mentioning that initiators should conclude the exchange as usual, but can check at the end whether they are talking to themselves or not. remove the selfie attack mitigation. Classical selfie attacks are when there is a pre-shared key between an initiator and a receiver, and the initiator will be talking to itself while it believes to be talking to the receiver. When there are only public keys, as in EDHOC, it is unclear to me if what is currently called in the draft is indeed a selfie attack. An initiator talking to itself knows it and does not believe to be talking to some other identity. As such this is why it could be possible to either remove the mention of selfie attacks in the draft, or update it.
I and R are expected to stop the exchange it they receive any identity they do not want to talk to. This likely includes their own identity. Good point that this leaks information. I think that should be added, but I don't see that the own identity is special. >Classical selfie attacks are when there is a pre-shared key between an initiator and a receiver, >and the initiator will be talking to itself while it believes to be talking to the receiver. >When there are only public keys, as in EDHOC, it is unclear to me if what is currently >called in the draft is indeed a selfie attack. The selfie attack mitigation is intended for Trust On First Use (TOFU) use cases, where there is no authentication in the initial setup. I don't think an initiator talking to itself in a TOFU use case would not know it except if they checked R's public key. Do you some better suggestion than "Selfie attack". I agree that it is not perfect. "Selfie attacks" has in older papers been called reflection attacks, but the term reflection attacks has also been used for very different attacks. One option is to not give the attack any name and instead just describe the attack.
I think I like to not give any name, as it does not perfectly match the classical definition. Here, the property which is violated is "If an EDHOC exchange is completed, two distinct identities/computers/agents were active". Which is different to violating the authentication of the protocol as is the case in classical selfie attacks. Good point. So what we are talking about in this issue is a slightly different privacy leak, which happens when the set of parties you are willing to talk to is equal to all responders minus yourself. To be more concrete, let me try to put it in a kind of drafty formal description that could replace the existing formulation. First the existing formulation: Now a possible replacement:
Thanks for the input! This issue is related to the TOFU use case which is still to be detailed (Appendix D.5). We probably should wait with the update until we have progressed that.
Relates to
I made PR for this issue. This is also related to PR and PR . The suggested text in is largely based on the suggested text above but I made some changes. I did not think this fitted well with the rest of the draft. The sentence was also not really needed. This is only true in the case where the set of identifiers is a small finite set. In the general case the set of identifiers the Initiator is not willing to communicate with is infinite. I suggest to add the following recommendation for TOFU To not leak any long-term identifiers, it is recommended to use a freshly generated authentication key as identity in each initial TOFU exchange.
I merged the PR to master. Keeping the issue open for a while.


Should be checked for conflicts with
I think fixing the comments above resolves conflict with , so can then be replaced by this.
This proposal for update in the key derivation description also addresses the clarifications requested in , thus replacing . We merge this to include it in -15 and enable further reviews.
This is not correct. How to derive and store PRKexporter is completely up to the implementation. One can derive PRKexporter everytime Exporter is called. This make it look like PRKout is overwritten. This should be formulated with and like TLS 1.3 or with and or something. How long to save the old keying material (PRKout, PRK_Exported, any derived keys) is likely up to the application. The importand thing is that they need to be deleted to give FS.
There was a request from someone that more guidance on the use of KeyUpdate should be expanded. Maybe not clear how you are supposed to alternate KeyUpdate and Exporter to get FS.
As you are considering making the KeyUpdate more detailed, I have a general design question. Are there use cases where one would expect Post-Compromise Security? That is, if one of the participant's PRK_out is compromised, a successful KeyUpdate mechanism between the two honest parties would heal them and lock out the attacker That is typically what is met by the double ratchet from the Signal app. The classical way to achieve that is roughly to have each party send out for the update fresh DH ephemeral shares, and add the corresponding DH secret inside the key derivation. (it would of course require more care than that in the details)
I think part of the plan is to make it less detailed and leave some stuff to the implementation/application :) The current KeyUpdate mechanism only gives forward secrecy. If you exchange some nonces and use them as a context you might get protection against an attacker is not monitoring all your traffic. I think details of this should be specified outside of EDHOC like in the OSCORE KeyUpdate draft in the CORE WG. The double ratchet was discussed in LAKE WG at an earlier point. The conclusion was that it added to much complexity to specify that as part of EDHOC. To get this kind of security an application has to rerun EDHOC frequently (like TLS 1.3). Signal uses the Diffie-Hellman ratchet very often which makes it understandable to have on optimized Diffie-Hellman ratchet post-handshake. Contrained use cases of EDHOC can not do Diffie-Hellman as often as Signal so it was determined that requiring rerun of the full EDHOC was the best tradeoff. Should the EDHOC specification say more about the benefits of frequently rerunning Diffie-Hellman? I don't remember how much it says. I recently wrote a paragraph about this that was accepted to RFC8446bis.
This is not correct. PRKout does not need to be stored. An implementation can derive the application keys directly and never store PRKout. An implementation can also store PRK_exporter if they don't use EDHOC-KeyUpdate.
This is not enough. You need to be sure that the old key is not needed more.
I merged which addresses some points raised in this issue. Please review and comment if there is anything missing.
No comments received, so I assume this is fine. (KeyUpdate is now in an appendix.)


Suggestion to clarify and maybe give example of randomness and unpredictability. The SHOULD should probably be removed. Unclear if 1 byte identifiers can ever by unpredictable.
Closing this as approved by Marco.
Looks good to me. NAME ?


Hi all, Our previous formal analysis on draft 12 and 14 lead to a publication at USENIX 23 available here URL As the two other previous formal analysis were cited in the draft, I'm proposing to add next to them our new one with this PR. As a side remark, our models are here (URL), and we are trying to update everything according to draft 17 with a new overall pass. It might be tight for IETF115, but we are trying our best! And anyway, it should only be positive results by now ;)
NAME Thanks! Great that you follow up with the latest version. The latest relevant changes are probably in -16 and only adds things to the key derivation (some of which was proposed by you :-).
Thanks for the pointer! Though, the biggest issue is not so much updating the model of the protocol, but rather making a new full pass on the security claims and new appendices, trying to have a clear systematized link between claims from the draft and what we check in the model.
NAME let's check if there are some other papers missing and what we want to say about them.
We should at least add references to work by ETH and ENS. Let's merge this as a starting point and continue discussion in .
Given the various security analyses EDHOC has seen and their insights being discussed in Section 8, would it make sense to add informative references to those (as done, e.g., for TLS 1.3, RFC 8446 Appendix E)? URL
Seems like a good idea to me
Related to
This was discussed on the IETF 116 LAKE WG meeting, and in absence of volunteers to draft such an appendix we decided to start with adding references. We may want to go somewhere in between a whole appendix and a sentence, and expand with a paragraph about each reference. We still need someone to draft that paragraph for the different references and would like to conclude on this fairly soon. We start by merging now.
Closing since is merged. Hi all, While we do not have any explicit comments on the document, we thought it is maybe still worthwhile to share the following analysis confirmation. We updated our computational analysis of the SIG-SIG mode, of which Marc presented an earlier version at IETF 114, to draft 17. We could confirm that with some of the later cryptographic suggestions (PR , ) included, EDHOC SIG-SIG achieves key exchange security (key secrecy and explicit authentication) in a strong model capturing potentially colliding credential identifiers, assuming, among others, an "exclusive ownership" property of the signature scheme (established for Ed25519, conjectured for the way ECDSA is used in EDHOC SIG-SIG). Our updated analysis is not publicly available yet at this point. Let us know if a public reference would be helpful for the draft RFC; we can also share the document individually upon request. The last point actually maybe does lead to a comment on the document: Given the various security analyses EDHOC has seen and their insights being discussed in Section 8, would it make sense to add informative references to those (as done, e.g., for TLS 1.3, RFC 8446 Appendix E)? Kind regards, Felix Günther (with Marc Ilunga)


Changes to comments from Russ Housley on 03-Mar-2020
Section 3.1.1: The text says: C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2: The text says: A sends a ClientHello to B, without including a key share. It would be helpful to say "without including a key share extension." Section 3.1.3: I think a bit more explanation is needed here. Nonces can make the keys different, why doesn't the nonce from the uncompromised party help in this example? Section 4: I would like to see a bit more context here. I agree with the recommendations for the intended environment, but they are overkill in the environment suggested by draft-ietf-tls-tls13-cert-with-extern-psk. In fact, they are overkill if (EC)DH is combined with the PSK at all. So, maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply.
Fixed by .
LGTM -- thanks, Russ!


The comment about how there are no guidelines about PSKs like there are about generating passwords seemed like a statement of the motivation for this draft, so I moved it to the introduction. (I was going to add a reference for the statement, but I couldn't figure out how to get the citation to compile correctly. This was the document I was going to cite, in case you think it needs it: URL)


More = better. There are a few other places that this treatment might be applied elsewhere if the editors feel that way inclined. This seemed to be the most important.
I'll do a pass for other obvious paragraphs that can be split up.


Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.


Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit a5ab40750ac9435b370bab7ded6dbdc60b35b01a https://deploy-preview-208--gnap-core-protocol-editors-URL
It may make sense to change the order to something like == && is present == && is absent == == && is present
I did changes for URL There are lots of other things that, I believe, could be improved & changed for the "Presenting Access Tokens" section and they will be addressed in separate PRs in the future.
Thank you, this is great! Aligns with the language in


URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.


Opaque identifiers provide a generic reference, so we can simplify the text. (mainly), and as a byproduct also and - removed userhandle from main response in section 3 changed title of section 3.4 (User -> Subject) and moved the text that requires RO = end-user at the top of the section, for clarity changed name (userhandle -> user) and wording in section 3.5. Maybe we could also simplify the title "Returning Dynamically-bound Reference Handles" into "Returning Reference Handles" (didn't do it yet).
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 73de700ce82846ec5e09f8f60550fac7bee0dfb5 Inspect the deploy log: Browse the preview:
With the adoption of the subject identifier format, we no longer need to have a GNAP-specific value and can instead leverage this more standard field. Alternatively, we could have a GNAP-specific subject identifier format, instead of a separate field.
In section 2.4 (Requesting User Information), the first sentence starts with: If the client instance is requesting information about the RO from the AS, ... From the title, the acronym "RO" should be changed into "end-user". The case where the RO is also the end-user is a specific case. This leads to the following change: If the client instance is requesting information about the end-user from the AS, ... In the following sentences of this section, RO should be changed into end-user.
The current text really means RO, and generally considers the case end-user = RO. Any other case would even trigger an error: "If the identified end-user does not match the RO present at the AS during an interaction step, the AS SHOULD reject the request with an error." (section 2.4) Which makes sense because why would we return something about the RO to a potentially unknown end-user? (the only problem is that this wording is buried in the text, so it's hard to understand) Back to the general case: The RO is in control of policies at the AS. The end-user is in control of a client and a request to the AS. The end-user and client may or may not have any prior relationship with the AS. The subject info is what is known by the AS (in theory could be RO and maybe end-user, but notice that in the terminology, we define the end-user as a natural person and the RO as a subject entity). I think we should clarify when we could have a remote RO too. Then do we even return a result if the AS knows something about the end-user? (different from RO in that case). Plus we need to keep in mind that we also use sub_ids for URL In general, we might want to avoid the term "user" as it is not specific enough.
The title has been changed into "Requesting Subject information". This title is incorrect as long as a subject can be also an organization or a device. An AS can hold information about an end-user or about RO when the RO is a human being. It does not hold information about organizations or devices. However, an end-user may belong to some organizations or/and use some devices. IMO, I would replace it by "Requesting end-user Information". If an AS holds information about an end-user, it seems logical that the end-user should have access to it. If it happens that the end-user has also a RO account on the AS, then it should also have access to it. In such a case, another section with the following title "Requesting RO Information" should be created. RO = end-user was a common case in OAuth. In GNAP and in the general case a RO is different from an end-user and an AS may have no relationship with any RO (e.g. when attributes only are being used).
I guess you refer to "2.2. Requesting Subject Information". We might have to harmonize a bit, but for instance "2.3. Identifying the Client Instance" might very well hold information about devices or at least the software running on it (that's the point of client software attestation to be discussed in ) We don't always know in advance whether it will be a RO or an end-user only, so the proposal isn't always applicable.
I was indeed referring to "2.2. Requesting Subject Information" which has no relationship with "2.3. Identifying the Client Instance". This means that your arguments do not apply to section 2.2. and, by implication, that my argumentation currently remains valid.
Well, I take the point in consideration but I don't think we should base our reasoning on the structure of sections, which can change
Identifying the User by Reference: Editor's note: We might be able to fold this function into an unstructured user assertion reference issued by the AS to the RC. We could put it in as an assertion type of "gnap_reference" or something like that. Downside: it's more verbose and potentially confusing to the client developer to have an assertion-like thing that's internal to the AS and not an assertion.
Why an assertion? Is that reference supposed to be linked to a session (cf "represent the same end-user to the AS over subsequent requests") or can it be persistent? I would see that more as an opaque identifier, rather than an assertion. Something like: asref seems a bit specific to GNAP (reference managed by the AS) but it could always be read "as a reference" in a more general setting. There's a variety of generic names that we could choose if needed, localuid, internal_uid, etc. But that really asks what additional types we could define as part of secevents (section 7.1.2). Beyond the case mentioned here, it would be most useful as an opaque identifier when RO != end-user, to avoid leaking private info about the RO (although currently we don't seem to cover that case yet) It's indeed more verbose than "user": "XUT2MFM1XBIKJKSDU8QM" but at least it's always the same structure (doesn't depend whether it's a reference or not), and it also makes the type more explicit.
A subject identifier makes sense here, and I agree that it should be a new value to let us constrain it to the GNAP context.
Fixed by SECEVENT opaque identifiers
I don't think this goes far enough -- I am thinking that with the opaque identifiers we can now simply return a with a format of that the client can be allowed to send in a follow-up request if it wants to. This way they all get treated equally, there's no special field anymore.


In the current version, the AS must include an access token. "if the AS includes an access token" sounds like the inclusion of an access token is optional.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 323dd6c268368857c2d9942048f94658b806b8ad Inspect the deploy log: Browse the preview:


for
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: c7273a059b212bf18879f131a5a18d9a776a2918 Inspect the deploy log: Browse the preview:
Error Response: Editor's note: I think we will need a more robust error mechanism, and we need to be more clear about what error states are allowed in what circumstances. Additionally, is the "error" parameter exclusive with others in the return?
As a starting point, I would suggest adding these sentences The error code parameter MUST be required and its value SHOULD be limited to ASCII characters. The error code indicates that a request is malformed. The AS MUST return an HTTP 401 (Unauthorized) status code to indicate that it can't identify a client instance (the error code can be ). The AS MUST return an HTTP 401 (Unauthorized) status code to indicate that it can't authenticate a client instance (the error code can be ). The AS MAY uncover additional information about the cause of the error when it can authenticate a client instance (the error code can be , , and so on).
Addressed by , still need error codes for things like token management.
The type of the of the error property in a response is currently ambiguous. In section 3 it is defined as an and in section 3.6 it is defined as a .
NAME thanks for catching that -- looks like both "error" and "errordescription" should be added to the list of parameters. I think the intent might have been for the value of "error" to be an object with "errorcode" and "error_description" fields inside of it though, so it might be better to align things in that direction instead. Do you have thoughts on which is preferable? Interop testing of error conditions is really difficult in practice, so this is a great catch!
Yaron: The AS MUST ignore any unknown extension. Justin: I’m OK with this stance, but it needs to be consistent throughout the protocol, not just at this level. Yaron: we can actually have one policy for an AS that doesn't understand something defined in the RFC (e.g. a token binding method) vs. extensions. Unknown extensions clearly must be ignored, otherwise you cannot deploy extensions incrementally. For RFC elements, this is more nuanced.
With the guidance on extension points from and error codes from and similar, this should now be covered by the current text.


Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.


Deploy Preview for gnap-resource-servers-editors-draft ready! Built Explore the source changes: 611af53328d71bac58f517702c5775a9c514d88d Inspect the deploy log: Browse the preview:


text for proxy security cases
Reverse proxy may act as origin server and hence client doesn't use e2e security to server group. However, in other cases a reverse proxy may assume the client uses e2e OSCORE security and not add any security by itself. To consider all the different, possible/valid cases for this. And see if it's different for forward proxies.
One particular example is a client that connects over CoAP+TLS+TCP (or CoAP+DTLS) to the reverse-proxy, where the proxy uses OSCORE security for the multicast request. The client is not aware of the (group) security material which the proxy and servers have.
At high level, there are 4 different potential cases of "proxying with security". Forward proxy with e2e security [=Group oscore e2e via proxy] Forward proxy with two-leg security [=unicast OSCORE or DTLS on 1st leg, with group OSCORE on 2nd leg] Reverse proxy with e2e security [=Group oscore e2e via proxy] Reverse proxy with two-leg security [=unicast OSCORE or DTLS on 1st leg, with group OSCORE on 2nd leg] Currently the draft doesn't say anything about these combinations, which are valid, which not, and where to find the security solution to them (e.g. a pointer to draft-groupcomm-proxy for covering most of these cases) This text/analysis could be a new Section 5.3 "Proxy Security" or so. Note: cases 2 and 4 depend on a 100% trusted proxy so no e2e security model. The client in this case is not even aware necessarily of the existence of Group-OSCORE. The proxy stores the "group member identity" to be used to make the Group OSCORE protected request. This may be a single identity, or a separate identity for each authorized user of the Proxy service. Case 1 and 3 most likely means OSCORE-in-OSCORE is needed?
It seems like a good idea. Intermediaries are usually considered non-trusted, hence the interest for an actual e2e security model between origin client and origin servers. How would the proxy store and use a "group member identity" ? Even if the proxy somehow obtains multiple different Sender IDs from the Group Manager (i.e., one for each authorized user of the proxy service), the proxy would have to sign a Group OSCORE protected request with a private key of its own (possibly one per corresponding Sender ID), which is not in control of the actual origin client. With such a level of trust on the proxy, and with a client not interested in e2e security anyway, it would be just easier to think of the proxy simply as another single member of the same OSCORE group including the servers, thus sacrificing verifiable data authorship/origin. Maybe this might be useful/applicable for case 4, with a client anyway likely unaware of what happens beyond the reverse-proxy and to be actually reaching a group of servers. Not sure about case 2, where the client would be aware of an actual group of servers it tries to reach. Yes, when exactly OSCORE is also conveniently used between Client and Proxy, to fulfill REQ2 from URL : REQ2. The CoAP proxy MUST identify a client sending a CoAP group request, in order to verify whether the client is allowed-listed to do so. For example, this can rely on one of the following ... Note that this requirement applies even in case end-to-end security is not enforced between client and servers.
Agree, in the two-legs security case it seems sufficient that the proxy has one "identity" within the group. And I agree that this proxy would most likely be a reverse proxy Case 4 i.e. it operates like a (trusted!) origin server. By definition of a reverse proxy , it has to be trusted just like a client trusts an origin server with being able to know and manipulate the served content.
This issue was addressed in Section 5.3 of version -04. NAME , can we close it?
Yes!
Looks good! See inline some proposed rephrasing.


…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.


When comparing the term 'Appraisal Policy for Evidence' and 'Appraisal Policy for Attestation Result', they are both saying 'evaluates the validity of information about an Attester'. This makes me feel Verifier and Relying Party are doing the same things and they are redundant. I think it's more appropriate to say that the Relying Party evaluates the evaluation results generated by the Verifiers.


TLS authentication is sufficient for establishing trust in the various entities before sending them privacy sensitive data. TLS is also widely supported today and attestation between servers is not. Most likely TLS will be the mechanism. This PR adds mention to in addition to attestation.
Addresses
says that the way for an Endorser to trust and Verifier is to use attestation. While I won't categorically say this should never be done, it seems like this is overly complex and a somewhat misuse of attestation. I think of the Verifier as a service like a web site, not an implementation like a TEE, so TLS or similar, not attestations, seems like the more efficient and conventional way to do this. I think attestation is associated with actual HW and SW, for example the Dell server, Intel CPU and Web stack used to run the service. The operator of a Verifier gets to change those around without having to tell the people using the service. On the other hand, if a Verification Service changes owners, say from Chinese to American, then Endorser concerned about confidential stuff in the Endorsements really wants to know. I also think that Verifier Owner should not be lumped in with Endorser. The Verifier Owner is very likely to be tightly coupled organizationally with the Verifier, where the Endorser is not likely to be.
PR addresses this well enough.
Reviewing the trust relationships described in the architecture document got me thinking about sharpening a distinction between device attestation (e.g., EAT for phone) and service authenticity (e.g. HTTPS for a web site): Device Attestation Focus is on the implementation, the HW and SW The legal entity of interest is the device manufacturer The claims are about the HW and the SW, not the device owner Example: a mobile phone (not its owner/user) Example: integrity of a remote device Service Authenticity Focus is on the provider of the service, not the HW or SW The legal entity of interest is the service provider There is no equivalent of claims, but if there was they would be about the business or person operating the service Example: a web site Example: an email provider (IMAP service) Service providers (e.g., web sites) use whatever HW and SW they want to use. As a user of the service we don’t care what HW and SW they select. We trust the service provider to pick good HW and SW and to configure and operate it correctly. They might change the HW and the SW and as a user we won’t know. For example we trust Bank of Xxx to operate their banking web site correctly with little concern for their HW. This is why attestation of the HW and SW is not so useful to the user of a service. Users of mobile phones and IoT devices are not trustworthy to pick secure HW and SW. They are not professionals like the people running web sites. There is little accountability against them if they pick bad SW and HW. Therefor we want attestation for these usage scenarios. This is why EAT, FIDO and Android Attestation exist. I don’t think the line between device attestation and service authenticity is completely black and white. In some use cases attestation may be bent to provide some service authenticity. But I don’t think it makes sense to add attestation to the millions of web sites out there, add support for it to browsers and make attestation an extra layer of security for web browsing. I think it is fine for a service provider to use attestation inside their service to monitor integrity and such of the HW and SW providing the service. But usually that won’t be manifest outside the service. It could be awkward for the user to the service to have to re evaluate the service every time the service provider changes HW. Another way to look at this is from a certification / regulatory view. If the thing you're looking at is a candidate for implementation certification such as Common Criteria, FIPS, FIDO certification, then it probably lines up with device attestation. On the other hand, if the thing your are looking at lines up with regulation (e.g., banking regulation, GDPR,...) and to some degree OWASP, then it probably lines up with service authenticity. I think the RATS architecture document should probably have text that describes when attestation is applicable and when it is not, for example saying something like “attestation is not a replacement or augmentation for HTTPS/TLS"
In the last editors session, the editor's rough consensus was that https does not provide the authenticity but it provides a secure channel. Instead, authenticity is checked via successful authentication rooted in identity documents (I hope I captured appropriately, please bash). Taking that into account, how does this effect this issue? Looking at the last paragraph, "Remote attestation procedures are not a replacement for secure authentication, they are based on secure authentication." might be missing vital parts. Does anything need to be added or modified here?
Note that is INCORRECTLY referenced here. Is the resolution of a different issue about HTTPS vs Attestation.
I think comments from NAME do need to be taken into account when the text to address this issue is written. My text in opening the issue is not intended as the text to resolve the issue. Probably the text that resolves the issue needs to refer to "HTTPS plus the web certificate infrastructure that includes public CA's and browsers and/or private CA's used in B-to-B..." or such.
I think the RATS architecture document should probably have text that describes when attestation is applicable and when it is not, for example saying something like “attestation is not a replacement or augmentation for HTTPS/TLS" The design team disagrees with this. Every authentication (including HTTPS) can be said in terms of attestation. It is the verifier that allows the decoupling of the RP to know the expected state of the Attester.


Added clarifying text -
" including roots of trust" from .
We should add the sentence "Normally, claims are not self-asserted by a layer or root of trust." in the section describing layered attester / layering. around line 1120?
I'd not object that. I'd be okay with "Normally, claims are not self-asserted by a root of trust."


Reworded 2nd and 3rd paragraphs
` Is there a different way to say this? I assume in Passport, we’re not relying on the Attester to report itself as untrustworthy? I think it’s more that it doesn’t get a passport, so it has nothing to hand the dude at the immigration desk? i.e. untrustworthiness is indicated by lack of a passport?
The paragraph should begin with "An Attestation Result that indicates ..." The Relying Party is always the entity / role that consumes the Attestation Result. The text that describes the Attester (in the passport model) technically violates the role interaction model. Instead, the refusal on behalf of an Attester (acting as a proxy for the Attestation Result) to convey the AR is a protocol or interaction break down scenario. And yes it is correct for the Relying Party to, by default, assume that lack of receipt of an Attestation Result means the Attester is presumed to be non-compliant. If the paragraph stated this simply up front then we can avoid dove tailing it into the description of what constitutes non-compliance behavior. For example, paragraph 2 could start differently: "By default the Relying Party assumes the Attester does not comply with Verifier appraisals. Upon receipt of an authentic Attestation Result and given the Appraisal Policy for Relying Party is satisfied. The Attester's state of compliance changes to be in compliance and actions consistent with compliance may be applied. If the Appraisal Policy for Relying Party is not satisfied, actions consistent with non-compliance may be applied. For example, the Attester may require remediation and re-configuration or simply may be denied further access." The third paragraph seems redundant to this (and somewhat wordy).