Ben observed that this might be at odds with the definition of the interface. This is true, but the illustrative value of the current structure is valuable. More text on that might help.
NAME said:
I think that the multiple invocations is enough to call out. However, the retrieval of bytes to send after processing some data is not necessary. For reference, the is: This does not necessarily imply that you pull after every byte provided. As the bytes here are provided in a coalesced packet, it is reasonable to defer the "Get Handshake" call until all of the bytes arrive. I know that our stack does, though this is not uniformly true. to Handshake Complete? YES! Thanks. That's going to be awkward, as it involves QUIC-layer messages, but I think we can do that. (In a separate PR though.)


These are all MUST in recovery and the editors discussed this and agreed that these should be MUST too.


Provides more details on why excluding maxackdelay when Ignore Order is used may cause premature PTOs.
I'm merging this -- I think this is good, but if we need to add more cautionary text, we can still do that.
When the number of in-flight ack-eliciting packets is larger than the ACK-Eliciting Threshold, an endpoint can expect that the peer will not need to wait for its maxackdelay period before sending an acknowledgement. In such cases, the endpoint MAY therefore exclude the peer's 'maxackdelay' from its PTO calculation. Note that this optimization requires some care in implementation, since it can cause premature PTOs under packet loss when ignoreorder is enabled. Isn't this oversimplifying things so that the aspect of time until an ACK is expected to be sent is removed? To me it is not that maxackdelay is removed completely from URL PTO = smoothedrtt + max(4*rttvar, kGranularity) + maxackdelay Instead it is replaced with expected time until the sender have sent ACK-Eliciting Threshold number of packets when that is less than maxackdelay that is configured. Secondly, are you expecting the sender to make an estimate of how many packets more are received before an ACK is sent, i.e. care about what phase it is currently when calculating the PTO in regards to which packet is expected to trigger the next ACK? However, that is clearly prone to be wrong if there is a loss occurring currently who's loss indicating ack has not yet been received by the sender. So it appears to me that this allowance is by default creating a situation which will cause premature PTOs, and it would be better to put some restrictions on it.
On the second point, the sender always knows how many packets are outstanding. So, it always knows whether the PTO computation -- which is always on the latest sent packet -- should include maxackdelay or not. That said, you are right the ignoreorder causes trouble here, so how about "MAY therefore exclude the peer's 'maxackdelay' from its PTO calculation unless ignoreorder is enabled. When ignore_order is enabled, premature PTOs are significantly more likely under packet loss."


It makes sense to cancel any pending cert orders when an account is deactivated, where the cert has not been issued yet.


Let's remove this sentence and add more information when we will have this additional experimental data
This area probably needs more experimentation in general. For instance, it is unclear how much we could partition such IPv6 addresses by origin like we ask for mDNS names. Given we already talk about this approach in the privacy section, these sentences do not feel mandatory to keep. No strong feelings either way though.
I looked at the current text more closely and I see what you are saying, especially regarding different origins. We should probably talk about the separation of origins or browsing contexts more in the introduction though. Currently it only refers to the fingerprinting threat, which could be construed to simply mean a long-term identifier.
I don't think we needed to nuke this whole section, just the future version of the document sentence.


Thx!
Should we maybe add a recommendation to the sec considerations that proxies may limited the amount of data they send as long as they don't see any reply. I guess initially you would limit to 10 packets and then following RFC8085 limit to one datagram per 3 seconds...? Not sure if that really is a good idea but I wanted to bring it up for discussion...
I thought about that when I first wrote the existing text, and I came to the conclusion that a limit here wouldn't protect against real attacks. If someone is attacking a closed UDP port, they're not accomplishing anything. If someone attacks an open UDP port (for example 443 because they want to attack someone's QUIC endpoint), then the target will reply with some sort of UDP packet (for example a QUIC RETRY) so this protection will disable itself. Does that make sense?
The challenge I see with any advice is that the proxy is not an application using UDP, it's just passing opaque data. So it will really struggle to rationalise at all about the various UDP use cases that clients have for the proxy. Perhaps rather than focus on advice, focus on how CONNECT UDP proxy considerations differ from CONNECT TCP proxies. That may well cover, at the same time, considerations like how long should a proxy hold open requests (tunnels) that don't exchange any packets in one or both directions i.e., a DoS attack on the proxy itself via a slow loris kind of mechanism
That's discussed in the Proxy Handling section, it references BEHAVE for how long sockets should be kept open
NAME would it be worth adding your reasoning (which makes sense to me) to the draft somewhere?
fair point, I'd read that and forgotten about it, maybe worth a back reference from the security considerations. For instance, HTTP/2 has some special callouts to CONNECT in its security considerations URL edit: I'm not claiming the same considerations apply here, just that server resource usage as a byproduct of proxying might be different than other request loads
That makes sense, I've written up to address these comments.
Thank you


This Partly addresses
Clarify that maximum sequence number is algorithm dependant and define a formula for it.
May be simpler to just have a single structure for the externalaad. externalaad = [ ver : uint, code : uint, alg : int, id : bstr, seq : bstr, ? tag-previous-block : bstr ]
the "context" parameter, which has value "Encrypted" This should be "Encrypt0", but even better OSCOAP should just point to draft-ietf-cose-msg that already specifies this.
-00 Section 3.2.3 - You are getting ahead of yourself. The only way that the identifiers would not be unique would be if the sender and recipient collided. I do not know that this would be a problem and therefore talking about it makes no sense. I am assuming that this is supposed to have something to do with the multicast work that I have not looked at. If so it does not belong here but there.
Agree. I'll delete all text on group communication from the document.
Multicast removed in branch v-02


The transport draft states the following (Section 4.4): This verbiage, introduced in PR , is ambiguous. Byte offset may refer to the Offset field in the STREAM frame; in this case, the definition above is incorrect. What we want to say is that the final size is one higher than the offset of the byte with the largest offset sent on the stream. If no bytes were sent, the final size is zero.


Say for example that A and B have the same IP Version and they have the same or overlapping Start IP Address / End IP Address ranges. A's IP Protocol is zero (the wildcard) whereas B's is non-zero. That causes a weird kind of overlap even though all the requirements are followed. Is it worth disallowing in the spec?
Earlier in this section, the version is defined as such: I think then this is OK, since zeros aren't allowed in route advertisements. NAME that sound OK?
The IP Verson cannot be zero in the ROUTEADVERTISEMENT, but the IP Protocol can: The following ROUTEADVERTISEMENT follows the requirements (the IP Protocol of A is lower than the IP Protocol of B), yet there is an overlap:
Oh, I see, I misread. I do think that it makes sense to put the wildcard first — so 0 shows up before others. And then the more specific protocol rules can potentially have different ranges. I still think this is acceptable to leave as-is.


We never defined what RA was. Do so by expanding it to Router Advertisment in the abstract.
Note: it's still not clear to me whether we need to cite the RA/DHCP/etc RFCs, or whether they're considered 'well-known' enough to be left alone. Or, is that a questdion for the rfc editors?
I'm comfortable with taking DHCP and Router Advertisements as assumed knowledge. Both are on the .
We never define what an 'RA' is, but we use that term in section 4.1. We should consider expanding it to the full term (Router Advertisement). We may also want to add an informative reference to it when we first mention it. Note that we have the same problem with DHCP here -- I'm not sure offhand what the best practice is regarding terms that have fairly wide use, but may not be understood by everyone (and even what that set of terms is).
RA is listed in the abbreviations document: URL but of course "expand on first use" seems like sound editorial practice.


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. >


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.


The endpoint sends frames, which carry -- not send -- identifier values.
The way it's intended to parse, "An endpoint ... MUST NOT increase the value they send," is probably incorrect in number or gender. But yes, changing the verb to reflect that the subject is the frames instead of the endpoint is also an option.
OK. I have no preference how this sentence is fixed -- as long as it's fixed.
This looks good. While we are at this paragraph, why say "client?" GOAWAY can be sent by either side now.
It can, but a server isn't going to retry push streams on a new connection; it's going to decide de novo whether to push there. Arguably, nothing breaks if the client increases the Push ID on the server after the fact.
BTW, thanks for catching this. I appreciate how many of these ambiguities you're winkling out.
NAME NAME OK, lgtm, then.
Maybe, given the ambiguity, the right answer is to get rid of "they" in the first place?


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.


But that is just how it is. We get to choose between that leakage and a known large amount of bustage.
This solution admits a straightforward, active distinguisher: just intercept CH1, respond with a fake HRR, and look at CH2. It's true that we "give up" on making HRR not stick out in . However, one of the design goals there is to prevent active attacks that trigger the HRR code path when it otherwise would not have happened. What we give up on is ensuring "don't stick out" when HRR is inevitable for the given client and server.
Ah, are you saying that this conflicts with (and thus would have to be removed if is merged)?
I believe resolves the same "OPEN ISSUE", yes.
I just noticed this as I was pondering our various HRR issues. RFC8446, section 4.1.2 says: URL The "and present in the HelloRetryRequest" portion is fun. In RFC8446 as written, we're not allowed to change the extension on the second ClientHello unless the server sent in HelloRetryRequest, which it doesn't. With the protocol as-is, it seems we'll at least need some text to deal with the contradiction. The impact is practice is thankfully limited. If the servers does not enforce consistency between the two ClientHellos, it doesn't matter. (They're not required to, but they're not explicitly forbidden from it either, and a stateless server may need to enforce some minimum consistency to avoid getting into a broken state.) If a server does, ECH's behavior on HRR will break it. Such a server is supposed to handshake with ClientHelloOuter, so it just affects the retry flow. That's maybe okay, but mildly annoying. Administrators using server software that checks need to know to first upgrade to a version that doesn't check before trying to deploy ECH. We can also add an ECH extension to HRR. Then, on ECH-reject + HRR, the server perhaps wouldn't send the extension and the client would be required to replay the extension. This is a waste in many ways, but would work. This would break don't stick out, but some threat models, don't stick out with HRR is hopeless anyway.


(See URL) It would also be weirdly asymmetric between ECH and SH. That said, this constraint is also pretty obnoxious. For instance, currently adds a new padding extension codepoint, because the old one isn't defined for other messages. However, the RFC8446 allowance only works for the existing padding code point, so you don't want to send any other code points in ClientHello, lest the server force you to keep it unchanged in ClientHello2. So maybe we should confirm no servers did the fully strict check and undo that constraint? (Although, for , I personally favor the padding message strategy anyway.)
NAME points out the Go implementation does check CH1 and CH2 consistency. Fortunately, it only checks known extensions, so it's still compatible with the ECH draft. URL Checking only know extensions is basically saying we should strike "and present in the HelloRetryRequest" in rfc8446bis and make sure everyone knows not to check this.
I don't think we can just strike this text because the point of that text was that you couldn't like change your KeyShares if the HRR didn't tell you to. But I agree we can sharpen this in some sensible way.
I figured that case was covered by "defined in the future", which I'm not proposing we delete. keyshare isn't defined in the future, so it falls under existing rules. The existing rules (bullet points over that one) only let you change keyshare "[i]f a "key_share" extension was supplied in the HelloRetryRequest". But perhaps that's a little roundabout. The rules I'm thinking of are (changes emphasized): Each extension gets to define how it reacts to HRR. It typically is sensitive the corresponding HRR extension, but doesn't have to be. RFC8446(bis) defines the rules for all existing extensions. Future extensions define their own rules. (And probably if they don't say anything, we assume they don't get to change.) As a server, you can make assumptions based on the rules for extensions you know about. You have to tolerate random changes in extensions you don't know about, because you don't know their rules.* I'm running a probe on a bunch of servers to see how they react to changes in cipher suites, curves, and a random extension.


It seems most don't notice. Some (I'm guessing Go) notice cipher suites and curves. None notice a random extension. That suggests the change will be compatible.
I spoke too soon. LibreSSL breaks if you change an extension they don't recognize. :-(
So draft-09 isn't tied up with this, I've uploaded URL as a bandaid for the potential compatibility issue. (I say potential because it's only a problem if the server checks unknown extensions and has different enough key share preferences from the client that it needs HRR. HRR is pretty rare, so it may not actually be an issue. For Chrome, at least, I don't think the particular servers I found actually trigger HRR. But it is still a risk for clients or servers with different configurations.)


Merged... with the neurons I have left on 22 December, this seems broadly true. I'm not sure we should be too prescriptive about load balancing in this doc, though -- in part because I suspect the challenge of handling DDoS attacks using QUIC traffic will lead to divergent innovation in the LB space in the near term...
So if the 5-tuple changes because of NAT, the connection ID might actually not change. So in case of DDoS you might want to look at the connection ID to at cover those cases. For DDoS you usually don't need a hard guarantee to track all flows (if you block a flow incorrectly, it has to reconnect), but where you can track the flow when the 5-tuple changes, it might actually help. That is what this paragraph is/was about.
"QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID and necessitate that connection ID aware DDoS defense system must have the same information about connection IDs as the load balancer {{?I-D.ietf-quic-load-balancers}}. This may be complicated where mitigation and load balancing environments are logically separate." This is insufficient. Even the load balancer is only able to identify the end server, not the connection.
On a related note, the suggestion to use the "first 8 bytes" of a server's connection ID is somewhat strange. Why not observe the CIDL it's using in long headers, or just have common configuration?
How about if we just remove any wording about load balancers here? Like this maybe:
On the 8 bytes: I actually not sure where this comes from, however, I assume that the thinking was that using the first 8 bytes might be good enough to avoid collisions if you don't know the connection ID length. But I guess we can remove it or add some more explanation... any thoughts?
If you read the Retry Services section of QUIC-LB, you'll see that there is no dependence on the Connection ID encoding at all. It is a common format for Retry Tokens that allows servers to (at a minimum) extract the original CIDs necessary for verification. Certainly, no device should drop packets simply because the CID has changed, which is maybe what you're trying to say here? But I'm not sure that this is a DDoS thing.


The point is when a DDoS attack is on-going you want to make sure that on-going connections keep running while new connections are handled more carefully. So you have to be flow aware. However, maybe it's acceptable if connectivity breaks during a DDoS when the 5 tuple changes...? Otherwise you would need to be CID aware.
This PR removes the problems I cited in the issue. Ship it. I wonder if we should hit the point in the last sentence a little harder. If you want to support connection migration, there's nothing you can do in this space except the Retry Service stuff in QUIC-LB, is there?


No point in levying requirements on them.
Section 8.2 says: However, this directly contradicts TLS 1.3 URL, which says: In order to say this, this document would need to Update 8446, and even then it doesn't make sense because the presumptive point of this rule is to detect attempts to negotiate QUIC with non-QUIC TLS endpoints, which don't need to conform to this RFC (and may predate it).
I don't think QUIC can tell anyone what do with regard to any protocol that is not QUIC. And since QUIC v1 carries its own TLS record wrapping it makes even less sense.
I agree with the problem statement, however I wonder if this opens a session ticket obtained using TLS13-over-TCP to be used in QUIC. Is that what we want?
NAME why would this text have an impact on that? Couldn't I negotiate TLS 1.3 over TCP w/o extension and then send the resume over QUIC w/ extension?
The point here is to insist on the alert if the extension is understood. This wasn't intended to supersede 8446.
NAME My bad. I was confused with the earlier versions of the QUIC-TLS draft that had the transport_parameters extension in the session tickets.
NAME I think you could phrase that, but is it useful, given that we can't rely on it?
Probably not. I'm OK with culling the text.
This might not be possible if a cloud load balancer only forwards QUIC with TLS and terminates TLS otherwise.


the type is called signaturealgorithmscert (singular) everywhere, not signaturealgorithmscerts (plural)


Fixes several nits from the gen-art review, which basically all come down to defining terms appropriately and/or referencing their definitions. modifies definition of "stream" and "stream error"; pulls in more terms from SEMANTICS references SEMANTICS for definition of fields rewords to avoid the term "hop" and describes intermediation more explicitly rewords to avoid saying "not possible" and copies language from SEMANTICS advising against retries updates reference to definition of CONNECT in SEMANTICS. NAME your review would be appreciated.
In the HTTP genart review, NAME writes:
Yes, CONNECT only supports TCP, and there's no short-term plan to change that. There is separate relevant work such as but I don't think we need to change anything in the draft here - it pretty clearly mentions TCP so I don't see any ambiguity.
This question should be addressed by the definition of CONNECT the spec is referring to. It's worth double-checking the references in that section, though; it points to HTTP11, when I think there should be a definition in SEMANTICS.
In the HTTP genart review, NAME writes:
Presumably a reference into SEMANTICS; I'll look for the right section to point to.
In the HTTP genart review, NAME writes:
In the HTTP genart review, NAME writes:
In the HTTP genart review, NAME writes: "HTTP/3 stream". Perhaps it's worth defining "HTTP/3 stream" explicitly, in analogy to "HTTP/3 connection". Perhaps it's worth defining "message", too (this is only an HTTP concept, correct?). The document should make sure it clearly distinguishes terms and concept of QUIC vs. of HTTP/3 in all cases. In particular, what is the relationship between HTTP/3 frames and QUIC frames? It's important to make their difference and relationship explicit, as the document uses several other terms interchangeably between HTTP/3 and QUIC, like "connection" and perhaps "stream".
A few minor suggestions, but this is a good change.This looks good to me, thanks!


This uses kramdown tricks to make real links for the section references to RFC 9001 and uses a nicer label for those.


From the meeting at IETF 112 ([1]): Consensus: 'in' won't be used, but it will be easy to add later if there's real demand [1] URL
Good eyes. Thanks!
Yes, we agreed to remove the 'in' operator as some kind of syntactic sugar. thanks
Thanks! I pushed a small commit removing an "in" example.


NAME The text in the PR adopts 1 PTO as a suggestion, as I am not sure if there is a point in that value being the exact limit. If it needs to be, we can rephrase the text to "MUST retire the corresponding connection IDs in one PTO and send corresponding RETIRECONNECTIONID frames."
I'm a bit worried that a stateless reset from a retired CID could be used as an attack vector by simply delaying packets en-route. However, if the reset is only effective on CIDs that are no longer recognised that shouldn't be a problem.
At the moment, states, quote: Upon receipt, the peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRECONNECTIONID frames in a timely manner. Failing to do so can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route correctly. As the text uses "SHOULD" rather than a "MUST", some view it as an optional requirement to switch to using a new connection ID in such a situation. Others think that it is a mandatory requirement for an endpoint to switch to a new connection ID. If we are to consider the latter behavior to be the case, I think the text should better be changed to "MUST retire the corresponding connection IDs and send the corresponding RETIRECONNECTIONID frames in a timely manner".
My personal take is that it would be nice if the processing of NEWCONNECTIONID frame and RETIRECONNECTIONID frame can be an optional feature. QUIC is already very complex, and it would be beneficial to have some features being optional, in sense that endpoints can simply discard certain frames when not implementing certain features. IIUC, at the moment, these two frames are optional for an endpoint that do not support migration. OTOH, from the robustness viewpoint of the protocol, it does make sense to change the text to MUST. We might have already crossed the river by introducing the Retire Prior To field. The third option is to add a TP that indicates if an endpoint supports retirement of connection IDs...
There was a lot of discussion when the Retire Prior To feature was added. At the time, I felt it pretty clear that it could not be optional from our server's perspective.


I agree the sentence with the SHOULD, if read in isolation, could be interpreted as making the feature as optional. But the sentence immediately following it makes it pretty clear that it's not option. I understand the desire to make things optional for simplicity's sake, but a primary point of this feature, when it was added, was that is was required. Making it optional now would, IMO, defeat the purpose of the feature.
My understanding is that this is optional in the sense GOAWAY is optional. At some point, the connection is likely to terminate abruptly if you don't follow the request.
That's one way to look at it. The difference here is that we're not trying to kill the connection with Retire Prior To.
There was definitely lots of discussion around the requirement level here when this was added (see ), NAME asked: There was good discussion following that ( and scroll down). My understanding of was that the endpoint being asked to retire a CID really SHOULD retire it or else the peer may stop responding to that CID. After the endpoint requesting retirement gives up on a CID and forgets about it, packets will either arrive with that CID or they will not. It has two choices, it can choose to process them if they arrive with the wrong CID, or it can drop them. The enforcement mechanism here is to stop processing the "bad" CIDs, not close the connection, especially as you take into account potentially delayed-but-valid packets. I think the current stance of "really SHOULD stop using such a CID, but the other endpoint needs to be careful about enforcing that" is the right one, if there's a wording update that would help with understanding there, then it would be great to update the wording as an editorial issue.
Whatever the answer here, the SHOULD was chosen because "timely manner" isn't defined in a testable fashion. If someone wants to argue for MUST, then we need a firmer definition of the reaction.
And to agree with NAME the squishiness here only exists up until the point that this is "do this or else". We should make it clearer that the cost of non-compliance is losing the connection. Not always, but a endpoint is entitled to cut and run if their peer doesn't comply.
NAME Thank you for the explanation and the links. They help a lot in understanding how we ended up here.


NAME Yeah we already state that "an endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an acknowledgement is received for the NEWCONNECTIONID frame requesting that retirement." So I think it's testable. Considering that we have a MAY on the side that initiates the retirement, I think we can have a MUST on the receiver side (assuming that we want to).
That almost works, except that PTO isn't a shared variable. It's subjective and so endpoints might disagree on where this line is. At 3PTO, that's probably not a disagreement worth having, but you are effectively recommending instant compliance if you set the bar that low, as packet loss on any packet sent that attempts to comply might cause it to take up to 3PTO to get through.
IIRC, the base of the SHOULD was that we didn't have a specific timeout anyone felt comfortable enforcing in the absence of shared timers between peers. We've had a general principle that requirements you can't tell whether the peer violated are probably SHOULDs instead of MUSTs. As Nick says, the SHOULD is intended to refer to doing so promptly, not to doing so at all.
While I agree that we have tried to make MUST requirements testable, I am not certain if it is a good idea to avoid use of MUST when a requirement cannot be tested (or if doing so is a good idea, per the definition of the keywords in RFC 2119). At least for this particular case, isn't it a requirement for an endpoint to drop the old connection IDs? Though I could well be wrong though in how the keywords are used in practice.
I'm fine saying MUST drop in a timely manner, and being explicit about what we mean by timely manner (3 PTO from the peer's perspective). Obviously, from the peer's perspective, that is enforceable. Locally though, it's obviously not as clear cut.
We need a PR. NAME do you think that you can do this? As discussed, should be that the receiving side will retire within one PTO. The sending side can enforce at 3PTO, by dropping the connection.
Discussed in Cupertino. NAME to quickly rev the PR to incorporate NAME suggestion.


NAME the delayed packets are handled by this text: If you've followed the requirement to retire as indicated, then a delayed packet triggering stateless reset can't hurt you.Looks fine to me. I'm also fine with Martin's suggestions as well.The endpoint here has always been going to do whatever it does, regardless of whether we said SHOULD or MUST, so this seems fine. I do like the direction for the other endpoint to wait 3PTO, that would be nice to include.


Originally raised by Magnus: Section 3.7: JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section. I think this should be explcit that it is "simulcast transmission of a MediaStreamTrack".


…oundaries defined by the CDDL
We should add something like: " within the syntactical boundaries defined by the CDDL in Figure 1."


In the API doc sec 5 says. "Message Framers (see Section 10), if required, should be added to the Preconnection during pre-establishment." Should this be SHOULD or even MUST? If SHOULD is correct I think we need to say slightly more about when it makes sense to add a framer later.
I think it should be "can be added..."; not normative, just descriptive of fact.
Can we start with the "If' perhaps... "If messages frames are to be used, they MUST be added to the Preconnection during pre-establishment."?


Not sure if the deprecation cutoff will be at 224 bits (~112 bit security level) or 255 bits (~128 bit security level) yet, so I've just done the former for now. This drops the old curves under 224 bits, updates the extension example bytes, and deprecates MD5.
As noted on-list, SHA1 can't be as easily dealt with here, so that'll be a topic for a separate changeset.
Here's a PR for this: Question: Are we dropping all curves <224 bits or <255 bits? (was consensus ever called on this specific number?)
There was not a specific WG consensus call on this point. I hope we don't need one and that we should keep the curves in that are used and trim the ones that aren't.
Good. In that case, I'll slash everything other than secp256r1 (prime256v1 / NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521), and sect571r1 (NIST B-571). (plus, of course, new CFRG curves yet to be added) PR updated. URL URL
Based on the fact that apparently precisely zero servers actually use SHA-224 for signatures, can we drop that too while we're at it? (not an exaggeration; the scan cited in the last comment shows none)
I would drop it. spt On Jun 17, 2015, at 20:09, Dave Garrett EMAIL wrote:
OK. PR updated.
NAME This can be closed now that PR has been merged.


NAME 7df2d9c should address this
To we need multiple local and remote candidates. Should this be represented as either: 1) taking two lists of objects; or 2) as two objects each with multiple addresses, ports, etc. I suggest option 1, since this makes it easier to resolve a to multiple preconnections, for NAT binding discovery. Relates to but with also different types of endpoint.
I like option 1 because it contains complexity.
See this email thread: URL Copy + pasting a relevant part from an email from NAME To me at least, it wasn't clear from the text that rendezvous() would kick off ICE-style probing. It's kind of obvious (when else would it happen?), but I think it would be good for the draft to spell this out.
modulo the do-we-want-to-bind-tightly-to-ICE question... Dear all, I know way too little about rendezvous mechanisms, so I may get this completely wrong - please bear with me! It may be that I describe an issue that’s a non-issue. But, if I do understand this right, maybe that’s something which needs fixing? Ok, here it goes… Our current Rendezvous text in the API draft says the following: "The Rendezvous() Action causes the Preconnection to listen on the Local Endpoint for an incoming Connection from the Remote Endpoint, while simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint. This corresponds to a TCP simultaneous open, for example.” Now, if an application chooses unreliable data transmission, it may get SCTP with partial reliability, or it may (in the future) get QUIC with datagrams, or whatever… and then, the protocol may be able to do what’s needed (something similar to a simultaneous open). However, in case of UDP: Listening is quite okay, “simultaneously trying to establish a Connection” really means nothing - no packet will be sent. I believe that applications doing this over UDP will implement their own “SYN”-type signal for this - but then it’s up to the application, which, over TAPS, would need to: create a passive connection, send a Message from that same connection, i.e. using the same local address and port (I believe?)


- which is a matter of configuring the local endpoint, and doable if the underlying transport system can pull it off. I think there’s nothing in our API preventing an application from doing this. If all of the above is correct, the problem that I see is that an application may ask for unreliable transmission, and then have one case in which calling “Rendezvous” is the right thing to do, and another case in which it is not - so it would need to be able to distinguish between these two cases: is it a protocol with Rendezvous-capability, or do I have to do it myself. Maybe, in case of UDP, the call to Rendezvous should just fail, and our text should say that Rendezvous failing would inform the application that it would have to implement it by itself, by issuing Listen and then sending a Message to the peer. Thoughts? Am I completely off track, or is this something that needs a text fix? Cheers, Michael


This check really is triggered by TLS providing new keys, not QUIC delivering data on a higher encryption level. Otherwise, in the case where no session ticket is sent, this condition would go undetected for unconsumed data at the Handshake encryption level.


Fix issue
In section 3, we have However, the error code does not exist (anymore), and I'm not sure we need such a specific error code anyway. Why not raising a in such case?
It's reasonable to use TRANSPORTPARAMETERERROR. Submitted PR for this issue.


I also want to point an issue due to this stance. The fact that we are not explicit and discuss the expectations and realities of different IP versions we have interesting failure cases due to this text from Section 3.1: “However, if the target_host is a DNS name, the UDP proxy MUST perform DNS resolution before replying to the HTTP request.” No where in the follow paragraphs in this section do it discuss the slight issue that a DNS resolution can return only an AAAA record and the MASQUE server may only support IPv4. What is the error response? Should this be a proxy-status response. I would not there are currently no response for “IP version not supported”.
These concerns apply equally to TCP proxying via HTTP. We should strive to provide parity to how CONNECT treats these matters. HTTP semantics don't say anything
+1 to Lucas' meta-comment about striving for parity with CONNECT There is no such thing as a "unsupported IP version" DNS failure. Let's take an example where the client wants to CONNECT-UDP via the UDP proxy to the target . This particular host is configured such that querying AAAA will get a valid address, and querying A will yield a "no answer no error" DNS result. Let's assume that in this example the UDP proxy is IPv4-only. In that scenario, the UDP proxy will only query A (because it doesn't know what AAAA is) and it will get "no result no answer" so it will send
NAME in light of the previous comments, can you clarify what you think is missing from the document please?
First of all, I think that just answering lets do like Connect is a poor answer. There are benefits to alignment, but also one should ask if one are preventing useful functionality. In this case I think there are a relevant difference between what could be answered depending on how one implement stuff. Your suggest road says that for a IPv4 only proxy with a DNS name that has AAAA record but no A record the answer is: a) There is no answer For a node that would query both the answer could actually be: b) There is host, but I can't reach it as I don't support the right IP version, try another proxy. Sure, limiting ourselves to a) is easy, but is it the most useful for the protocol?
Disagree it's a poor answer.


An HTTP proxy that inplements CONNECT for UDP is likely going to implement CONNECT for TCP. How to treat name resolution for both of these has to be consistent. The Proxy-Status header field is the appropriate way to signal such failures. Any text more complicated than what we have now, should be pursued in a separate document IMO. Not added at this late stage. It would be straightforward to form up a document like "DNS considerations for HTTP proxying" that is additive to the specifications we have.
I agree: Proxy-Status is the right place for this discussion, and CONNECT-UDP already recommends Proxy-Status. Also, as a technical matter, this is not how dual-stack connectivity works. As noted above, an IPv4-only UDP client will never issue a AAAA query for a destination hostname.
I agree with what Lucas and Ben said above. Let's move this discussion to an extension draft.
I agree that this discussion probably deserves to be in an extension draft. As is stands today, a DNS failure as described in this thread can just as easily result in a destination-unreachable / connection-closed error for the CONNECT-UDP stream, and an extension to provide detailed information as to why seems like the natural path forward.
Proxy status is absolutely the right thing to do here. The proxy-status is what we are already doing in production for CONNECT and CONNECT-UDP. The current text seems entirely appropriate for this: The only thing I could see saying further is to mention the error parameter, like this: I do not think we need any extension draft for this. This is very straightforward, and doesn't need to say much.
Thanks Tommy, I think that's a useful clarification. I wrote up PR based on your proposal to make this clearer
Ok, I am fine with this resolution.
Thank you for confirming Magnus!


I think there are two option here, 1) close/deny the connect request, and 2) use streams instead. I think we should consider both option, especially given stream are just there to use.
Isn't this a dup of ? That's fixed with . I guess the text could be generalized to talk about more than just IPv6 MTU issues.
No, this aspect on what you do when the MTU required is not present is not resolved by that PR. I would note that closing gives the endpoints one experience that is likely easier to handle in implementation and do avoid the issue with reordering and the varying packet treatment that moving to stream would result.
I would suggest adding a sentence saying that if an endpoint realizes that the IPv6 tunnel MTU goes lower than 1280, then it MUST close the stream.
IETF 114: Note that if something happens and your MTU gets smaller, you may need to destroy that link. Potentially make this option a SHOULD do PMTUD, otherwise you could end up in a situation where you're not a compliant IPv6 tunnel. Proposal:
Even if PR was an improvement to the description of the IPv6 minimal link MTU issue the text still leaves an open issue in that it doesn't make clear which of the endpoints that are responsible for HTTP intermediaries or if is truly both which has another implication. So a Connect-IP endpoint will be aware of the HTTP datagram supported MTU and if its HTTP/3 connection can support sending at least 1280 bytes of IPv6 packets without fragmentation. However, if there is two or more HTTP intermediaries in between the client and the server then there are HTTP intermediaries that might have an HTTP/3 connection which has less than 1280 bytes MTU for HTTP datagram payloads in-between the client and server. Thus, arises the issue of how to detect this. PR states: if HTTP intermediaries are in use, CONNECT-IP endpoints can enter in an out of band agreement with the intermediaries to ensure that endpoints and intermediaries pad QUIC INITIAL packets. From my perspective the big question is how a client or a server knows that there are intermediaries, or the most important aspect, that there are no unknown HTTP intermediaries. To my understanding both the client and the server can potentially bring in HTTP intermediaries unknown to the other part.


Thus resulting in a HTTP intermediary to intermediary connection where neither endpoint knows if the requirement is fulfilled. Thus my interpretation is that the only way to be sure that it works it to actually execute on the third bullet in the PR: CONNECT-IP endpoints can also send ICMPv6 echo requests with 1232 bytes of data to ascertain the link MTU and tear down the tunnel if they do not receive a response. Unless endpoints have an out of band means of guaranteeing that one of the two previous techniques is sufficient, they MUST use this method. I would also note that this only verifies from the acting endpoint towards its peer, not the reverse path. For that to be verified the peer need to send ICMP probes the other direction. Thus, my conclusion is that Connect-IP still don't ensure that the minimal MTU is fulfilled.
Isn't the quick-fix to require that the ICMP reply also be 1232 byte sized?
Normally I would say now, as you want to ensure that the reply makes it back that shouldn't be padded. Also if the response is anything else than echo reply you also should not pad. However, I think the implication is the same either way. Both masque client and server need to send ICMP or modify its ICMP processing. Given that I would think having each endpoint doing independent processing of its forward path might actually be simpler and enables using a standard off the shelf ICMP implementation and not have to modify it.
Our implementation has userspace ICMP request/response handling for echo request/response, it wasn't too hard to write. I don't propose modifying anything, but the structures were ~50 lines of code to set up. I agree we shouldn't be modifying responses we did not generate.
I think the existing text already is generic to "endpoint", not client or server: So this implies that both sides need to send the PING if they haven't guaranteed the MTU. This seems like this is already handled?
If both endpoints are required to send ping it would be resolved. However, that is not what is written in the draft currently. What is written is the there are various techniques, and if an endpoint choses something else than verifying its forward path using ping, it becomes unclear who is actually responsible for any HTTP intermediaries. Which results in an unclear requirement and very likely failure of the MTU verification resulting in an MTU black hole.


Well, it does say that endpoints MUST use this method unless the already have other coordination. I could see some clarification text to say that the guarantee for the other methods must include knowing there isn't an intermediary — which is actually pretty easy to guarantee in many cases.
That is what I intended when writing , but perhaps I wasn't clear. Can one of you propose a PR that would clarify this?
As per , the IPv6 minimum link MTU is 1280 bytes. However, states that it is possible to have a functional QUIC connection on a path that only allows 1200 bytes of UDP payloads. Such a path would only allow HTTP Datagrams with payloads up to 1180 bytes. If we only send IPv6 packets over QUIC DATAGRAM frames, such a setup would result in violating the IPv6 minimum link MTU. We should describe this problem and how to react to it. Possible solutions include failing the CONNECT-IP request, using the DATAGRAM capsule, or different solutions altogether.
This is only a problem for the end-2-end QUIC handshake packets, right? I was assuming that you either have a QUIC tunnel that has a larger MTU in order to use datagrams or you have to use stream-based transmission for the e2e handshake and then need a way to switch to datagram later. In any case we need to say more in the draft!
From the most recent session, I think we may have consensus to address this by noting that CONNECT-IP over H3 requires a minimum link MTU of X bytes on every HTTP hop for IPv6 compliance, leaving support for smaller links to an extension.
I'm not sure the consensus was clear, but I think it's upon us to make a proposal and see if it flies =)
That sounds like the best path forward.
I propose a simple solution that should be enough for most use-cases: if any endpoint detects that the path MTU is too low, it MUST close the tunnel if the tunnel had IPv6 addresses or routes on it. Endpoints are not required to measure the path MTU. endpoints that wish to use IPv6 SHOULD ensure that their path MTU is sufficient. For example, that can be guaranteed by padding QUIC initial packets to 1320 bytes.
That seems reasonable to me as a proposal!


So how does the endpoint determine that the Path MTU is too low? In the scenario that looks like this C - I1 -I2 - S and it is the I1-I2 path that can't support 1280 byte datagrams. The I nodes are HTTP intermediaries. The client will not know that the datagram MTU size is too low on these nodes, to my understanding the datagram payloads will simply be dropped by the I nodes in either direction.
In that scenario, if the endpoint wants to check it can send an ICMPv6 echo request with 1232 bytes of data - if it receives an ICMPv6 echo reply that means that the path supports the minimum IPv6 MTU.
NAME then we are making it mandatory to send ICMPv6 echo to the external address assigned for the client, and for the server sending one to the client, this to determine that minimal 1280 bytes are working over MASQUE. Because to me there are no way the MASQUE endpoint can determine in all cases if there are HTTP intermediaries or not. Else we have to put requirements on the HTTP intermediaries to understand MASQUE, and to my understanding what was not desired. And maybe using ICMPv6 is the easiest method with the lowest implementation burden. The issue I see with this aspect is that many applications when establishing a Connect-IP path might not want to wait for the ICMPv6 response before sending other traffic so we have a situation where there is a small, but non-zero risk that these packets goes into a black hole, and then the ICMP response comes back and the MASQUE Connect-IP stream will be closed due to the response to indicate the failure. I think this is all manageable and not different from failures that can occur for other reasons.
I don't see why this should be mandatory. When I plug in an Ethernet cable into my computer, I don't know whether the IP stack on the next router spuriously drops packets above 1000 bytes long, and my OS has no requirement to measure the path MTU.
But for the said router dropping IPv6 packets below 1280 would be a protocol violation. The issue here is the interaction with the HTTP intermediaries and what is under the control of Connect-IP function. So Connect-IP basically provides a IPv6 capable link.


Per IPv6 RFC that requires us to support 1280 at least. What have been the rough consensus so far is that we are not defining an fragmentation and reassembly mechanism, or rather how to ensure that one uses QUIC streams when the transport is HTTP/3 for below 1280 IPv6 packets and instead reject the service. Thus we are in the position of having to answer how does one know when to reject the service. The alternatives I see are: 1) Force the Connect-IP endpoints to ICMP ping each other to verify that the path supports 1280 IPv6 packets 2) Have the HTTP intermediaries be Connect-IP aware to the level that they can reject the HTTP request if the path does not support 1280 packets. Where 2) have the downside that we still likely have some black holes in cases where the HTTP intermediaries are not connect-IP aware and ignores the requirements. Where 1) have the downside that the endpoints request can't be rejected during the request response sequence and instead have to be closed with an error message indicating the paths failure to support the packet.
I'm opposed to requiring ICMP pings because the majority of use-cases will not have this problem. How about we add text like this: CONNECT-IP endpoints that enable IPv6 connectivity in the tunnel MUST ensure that the tunnel MTU is at least 1280 bytes to meet the IPv6 minimum required MTU. This can be accomplished multiple different ways, including: Endpoints padding QUIC initial packets when it is known that there are no intermediaries present Endpoints sending ICMPv6 echo requests with 1232 bytes of data an out of band agreement between one of the endpoints and any involved intermediaries to have them pad QUIC initial packets
So I understand your desire to not add complexity anywhere for a likely seldom arising case. However, I do fear that not addressing this with a clear assignment on whose responsibility it is to avoid the issue will result in that none does anything of it. Because an endpoint that uses HTTP/3 can verify its first hop. However, the complexities arise when you have HTTP intermediaries in the mix.


I get that, but since the complexity is added by intermediaries we just need to make it clear that the intermediary needs to not be silly
One part is to detect if the link is capable of 1232 bytes, however, if not, we also not to provide more guidance what to do. I think there are two options: either close the connection or use quic streams instead of data datagrams.


Tweaks to future proof document.
Spencer had the following comment: I found the reference to MMUSIC WG in When a new codec is specified, and the SDP for the new codec is specified in the MMUSIC WG, no other standardization should be required for it to be possible to use that in the web browsers. to be odd. MMUSIC may be around forever, but this work might be refactored at some point in the future. Is the point that When SDP for a new codec is specified, no other standardization should be required for it to be used in the web browsers. Or is there another way to say this? I'm also wondering if the statement is true for any WebRTC endpoint, not just browsers.


Looks good! I would maybe add 1 sentence explaining the rule for what is called a secret and what is called a key. The rule says that a secret will go through some key derivation to obtain a key/keys, is that right?
NAME Yep, that's exactly right. Added a sentence. Thanks for the feedback everyone!
Reopening due to incomplete discussion and inaccuracy. The claims presented are incorrect in response by NAME demonstrate a misunderstanding of the roles of these keys and uses, and constitutes a change to the fundamental uses thereof. The authenticationsecret is NOT a public value nor was it ever introduced as such. If an application is using it as a public value, that onus is on the developers, and I advise against using Cisco's implementation as a standard for MLS. As shown in the name and all original discussion, the authenticationsecret is intended as a secret value (or else 'public' in the same way that the group secret is 'public). It is used for further derivation to support authentication. This should be corrected, and such foundational changes without WG discussion should be avoided.
Clearly we have a disagreement here NAME but maybe let's hold off on attributing misunderstanding. It seems like you are claiming that in order for MLS to be secure, the needs to be protected to the same level as the . What is this based on? If that is true, then we should probably remove the altogether. The "out-of-band" protocol in which it would be confirmed would have to be part of the MLS security analysis, thus no longer out-of-band.
NAME that is not the claim at all - different uses imply different compromise risks. This should not be a new concept to understand. As demonstrated in the terminology, the authenticationsecret is linked to authentication, not confidentiality. MLS, per specification, outsources authentication (the AS is not explicitly defined and all entity authentication within MLS relies on it). Even though it is definitionally out-of-scope and therefore out-of-band (certificates, authentication verification are entirely out-of-band of the protocol spec), we do not say that signature secret keys can be "public" - yet you are asserting that an authenticationsecret which can support epoch-level authentication would be public.


The authenticationsecret is private in the same way that the exportervalue is: based on key schedule derivation, compromise of these keys should not undermine MLS, but secrecy of them can be leveraged. So, unless you are now proposing removing mention of certificates, etc. from the core protocol, there really isn't a logical basis for removing 'out-of-band' authentication mechanisms.
What I'm trying to get at here is: What is the negative consequence if an is known by someone other than the members of a group? For example, leaking a signature private key would enable the attacker to impersonate the corresponding member. Leaking the would allow the attacker to decrypt all of the group's messages. What is the bad consequence of an becoming public?
NAME I am also assuming that this push to use epoch-level authentication values as public codes is based on Cisco's implementation choice. I would be curious to know why there is such insistence that all implementations also go about using authentication in the same way. If an implementation chooses to use it as a secret value to then derive an authentication code based on yet other information, why is that a problem?
Publishing the authenticationsecret as a public value has a similar effect as publishing the exportervalue as public - it is not an issue for MLS per protocol spec, but it would definitely be an issue for the application if it is then used for something secret thereafter. One reason not to specify these as public values is that they are derived following the conditions placed on keys and therefore could be used as secret values if desired by an application. Forcing or annotating them as immediately public, or as final 'codes', when such a use as a secret key is an out-of-scope potential is artificial and unnecessary.
I'm not pushing anything, I'm just trying to get the protocol to be clear. If this thing needs to be secret, then it needs to be secret, and we need to document that so that people keep it secret. Thanks for elaborating more on your concerns. I see what you're saying -- basically the same point that NAME and I discussed . I think the core of the disagreement here is what we mean when we say that a value is "public" or "secret".


I mean something very specific: That the security guarantees of MLS will not be harmed if a public value is provided to the attacker, and they will be harmed if a secret value is provided to the attacker. Importantly, "public" does not mean that the value must be published, or that the security guarantees of an application using MLS will not be harmed if you publish the value. It seems to me that in that specific taxonomy, the is "public" and not "secret". Do you disagree?
BTW, the notion of something being "public" at one layer but "secret" at another is not new. For example, values exported from TLS aren't secret in the sense that publishing them would compromise TLS. You could authenticate your TLS connection by exporting a value and shouting it through megaphones across a crowd. But the main way people use them in practice is as secrets in some other protocol. Every WebRTC call uses SRTP keys that are exported from TLS, and many people would be very sad if these "public" values were published.
If it would help, I would be happy to add some text to the Security Considerations clarifying this distinction. Basically, draw a clear boundary around which values have to be kept confidential to the client in order to realize the security properties of the protocol. But I still think is a clearer name. Doesn't mean you have to use it in any particular way in your application; doesn't prevent it being used as a shared secret; but also doesn't imply that the MLS library has to worry about its secrecy.
Within the bounds of that particular taxonomy there is not an issue. However, while you may be following a given taxonomy, that is not a general one, one that would be widely understood by implementors, nor is it specified in the protocol spec. It is not an unreasonable taxonomy, but it certainly not a general one. If you are looking for MLS usage spec to align to your taxonomy then I do think that there should be a clarification section added. BTW as a point case on more standard terminology use, the TLS 1.3 spec uses the exact phrasing for exporters as "exportermastersecret", from which the actual exporter may be derived. This aligns very closely to the authenticationsecret, from which an authentication code later may be derived.


TLS is generic in 'exporters' after an exportermastersecret is derived. Thus there is alignment of the term 'secret' to things that can be used for keys (have sufficient entropy), not as an alignment to public/secret at different layers. I am strongly opposed to the use of authenticationcode, and see no clear definition for that in your customized taxonomy. As such, it would follow the more standard interpretations, such as message authentication codes, etc. which are indeed explicitly public values. Codes are normally an end-state in themselves, not keys. Perhaps it is a clearer name for the Cisco implementation design, but it is not a clear name for something that can/should be used for further derivations as may be more generally applicable. Following the TLS norm for exporters, the name would be "authenticationmastersecret". The shortened "authenticationsecret" was a good name. If you are going to provide a write-up for the custom taxonomy, then an adjustment to "authenticationexporter" could perhaps be made.
The notion of a having boundary to the protocol and values that may or may not safely be exported across the boundary is not exotic or customized. You see it in FIPS 140-2, PKCS, and WebCrypto, and in tools like ProVerif and Tamarin. The only choice I'm making is in the specific words, in particular reserving "secret" for "something that should not be exposed outside the protocol implementation because it would compromise the protocol". I hope you agree that is different from say in this regard. It would be OK for an MLS implementation to have an API for an application to access the , but it would not be OK to have an API to access the . I'm not wedded to , I just want something other than . If you want to align with the exported values (to which I agree it is similar), we could call it an .
The distinction between those documents and tools, and the MLS spec is that those tools clearly define the boundaries and terminology, vs. just anyone making terminology assumptions without them being specified in the document. Not to be pedantic, but if you want to assume specific meanings for terms relative to a threat model for MLS only, versus a general usage ("exporter secrets" being secrets used in other things), then you really do need to specify those assumptions within the specification itself and not various side discussions.


Such specification is part of what a standard is meant to do. Within other documents this is clearly defined - i.e., what is known as a threat model - such as one sees in ProVerif and Tamarin. Assuming that you are going to add such a taxonomy, and that it follows that described by you in , then the correct term would be "authenticationkey". To quote you what you said there, which correctly aligns to a reasonable usage of the authenticationkey. pointed out that there is a lack of consistency in the usage of "keys" vs "secrets" throughout the document - something that still has not been addressed and should not be dropped from the issue for edits. Regardless of what taxonomy is being used or even assumed, there is no consistency in it in the spec. You seem to be commenting on adjustments only for the "key" and "secret" uses that appear as variables, but the commentary within the spec interchangeably use these terms for the same thing. Whatever is used should be applied consistently. It is not reasonable to assume that developers will correctly guess reasons for terminology separations particularly when they are inconsistently enforced.
On your latter point about usage of "keys" vs "secrets" throughout the document — Sorry if I misinterpreted your intent here. If you're seeing places where there are inconsistencies, it would be helpful if you could highlight those more specifically, or ideally send a PR to fix them.
NAME had a call about this today and hashed out a couple of things: We should be clear in general about what we mean by secrets/keys, in that we generally use them interchangeably, but sometimes use one or the other to indicate how a specific value is used The need for secrecy of the value labeled depends on the context in which it is used. So we should provide some text to suggest that there are different ways to use it, and use a fairly neutral name. NAME suggested , which I like a lot. I have attempted to implement these in
The spec currently uses a mix of terminologies for keys/secrets.


In the key schedule we have the following: senderdatasecret | "sender data" encryptionsecret | "encryption" exportersecret | "exporter" authenticationsecret | "authentication" externalsecret | "external" confirmationkey | "confirm" membershipkey | "membership" resumptionsecret | "resumption" It would be best to provide a coherency to how we use these terms and check for consistency throughout, to avoid confusion for readers: A simple solution would be to use "secret" for all cases, i.e., changing membershipkey to membershipsecret.Another alternative, which may take more refining but could be useful to readers is to separate out terms based on items that are for internal protocol use versus external protocol use. For example, encryption, confirmation, membership, etc., would use "key" and exporter, authentication, etc., could use "secret", or vice versa. --Break-- Ref the mailinglist on confirmation vs authentication secrets, perhaps the naming of these two are a little misleading - authentication normally being within bounds of a protocol while confirmation is external to it. This confusion probably sparked some of that discussion to begin with. It could_ be worth considering switching those terms for clarity.
I actually think we have a fairly coherent taxonomy here: "secret" is something that gets fed into HKDF to derive further things "key" is something that gets fed into another algorithm, e.g., HMAC Looking through the list, the ones that deviate from this pattern are: , which is exported to the application but expected to be kept private , which is exported to the application but not expected to be kept private Given that, I would propose we update the table in question to something like the following, using because that's how it's used, and to follow the "security code" terminology used by applications:
Things are easier to understand like this! The "Purpose" column is quite valuable I think, I remember I was quite overwhelmed when I first read it and had no idea what all those secret / keys were used for. This helps to understand the big picture.


Addresses feedback from NAME and NAME to add a reference to the recovery doc on handling bursts resulting from flow control credit; that advice on when to send *_DATA frames (at least 2 RTTs before sender is blocked) is too specific. I've also done some editorializing to fix flow.
Is this the right place to discuss pacing? In my mind, we’re talking about different layers here. Bursty sending could happen due to many reasons, only one of them is due to increased flow control credit.
Yeah I was wondering that too. We do talk about application limited in the recovery doc, so maybe that's the place to clarify this. I'll see (after the weekend) if it makes sense to add anything there.
I think we should discuss what to do in one place, but given the sort of traffic bursts that can arise if you happen to get this wrong, I am still keen to see a couple of sentences here that explain the pathology when a sender has cwnd and no credit, and then suddenly get lots of credit. We see the enormous burst, and it is REALLY not nice if you don't have a pacer to fix it (or figure out the receiver should have sent the credit earlier).
NAME in the recovery draft covers the general case of an under-utilized cwnd, which applies here. The same bursting can happen with a bursty app as well, but we've said it all in one place -- in that section of the recovery draft. I think that section could use some editing work (which I'll take on separately), but we've already said there that it applies to flow control. I think that ought to cover the pacing concern.


A reviewer pointed out that we used notifying, informing, signalling, and alerting to mean the same thing: sending the Captive Portal Signal. I've chosen to use signal as the verb of choice. The phrasing seems a bit awkward in a few places, so I'm not 100% confident in my choice here.
Alvaro writes, Let's make this consistent across the entire document. Doesn't have to be alert, but should be consistent.
Are we using User Equipment of end-user device?


Use RFC references
Maybe use generic language, like "signing oracle" :)
ooh, naming things is so difficult :) Maybe "remote certificate signing offload"?
Please double-check. At least one of these appears to be wrong.
were you looking at the editor copy perhaps, does the latest draft appear wrong as well? URL i think the editor copy went out of sync
Ahh. I was seeing Richard as being out of date. I was also wondering if NAME wanted to consider affiliation adjustment also.
NAME Should we update your affiliation to Mozilla here?
Request an extension point from the IANA experts and add it to the document.
shipit. As these are all editorial changes, I don't think we need a long discussion.


LGTM
lgtm
The question has come up about what the default candidate should be set to during trickle ICE but after at least one candidate has been gathered so at least in principle you could set c= to one of those candidates. See also; URL
Want to pick a solution that works even if we we do continous trickle and ice does not finish.
Consensus on today's call is: Before ICE is completed, follow the 5245 guidance and pick the "best" candidate. Once ICE is completed, pick whatever you are actually using.
If we move to a mode where ICE never completes, perhaps use the active pair.
It turns out that this was pretty clear already. I have made it slightly clearer.


If we're using an IP as an identifier, dual stack can add complexity. Mention this.
Raised during review that dual-stack is a use-case worth calling out explicitly. Some suggested text: "Further attention should be paid to a device using dual-stack [rfc4213]: it could have both an IPv4 and an IPv6 address at the same time. There could be no properties in common between the two addresses, meaning that some form of mapping solution could be required to form a single identity from the two address."


This provides more detail on how to implement Clone with TCP, and clarifies that SCTP's "Initiate" should not yield a stream of an already existing SCTP Association in case "activeReadBeforeSend" is Preferred or Required.
Currently the "Clone" part of, e.g., TCP (section 10.1) only says: "Calling Clone on a TCP Connection creates a new Connection with equivalent parameters. The two Connections are otherwise independent." This text should reflect that equivalent behavior must be maintained upon later Connection configuration calls. And, there should be more text in general on cloning (see issue ).
This text must refer to a new "do I want a Connection that supports initiate followed by listen?" property. This property will be added to address - so I'll address this issue when the PR addressing has landed.
Added a question for NAME


Fix issue
In section 3.1, we wrote When the multipath option is negotiated, clients that want to use an additional path MUST first initiate the Address Validation procedure with PATHCHALLENGE and PATHRESPONSE frames described in of ]. After receiving packets from the client on the new paths, the servers MAY in turn attempt to validate these paths using the same mechanisms. With multipath, we cannot simply write that the server MAY validate the new path. There is a risk of a malicious client that operates as follows: client creates path from its own address, A. Path is validate by server client starts long download from server client creates a second path to server using a spoofed address, B client starts address validation for B but does not care about the response from the server client stops acknowledging packets over the first path to force the server to move packets to the second one and then opportunistically acknowledges packets that should have been sent by the server over that second packet (SPNS would probably make such an attack simpler than MPNS) We probably need to start working on the security considerations section of the draft.
This is already covered in the QUIC threat model. The server is supposed to validate new paths by sending a "path challenge" on that path, then waiting for a challenge response. If the client spoofs a path, it will never receive the challenge, and thus the server will never receive the response and will not validate the path. See section 8.2 of RFC 9000, path validation. Security section 21.1.3. Connection Migration states that "Path validation () establishes that a peer is both willing and able to receive packets sent on a particular path."
So yes, the current text should be "the servers MUST in turn attempt to validate these paths using the same mechanisms, as specified in {{ Section 8.2 of RFC9000 }}."
No, this should not be a MUST. It is true that the path MUST be validated before it can be used. However, just because the serve receives a new packet on a path, that doesn't automatically mean that the server has to start path validation. It could e.g. also decide to simply withdraw that packet.
Actually, this is also not right. This is what RFC9000 says (section 9): So I guess we should maybe not use normative language here but refer to section 9 in RFC9000 instead...?
Just submitted PR for this issue.


SORRY I made a PR on your PR, when I meant to leave a review comment, see 1024. .... Silly to make a PR on a PR - I added a review comment instead...
In section 4.1.4 in the impl draft, we have: "The order of operations for branching, where lower numbers are acted upon first, should be: Alternate Paths Protocol Options Derived Endpoints" However, I would say there is not really a strict ordering required. The text actually indicates that selection of the protocol is rather independent while there is usually a dependency between the interface and derived endpoint. I think this is related to my other issue about the use of the term path, because a path consists of both the local and remote endpoint and therefore there is of course a dependency. So in summary I'm not sure how useful I find this whole section as currently written...
We should conclude if anything more is needed here besides cleaning up the terminology, where Alternate Paths is not a good term - see .
Any implementation should have a consistent order of operations. This is a recommended example. Reference the arch text that says it needs to work the same way each time.
Reference ICE/HE


This rewrites the context-free URI section to give more context. It also moves the section out from underneath the example identifiers section, and into a proper sub-section of the top level "User Equipment Identity" section. Closes issue
NAME , I mostly took your text word-for-word. Thanks for it!
A reviewer writes, I think this is trying to say the server should not be looking at Ethernet addresses, for example, because the server is probably not on the same subnet as the User Equipment. So the info needs to be in the URL. Figure out what we're trying to say, and whether this is the right section for it.
That's exactly what it's talking about. That said, while it is related to identifying the UE, it's not an example identifier. It has been a while since I thought about this, and I wasn't at the meeting where it was discussed, but I think the intention here was to limit any URIs provide in the API to these context-free URIs. That is, the resource pointed to by the URI cannot depend on information not present in the URI. For example, the API draft (URL) provides a 'user-portal-url'. Suppose that URL is "captive-URL". That resource could be implemented by checking the source ethernet address of the connection to see if you're already logged in. But, that won't be correct if you're not in the same subnet. Instead, the URL should be something like: "captive-URL" So, this is more of a constraint on the API and how it uses identifiers than an example of an identifier. Did we just get the indentation wrong? Or was this a misunderstanding of what the working group requested?
Maybe all this needs is a preface explaining how some systems operate. The last two paragraphs are a direct copy of existing text.
Hardly surprising that I think this is OK :)


Would be nice if someone has time to do some ascii art :-)
Wouldn't that be fig. 4 in the architecture draft? Except that, looking at this now, I see inconsistencies! E.g., I don't see "RendezvousDone" in the figure. Also, instead of ConnectionReceived, it says "Connection Received" - rather, this should probably marked as an event by writing it as "ConnectionReceived<>". The figure is also missing InitiateWithSend() ... probably it would be good to make this figure both complete and consistent with section 13, "Connection State and Ordering of Operations and Events", of the API draft? I don't think very much is missing there.
I think it would be nice to have a real state diagram here, probably with states like "closed", "open" and "listen" and the events that create a transition between these state.
I'm not sure that Figure 4 in the Arch diagram serves the purpose that Mirja's trying to address with the state diagram in API. I also don't think we need FIgure 4 to align with the specific naming and CamelCasingConventions in API.
Thanks! I guess you could add a loop for sent<> and received<> in established state but maybe that also too much.Works for me


People shout at me for doing this, so I'm paying it forward. Perhaps you could move the SHOULD requirement to a statement in Section 3, so that it covers all forms of the CONNECT-UDP request.


We have decided to moved the compressed elliptic curve representations to an external draft since the issue is equally applicable to regular TLS/DTLS and does not need to be cTLS specific.
NAME It looks like you need to run .
It seems that we have consensus to move compressed representations into new IANA codepoints, rather than try to reuse the existing codepoints with a template-driven encoding. That would make the question of compressed representations orthogonal to cTLS, so this topic can be removed from the draft.
Fixed by


See also . Ref: URL Fixes URL
To be honest I also considered a comment along the lines of "couldn't we just say 'standard Boolean math'?" But (another little -used math degree here) I found it pleasing and, on reflection, possibly beneficial for an implementor.
Among other things, it dawns on me that if I were implementing, I'd copy-paste all those lines into a unit test.
The proposed operator precedence in the draft is shown below. Precedence Syntax -- -- 5 (...) 4 ! 3 ==, !=,, >=,=~ 2 && 1 It is assumed that these precedences are motivated by existing languages, but it is also noted that operator precedence is different in different languages such as JavaScript and Python. For example, logical not has low precedence in Python but high precedence in JavaScript and C. The less than/greater than operators have higher precedence than the equality operators in JavaScript and C, but the same precedence in Python. Existing JSONPath implementations that follow these languages for evaluating filter expressions will also have these differences. This issue, created by request, collects the comparable operator precedences for Python, JavaScript, Perl, C And XPath 3.1, to illustrate where they're similar to the draft, and where they differ. Perl is included because of these languages, it is the only one that has a operator. Note that in Perl, the precedence of the operator is higher than the comparison operators. One comment: the draft operator precedence table should include an additional column for associativity, which is needed to fully describe the operator. The unary logical not operator should be shown as "right associative", and the binary operators should be shown as "left associative". Precedence Associativity -- -- 7n/a 6left to right 5right to left 4left to right 3left to right 2left to right 1left to right Source: Precedence Associativity -- -- 9left 8left 7chained 6chain na 5left 4left 3right 2left 1left Source: Remarks: Unary "not" is equivalent to "!" except for lower precedence.


Binary "and" and "or" are equivalent to && and except lower precedence Precedence Associativity -- -- 6Left to right 5Right to left 4Left to right 3Left to right 2Left to right 1Left to right Source: Precedence Syntax -- -- 8() 7x[index:index] 6x[index] 5x.attribute 4in, not in, is, is not, , >=,<>, !=, == 3not x 2and 1or Source: Precedence Associativity -- -- 3NA 2Either 1Either Source: Remarks: XPath 3.1 and XQuery don't have a logical not operator, there's a operator, but it's a binary operator that means something different. Instead, XPath 3.1 and XQuery provide the function , whose precedence rules follow the rules for functions.
Since logical NOT binds more tightly than logical AND which binds more tightly than logical OR in all but one of the above tables and since we don't support comparison of predicates, I'm finding it hard to think of a case where the semantics differ between these tables. Can anyone provide such an example?
Which one? They're all the same.
One might ask the question, if one were interested in these things, why is the draft precedence ordering slightly different from all of Python, C, JavaScript and Perl? Why not make it the same as at least one of them? There is no difference in implementation effort.
I think we are still decoding this statement. Where is the difference?
The draft relational and equality/inequality operators are grouped together, like Python, but unlike C, JavaScript, and Perl. The draft logical not binds high, like C and JavaScript, but unlike Python. (Perl being Perl has two logical nots, one that binds high and one that binds low, but are otherwise equivalent.)
Logical NOT is missing from the XPath 3.1 table.
XPath 3.1 and XQuery don't have a logical not operator. Instead, they provide the function , whose precedence rules follow the rules for functions (not shown in my table.)
It may also be interesting to compare with the . In , like XPath 3.1, Boolean 'NOT' is a , not an operator.
We could at least document the associativity.


After discussion, is there anything that needs to be changed in the draft aside from adding associativity specification?
LGTM


This ended up in more text that I thought. I'm not certain if we need all of it. Further I'm unsure about the concrete wording in many cases, so any comments are more than welcome!
This is supposed to address issue
I do mentioned name resolution, however, leakage though DNS might rather be a DNS problem and not necessarily an issue that needs to be considered in taps. Sharing cache state is a good point. I vaguely remember that we already address that somewhere else (could also be in the implementation draft as this is rather an implementation issue). But maybe we can add a pointer...?
Leakage though DNS may need to be addressed by TAPS, as with the current sockets API, the application has complete control about when DNS resolution is done (and, at least as long as things like DoH/DoT are predominantly implemented by nonsystem resolver libraries, how). TAPS as envisioned gives the system more control over resolution.
(IIRC the architecture does explicitly address and mention the shared cache issue; adding a line to refer to that in privacy considerations might be nice but isn't IMO necessary.)
Gorry, I addressed all your nits/comments.
I think it is a good start, but I miss two aspects: Information leakage through DNS, which can also make addresses on different paths linkable Information leakage within an application though shared caches, e.g., within a browser. I agree this is a good starting point; note that I took the liberty to directly fix some nits (such as capitalizing TAPS) and typos; these never change the intended meaning.


Section 7.6.1: The RECOMMENDED value for kPersistentCongestionThreshold is 3, which is approximately equivalent to two TLPs before an RTO in TCP. Any values that needs to be explicitly forbidden? For example does it need a sentence saying that it MUST be larger than X? I would think that 1 would be to low and allow slow start after just one RTT+variations? I understand that likely would give the application bad behavior but likely also have negative impact on other applications if the QUIC stack ends up doing slow start crashing into the wall and then slow starting again?
I lean towards not being overly proscriptive here. We could elaborate on the pros and cons of smaller and larger values if you think that is necessary? Exponential backoff is clearly critical, but it's less clear to me that the CWND really needs to be collapsed in these situations.
I am really just trying to asses if there are significant risks with any specific ranges of values. For example causing very bursty behavior that could be considered harmful or becoming extremely aggressive after a persistent congestion event, in those cases some text may be necessary.
Based on , labeling this as "editorial"
Thinks this resolve my issue, but would prefer Ian's proposal.


In Section 7.4.1 "Pre-Authorization" the spec says: If a CA wishes to allow pre-authorization within ACME, it can offer a "new authorization" resource in its directory by adding the field "newAuthz" with a URL for the new authorization resource. That text indicates that the CA may wish to not support pre-authorization in which case the "newAuthz" resource will not be present in the directory. One example of an ACME CA choosing to not support pre-authorization is Let's Encrypt. This commit clarifies the "newAuthz" field of the directory is optional in Section 7.1.1 "Directory" where a developer is likely to look to understand which resources must be supported/present in the directory and which are optional ("meta", "newAuthz"). If the server doesn't support pre-authorization it MUST omit the "newAuthz" field.


In addition to adding the error, as proposed in , this PR fixes some issues discussed in the F2F meeting, namely moving ACME URNs under the IETF parameters space, and having errors be a sub-namespace of an overall ACME namespace.


This paragraph is redundant with the previous paragraph, however, not sure I removed the right one now...


On Tuesday, October 11, 2016 08:14:32 pm Martin Thomson wrote: or missing_extension
I think that missingextension would be OK, but we would hit the lower-level decodeerror first, since HRR is defined with:


The publicly verifiable basic token issuance protocol doesn't include an origin name that the issuer can see, so it does allow origins to be able to use that issuer (as long as the know the key) without explicit coordination or permission from the issuer. This isn't necessarily a problem, but we should likely mention it.


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)


Technically design, but barely.
Originally posted by NAME in URL There are three reasonable places to blow up: When you decide to stop reading a critical stream (i.e. when STOPSENDING is sent) When you discover the peer has stopped reading a critical stream (i.e. when STOPSENDING is received) When you discover the peer has closed a critical stream (when RESETSTREAM or FIN is received) My inclination would be to advise against FIN/SS/R_S on a critical stream and mandate connection termination on receipt of any of them.
Completely agree. This seems like the simplest and most obvious solution.
SGTM mike
Note that this PR does NOT address , just a comment that came up there.
Re-reading this, I think the existing text is pretty good; it just needs a little reframing. The existing requirement is to error out "If the control stream is closed at any point," without reference to whether it was closed because the peer send a FIN/RESET on their control stream or you obeyed a STOP_SENDING on yours. I think I'll add a requirement not to request closure of a control stream; do you think we need more elucidation here?
nits, but LGTM


this is a little longer than I had hoped given that bootstrap deadlock is not a new problem for dns introduced by doh.. but the https validaton angle is worth mentioning.
If DOH uses https under the hood, how does this https host name get resolved? I would have expected this to be mentioned in the RFC, though I didn't see any mention of it, besides OCSP Stapling. Is it assumed that DOH would need to be bootstrapped by traditional DNS? Or is it assumed that a DOH endpoint would have a TLS/SSL certificate for its ip address? (Apparently a certificate for an IP address is possible in some cases, though hard to get.) I assume DOH is not intended to be used by home NAT routers? (How would the router get a signed TLS certificate? Maybe a DHCP response could say: use this DOH url and trust this self-signed cert for its ip address (though a certificate might be too big for a DHCP response). Or, in cases where no local DNS services are needed, the DHCP response could maybe say: use this public DOH url, here's the ip address for that hostname)
The document doesn't describe how a HTTPS client authenticates HTTPS... that's on purpose in order to simply leverage HTTPS without surprises. as a practical matter a number of things can be done. One is TOFU as you suggest. Another is an IP based certificate which you also suggest. Another would be to lookup the name via another, perhaps less trusted resolver, knowing that HTTPS means the IP address isn't part of the security scheme anyhow - its just a route.. subject to blocking, but not to impersonation. Another would be to bootstrap the client with a name and an address instead of one or the other. but as a general matter I think this is one step beyond the scope of the document as its basically writing down the rules for HTTPS.
This issue semi-duplicates
I think this should at least be called out as an operational concern. e.g. mentioning that you probably need an alternate resolver to find the DOH server, after which a paranoid implementation can re-query for the DOH's address as an integrity check.
This is the direction I have taken for .


When opening a connection to the remote DOH server, if an ip was provided, it will just use that, if not, it will try to resolve using the local stub, but that may not work.... Just like an IP has always been provided to bootstrap which nameserver to use, here we need to also be provided a name so we can validate that the server we are talking to is the one we trust.


Throughout the document the term "trust anchor" is meant in the to be a public key and associated (meta)data. This definition does not cover attestation schemes based on symmetric crypto, e.g., , and Arm PSA, and should be extended to also cover such cases.
Was there specific text that you believe needs to be changed?
yes, we identified at least two places: §7.1 and §12.4.
Reads great to me. Any other opinions?


I think this helps?
Magnus Nystrom : scenario of "mutual distrustful parties" is unclear to me. One stated scenario is where multiple client connections aggregate at an intermediary that then maintains a single connection to an origin server. Another stated scenario is where multiple origin servers connect to an intermediary which then serves a client. In these scenarios, is the concern that the intermediary may control either a client or an origin server and thus would be able to leverage the compression context at, say, a second client and then observe (as the intermediary) the result of a guess for a field tuple? It may be helpful to explain this in a little more detail. as to what strategy (option) implementations should choose to protect against this attack. It seems like the Never-Indexed-Literal is a good candidate which should be easy to implement.
This text was mostly lifted from RFC 7541. intermediary may control either a client or an origin server and thus would be able to leverage the compression context at, say, a second client and then observe (as the intermediary) the result of a guess for a field tuple? Yes, this is the concern. It's interesting that 'intermediary' here also refers to a browser that coalesces requests from different tabs onto the same connection. I agree. as to what strategy (option) implementations should choose to protect against this attack. I think the document recommends the tagging option unambiguously: "An ideal solution segregates access to the dynamic table based on the entity that is constructing the message" While never-index literals is the less complicated fallback option.
NAME so are you proposing any changes to the text?


NAME done; see change. P.S. GitHub lets you make suggestions using the little +/- icon in the inline comment UX :)
Pulling this conversation out of : It's clear that there's demand for error codes scoped to the API, without creating documentation pages for each code and linking to them in the field. There are many ways that implementers could do this, from linking to non-existent URLs to URNs to tags URIs, etc. It would be useful if the specification included examples of this, and made a clear recommendation for this case.
We (well, mostly NAME have made some good progress on the other issues raised out of but we haven't looked at this one yet. As strawman to get this moving, how about: we register a URN namespace id, and we recommend that non-dereferenceable URIs should be URNs using that, namespaced with an appropriate domain and raw type id, for example: . Would that work? It would give us a clear solution to recommend, which is explicit but easy to read, with minimal extra complexity or overhead for implementers (imo). I don't have examples, but I suspect there are other standards elsewhere that would appreciate having a problem id namespace for URNs as well. I don't love using a domain for namespacing a non-locator, but I think some namespacing is preferable, and I'm not sure what other namespaces would be suitable. Alternatives very welcome :smile:
We penciled in the URI prefix for registered types as "URL" in , but that was not finalised. I think registering one or more problems as exemplars is a good path forward for this and other issues (e.g., as discussed in ). We need to be very careful to set a good example in them, which means we need good candidates; I'm thinking 'JSON Validation Error' and 'XML Validation Error' might be appropriate (perhaps along with corresponding wellformedness errors). If we choose a urn, I suspect there will be considerable pressure to use or something similar, as per .
my understanding of the "urn:ietf:params" namespace is that it is meant to be used for parameters managed/defined by IETF specs. i think the original's suggestion intent was to have a "safe prefix" for a namespace which then would be "unmanaged" with some conventions around that, such as using domains names.


i think the idea of giving examples (and even a suggested namespace along with conventions for using it) is a good one. that way we can clearly support both scenarios: if you're planning on making documentation available, use a resolvable URI but keep in mind that this best should be managed in a way so that it works for a good number of years. if you're planning on just identifying problem types, use a non-resolvable URI, and here's a recipe for doing it.
:+1: exactly I think is relevant in that it would be helpful to everybody if we can follow our own recommendations in our own problem id registry, but it's otherwise independent.
the difficulty may be that IETF has an institutional approach for managing parameters (urn:ietf:params:http-problems mentioned by NAME above), whereas most orgs minting problem types probably won't have one and won't create one. which may lead to us to saying three things about what kind of URI to use: check out common problem types registered under urn:ietf:params:http-problems and consider reusing one if it fits. use URIs when creating dereferencable problem type identifiers. when using non-dereferencable problem type identifiers be clear about that by using non-dereferencable URIs, and here's an URN-based recipe how to do that.
Ah, I see, ok. Yes, that makes sense, and given that the 3 part recommendation seems reasonable to me.
to be used for parameters managed/defined by IETF specs. No, it's for parameter name spaces managed by IETF documents -- which this would be. We could also give an example that uses a URI.
that's what i wanted to say. so these URIs/examples would just cover the common problem types that would be managed by the spec. which then would be for those other types that people/orgs are minting and where they say these are not resolvable, right? i think for those terry proposed a URN namespace instead of tag URIs, but either way it simply would help to state the use case ("your own types, not intended to be resolvable") and provide a recipe ("here's one way to do it").