jiebi/CodeConvo huggingface dataset:
The unifying component is the root of trust and the nested, staged, or chained attestations produced. The nested or chained structure should include claims, collected by the attester to aid in the assurance or believability of the attestation Evidence." The following sentence should be broken into two: "This example could be extended further by, say, making the kernel become another Attesting Environment for an application as another Target Environment, resulting in a third set of Claims in the Evidence pertaining to that application." Proposed: "This example could be extended further by making the kernel become another Attesting Environment for an application as another Target Environment. This results in a third set of Claims in the Evidence pertaining to that application." How about changing the following sentence from: "Among these routers, there is only one main router that connects to the Verifier. " To: "A multi-chassis router, provides a management point and is the only one that connects to the Verifier. " For the following sentence, trying to remove the use of a word twice in a row and convey the same intent. Old: "After collecting the Evidence of other Attesters, this inside Verifier verifies them using Endorsements and Appraisal Policies (obtained the same way as any other Verifier), to generate Attestation Results." Proposed: "After collecting the Evidence of other Attesters, this inside Verifier uses Endorsements and Appraisal Policies (obtained the same way as any other Verifier) in the verification process to generate Attestation Results." I may try another pass at section 4 to improve readability. Section 5, Consider breaking this into 2 sentences, from: "This section includes some reference models, but this is not intended to be a restrictive list, and other variations may exist." To: "This section includes some reference models. This is not intended to be a restrictive list, and other variations may exist." Section 5.1 Two result words together is not necessary. Change from: "The second way in which the process may fail is when the resulting Result is examined by the Relying Party, and based upon the Appraisal Policy, the result does not pass the policy. "
To: "The second way in which the process may fail is when the Result is examined by the Relying Party, and based upon the Appraisal Policy, the result does not pass the policy. " I suggest making the last paragraph the second paragraph. It's easier to read than the others and provides an introduction to the model before you begin talking about how it might fail. ** I may come back to this section to provide wording suggestions. Section 5.2 I suggest moving the last paragraph to the first in this instance. It also provides a nice high-level overview. The current paragraph 1&2 flow well together, hence this order suggestion. The third paragraph is a really long way of stating that interoperability is required. Entities must be able to create, send, receive, and process data (hence the need for a standard). It's fine, but could be shorter. Section 5.3: OLD: "One variation of the background-check model is where the Relying Party and the Verifier on the same machine, and so there is no need for a protocol between the two." Proposed: "One variation of the background-check model is where the Relying Party and the Verifier are on the same machine, performing both functions together. In this case, there is no need for a protocol between the two." I think the addition is necessary or you could scratch your head wondering why no protocol is needed. If they are separate functions on the same system, you'd need some way for the relying party to access the results of the verifier. The next sentence could benefit from being made into several. OLD: "It is also worth pointing out that the choice of model is generally up to the Relying Party, and the same device may need to create Evidence for different Relying Parties and different use cases (e.g., a network infrastructure device to gain access to the network, and then a server holding confidential data to get access to that data). As such, both models may simultaneously be in use by the same device." If the server holds confidential data, why does it need to create evidence to access the data? I'm not following the second example as written, so my proposed text may not be as intended.
Proposed: "It is also worth pointing out that the choice of model is generally up to the Relying Party. The same device may need to create Evidence for different Relying Parties and/or different use cases. For instance, a network infrastructure device may attest evidence to gain access to the network or a server holding confidential data may require attestations of evidence to gain access to the data. As such, both models may simultaneously be in use by the same device." Section 6: The first 3 sentences are fine, but if you wanted to reduce it, it could be one sentence. Current: "An entity in the RATS architecture includes at least one of the roles defined in this document. As a result, the entity can participate as a constituent of the RATS architecture. Additionally, an entity can aggregate more than one role into itself. " Proposed: "An entity in the RATS architecture includes at least one [or more] of the roles defined in this document. " Or more is redundant, so that really isn't necessary to convey the same point. Then the last sentence: I'd change it a little from: "In essence, an entity that combines more than one role also creates and consumes the corresponding conceptual messages as defined in this document." To: "In essence, an entity that combines more than one role may create and consume the corresponding conceptual messages as defined in this document." It might not, it could be the verifier and relying party. Section 5: Consider changing from: "That is, it might appraise the trustworthiness of an application component, or operating system component or service, under the assumption that information provided about it by the lower-layer hypervisor or firmware is true. " To: "That is, it might appraise the trustworthiness of an application component, operating system component, or service under the assumption that information provided about it by the lower-layer hypervisor or firmware is true. " Section 7: I'd say it's really a stronger level of assurance of security rather than a stronger level of security in the following: "A stronger level of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering. "
Then with the following sentence, "The component that is implicitly trusted is often referred to as a Root of Trust." I think it would be worth mentioning that a hardware RoT is immutable and mutable RoTs in software are also possible, offering different levels for an assurance of trust/security. Section 9. Since ROLIE [RFC8322] has been added to SCAP2.0, it would be good to list that as an option since a lot of time and effort went into how to secure the exchange of formatted data for that protocol. Section 11. Privacy This is a good start. Remote attestation also provides a way to profile systems as well as the user behind that system. If attestation results go higher in the stack to include containers and applications, it could reveal even more about a system or user. The scope of access needs to be emphasized, including the administrators access to data (or restrictions). If there is a way to make inferences about attestations from their processing, that should be noted as well. Section 12: This will need to state an explicit requirement for transport encryption. In the introductory paragraph, the text is as follows: "Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy, needs to support end-to-end integrity protection and replay attack prevention, and often also needs to support additional security protections. For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many use cases. " Proposed: "Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy must support the security properties of confidentiality, integrity, and availability. A conveyance protocol includes the typical transport security considerations: o end-to-end encryption, o end-to-end integrity protection, o replay attack prevention, o denial of service protection, o authentication, o authorization, o fine grained access controls, and o logging in line with current threat models and zero trust architectures." Best regards, Kathleen
Describe how GET (not POST) is used with server push. This will ensure that you answer the bigger question: what do you do with a server push from an arbitrary server? I assume that this won't be privileged in any way, and only the configured DNS API server will have its answers routed to the DNS stack, but that needs to be explicit.
Server push in a request-response protocol like DNS would take a lot of designing. It isn't really needed in DNS because the server can always slap in additional answers in the Additional section of a request. I propose we close this by saying "HTTP server push is not defined for this protocol, but might be defined in a future version". If someone wants to define an EDNS0 or session-signal extension for it, that should be just fine.
HTTP already has server push, so I would prefer something closer to "this protocol does not alter the semantics of HTTP server push".
I think NAME is closer to what I'm thinking.. (though I don't really think that needs to be stated beyond other clarifications that this document just uses http in a particular manner, it does not define it.) additionally RR's don't quite address the same use case by the way as push can operate in more of a pub-sub fashion if you like where an additional RR is definitely a poll model.
Of course this protocol does not alter the semantics of server push, but what does it mean for a DNS client? In the DNS protocol, the only thing even vaguely like server-initiated information is stuff in the Additional section of an answer, and even then, there are pretty strict rules about ignoring it if it is at all smelly.
an often times misunderstood part of push is that a server pushes both a response and the request that it is responding to. (like dns, http is always a request/response pair, so if the client doesn't provide the request the server needs to). So that's what it means - its an answer to a particular question and you can cache it or not depending on whether that's a request you would have asked/trusted the peer to handle. That's pretty much the same rule for dns and traditional http clients. A client who would rather not have things pushed at them has existing protocol mechanisms to disable that (SETTINGS) which doh doesn't need to specify.
PR for I considered referring to RFC6724, but that raises more questions than it answers it seems.
From Tom Pusateri: When more than one IPv4 or more than one IPv6 address is present, it seems like it would be better to first prefer an address that is on a shared network instead of always taking the first one (which doesn’t mean anything in DNS). If you want others to use the same address you should prefer the lowest one or the highest one or something sortable instead of the first one which could be different depending on hashing in a cache.
Discussed and agreement was to find a simple alternate algorithm.
Closed by PR
No context and empty context are now declared to be the same. Add some ALL CAPS WORDS for future specifications to deprecate no context. I used SHOULD to forbid no context because, if some protocol currently uses no context, switching it to empty context is a breaking change and probably not worth it. We just want new ones to always provide a context. This affects the rules for using exporters, so RFC 5705 is added to the list of updated documents. Closes issue .
Improves example description
https://ietf-wg-URL The example with just RateLimit-Limit and RateLimit-Reset In it seems this is a case where the RateLimit-Reset value is not able to be used to determine how long one should wait, but is rather just a Limit definition ? Why not then just use RateLimit-Limit: 10;w=1 and omit the other two headers ? Is this to cater for the inevitable 429 to provide a RateLimit-Reset value at that point ? If that is the case I question the value of using the two headers in “successful” responses.
This example is related to an implementation that uses the "old" ratelimit field set, that do not support . We should improve the description.
:+1:
This attempts to address the remaining feedback on PR on issues that were not fixed before it was merged. Signed-off-by: Dave Thaler
The simple word choice / grammar changes seem OK. I still don't understand the difference between a "claims collector" and a "verifier" (in the case where Attester B, C,... are signing evidence) and a "target environment" (in the case where Attester B, C, ... are not signing evidence). It seems this term isn't actually necessary. The case where Composite Attester is relying Evidence from "sub" attesters, the composite attester (aka claims collector) is relying Evidence not "collecting claims" in the sense that an attester "collects claims about a target environment". I think it is confusing to overload this terminology to also mean "rely Evidence".
I was just going to add something about correlating requests based on their content, but then it seemed like the text was duplicated some. Here is my attempt at making this better. I also expanded the notion of "configuration" to include the identity of the relay. That made it a little tricky - we really do want diversity of relays - but it makes more sense to talk about minimum anonymity set size rather than to imply that there can be a single configuration, because that is unrealistic.
Hi, The specification talks about State. Could I suggest that it explicitly mention 'or other user identifiable payloads.' Because things like JSON documents (e.g. a JWT) and SAML assertions are not 'cookies' but can carry information that might be user identifiable. Thoughts?
I think we've given short shrift to the way in which the content of requests can be used to link them. Perhaps some new text for Section 8...
NAME that text looks good to me Wanna toss up a PR?
This is an error that can be detected in frame parsing without additional context.
Over on URL we had a discussion about whether a MAXSTREAMS frame with value exceeding 2^60 generates a FRAMEENCODING or a STREAMLIMIT error. Draft 29 Section 19.11 says: corresponding type that can be opened over the lifetime of the connection. This value cannot exceed 2^60, as it is not possible to encode stream IDs larger than 2^62-1. Receipt of a frame that permits opening of a stream larger than this limit MUST be treated as a FRAMEENCODINGERROR. but as NAME points out, Section 4.5 says with a value greater than 2^60, this would allow a maximum stream ID that cannot be expressed as a variable-length integer; see Section 16. If either is received, the connection MUST be closed immediately with a connection error of type STREAMLIMITERROR Meanwhile, for the STREAMSBLOCKED frame in Section 19.15 we have: I suspect both Vidhi and I are correct, bogus MAXSTREAMS can be treated as either STREAMLIMIT or FRAME_ENCODING. If so, its probably a minor editorial fix to state either/or in both the sections.
NAME suggested that it should only be a FRAMEENCODINGERROR, as it's invalid to send a MAX_STREAMS larger than 2^60 under any circumstance, regardless of connection state, and I agree that's the clearest application of our principles.
I agree that requiring the use of FRAMEENOCDINGERROR is fine. Even though we occasionally allow an endpoint to use multiple error codes when there is more than one way of checking the status (i.e. FLOWCONTROLERROR vs. FRAMEENCODINGERROR for STREAM frames), the check required in this particular case is purely unrelated to the connection state. Hence my +1.
I would be happy with a single error too. I'm not fussy about the actual code used as long as the spec is clear and consistent. That means that we'd need to reduce STREAMS_BLOCKED to one error code too, and potentially any other situation that allows either.
I'm going to drop . I agree with the comments suggesting that FRAMEENCODINGERROR is the right answer. Note that you might still receive a different error, as we permit endpoints that detect multiple errors to send any that it detects, and this case clearly justifies use of STREAMLIMITERROR.
As of , the client MUST use the same handshake message.
NAME That's quite complicated, and I'm not sure if we've chosen the right design here. I'd like to keep this PR editorial though. I opened to discuss this.
In URL, NAME points out that after a Retry, all 0-RTT packets sent in the first flight are still valid, although they will probably have been dropped by the server (unless there's significant reordering). That means that a client SHOULD retransmit all 0-RTT packets in the second flight. We now have two different scenarios: In the case of a HelloRetryRequest, the client is prohibited from sending 0-RTT, and has to cancel retransmissions for all outstanding 0-RTT packets. In the case of Retry, the 0-RTT packets from the first flight are declared lost (without any effect on the cwnd though) and retransmitted. Considering that Retry adds a roundtrip anyway (and thereby limits the usefulness of 0-RTT), and that we only expect it to be used by a server that's under attack (which makes it likely to refuse 0-RTT later in the handshake), does it really make sense to send 0-RTT in that case?
NAME I am not sure if I agree with the observation. The transport draft states that a server MAY send Retry packets in response to Initial and 0-RTT packets. A server can either discard or buffer 0-RTT packets that it receives (). Notice that the server is allowed to "buffer" 0-RTT packets. I am not sure if I like this ambiguity (because I think most if not all of us will be dropping 0-RTT packets that carry the original DCID when sending a Retry), but IMO the draft is clear.
NAME thanks for pointing that out. My point is that we should change the draft (i.e. this is a design issue, not an editorial issue).
The reason a server (or a LB) performs a Retry is that it either has reasons to suspect that the client isn't reachable at the 2-tuple it sent the packet from, or that it is under load, and either uses the Retry to redirect traffic to a different backend server, or just to buy itself some time Under both circumstances, a server wouldn't want to allocate additional state for buffering 0-RTT packets. I'm therefore suggesting to change the draft such that: A server that performs a Retry MUST discard 0-RTT packets. A client MUST NOT use 0-RTT after a Retry was performed. Does that make sense to you?
Yeah, I can envision a server that considers buffering some number of packets to be cheaper than doing a TLS handshake. For such servers, delaying the TLS handshake until client proves it's existence but buffering the 0-RTT packets in the meantime would make sense. That said, I'd be fine with this, assuming that the discarded 0-RTT packets are the ones that carry the original DCID. I would prefer not having this requirement. Once the client is known to exist, a server needs to communicate with the client. Use of 0-RTT helps reduce the server load, because when used, average lifetime of connections becomes 1-RTT less. That leads us to having less concurrent connections.
When our implementation does Retry, it's because we've hit a memory pressure limit and we want to protect ourselves from attack. If a client supplies us with a valid token, we will accept 0-RTT still, but we won't buffer it from the previous Initial (without a token). So, if the client gets a Retry and still wants to do 0-RTT, they need to retransmit it, with the new CID, in a new packet (with a new packet number). I don't see why that design should be prevented.
Ok, I see that there's value in doing 0-RTT after a Retry, and furthermore, there seem to be good reasons (prevention of tampering by middle boxes) to disallow 0-RTT after a HelloRetryRequest in TLS 1.3, as NAME pointed out OOB. Since we can assume that most (all?)
server implementation will drop 0-RTT packets when sending a Retry, the only reasonable thing to do for a client is to treat all 0-RTT packets as lost and retransmit them. Considering that, it would make sense to require servers to drop all Retry packets from the first flight, as NAME suggests.
NAME Thank you for suggesting a path forward. I think my weak preference goes to something slightly different. I think we are in agreement that most if not all the servers would not buffer the 0-RTT packets carrying the original DCIDs when they send Retrys. It makes sense to acknowledge the fact in the specification and suggest clients to retransmit 0-RTT data it has already sent. What I am not sure is if there is a reason to forbid servers from buffering such 0-RTT packets. From client's point of view, sending 0-RTT data once per connection is an optimization. Retransmitting 0-RTT data when the server sends a Retry is further optimization. If we think that way, servers that buffer 0-RTT packets when sending a Retry has increased chance of utilizing 0-RTT data. Compared to that, there is no reason to mandate servers to drop 0-RTT packets. To summarize, I think all we need to clarify is that servers responding with Retries are likely to discard 0-RTT packets that carry the original DCIDs and therefore that retransmitting 0-RTT data makes sense. But nothing more.
What if client takes action on Retry, and the old 0-RTT state lingers - wouldn't that make servers more vulnerable to DDoS attacks from packet sniffers?
This also bears on . If the DCID doesn't change, then the server won't be able to differentiate the first flight of 0-RTT packets, which you're proposing to drop, from the second flight of 0-RTT packets which it accepts. The current text says that the server MAY buffer and process them later; you're saying that servers probably won't. I think that's fine, but some might -- hence, I favor NAME suggestion to retain the permission to buffer but the caution to the client that the packets were quite possibly lost/dropped.
In terms of actual spec change, I think that means this text in : ...becomes a SHOULD instead of a MAY.
It seems like you have sorted this out. I have no problem with using "SHOULD" over "MAY" here. Note that the reason we have this distinction is logical separation of the mechanism of Retry and 0-RTT acceptance. Retry strictly precedes the connection attempt. No point in blocking 0-RTT if you have to Retry. HelloRetryRequest is different in that certain characteristics it might cause to reset affect whether the 0-RTT works. Retry is required to use the same ClientHello, so there is no need to have the two interact; you can treat a Retry almost as a loss event for the first Initial and everything works fine.
So, the effect of not changing the handshake message is that all previously-sent 0-RTT data is still valid, but has potentially/probably been lost rather than queued. Clients obviously MUST NOT reuse the packet number for different data, but in their not-resetting, they also can't change the data that they've already sent in those packets. They'll need to retransmit it, because otherwise there's a potential DoS attack by delaying/replaying a 0-RTT packet by one RTT against a server that does Retries.This PR looks good to me as an editorial improvement. Regarding NAME point, the transport draft explicitly states that a server sending a Retry can buffer 0-RTT packets that carried the original DCID, and process them after receiving a response to the Retry. To put it differently, I think we are clear on the semantics and that there are ways to implement this without having security concerns. That said, I understand that NAME has opened a design issue () to discuss if that is the design we want to have.LGTM