jiebi/CodeConvo huggingface dataset:
From Ilari Liusvaara on the : From NAME on the :
Maybe also consider for identification. That's not perfect, because of the "none" thing, but it might be a better fit. The TLS schemes are generally OK provided that you only use the recommended ones (of which there aren't many).
I don't love JWA since , but using TLS SignatureScheme with a requirement to only use the recommended ones sounds good to me.
NAME Doesn't it define the algorithm and then define the subkey types and in ?
NAME that could be made to work though it's quite clunky since it requires a separate string parameter for "alg". Overall I think the is a much better fit for signatures here. We already tightly integrate with TLS but not JWA. All that said, the closest option for hashes is the and that's been orphaned by RFC 8447. At this point I guess we should bite the bullet and define a new registry. Perhaps we include as current values: hmac-sha256 hmac-sha384 hmac-sha512 signature-rsapkcs1sha256 signature-rsapkcs1sha384 signature-rsapkcs1sha512 signature-ecdsasecp256r1sha256 signature-ecdsasecp384r1sha384 signature-ecdsasecp521r1sha512 signature-rsapssrsaesha256 signature-rsapssrsaesha384 signature-rsapssrsaesha512 signature-rsapsspsssha256 signature-rsapsspsssha384 signature-rsapsspsssha512 signature-ed25519 signature-ed448 Of course this requires to paint the bikeshed one of two colors: HMAC and Signatures in the same registry, using a single new auth scheme Separate registries, using separate auth schemes Thoughts? At this point I suspect this issue will need WG discussion at IETF 116.
I had to implement rsapsspss_shaX algorithms to produce test vectors for DCs, and unless there's a really compelling reason to include them, I'd really rather not. They're just such a pain to use, and the support for them is very poor (thus me needing to implement them).
FWIW, adding an entry in the registry doesn't mean it'll be mandatory to implement so there's not much of a cost.
But I don't feel strongly about this one so I'm happy to not include it if it's the WG's preference.
Just saying here's a registry that you might could co-opt: URL Defined by URL
This is an existing registry of hash algorithms with string identifiers: URL Defined by URL
Discussed at IETF 116, sense of the room appeared to be that removing the HMAC feature entirely and switching to the TLS SignatureScheme registry for signatures was the simplest solution here.
OK wrote up to address this
Is there a technical reason why the header was not chosen for this draft? That can be sent without a corresponding challenge (in an unprompted way), as we note in the . It seems like that would work in this context, too.
Is this rather about using the Authorization header?
Yep!
NAME can you elaborate on "as we note in the "? I skimmed through that draft and it seems to clearly require a TokenChallenge before sending a Token.
I thought we had text that described it, but I can't find it. In any case, I think one can send the Authorization header unsolicited, so I think this draft ought to do that instead of rolling a new auth header.
Fair enough, let's discuss this at 116.
FWIW, I agree that unprompted "Authorization" is permissible in this context, but I think "Unprompted-Authorization" could be useful for clarity when reading logs, etc.
Discussed at IETF 116, sense of the room appeared to be that switching to Authorization made sense.
OK wrote up to address this
" For example, services that depend on individual user authentication often require a connection to be secured with TLS ("Transport Layer Security", [RFC8446]) prior to exchanging any credentials." This originates from RFC 7235. Nowaday, shouldn't we instead say "require HTTPS"?
I think it should be ... authentication require a secured connection prior to exchanging any credentials (ref target="URL"). and x:ref around the term "secured" (defined in that section).
In Section 8: Given that the exporter can be produced at any point in the lifetime of a TLS connection and that TLS connections can remain open for a very long time, it's not clear that this guarantees freshness in the same way that a nonce does. It might be clearer to state that it guarantees the authenticator is no older than the beginning of the current TLS connection. (I presume that a server can use GOAWAY to get rid of connections it considers unacceptably old.)
HTTP defines its own protocol versions as having two numbers "URL" regardless of anyone's future opinions on the subject. This is necessary for Via and Upgrade. In the past, it has always been assumed that no document claiming to define a version of HTTP would ignore that fact. Regardless, HTTP/1.1 needs to refer to future versions of HTTP within the scope of its own syntax. Hence, the following text (currently in crefs) has been suggested for the last paragraph of the section "Protocol Versioning" in Semantics.
SGTM
Why "ought to be used"? I understand that you want to avoid MUST/SHOULD,..., but why not just "is used"? That would make it:
+1, let's limit the RFC6919 language. You're defining a mapping between formats, not really adding new normative or moral requirements. The "0" is simply how a major-only version is rendered in a URL field.
The background here is that we used 'ought' liberally in 723x (e.g., 49 times in 7231) to give implementers guidance towards good behaviour without affecting conformance for existing deployments. So this is entirely in the spirit of the existing specifications.
That use is often appropriate. In this case, the conditions are such that "is" works. It is also more assertive, which works.
all: try and do your best to focus on the substance of the question rather than the editorial wrappings. Thanks.
The substance of the question is obvious, in my opinion. I'd question whether there's a need for discussion on that. However, the editorial wrappings do actually matter in having the final document communicate what we want it to communicate. It's feedback I'd typically give on a PR rather than the issue, but in this case the issue contains proposed text, so the editorial feedback is here too.
Agree with Mike. I came to this issue almost by chance, I thought it was important because Julian wrote a mail to the mailing list. When I had a look at the issue, the only thing that caught my eye was the "ought", because the substance is indeed obvious (at least to me). If "ought" is used liberally in 723x, there may be good reasons for it, and in many places it may make sense.
Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.
This is based on the long set of negotiated changes added to . This adds the blacklist as Sam Hartman proposed at IETF 91.
Section 9.2.2 places restrictions on the ciphers that are acceptable for a http/2 connection that are different to the acceptable ciphers for a https connection that may be offered over the same handshake. To comply with 9.2.2, as server accepting an ALPN connection must either: a) influence the cipher selection to ensure an acceptable h2 cipher is selected; b) be informed of the cipher selected and if it is not acceptable then select http/1.1 instead of h2 as the protocol. Neither of these capabilities are required of a RFC7301 compliant implementation. Specifically there is no requirement for an ALPN extension to be able to influence cipher selection, nor is there a requirement for an ALPN to make the cipher that will be selected available to the protocol selection.
Even if ALPN does allow arbitrary selection of cipher/protocol pair, it is impossible for a server to select an acceptable cipher/protocol pair because clients interpretations of 9.2.2 will vary over time and available ciphers. If a server selects a cipher/protocol pair that it believes is h2 acceptable, but the client disagrees, then communication failure results. Thus the moment there are different interpretations of 9.2.2 in the client population it will be impossible for a single h2 server to accept connections from 100% of the population.
The server need only support the minimum requirements in 9.2.2 at the TLS layer, i.e. enable TLSECDHERSAWITHAES128GCM_SHA256 overall and make it a suitably high preference. If the 9.2.2 requirements are increased in the future, then that requires an ALPN bump too and thus it can be deployed without worry.
Note that I think discussion on this topic has moved beyond the specific concerns raised in this issue. This issue should probably be decomposed into: Should we be restricting TLS ciphers within the application protocol draft document The usage of the ALPN handshake is fragile as any differing interpretations of 9.2.2 against future ciphers can result in communication failure.
The ALPN RFC does not require that a ALPN implementation provide functionality needed to implement 9.2.2, specifically either to a) use protocol selection to influence the cipher selection; or b) be informed of the cipher selected to influence protocol selection.
Ideally, no, the HTTP/2 spec should not be setting TLS details. HTTP/2 should simply require TLS 1.3, or at least a 1.2.1 with the required improvements done in the relevant spec. This, however, requires a level of coordination between working groups that isn't currently available. This section is just a hack to make a TLS 1.2-h2 variant that's the best that's currently attainable. It's a transitional spec until TLS 1.3 is eventually complete some time in the indeterminate future, just as HTTP/2 is likely to be a transitional spec until HTTP/3 gets written. The cleanest route would be to cut out sections 9.2.1 & 9.2.2 and make a new TLS 1.2.1 spec that satisfies those requirements, then separately publish that and require its usage here. (though, you'd have to come up with some way to handle the minor version number; maybe implement TLS 1.2.1 entirely as an extension) It's probably too late in the HTTP/2 development process to do this, unfortunately, though it would be a cleaner spec with less fiddly bits that can break interoperability.
Discuss on-list, please.
Actually, it's about ethics in game journalism.
Consensus to adopt .
Addresses encodings of signature component values for query parameters and field values.
: This seems to be inconsistent with Section 2.2.8 ("Query Parameters"), which could create non-ASCII component values.
FWIW, a query parameter (after application of URL) could contain CR, LF and other control characters.
So we likely need to serialize information extracted from query parameters using some kind of encoding; maybe an SF Byte Sequence.
This is tricky -- originally the query parameters were kept in percent-encoded form but from WG discussion we changed that to just use the unencoded value instead since several percent-encoded forms could be used. However it does look like the unencoded form could end up with problematic values here, so maybe we need to go back to that. I'd rather us use an encoding native to the value rather than inventing something to put on top of it, even trying to re-use the flag we've already got defined for headers.
And we did that because to extract query parameter values, we need a query parser, and that is defined the way it is. I believe that decision was good, we now just need to figure out out to transform the extracted values so that they can be used in the signature base. (And, FWIW, at the end we also should have an example for a case like that in the spec).
In 2.2.8, it might be good to mention that the referenced algorithm only supports query parameters using (percent-escaped) UTF-8 encoding (this came as a surprise to me because I assumed it works the same as the algorithm used for forms decoding).
in 2.1.3: What if the field value contains non-ASCII characters (from obs-text)? Of course that could be considered an error, but I believe the intention is to be able to represent anything here. So the text should refer to the field value as byte sequence, in which case the encoding step would not be needed.
This text was added in response to a comment about needing to know which encoding to put into the byte sequence input, and the commenter suggested ASCII as the base for it. If field values have a well-defined byte sequence that isn't ASCII characters only, then we should refer to whatever that is from the HTTP docs.
Well, field values in HTTP can be anything. It's obsolete, it's deprecated, but that's what it is.
So we need to deal with it one way or another. I could live with UTF-8, and a note that if the octet sequence does not decode as UTF-8, you can't sign it.
NAME - yes, you can merge and close issues as you wish, you are the editor. But by all means do not submit a new draft until the changes have been reviewed by those who opened the issue. (cc chairs NAME NAME )
As far as I can tell, the changes require percent-encoding only for non-ASCII values. That is, the character U+0080 would get the same encoding as a verbatim "%80" in a field value. I believe this is a problem.
This issue has been addressed. There is no percent encoding needed in this section since the value is taken directly from the bytes of the field in a binary-wrapped representation, and the bytes are encoded using the base64 serialization of a Byte Sequence from Structured Fields:
I'm talking about the simple case, not the one where Byte Sequence encoding is used (yes, the issue title doesn't match anymore).
Ok, opened new issue URL
For .
NAME it didn't so much introduce it as much as it just changed the nature of the example.
Well, before the term "timing attack" did not appear in the spec...
... needs a rewrite. I'm thinking of splitting up into distinct sections, e.g., Cache Poisoning Timing Attacks Caching of Sensitive Information Information Leakage ... with appropriate mitigations in each (e.g., double keying).
This also adds "Timing Attacks", right. Updated change log as well.
That needs some tweaks ... the action words like SHOULD are supposed to be targeted to implementation roles, not protocol extensions. Can we just copy the same Note from the Accept section?
I can avoid the SHOULD NOT. I used different text because for transfer codings "we" actually own the registry, while for content types we do not...
Heh, I think it's a stretch of the imagination to think that we control the registry even when we define it ... people still deploy first and register later. In any case, a simple should be sufficient.
I actually reverse my opinion about the SHOULD NOT - we already use BCP14 keywords in the paragraphs before and after this one. So please consider again the pull request.
My .02 - acknowledging that 2119 keywords are only intended for implementations roles, I don't think that throwing up our hands and saying "people will do what they will" is productive. While some people ignore (or just don't read) the RFCs, many do, and when they do, we owe it to them to communicate in the clearest, concise way possible. 2119 keywords are a fantastic tool for doing that.
NAME - so are you ok with this change?
I am - although if we come up with a unified way to deal with requirements consistently across the documents, it might change.
Continuing from URL In the current spec, nothing is said about how to handle transfer-parameters. Notably, nothing is said about the case sensitivity of the parameter key. This results in a conflict with the TE header: if you see a "q" token, you cannot know if it is a transfer-parameter vs a t-ranking. It is noted that the "q" token is case insensitive in section 4.3.
See URL
OK. An edge case of an edge case. Note that among the currently registered transfer codings, none defines parameters. Drastic options might be: Disallow parameters on transfer codings (and thus also on content codings) Remove quality values on transfer coding negotiation. More realistic: in the registration procedure for content/transfer codings, note that a parameter "q" is discouraged (forbidden) due to the ambiguity in "TE". Should I make a proposal for this?
Actually, we have a similar situation for Accept:; see :
Not only "q" but also "Q": case sensitivity isn't mentioned for transfer parameters.
and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.
Going to let NAME have a look at this as well.
(Warning, I may have reached peak pedantry.) In Section 5.1, there are two references to frames which "contain" an ENDSTREAM flag. All HEADERS, CONTINUATION, and DATA frames contain this flag, which might be set or not. Most other references in the document are to the flag being set, which is more precise. There are also two references to frames "bearing" ENDSTREAM, which could be taken either way.
If you care enough to write the issue, maybe you also care enough to offer a pull request.
Note that I also cleaned up the surrounding paragraph and removed parentheses from around the statement that the response always terminates after the header section.
currently links to "Message Payload", but that is not that helpful in order to find out what fields actually are "payload header fields".
Note. We currently say: "The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 6.4) MAY be omitted." URL would change this to: "The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that header fields that describe message body encoding or transmission (e.g., Transfer-Encoding) MAY be omitted." (me confused by that)
I should probably just list them all. Content-Length and Transfer-Encoding are the obvious ones, but I would have to go through the spec to be sure there are not more. The reason for this is that servers do not generate the body on HEAD responses, so the fields that are defined while buffering the first 8K of body (when they can still be sent as headers) are not sent on HEAD responses. Maybe we should just say that.
Add reference for obs-fold, add note about transforms,
The spec several times refers to the term obs-fold, but doesn't say where it's defined (-> URL). Furthermore, in 1.3 it claims that addition of obs-fold could be permitted under certain circumstances. That IMHO is incorrect.
Adding the reference makes sense. The signatures spec doesn't change how the messages are created, nor does it make more allowed than it is now, it just tells people what to do with the messages that they have even if they have in them.
: This is misleading. No HTTP permits addition of leading/trailing whitespace. Leading/trailing whitespace in field values by definition is invalid.
While technically true, many (including implementers) won't understand the nuance Here. Given the impact, it's better to be over-inclusive, I think.
If invalid changes are included, then it might be best to either say that some of these changes might be invalid or point specifically to those that are.
Yes, my proposal would be to split the list into two; the second just listing the transformatios that might happen in reality despite bing forbidden.
NAME I agree that we need to prepare developers for the messy reality of HTTP in addition to what's strictly allowed. What else would appear in this second list?
The only other thing that I can see right now is addition of obs-fold.
Speaking of which: there are other transformations like parsing and re-serializing field values, which are certainly allowed. Shouldn't these be mentioned here as well?
NAME Re-serialization of a field value by an intermediary would likely break things in an expected way. It was my impression that this was not allowed by intermediaries in general. A structured field does help this, and the flag protects against that kind of transformation, as mentioned in the section.
I don't think we have a rule anywhere that would keep an intermediary from parsing and re-serializing fields. And even if that was the case, the same would be true for the original point (addition of leading/trailing WS), so I'm trying to understand where we draw the line.
We could try to make every statement precise. We could add "of the frames defined in this document" to a bunch of places. Or we could make a (better) blanket statement. That is what this does.
As discussed in , the current language of 5.1 prohibits all frames on closed streams other than the ones indicated. It is not clear whether the requirement in Section 5.5 constitutes "more specific guidance." My suggestion in the erratum was to scope "any frame" to "any frame defined in this document" where we might allow an extension frame to appear, since that was the minimal change to the RFC 7540 text, but the editors might choose a broader rewording.
So the text already says: "Frames of unknown types are ignored." right next to the guidance you refer to. Maybe we just need to be more direct about this.
Be careful Martin, you removed the sentence "Frames of unknown types are ignored" so I think we're losing one piece of information when looking at the patch. I should re-read it withiin its context to make sure we don't miss anything, but I preferred to warn.
NAME yes, that was a deliberate change. I replaced that text with a complete paragraph and a reference to the extensibility section, which already covers the rules for unknown frames clearly: "Implementations MUST discard frames that have unknown or unsupported types."
I think this is fine.
See URL Hi! Unfortunately, we couldn't submit the draft before the meeting and discuss it face-to-face. But here's a -01 fresh from the oven. We absorbed the feedback we got in SF and went ahead with one single header. However, the two modes of use ([1], [2]) define different inputs into the timestamping machinery and therefore create a different binding between COSE and TST. At present, the only way to distinguish between the two semantics is by their position in the COSE message (i.e., protected vs unprotected), which does not look like a good design :-) cheers, thanks [1] URL [2] URL ---------- Forwarded message --------- From: Date: Tue, 7 Nov 2023 at 14:36 Subject: New Version Notification for draft-ietf-cose-tsa-tst-header-parameter-URL To: Henk Birkholz , Maik Riechert , Maik Riechert , Thomas Fossati , A new version of Internet-Draft draft-ietf-cose-tsa-tst-header-parameter-URL has been successfully submitted by Thomas Fossati and posted to the IETF repository. Name: draft-ietf-cose-tsa-tst-header-parameter Revision: 01 Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens Date: 2023-11-07 Group: cose Pages: 6 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSESign and COSESign1) with existing RFC 3161-based timestamping infrastructure. The IETF Secretariat