jiebi/CodeConvo huggingface dataset:
Change:
version 1 uses version 0x00000001.  Operators should expect to observe packets with other version numbers as a result of various Internet experiments, future standards, and greasing (RFC7801). <del> All deployed versions are maintained in an IANA registry (see Section 22.2 of QUIC-TRANSPORT). </del> <ins> An IANA registry contains the values of all standardized versions of QUIC, and may contain some proprietary versions (see Section 22.2 of QUIC-TRANSPORT).  However, other versions of QUIC can be expected to be seen in the Internet at any given time. </ins> source and destination connection ID: short and long headers carry a destination connection ID, a variable-length field which, if not

Discussion:
Text as proposed by Lars on list.
I don't think it's correct to claim that "all deployed versions are maintained in an IANA registry" - many versions are being and have been deployed that are not in that IANA registry at all (see URL); there is a huge range for experimental versions.
This was discussed on the list and has a proposed resolution; PR to be submitted.
Also this was commented by Eric Vyncke as well:
Change:
these countermeasures could be insufficient if UDP-based services do not properly authorize requests. <ins> Because the migration attack described in request-forgery-with- spoofed-migration is quite powerful and does not have adequate countermeasures, QUIC server implementations should assume that attackers can cause them to generate arbitrary UDP payloads to arbitrary destinations.  QUIC servers SHOULD NOT be deployed in networks that also have inadequately secured UDP endpoints. Although it is not generally possible to ensure that clients are not co-located with vulnerable endpoints, this version of QUIC does not allow servers to migrate, thus preventing spoofed migration attacks on clients.  Any future extension which allows server migration MUST also define countermeasures for forgery attacks. </ins> 21.4.1. QUIC offers some opportunities for an attacker to influence or

Discussion:
I also think it might be worthwhile to move much of this section to security considerations, leaving only the requirements here. NAME WDYT?
This is already in the security considerations section, so we're good. Though it's hard to see, because the section is already so large.
I find Martin's argument that QUIC servers are able to control their topology well enough to prevent request forgery attacks somewhat persuasive. However: I think the document should be clearer that if you can't do this you can't deploy QUIC as a server. We should add text indicating that a candidate extension to allow migration by the client would need to deal with this (likely by adding one of the countermeasures we decided not to ass). This is a very long specification and otherwise the institutional knowledge about this issue is likely to be lost.
If people agree, I can provide PRs for these.
These sound like good additions that I would welcome. (I would write the PR, but I don't trust myself, I'd appreciate you providing text.)
Sounds like a good path forward.
Do you mean migration by the server?
I'm not clear on the grammar, but I mean "the server address changing"
FWIW, when we've talked about a server migration extension before, it was usually in the form of a frame that mimics the preferred_address TP, prompting the client to probe the new address and actually make the change. That approach seems like it limits the attacks to those already possible with SPA, though it broadens the window / number of attempts.
Could people take a look at the PR? Would like to move this along.
Thanks for writing this up. My only comment is that this is two points and therefore two paragraphs.
Change:
connection error of type FRAME_ENCODING_ERROR. An endpoint might receive multiple NEW_TOKEN frames that contain the <del> same token value.  Endpoints are responsible for discarding duplicate values, which might be used to link connection attempts; see validate-future. </del> <ins> same token value if packets containing the frame are incorrectly determined to be lost.  Endpoints are responsible for discarding duplicate values, which might be used to link connection attempts; see validate-future. </ins> Clients MUST NOT send NEW_TOKEN frames.  Servers MUST treat receipt of a NEW_TOKEN frame as a connection error of type

Discussion:
This is already implied by the existing text, but it isn't said directly. That is, we say that the values can't be linkable, which is a stronger requirement. Saying that you can't send the same value on two connections is much clearer.
This text does not forbid the server from sending the same token on multiple connections. Consequently the client has a hard, or impossible, task of excluding duplicates. At least if you only read that section. Later the text says: >The token MUST NOT include information that would allow it to be linked by an on-path observer to the connection on which it was issued. This suggests that the token MUST indeed be unique, but in a roundabout manner. It would be helpful to make the initial paragraph clearer by stating the that the duplicate token can only happen on the same connection and that the server MUST ensure different connections use different tokens.
A nit, but looks good, thanks for working patiently!
Change:
dispose of pooled tickets after some reasonable amount of time that mimics the ticket rotation period. <ins> In some cases, a server may send NewSessionTicket messages immediately upon sending the server Finished message rather than waiting for the client Finished.  If the server has not verified the client's ownership of its IP address, e.g., with the TLS Cookie extension (see RFC8446; Section 4.2.2), an attacker may take advantage of this behavior to create an amplification attack proportional to the count value toward a target by performing a key exchange over UDP with spoofed packets.  Servers SHOULD limit the number of NewSessionTicket messages they send until they have verified the client's ownership of its IP address. </ins> Servers that do not enforce a limit on the number of NewSessionTicket messages sent in response to a "ticket_request" extension could leave themselves open to DoS attacks, especially if ticket creation is

Discussion:
Adding the text proposed in the email
Unless I am missing something, I believe that checking the IP address may be useful to filter packets that are outside the key exchange, but I do not see this as a counter measure to the amplification attack. With a single round trip, unless i am missing something, I do not see how the server can verify the Client's IP address. It receives the ClientHello responds with the ServerHello..Finished,NewSessionTickets. In other cases, the server received from the given IP address the ClientHello and the client Finished which I think proves that IP receives the the ServerHello and responds to it. Yours, Daniel
TLS has a cookie extension for this purpose, for example.
Thanks, looks good to me. Yours, Daniel
I agree with the change below and updated the text. OLD: Server should limit the number of NewSessionTicket messages sent in response to a "ticket_request" should be based on the applicability and the amplification factor of such attack. NEW Servers SHOULD limit the number of NewSessionTicket messages they send until they have verified the client's ownership of its IP address.
Great! We're just waiting on NAME
Approved pending Chris' last suggestion
Change:
solely with the IESG and is subject to the normal review and appeals process associated with the RFC process. <del> 3.4. </del> <ins> 2.4. </ins> The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix: the extended date/time format is described by the rule "date-time-ext". <del> 3.5. </del> <ins> 2.5. </ins> Here are some examples of Internet extended date/time format.

Discussion:
The current draft does not say what it actually means when a timezone name is added to a timestamp. Is the combination of the timezone name and the timezone offset an assertion that the offset was correct for the named timezone at the time? What if that assertion is not true? What about future times? Does the timezone name take precedence over the offset given (i.e., the timestamp changes its meaning with political decisions) or does the offset win?
(From the SEDATE meeting: "encode the intention"?)
(From the SEDATE meeting: "don't encode the timezone if that is not the overriding information".) One use case is documenting the time zone name, though.
We now have a clarified scope ( as published in -02). This makes the underlying issue out of scope -- the RFC 3339 semantics prevail. Discuss.
essentially is the continuation of this issue with a revised question. The resolution of the question in this PR remains in place.
As a description of one path forward, this is good - and it's sufficient for the proposal that I made. Good threading of the potential needle here.
Change:
4.3.3. A sender can use the Block-wise Transfer elective Option to indicate <del> that it supports the block-wise transfer protocol I-D.ietf-core- block. </del> <ins> that it supports the block-wise transfer protocol RFC7959. </ins> If the option is not given, the peer has no information about whether block-wise transfers are supported by the sender or not.  An

Discussion:
There's no longer an informative reference to this expired draft. Originally, it was included in the Introduction of draft-savolainen-core-coap-websockets-07.
Change:
Encoding considerations: Must be encoded as using W3C.REC-exi- 20140211.  See RFC-AAAA for details. <del> Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information.  This format does not provide any security and instead relies on the transport protocol that carries it to provide security.  Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. </del> <ins> Security considerations: See sec-sec of RFC-AAAA. </ins> Interoperability considerations: Applications should ignore any XML tags or attributes that they do not understand.  This allows

Discussion:
Alternatively we can have the same text 9 times instead of 8
Alexey confirmed in the CoRE session that this is OK, so let's go forward with this.
The IANA types review list explicitly wanted all of this repeated because they don't read the draft on the email and each type needs it's own email. It is insane. So I would not make this change. LGTM
Change:
formats.  Specifically, begin or continue sending the requested feedback types and reacting to received feedback, as specified in RFC4585, Section 4.2.  When sending RTCP feedback, follow <del> the rules and recommendations from I-D.ietf-avtcore-rtp-multi- stream, Section 5.4.1 to select which SSRC to use. </del> <ins> the rules and recommendations from RFC8108, Section 5.4.1 to select which SSRC to use. </ins> If the directional attribute in the answer indicates that the JSEP implementation should not be sending media ("recvonly" for

Discussion:
I don't know why build of ghpages is failing travis. It works for me on my machine so going to ignore this for a bit.
Here is the diff of the change.
BLOCKER: The nits tool reports (and a cursory hand check supports this) that six of the references are unused, and RFC4572 has been (recently) obsoleted. The remaining references are largely out of date by many versions, which I believe the current tools will automatically handle if version numbers are simply pulled out of the source. Finally, a large number of the referenced working group documents still use the individual name (e.g., draft-nandakumar-rtcweb-sdp instead of draft-ietf-rtcweb-sdp).
Need to verify section numbers when these refs change, but otherwise seems fine.
LGTMLG, assuming this generates the equivalent text.
Change:
therefore allow clients to detect and recover from this situation (see esni-resolution for more details). <del> Servers operating in Split Mode SHOULD have DNS configured to return the same A (or AAAA) record for all ESNI-enabled servers they service.  This yields an anonymity set of cardinality equal to the number of ESNI-enabled server domains supported by a given client- facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client- facing server can guess the correct SNI with probability at least 1/ K, where K is the size of this ESNI-enabled server anonymity set. This probability may be increased via traffic analysis or other mechanisms. </del> <ins> Content providers operating in Split Mode SHOULD ensure that the A and AAAA records for ESNI-enabled server names do not allow identifying the server name from the IP address.  This can for example be achieved by always returning the same records for all ESNI-enabled names, or by having the function that picks addresses from a pool not depend on the server name.  This yields an anonymity set of cardinality equal to the number of ESNI-enabled server domains supported by a given client-facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client-facing server can guess the correct SNI with probability at least 1/K, where K is the size of this ESNI- enabled server anonymity set.  This probability may be increased via traffic analysis or other mechanisms. </ins> The following sections describe a DNS record format that achieve these goals.

Discussion:
The current text about anonymity sets for records is too restrictive. If I have 100000 names and 100 IPs and for all queries I randomly return four out of my 100 IPs chosen randomly, I still provide the same anonymity set but I violate the SHOULD. The proposed text
The document currently states: I think this is too restrictive. If I have 100000 names and 100 IPs and for all queries I randomly return four out of my 100 IPs chosen randomly, I still provide the same anonymity set but I violate the SHOULD. How about:
Agreed. At a minimum this should reference a set of A and AAAA records rather than "the record" (as many records across the A and AAAA rrsets is very common). I think NAME proposed text is fine.
NAME sgtm, do you plan to open a PR? I made URL but I think your wording is better.
Created
LGTM -- thanks!
Change:
2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710.  The CAPPORT architecture </del> <ins> Advertisements is described in RFC7710bis.  The CAPPORT architecture </ins> expects this URI to indicate the API described in section_api. Although it is not clear from RFC7710 what protocol should be

Discussion:
Note that this leaves this paragraph intact: That paragraph probably needs to go based on what is in 7710bis now.
And remove some of the stuff that is speculative from SS2.2.1.
Change:
The DNS API client SHOULD include an HTTP "Accept" request header to indicate what type of content can be understood in response. Irrespective of the value of the Accept request header, the client <del> MUST be prepared to process "application/dns-udpwireformat" (See dnswire) responses but MAY also process any other type it receives. </del> <ins> MUST be prepared to process "message/dns" (as described in dnswire) responses but MAY also process any other type it receives. </ins> In order to maximize cache friendliness, DNS API clients using media <del> formats that include DNS ID, such as application/dns-udpwireformat, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as application/dns-udpwireformat.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </del> <ins> formats that include DNS ID, such as message/dns, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as message/ dns.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </ins> DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them.

Discussion:
The media type has been the subject of some debate. The above might be the best I've seen.
Change:
4.1. <del> The media type is "application/dns-udpwireformat". </del> The data payload is the DNS on-the-wire format defined in RFC1035. <ins> The format is for DNS over UDP.  (Note that this is different than the wire format used in RFC7858. </ins> When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query

Discussion:
Make clear here that it doesn't intrinsically come with a content-length limit, despite traditional DNS message length limits?
I merged this in a race condition with NAME 's comments. I support that change, but its a little different than the bug that drove this. NAME can you just make the change directly and minimally in this same text?
it could use a preview to help the reader orient herself
See
Change:
This section describes how the registering endpoint can maintain the registrations that it created.  The registering endpoint can be the <del> registrant-ep or the CT.  An endpoint SHOULD NOT use this interface for registrations that it did not create.  The registrations are resources of the RD. </del> <ins> registrant-ep or the CT.  The registrations are resources of the RD. An endpoint should not use this interface for registrations that it did not create.  This is usually enforced by security policies, which in general require equivalent credentials for creation of and operations on a registration. </ins> After the initial registration, the registering endpoint retains the returned location of the Registration Resource for further

Discussion:
It appears I've missed some of Alexey's remarks responding to the changes made after his initial review (, 2019-11-20). This contains fixes for the points he still wanted changed / suggested after my original response to his review.
Change:
explicitly allow for integers encoded with leading zeros. [CREF11] JLS: Should we register both or just the cose+cbor one? <ins> [CREF12] JLS: Should we create the equivalent of the smime-type parameter to identify the inner content type? </ins>

Discussion:
Create IANA considerations for: 1) key and keyset CBOR tags 2) COAP Content Format registrations
Change:
Intra-data-center communication.  Machine-to-machine communication within a single data center or PoP may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections <del> with early data. </del> <ins> with early data; see security-con for considerations when using early data with external PSKs. </ins> Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs,

Discussion:
While trying to find a home for this text, I did some other unrelated cleanup. I couldn't find a spot better than the security considerations. cc NAME
Slightly different placement than I suggested, but it works too.
From NAME This is a great point. We can add some language which describes considerations for external PSK reuse with early data.
Martin: I think we should add: When early data is used with an external PSK, the random value in the ClientHello is the only source of entropy that makes the keying material for the early data associated with one session different from the keying material for the early data associated win another session. As a result, when the external PSK is used more than one time, the random number source on the client has a significant role in the protection of the early data. However, this does not address the last point. Early data always has replay concerns. This was discussed at length during the development of RFC 8446. This is the reason that RFC 8446 says that clients "MUST only send early data which they deem safe to be replayed." With that warning in RFC 8446, what more needs to be said here?
Not sure what you mean regarding the last point, but this is a good contribution. How about (copy editing only):
That reads pretty well to me. Thanks, NAME
MT's text also looks good to me. I'm not sure I understand the (as-yet-unaddressed) point about anti-replay performance, though. I mean, I can parse it -- it's a claim that (some? all?) anti-replay implementations will incur more runtime cost than in scenarios where the PSK is reused and the random data is "not good enough". But how would that come to happen? Are we imagining an implementation that uses a hash table and inputs the client random as the hash input, and "not good enough" randomness would cause unbalanced hashing? Or is the nature of the concern on a totally different axis?
Yeah, I think that we can let that point lie. The NSS anti-replay implementation is somewhat vulnerable to hash stacking, but the effect is that early data is accepted less often, it's not that server CPU cycles are wasted.
Change:
if one exists This registry will be initially populated by the values in table- <del> ec1-keys, table-ec2-keys, table-rsa-keys, and table-symmetric-keys. The specification column for all of these entries will be this document. </del> <ins> ec2-keys, table-rsa-keys, and table-symmetric-keys.  The specification column for all of these entries will be this document. </ins> 15.7.

Discussion:
The CFRG EC algorithms are currently too far in the future to keep. Remove the ad put in the to be done later document.
Change:
cipher suite adds additional constraints on signature algorithms. server-certificate-selection describes the appropriate rules. <del> rsa_pkcs1_sha1 and dsa_sha1 SHOULD NOT be offered.  Clients offering these values for backwards compatibility MUST list them as the lowest priority (listed after all other algorithms in the </del> <ins> rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list them as the lowest priority (listed after all other algorithms in the </ins> supported_signature_algorithms vector).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection).

Discussion:
I'm going to see about getting rid of it anyway, but I think, for the spec, this is probably the better text, as sad as it makes me. The revised signature algorithm mechanism left the {sha1, ecdsa} SignatureAndHashAlgorithm without a corresponding SignatureScheme defined at all. SHA-1 does not have a corresponding curve, so defining it alongside ecdsap256sha256 and friends was a nuisance. But omitting it, combined with other text, implicitly means it "MUST NOT be offered or negotiated by any implementation". Clients (ideally) send only one ClientHello, so this implies a constraint on TLS 1.2 as well. SHA-1 needs to go, but I think I was a tad overzealous here. I wouldn't be surprised {sha1, ecdsa} can be removed from TLS 1.2 right now. Certainly it will be much much easier to remove than {sha1, rsa}. But this is probably better a SHOULD NOT rather than a MUST NOT. We wouldn't like to discover after the fact that a MUST NOT in TLS 1.3 is untenable due to some ecosystem problem. Notably, old versions of some popular server software ignore signature algorithms and only sign SHA-1. This mostly affects RSA since ECDSA isn't that common, but any such ECDSA deployments would be affected. This is also a little odd for servers as TLS 1.2 says missing sigalgs means the client is assumed to support {sha1, X}. (Although, strictly speaking, the spec does not say the server must do anything useful with that advertisement.) In contrast, dsasha1 is already not offered by many major browsers but is merely a SHOULD NOT. Define ecdsasha1RESERVED as a companion to dsa*RESERVED to bring it out of the implicit MUST NOT. Then include it in the SHOULD NOT lists alongside rsapkcs1sha1 and dsasha1.