Question:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

In this version of TLS 1.3, the two input secrets are: PSK (a pre-shared key established externally or derived from the <del> resumption_main_secret value from a previous connection) </del> <ins> resumption_secret value from a previous connection) </ins> (EC)DHE shared secret (ecdhe-shared-secret-calculation)


Question:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

will still be HKDF-Extract(0, 0).  For the computation of the binder_key, the label is "ext binder" for external PSKs (those provisioned outside of TLS) and "res binder" for resumption PSKs <del> (those provisioned as the resumption main secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </del> <ins> (those provisioned as the resumption secret of a previous handshake). The different labels prevent the substitution of one type of PSK for the other. </ins> There are multiple potential Early Secret values, depending on which PSK the server ultimately selects.  The client will need to compute


Question:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

The exporter value is computed as: <del> Where Secret is either the early_exporter_main_secret or the exporter_main_secret.  Implementations MUST use the exporter_main_secret unless explicitly specified by the application. The early_exporter_main_secret is defined for use in settings where an exporter is needed for 0-RTT data.  A separate interface for the early exporter is RECOMMENDED; this avoids the exporter user accidentally using an early exporter when a regular one is desired or vice versa. </del> <ins> Where Secret is either the early_exporter_secret or the exporter_secret.  Implementations MUST use the exporter_secret unless explicitly specified by the application.  The early_exporter_secret is defined for use in settings where an exporter is needed for 0-RTT data.  A separate interface for the early exporter is RECOMMENDED; this avoids the exporter user accidentally using an early exporter when a regular one is desired or vice versa. </ins> If no context is provided, the context_value is zero length. Consequently, providing no context computes the same value as


Question:
The reason for the SHOULD is that the current text says: do a key update as described in {{key-update}} prior to reaching these limits. Note that it is not possible to perform a KeyUpdate for early data and therefore implementations SHOULD not exceed the limits when sending early data. We could of course change both.
DTLS 1.3 introduces integrity limits for the AEAD algorithms, which is good. TLS 1.3 does not have any AEAD integrity limits, probably because the assumption that only a single AEAD forgery can be attempted. My understanding is that this is not true for 0-RTT data which works more like DTLS and where an attacker can attempt any number of forgery attempts on a single AEAD key. RFC 8446 has relatively strong anti-replay protection: "The server MUST ensure that any instance of it (be it a machine, a thread, or any other entity within the relevant serving infrastructure) would accept 0-RTT for the same 0-RTT handshake at most once." but this does not stop an attacker from attempting an unlimited number of forgeries. I think consideration / mitigation of this is missing from RFC8446. Some alternative suggestions: Should the 0-RTT requirement above be strengthen to: "The server MUST ensure that any instance of it (be it a machine, a thread, or any other entity within the relevant serving infrastructure) would process a 0-RTT handshake with the same PSK, URL pair at most once." should RFC8446bis continue to ignore AEAD limits for 0-RTT? 0-RTT data already has lower security (weaker replay protection)? In this case I think some considerations should be added describing that the integrity protection of is weaker than for normal application data. should RFC8446bis introduce DTLS 1.3 type integrity limits for clientearlytraffic_secret? This aligns the integrity limits of 0-RTT data in TLS with the normal application data in DTLS.
Could you say a bit more about how this would work in practice? I did not consult the spec just now, but I had the impression that 0-RTT still had only a single attempt at forgery (at least, per replay cache instance/backend server).
Ah, the linked DTLS issue mentions long-lived external PSKs specifically. I agree that our story for those is less well specified and probably not great. Off the top of my head, I would suggest "don't use 0-RTT with long-lived PSKs".
I think that the original is fine. I don't think that there is any meaningful distinction between 0-RTT handshake and the (PSK, URL) tuple, at least as far as the derived keys go. Change the PSK, PSK identity, or random and you get a new key derivation. I had expected that early data was subject to the same constraints as later epochs. The only caveat being that it is impossible to update early data keys using KeyUpdate. The answer is to finish the handshake of course, so a hard error is fine. We might advise servers to cap maxearlydata_size to help avoid any issues of overrun, though with certain perverse padding arrangements, that might not provide any real guarantee. As above integrity limits should also apply.
URL fixes (1) The case for (3) is actually more subtle, as the problem is not clientearlytraffic_secret but rather the trial decryption skipping phase. We might need to apply DTLS 1.3 like limits there.

an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses.  Implementations SHOULD do a key update as described in key-update prior to reaching <del> these limits. </del> <ins> these limits.  Note that it is not possible to perform a KeyUpdate for early data and therefore implementations SHOULD not exceed the limits when sending early data. </ins> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of


Question: MGF1 got unhelpfully spelled out as "mask generation function 1" in RFC 8446. I'm guessing this is the result of an acronym expansion editting pass, but the function is simply called "MGF1". There is no such thing as "mask generation function 1". Correct this back to MGF1. In hopes this doesn't get hit the same editing pass later, I've tweaked the wording and moved the citation so that "mask generation function" is still uttered before MGF1, and it's clearer that both primitives are defined in RFC 8017.

signature is represented as a DER-encoded X690 ECDSA-Sig-Value structure as defined in RFC4492. <del> Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask generation function 1.  The digest used in the mask generation function and the digest being signed are both the corresponding hash algorithm as defined in SHS.  The length of the Salt MUST be equal to the length of the output of the digest algorithm.  If the public key is carried in an X.509 certificate, it MUST use the rsaEncryption OID RFC5280. </del> <ins> Indicates a signature algorithm using RSASSA-PSS with a mask generation function of MGF1, as defined in RFC8017.  The digest used in MGF1 and the digest being signed are both the corresponding hash algorithm as defined in SHS.  The length of the Salt MUST be equal to the length of the output of the digest algorithm.  If the public key is carried in an X.509 certificate, it MUST use the rsaEncryption OID RFC5280. </ins> Indicates a signature algorithm using EdDSA as defined in RFC8032 or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. <del> Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask generation function 1.  The digest used in the mask generation function and the digest being signed are both the corresponding hash algorithm as defined in SHS.  The length of the Salt MUST be equal to the length of the digest algorithm.  If the public key is carried in an X.509 certificate, it MUST use the RSASSA-PSS OID RFC5756.  When used in certificate signatures, the algorithm parameters MUST be DER encoded.  If the corresponding public key's parameters are present, then the parameters in the signature MUST be identical to those in the public key. </del> <ins> Indicates a signature algorithm using RSASSA-PSS with a mask generation function of MGF1, as defined in RFC8017.  The digest used in MGF1 and the digest being signed are both the corresponding hash algorithm as defined in SHS.  The length of the Salt MUST be equal to the length of the digest algorithm.  If the public key is carried in an X.509 certificate, it MUST use the RSASSA-PSS OID RFC5756.  When used in certificate signatures, the algorithm parameters MUST be DER encoded.  If the corresponding public key's parameters are present, then the parameters in the signature MUST be identical to those in the public key. </ins> Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used


Question:
Just a few things I noticed that I think make it a little bit easier to follow. Name resumption_secret consistently when used Show full legend for each handshake flow Simplify/clarify secret sources table a bit and make text cases consistent The resumption secret naming was also apparently noticed by NAME in issue . (Edited to note: this PR has been pruned down to a smaller list of changes; see commit message)
Ok, to respond to comments I've pushed a new commit. RE: capitalization: Upper or lower is fine, as long as it's consistent. I've switched it to all upper (title case) instead of all lower. RE: legend repetition: If you're just reading one section, e.g. got to it via TOC, you might not have seen the legend (recently). I've made it less wordy now and also added a line to indicate "+" is for extensions, as I realized that wasn't necessarily clear. (and added a "+" where the notation was inconsistent) We do have an extension that was previously a message, now. The basic point is consistency; make each handshake flow make sense on its own. I think repeating the legend is helpful, but if you really don't want to repeat it that I can cut this down to just the little stuff and table. Showing "N/A" instead of repeating things in the table is the most helpful part here, I think. It states that SS=ES in some circumstances elsewhere, but the table isn't clear that these are the exact same values, especially because the extracted ones are not.
Edited again and repushed for some more naming consistency.
Revised & rebased. Of note, I think these changes to the table make it far easier to see what's going on here.
NAME If you're going to be rewriting this, I'll just set those parts aside. The commit here is now just the little stuff: fix the spacing, add a line stating what SS/ES are in the list of derivations, and fix "shared_secret" (there's no such value named that; just drop the underscore).
NAME commit updated with fixes for your comments above
The key derivation process uses the "master secret" as the basis for application traffic keys and both the resumption and exporter secrets. There are lots of other secrets though. I don't have a better name right now, so close this if none better can be found. Also s/resumption master secret/resumption secret/ throughout, it's a little inconsistent.
Now master of more

shown below. The derivation process is as follows, where L denotes the length of <del> the underlying hash function for HKDF RFC5869. </del> <ins> the underlying hash function for HKDF RFC5869.  SS and ES denote the sources from the table above.  Whilst SS and ES may be the same in some cases, the extracted xSS and xES will not. </ins> The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below.


Question:
Just a few things I noticed that I think make it a little bit easier to follow. Name resumption_secret consistently when used Show full legend for each handshake flow Simplify/clarify secret sources table a bit and make text cases consistent The resumption secret naming was also apparently noticed by NAME in issue . (Edited to note: this PR has been pruned down to a smaller list of changes; see commit message)
Ok, to respond to comments I've pushed a new commit. RE: capitalization: Upper or lower is fine, as long as it's consistent. I've switched it to all upper (title case) instead of all lower. RE: legend repetition: If you're just reading one section, e.g. got to it via TOC, you might not have seen the legend (recently). I've made it less wordy now and also added a line to indicate "+" is for extensions, as I realized that wasn't necessarily clear. (and added a "+" where the notation was inconsistent) We do have an extension that was previously a message, now. The basic point is consistency; make each handshake flow make sense on its own. I think repeating the legend is helpful, but if you really don't want to repeat it that I can cut this down to just the little stuff and table. Showing "N/A" instead of repeating things in the table is the most helpful part here, I think. It states that SS=ES in some circumstances elsewhere, but the table isn't clear that these are the exact same values, especially because the extracted ones are not.
Edited again and repushed for some more naming consistency.
Revised & rebased. Of note, I think these changes to the table make it far easier to see what's going on here.
NAME If you're going to be rewriting this, I'll just set those parts aside. The commit here is now just the little stuff: fix the spacing, add a line stating what SS/ES are in the list of derivations, and fix "shared_secret" (there's no such value named that; just drop the underscore).
NAME commit updated with fixes for your comments above
The key derivation process uses the "master secret" as the basis for application traffic keys and both the resumption and exporter secrets. There are lots of other secrets though. I don't have a better name right now, so close this if none better can be found. Also s/resumption master secret/resumption secret/ throughout, it's a little inconsistent.
Now master of more

7.2.2. A conventional Diffie-Hellman computation is performed.  The <del> negotiated key (Z) is used as the shared_secret, and is used in the </del> <ins> negotiated key (Z) is used as the shared secret, and is used in the </ins> key schedule as specified above.  Leading bytes of Z that contain all zero bits are stripped before it is used as the input to HKDF.


Question: The current wording at the end of the section on resumption and PSK should be changed to indicate that if a server declines resumption then a full handshake, including the server Certificate and CertificateVerify messages, should take place. In its current state, the comment on omission of these messages is not disjoint from the statement regarding the server's rejection of resumption.

tls-resumption-psk shows a pair of handshakes in which the first establishes a PSK and the second uses it: <del> Note that the client supplies a ClientKeyShare to the server as well, which allows the server to decline resumption and fall back to a full handshake.  However, because the server is authenticating via a PSK, it does not send a Certificate or a CertificateVerify.  PSK-based resumption cannot be used to provide a new ServerConfiguration. </del> <ins> As the server is authenticating via a PSK, it does not send a Certificate or a CertificateVerify.  PSK-based resumption cannot be used to provide a new ServerConfiguration.  Note that the client supplies a ClientKeyShare to the server as well, which allows the server to decline resumption and fall back to a full handshake. </ins> The contents and significance of each message will be presented in detail in the following sections.


Question:
LGTM
Hubert Karlo writes: And how does the client know that the algorithms came from the server. We should have a "client MUST wait for the full handshake to finish before recording this information" or we will have a very nice cipher downgrade. Just having it signed is likely not a good idea, as they may depend on ciphersuites advertised by client.
Since the ServerConfiguration and the suites are covered by the signature the server provides, isn't it safe to use the configuration add soon as you have verified the server identity?
n.b., I have no problem with mandating that clients wait for finished, because it is immediately after the signature, but I wasn't the properties to be clear.

send a Certificate message and a CertificateVerify message, even if the "known_configuration" extension was used for this handshake, thus requiring a signature over the configuration before it can be used by <del> the client. </del> <ins> the client.  Clients MUST not rely on the ServerConfiguration message until successfully receiving and processing the server's Certificate, CertificateVerify, and Finished.  If there is a failure in processing those messages, the client MUST discard the ServerConfiguration. </ins> 6.3.8.


Question: NAME did a massive message->alert change a while back and I did yet more when we were rebasing his patch. Looks like there's more up here in Closure Alerts. We're referring to alerts, not the messages that carry them. Switch to "alerts" instead to remain consistent with the rest of the document, notably the following section.

close a connection does not prohibit a session from being resumed. <del> This message notifies the recipient that the sender will not send </del> <ins> This alert notifies the recipient that the sender will not send </ins> any more messages on this connection.  Any data received after a closure MUST be ignored. <del> This message is sent by the client to indicate that all 0-RTT </del> <ins> This alert is sent by the client to indicate that all 0-RTT </ins> application_data messages have been transmitted and that the next message will be handshake message protected with the 1-RTT handshake keys.  This alert MUST be at the warning level.  Servers <del> MUST NOT send this message and clients receiving this message MUST </del> <ins> MUST NOT send this alert and clients receiving this alert MUST </ins> terminate the connection with an "unexpected_message" alert. <del> This message notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just </del> <ins> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just </ins> closing the connection by sending a "close_notify" is more appropriate.  This alert SHOULD be followed by a "close_notify". This alert is generally a warning.


Question: Cleaned up references to knownconfiguration extension (merged into earlydata in draft-08)

ServerConfiguration format. The semantics of this message are to establish a shared state between <del> the client and server for use with the "known_configuration" extension with the key specified in key and with the handshake </del> <ins> the client and server for use with the "early_data" extension with the key specified in "static_key_share" and with the handshake </ins> parameters negotiated by this handshake. When the ServerConfiguration message is sent, the server MUST also send a Certificate message and a CertificateVerify message, even if <del> the "known_configuration" extension was used for this handshake, thus </del> <ins> the "early_data" extension was used for this handshake, thus </ins> requiring a signature over the configuration before it can be used by the client.  Clients MUST NOT rely on the ServerConfiguration message until successfully receiving and processing the server's Certificate,


Question: Minor editorial tweaks. I just noticed the extra line that gets left in there when shown up top (two lines between first two shown blocks, instead of one). This fixes that. Also drops the periods after the comments, as they're not sentences.

"supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { // RSASSA-PKCS-v1_5 <del> algorithms.  rsa_pkcs1_sha1 (0x0201), rsa_pkcs1_sha256 (0x0401), </del> <ins> algorithms rsa_pkcs1_sha1 (0x0201), rsa_pkcs1_sha256 (0x0401), </ins> rsa_pkcs1_sha384 (0x0501), rsa_pkcs1_sha512 (0x0601), Note: This production is named "SignatureScheme" because there is


Question: The draft was in a sort of halfway state between whether TLSCiphertext has a fragment that is a selection or just embedding the AEAD elements directly. This should normalize it to the embedded view without the extra GenericAEADCipher struct definition. (i don't think this changes the logic of the draft at all)

described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key. The type field is identical to TLSPlaintext.type. The version field is identical to TLSPlaintext.version. The length (in bytes) of the following TLSCiphertext.fragment. The length MUST NOT exceed 2^14 + 2048. The AEAD encrypted form of TLSPlaintext.fragment. Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the <del> GenericAEADCipher.nonce_explicit part.  In many cases, it is appropriate to use the partially implicit nonce technique described in Section 3.2.1 of RFC5116; with record_iv_length being the length of the explicit part.  In this case, the implicit part SHOULD be derived from key_block as client_write_iv and server_write_iv (as described in key-calculation), and the explicit part is included in </del> <ins> TLSCiphertext.nonce_explicit part.  In many cases, it is appropriate to use the partially implicit nonce technique described in Section 3.2.1 of RFC5116; with record_iv_length being the length of the explicit part.  In this case, the implicit part SHOULD be derived from key_block as client_write_iv and server_write_iv (as described in key-calculation), and the explicit part is included in </ins> GenericAEAEDCipher.nonce_explicit. The plaintext is the TLSPlaintext.fragment.


Question:
This change clarifies that the signature over ServerDHParams data is a signature over the hash of the client + server hello random random data and the ServerDHParams data. I believe this small regression was introduced in TLS1.2 with the result that the TLS1.2 RFC (and current TLS1.3 draft) does not contain sufficient detail to implement TLS + DHE. All TLS1.2 clients and servers that I have tested do include the hello random data (and omitting it would leave implementations open to replay attacks).
Thanks for the PR. Note that the formal PDU definitions here appear to be correct, so there should be enough information to implement things correctly: I agree it wouldn't hurt to have the explanatory text be clearer. However, in TLS 1.2 we stopped explicitly saying that things were hashed before signing (because we are treating signing as a primitive), so we probably don't want to say "hash". Maybe just say a signature over the random values and the params?
Ah, this explains my confusion. After reading section 7.4.1.4.1, I formed the opposite impression about signing; that hashing and signing are explicitly different primitive operations and may be composed in a variety of ways. But I see how that "digitally-signed" seems to be a reserved term that implies both operations.
I'm not trying to discourage you here. If you were confused, others will probably be as well, so if you have some text that you think would clear this up, it would be welcome.
Thanks! I've updated the PR with an even simpler diff that I think would have made me less confused when I got to it.

The server's key exchange parameters. <del> For non-anonymous key exchanges, a signature over the server's key exchange parameters. </del> <ins> For non-anonymous key exchanges, a signature over the client and server hello random data and the server's key exchange parameters. </ins> If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm MUST be a pair listed in that


Question: Lack of a blank line after "draft-14" but before the bullet point causes it to render all on one line: URL This is just a quick patch to make the spacing consistent because apparently Markdown (or, at least whatever is interpreting it there) can be picky. ;) This is just a whitespace fix.

1.2. <del> draft-14 - Allow cookies to be longer. </del> <ins> draft-14 Allow cookies to be longer. </ins> draft-13


Question:
NAME NAME PTAL
LGTM
lgtm
Don't forget no_certificate.
Not relevant: nocertificateRESERVED(41), / fatal / , Martin Thomson EMAIL wrote:
Right. I just noticed that we send an empty certificate instead.

6. One of the content types supported by the TLS record layer is the <del> alert type.  Alert messages convey the severity of the message (warning or fatal) and a description of the alert.  Alert messages with a level of fatal result in the immediate termination of the connection.  Like other messages, alert messages are encrypted as </del> <ins> alert type.  Like other messages, alert messages are encrypted as </ins> specified by the current connection state. <ins> Alert messages convey the severity of the message (warning or fatal) and a description of the alert.  Warning-level messages are used to indicate orderly closure of the connection (see closure-alerts). Upon receiving a warning-level alert, the TLS implementation SHOULD indicate end-of-data to the application and, if appropriate for the alert type, send a closure alert in response. Fatal-level messages are used to indicate abortive closure of the connection (See error-alerts).  Upon receiving a fatal-level alert, the TLS implementation SHOULD indicate an error to the application and MUST NOT allow any further data to be sent or received on the connection.  Servers and clients MUST forget keys and secrets associated with a failed connection.  Stateful implementations of session tickets (as in many clients) SHOULD discard tickets associated with failed connections. All the alerts listed in error-alerts MUST be sent as fatal and MUST be treated as fatal regardless of the AlertLevel in the message. Unknown alert types MUST be treated as fatal. </ins> %%% Alert Messages 6.1.


Question:
NAME NAME PTAL
LGTM
lgtm
Don't forget no_certificate.
Not relevant: nocertificateRESERVED(41), / fatal / , Martin Thomson EMAIL wrote:
Right. I just noticed that we send an empty certificate instead.

6.2. <del> Error handling in TLS is very simple.  When an error is detected, the detecting party sends a message to its peer.  Upon transmission or receipt of a fatal alert message, both parties immediately close the connection.  Servers and clients MUST forget keys, and secrets associated with a failed connection.  Stateful implementations of session tickets (as in many clients) SHOULD discard tickets associated with failed connections. Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST send the appropriate alert prior to closing the connection.  For all errors where an alert level is not explicitly specified, the sending party MAY determine at its discretion whether to treat this as a fatal error or not.  If the implementation chooses to send an alert but intends to close the connection immediately afterwards, it MUST send that alert at the fatal alert level. If an alert with a level of warning is sent and received, generally the connection can continue normally.  If the receiving party decides not to proceed with the connection (e.g., after having received a "user_canceled" alert that it is not willing to accept), it SHOULD send a fatal alert to terminate the connection.  Given this, the sending peer cannot, in general, know how the receiving party will behave.  Therefore, warning alerts are not very useful when the sending party wants to continue the connection, and thus are sometimes omitted.  For example, if a party decides to accept an expired certificate (perhaps after confirming this with the user) and wants to continue the connection, it would not generally send a "certificate_expired" alert. </del> <ins> Error handling in the TLS Handshake Protocol is very simple.  When an error is detected, the detecting party sends a message to its peer. Upon transmission or receipt of a fatal alert message, both parties immediately close the connection.  Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST send the appropriate alert prior to closing the connection. </ins> The following error alerts are defined:


Question: As all error alerts are now considered fatal (PR ), we no longer need "This alert is always fatal" explicitly stated everywhere in that section.

Upon transmission or receipt of a fatal alert message, both parties immediately close the connection.  Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST <del> send the appropriate alert prior to closing the connection. </del> <ins> send the appropriate alert prior to closing the connection.  All alerts defined in this section below, as well as all unknown alerts are universally considered fatal as of TLS 1.3 (see alert-protocol). </ins> The following error alerts are defined: <del> An inappropriate message was received.  This alert is always fatal and should never be observed in communication between proper implementations. </del> <ins> An inappropriate message was received.  This alert should never be observed in communication between proper implementations. </ins> This alert is returned if a record is received which cannot be deprotected.  Because AEAD algorithms combine decryption and verification, this alert is used for all deprotection failures. <del> This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). </del> <ins> This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. </ins> A TLSCiphertext record was received that had a length more than 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record <del> with more than 2^14 bytes.  This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). </del> <ins> with more than 2^14 bytes.  This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. </ins> Reception of a "handshake_failure" alert message indicates that the sender was unable to negotiate an acceptable set of security <del> parameters given the options available.  This alert is always fatal. </del> <ins> parameters given the options available. </ins> A certificate was corrupt, contained signatures that did not verify correctly, etc.


Question: As all error alerts are now considered fatal (PR ), we no longer need "This alert is always fatal" explicitly stated everywhere in that section.

certificate, rendering it unacceptable. A field in the handshake was out of range or inconsistent with <del> other fields.  This alert is always fatal. </del> <ins> other fields. </ins> A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not <del> be located or couldn't be matched with a known, trusted CA.  This alert is always fatal. </del> <ins> be located or couldn't be matched with a known, trusted CA. </ins> A valid certificate or PSK was received, but when access control was applied, the sender decided not to proceed with negotiation. <del> This alert is always fatal. </del> A message could not be decoded because some field was out of the specified range or the length of the message was incorrect.  This <del> alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). </del> <ins> alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. </ins> A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message. <del> This alert is always fatal. </del> The protocol version the peer has attempted to negotiate is <del> recognized but not supported.  (For example, old protocol versions might be avoided for security reasons.)  This alert is always fatal. </del> <ins> recognized but not supported. (see backward-compatibility) </ins> Returned instead of "handshake_failure" when a negotiation has failed specifically because the server requires ciphers more <del> secure than those supported by the client.  This alert is always fatal. </del> <ins> secure than those supported by the client. </ins> An internal error unrelated to the peer or the correctness of the protocol (such as a memory allocation failure) makes it impossible <del> to continue.  This alert is always fatal. </del> <ins> to continue. </ins> Sent by a server in response to an invalid connection retry <del> attempt from a client. (see [RFC7507]) This alert is always fatal. </del> <ins> attempt from a client. (see [RFC7507]) </ins> Sent by endpoints that receive a hello message not containing an extension that is mandatory to send for the offered TLS version. <del> This message is always fatal.  [[TODO: IANA Considerations.]] </del> <ins> [[TODO: IANA Considerations.]] </ins> Sent by endpoints receiving any hello message containing an extension known to be prohibited for inclusion in the given hello message, including any extensions in a ServerHello not first <del> offered in the corresponding ClientHello.  This alert is always fatal. </del> <ins> offered in the corresponding ClientHello. </ins> Sent by servers when unable to obtain a certificate from a URL provided by the client via the "client_certificate_url" extension


Question: As all error alerts are now considered fatal (PR ), we no longer need "This alert is always fatal" explicitly stated everywhere in that section.

Sent by servers when a retrieved object does not have the correct hash provided by the client via the "client_certificate_url" <del> extension RFC6066.  This alert is always fatal. </del> <ins> extension RFC6066. </ins> Sent by servers when a PSK cipher suite is selected but no acceptable PSK identity is provided by the client.  Sending this


Question: No context and empty context are now declared to be the same. Add some ALL CAPS WORDS for future specifications to deprecate no context. I used SHOULD to forbid no context because, if some protocol currently uses no context, switching it to empty context is a breaking change and probably not worth it. We just want new ones to always provide a context. This affects the rules for using exporters, so RFC 5705 is added to the list of updated documents. Closes issue .

RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  This document replaces the PRF with HKDF, thus requiring a new <del> construction.  The exporter interface remains the same, however the value is computed as: </del> <ins> construction.  The exporter interface remains the same.  If context is provided, the value is computed as: If no context is provided, the value is computed as: Note that providing no context computes the same value as providing an empty context.  As of this document's publication, no allocated exporter label is used with both modes.  Future specifications MUST NOT provide an empty context and no context with the same label and SHOULD provide a context, possibly empty, in all exporter computations. </ins> 8.


Question: 1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.

The key exchange and authentication modes this PSK is allowed to be used with <del> The Application-Layer Protocol Negotiation (ALPN) label(s) </del> <ins> The Application-Layer Protocol Negotiation (ALPN) protocol, if any is to be used </ins> The Server Name Indication (SNI), if any is to be used


Question: 1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.

handshake but reject 0-RTT, and SHOULD NOT take any other action that assumes that this ClientHello is fresh. <del> The parameters for the 0-RTT data (symmetric cipher suite, ALPN, etc.) are the same as those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </del> <ins> The parameters for the 0-RTT data (symmetric cipher suite, ALPN protocol, etc.) are the same as those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </ins> 0-RTT messages sent in the first flight have the same content types as their corresponding messages sent in other flights (handshake,


Question: 1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.

with a HelloRetryRequest.  A client MUST NOT include the "early_data" extension in its followup ClientHello. <del> In order to accept early data, the server server MUST have accepted a PSK cipher suite and selected the the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the following values are consistent with those negotiated in the </del> <ins> In order to accept early data, the server MUST have accepted a PSK cipher suite and selected the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the following values are consistent with those negotiated in the </ins> connection during which the ticket was established. The TLS version number, AEAD algorithm, and the hash for HKDF. <del> The selected ALPN RFC7443 value, if any. </del> <ins> The selected ALPN RFC7301 protocol, if any. </ins> Future extensions MUST define their interaction with 0-RTT.


Question: 1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.

application MAY opt to retransmit the data once the handshake has been completed.  TLS stacks SHOULD not do this automatically and client applications MUST take care that the negotiated parameters are <del> consistent with those it expected.  For example, if the ALPN value has changed, it is likely unsafe to retransmit the original </del> <ins> consistent with those it expected.  For example, if the selected ALPN protocol has changed, it is likely unsafe to retransmit the original </ins> application layer data. 4.2.9.1.


Question:
It seems section 4.1.3 Server Hello has not been updated to reflect the new version negotiation mechanism. says "servers says "servers MUST [...] negotiate the highest mutually supported version".
Thanks, I caught a few of these on my reread yesterday too, but I probably missed some too, so keep them coming!

%%% Key Exchange Messages This field contains the version of TLS negotiated for this <del> session.  Servers MUST select the lower of the highest supported server version and the version offered by the client in the ClientHello.  In particular, servers MUST accept ClientHello messages with versions higher than those supported and negotiate the highest mutually supported version.  For this version of the specification, the version is 0x0304.  (See backward-compatibility for details about backward compatibility.) </del> <ins> session.  Servers MUST select a version from the list in ClientHello.supported_versions extension.  A client which receives a version that was not offered MUST abort the handshake.  For this version of the specification, the version is 0x0304.  (See backward-compatibility for details about backward compatibility.) </ins> This structure is generated by the server and MUST be generated independently of the ClientHello.random.


Question: Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.

otherwise, a TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher <del> suites. </del> <ins> suites. (see cipher-suites) </ins> A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for


Question: Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.

Supported Versions ("supported_versions"; supported-versions) <ins> Cookie ("cookie"; cookie) </ins> Signature Algorithms ("signature_algorithms"; signature- algorithms)


Question: Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.

Pre-Shared Key ("pre_shared_key"; pre-shared-key-extension) <del> Cookie ("cookie"; cookie) </del> Server Name Indication ("server_name"; Section 3 of RFC6066) All implementations MUST send and use these extensions when offering


Question: Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.

9. Security issues are discussed throughout this memo, especially in <del> Appendices B, C, and D. </del> <ins> implementation-notes, backward-compatibility, and security-analysis. </ins> 10.


Question: Adding "itself" makes the sentence much easier to understand. Actually, two Japanese, who are implementing TLS 1.3 independently, took a long time to understand this.

The client uses the "signature_algorithms" extension to indicate to the server which signature algorithms may be used in digital <del> signatures.  Clients which desire the server to authenticate via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </del> <ins> signatures.  Clients which desire the server to authenticate itself via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </ins> "signature_algorithms" extension then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions).


Question: Ticket is a term that refers to a PSK identity established using an handshake. For out-of-band PSK, we do not use the term.

prevents passive observers from correlating sessions unless tickets are reused.  Note: because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even <del> in milliseconds.  External tickets SHOULD use an obfuscated_ticket_age of 0; servers MUST ignore this value for external tickets. </del> <ins> in milliseconds.  For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value. </ins> A list of the identities that the client is willing to negotiate with the server.  If sent alongside the "early_data" extension


Question: draft_eddsa is now . sandj-tls-iana-registry-updates is now ietf-tls-iana-registry-updates.

length of the digest output.  This codepoint is also defined for use with TLS 1.2. <del> Indicates a signature algorithm using EdDSA as defined in I- D.irtf-cfrg-eddsa or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. </del> <ins> Indicates a signature algorithm using EdDSA as defined in RFC8032 or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. </ins> rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list


Question: draft_eddsa is now . sandj-tls-iana-registry-updates is now ietf-tls-iana-registry-updates.

suites to the registry.  The "Value" and "Description" columns are taken from the table.  The "DTLS-OK" and "Recommended" columns are both marked as "Yes" for each new cipher suite.  [[This assumes I- <del> D.sandj-tls-iana-registry-updates has been applied.]] </del> <ins> D.ietf-tls-iana-registry-updates has been applied.]] </ins> TLS ContentType Registry: Future values are allocated via Standards Action RFC5226.


Question:
Need to be explicit say that it's the ExtensionType registry from RFC 4366.
I literally was making the same change in my editor when the notification came in! (Should it be the "TLS Extensions ExtensionType registry"?)

"encrypted_extensions", "end_of_early_data", "key_update", and "handshake_hash" values. <del> This document also uses a registry originally created in RFC4366. IANA has updated it to reference this document.  The registry and its allocation policy is listed below: </del> <ins> This document also uses the TLS ExtensionType Registry originally created in RFC4366.  IANA has updated it to reference this document. The registry and its allocation policy is listed below: </ins> IANA [SHALL update/has updated] this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes",


Question: When we banned client auth and PSK, we only meant to do it for the main handshake, not the post-handshake phase. This reverts that change, as well as clarifies the prophibition on PSK plus cert-based auth.

authorities). Servers which are authenticating with a PSK MUST NOT send the <del> CertificateRequest message. </del> <ins> CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see post-handshake- authentication) provided that the client has sent the "post_handshake_auth" extension (see post_handshake_auth). </ins> 4.3.2.1.


Question: Changed "media stream" to "media stream and component" in one place, and made some grammatical changes to the definition of an ICE generation.

candidates, such as STUN and TURN. All of the candidates sent within an ICE session; these are the <del> candidates that are associated with a local/remote ufrag pair (which will change on ICE restart, if any). </del> <ins> candidates that are associated with a specific local/remote ufrag pair (which will change on ICE restart, if any occurs). </ins> Any session-related (as opposed to candidate-related) attributes required to configure an ICE agent.  These include but are not


Question: Changed "media stream" to "media stream and component" in one place, and made some grammatical changes to the definition of an ICE generation.

Once the candidate has been sent to the remote party, the agent checks if any remote candidates are currently known for this same <del> stream.  If not, the new candidate will simply be added to the list of local candidates. </del> <ins> stream and component.  If not, the new candidate will simply be added to the list of local candidates. </ins> Otherwise, if the agent has already learned of one or more remote candidates for this stream and component, it will begin pairing the


Question:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

The use of source control improves traceability and visibility of changes.  Issue tracking can be used to manage open issues and provide a record of their resolution.  Pull requests allow for better <del> engagement on technical and edditorial changes, and encourage </del> <ins> engagement on technical and editorial changes, and encourage </ins> contributions from a larger set of contributors.  Using GitHub can also broaden the community of contributors for a specification.


Question:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Working Groups might integrate the capabilities provided by GitHub into their processes for developing Internet-Drafts. <del> This document is meant as an supplement to existing Working Group </del> <ins> This document is meant as a supplement to existing Working Group </ins> practices.  It provides guidance to Working Group chairs and participants on how they can best use GitHub within the framework <del> established RFC 2418 RFC2418.  The small number of rules in this </del> <ins> established by RFC 2418 RFC2418.  The small number of rules in this </ins> document are there to ensure common usage patterns between working groups and to avoid issues that have been encountered in the past. A companion document, GH-CONFIG, describes administrative processes <del> that supports the practices described in this document. </del> <ins> that support the practices described in this document. </ins> 1.1.


Question:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

the only possible choice for hosting.  There are other services that host revision control repositories and provide similar additional features to GitHub.  For instance, BitBucket [4], or GitLab [5] <del> provide a similar feature set.  In additional to a hosted service, </del> <ins> provide a similar feature set.  In addition to a hosted service, </ins> software for custom installations exists. This document concentrates primarily on GitHub as it has a large and


Question:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

3. <del> A Working Group Chairs are responsible for determining how to best </del> <ins> Working Group Chairs are responsible for determining how to best </ins> accomplish the Charter in an open and transparent fashion.  The Working Group Chairs are responsible for determining if there is interest in using GitHub and making a consensus call to determine if <del> a the proposed policy and use is acceptable. </del> <ins> the proposed policy and use is acceptable. </ins> <del> Chairs MUST involve Area Directors any decision to use GitHub for anything more than managing of drafts. </del> <ins> Chairs MUST involve Area Directors in any decision to use GitHub for anything more than managing drafts. </ins> While a document editor can still use GitHub independently for documents that they edit, even if the working group does not


Question:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

multiple documents. Maintaining multiple documents in the same repository can add <del> overheads that negatively affect individual documents.  For instance, </del> <ins> overhead that negatively affects individual documents.  For instance, </ins> issues might require additional markings to identify the document that they affect.  Also, because editors all have write access to the repository, managing the set of people with write access to a larger


Question:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

One common practice is to use these continuous integration services to build a text or HTML version of a document.  This is then published to GitHub Pages, which allows users to view a version of <del> the most recent revision of a document.  Including prominent link to this version of the document (such as in the README) makes it easier for new contributors to find a readable copy of the most recent version of a draft. </del> <ins> the most recent revision of a document.  Including a prominent link to this version of the document (such as in the README) makes it easier for new contributors to find a readable copy of the most recent version of a draft. </ins> Continuous integration can also validate pull requests and other changes for errors.  The most basic check is whether the source file <del> can be transformed successful into a valid Internet-Draft.  For </del> <ins> can be transformed successfully into a valid Internet-Draft.  For </ins> example, this might include checking that XML source is syntactically correct. <del> For documents that use formal languages a part of specifications, such as schema or source code, a continuous integration system might also be used to validate any formal language that the document contains.  Tests for any source code that the document contains might be run, or examples might be checked for correctness. </del> <ins> For a document that use formal languages as part of the specification, such as schema or source code, a continuous integration system might also be used to validate any formal language that the document contains.  Tests for any source code that the document contains might be run, or examples might be checked for correctness. </ins> 8.


Question:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

If a contributor makes a comment that raises what you believe to be a new issue, create an issue for them.  If the issue has an obvious solution, consider creating a pull request.  It doesn't matter what <del> venue the issue was raised in, email, issue discussion, a pull request review, capturing issues quickly ensures that problems become visible and can be tracked. </del> <ins> venue the issue was raised in (e.g., email, issue discussion, a pull request review); capturing issues quickly ensures that problems become visible and can be tracked. </ins> This takes a little more effort, but these simple steps can help encourage contributions, which will ultimately improve the quality of


Question:
Two changes, two issues, but really this is the one idea. The previous draft said that features not used could be disabled. This is bad advice because that might be denying editors access to tools that would make their task easier. The new advice says that editors can use features that the working group doesn't rely on. It also says that chairs should consult editors to ensure that policies aren't adversely affecting them.
Most of the operating modes assume that editors are given considerable latitude in how repositories are managed. This is good up until the point that the Working Group starts to formally rely on things that are in the respository. The document sort of prevaricates about this point, including strong admonitions that suggest rules be formalized for every aspect of usage. Instead, I think that it would be better if the document said - up-front - that editors are to be given control unless the Working Group starts to formally depend on a particular function (like issue opening/closing, labels, pull requests, whatever...). At that point, it is the chair's responsibility to identify what the WG depends on and to clearly articulate the policies around that usage.
Section 3.1 talks about turning off GitHub features not being used by the WG, but it doesn't say how to do that in the UI. I ask this because I cannot see a way to prevent issues or PRs just by wandering through the GUI.
This isn't something that I'd want to publish. The way that features are configured is too tightly coupled to UX decisions that GitHub might remake and any point. In fact, I might prefer not to include the offending text at all. Disabling features can be a useful way to slim down the options presented to users (which can help new users), but it can also be fairly hostile to new contributors. For instance, if the working group disables issues because they aren't using them, it sounds reasonable, but new contributors might then be dissuaded from opening a genuine issue. Working groups might be better served by informally letting contributors know how to best provide their input.
I'm happy with either the current text plus "At the time this is written, to turn of y" or removing the suggestion.

Group will rely upon.  features contains a more thorough discussion on the different features that can be used. <del> Once a document is published in a repository on GitHub, many features like pull requests, issue tracking or the wiki can be individually disabled.  If specific features are not used by the Working Group in the development of the document, disabling those features avoids creating confusion in the wider community about what can be used. </del> 3.2. Working Group Chairs that decide to use GitHub MUST inform their


Question:
Two changes, two issues, but really this is the one idea. The previous draft said that features not used could be disabled. This is bad advice because that might be denying editors access to tools that would make their task easier. The new advice says that editors can use features that the working group doesn't rely on. It also says that chairs should consult editors to ensure that policies aren't adversely affecting them.
Most of the operating modes assume that editors are given considerable latitude in how repositories are managed. This is good up until the point that the Working Group starts to formally rely on things that are in the respository. The document sort of prevaricates about this point, including strong admonitions that suggest rules be formalized for every aspect of usage. Instead, I think that it would be better if the document said - up-front - that editors are to be given control unless the Working Group starts to formally depend on a particular function (like issue opening/closing, labels, pull requests, whatever...). At that point, it is the chair's responsibility to identify what the WG depends on and to clearly articulate the policies around that usage.
Section 3.1 talks about turning off GitHub features not being used by the WG, but it doesn't say how to do that in the UI. I ask this because I cannot see a way to prevent issues or PRs just by wandering through the GUI.
This isn't something that I'd want to publish. The way that features are configured is too tightly coupled to UX decisions that GitHub might remake and any point. In fact, I might prefer not to include the offending text at all. Disabling features can be a useful way to slim down the options presented to users (which can help new users), but it can also be fairly hostile to new contributors. For instance, if the working group disables issues because they aren't using them, it sounds reasonable, but new contributors might then be dissuaded from opening a genuine issue. Working groups might be better served by informally letting contributors know how to best provide their input.
I'm happy with either the current text plus "At the time this is written, to turn of y" or removing the suggestion.

that new contributors need.  A link to the CONTRIBUTING file from the README is advised. <ins> The set of GitHub features (features) that the Working Group relies upon need to be clearly documented in policies.  This document provides some guidance on potential policies and how those might be applied. Features that the Working Group does not rely upon SHOULD be made available to document editors.  Editors are then able to use these features for their own purposes.  For example, though the Working Group might not formally use issues to track items that require further discussion in order to reach consensus, keeping the issue tracker available to editors can be valuable. Working Group policies need to be set with the goal of improving transparency, participation, and ultimately the quality of the consensus behind documents.  At times, it might be appropriate to impose some limitations on what document editors are able to do in order to serve these goals.  Chairs SHOULD periodically consult with document editors to ensure that policies are effective and not unjustifiably constraining progress. </ins> 3.3. New repositories can be created within the Working Group organization


Question:
This is the way we've been treating this, so let's acknowledge that.
As I noted on the list, I don't think this is correct. I proposed alternate text.
Still LGTM. :-)

sufficient, though it might be helpful to occasionally remind new contributors of these guidelines. <del> A choice to use GitHub is similar to the formation of a design team (see Section 6.5 of RFC2418) provided that the work uses a public repository.  That is, the output of any activity using GitHub needs to be taken to the Working Group mailing list and subject to approval, rejection, or modification by the Working Group as with any other input. </del> Working Group Chairs are responsible for ensuring that any policy they adopt is enforced and maintained.


Question:
This is the way we've been treating this, so let's acknowledge that.
As I noted on the list, I don't think this is correct. I proposed alternate text.
Still LGTM. :-)

documents they edit but preserves the need for contributors to understand their obligations with respect to IETF processes. <ins> Work done in GitHub has no special status.  The output of any activity using GitHub needs to be taken to the Working Group and is subject to approval, rejection, or modification by the Working Group as with any other input. </ins> 3.2. New repositories can be created within the Working Group organization


Question: We should review the appendices and include the appropriate references to them through the main body of the document.

discovered.  Such elements may include classes of data, major roles, and role interactions.  This scenario also informs protocol and data model development in support of vulnerability assessment, as part of <del> overall posture assessment.  Vulnerability discovery, disclosure, and publication is out of scope. </del> <ins> overall posture assessment (see implementation-examples for examples of solutions that support this scenario). Vulnerability discovery, disclosure, publication, and prioritization is out of scope.  However, given the importance of prioritization in an enterprise's vulnerability assessment process, it is discussed in priority. Information on how the scenario aligns with SACM and other existing work is discussed in sacm-usage-scenarios through alignment-with- other-existing-works. </ins> 2.


Question: We should review the appendices and include the appropriate references to them through the main body of the document.

data, and vulnerability assessment results. The enterprise has a procedure for reassessment of endpoints at <del> some point after initial assessment. </del> <ins> some point after initial assessment (see continuous-vulnerability- assessment for more information). </ins> 4.


Question: We should review the appendices and include the appropriate references to them through the main body of the document.

performed on an ongoing basis, resulting in routine, or even event- driven, collection of basic endpoint information. <del> See "Data Attribute Tables and Definitions" for information-specific details. </del> <ins> See data-attribute-table for information-specific details. </ins> 4.2.


Question: We should review the appendices and include the appropriate references to them through the main body of the document.

processing of vulnerability description data is expected to trigger the vulnerability assessment. <del> See "Data Attribute Tables and Definitions" for information-specific details. </del> <ins> See data-attribute-table for information-specific details. </ins> 5.


Question: We should review the appendices and include the appropriate references to them through the main body of the document.

capability can be pushed to the vulnerability assessment capability by the endpoint whenever that information changes. <del> See "Data Attribute Tables and Definitions" for information-specific details. </del> <ins> See data-attribute-table for information-specific details. </ins> 6.


Question: We should review the appendices and include the appropriate references to them through the main body of the document.

with sufficient context, so that appropriate action can be taken. Vulnerability assessment results are ideally stored for later use. <del> See "Data Attribute Tables and Definitions" for information-specific details. </del> <ins> See data-attribute-table for information-specific details. </ins> 7.


Question:
I've specified a Topic header field that we can use as a "collapse key".
Regarding max topics, I don't plan on limiting the max topics. I'm using a sharded db with a compound hash+range key for indexing, and plan on storing the topic in the range key for direct access to delete it for later messages with a topic field. There is the side-effect that the UA will get messages out-of-order as a result. ie. all messages with no topic will be delivered in order, then messages with a topic will be delivered in the order of their topic names.
We currently impose a limit of four topics (née collapse keys) +NAME I do like the change. GCM has a separate feature called Topics, i.e. subscriptions to a category, which may cause some confusion. Thinking about the name without taking this into account, I still think it makes sense in this context. URL
NAME yup, the common use case of sending "You have N messages in your mailbox", makes sense to just tell a developer to add the topic "Inbox", and the user will always get the last one sent in. I am curious about how systems having topic limits plan on communicating this to the app-server. Is there some minimum the spec should mandate just so that an app developer isn't surprised later when their app needing 5 topics doesn't work right on a browser that has topic limits?
Would 429 work for systems that run out of topics (or collapse keys)? That seems right to me.
429 seems to specific to be used for this scenario: The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting"). Could be a 500?
Is there a length limitation on the Topic? This could also be implementation-specific and signaled by: 431 Request Header Fields Too Large (RFC6585)
I think that NAME and I concluded that we could accept any size of topic. Up to the limits on header field sizes, that is, which would trigger 431. Maybe, but it is the best match I have. And I think that 4xx is better than 5xx.
If you continue with 429, how does an application server discern between 429 Rate Limiting and 429 Too Many Topics? By the presence of Retry-After?
Retry-After might be present in all cases. However, you raise a point that the definition of 429 leaves open: Is this too many requests globally? By the same client? To the same resource? To the same resource by the same client? Basically, the "scope" of applicability for 429 is hard - if not impossible - to determine. The scope is defined in some server specific terms. The question I'd ask is whether we want to provide some webpush-specific mechanism for identifying the scope of applicability for the rejection.
What about using a Scope header field in the response? In this case it will be 'Topic', maybe for too many messages for a subscription it could be 'Subscription', etc.
All these things are possible. The question is how important it is. Also, if we wanted to address the scope problem, I would want to address it more generally and then maybe add any push-specific extensions as necessary. This is a problem with 429 that - if it is worth fixing here - is probably worth fixing generally.
Maybe this was answered elsewhere, but why not just reusing the push message URI? To replace a previous message, the application would create a new message and include the previous message URI in the creation request, inside a "Replace" header. Otherwise, it would work in the same way as this proposal. This would be easy to handle on the Push Server side. On the application server side, this would mean storing the previous message URI. But the application server needs to store the topic of the previous message anyway.
NAME the idea here was that remembering the push message URI was a burden we didn't want to impose on applications. Those that aren't using acknowledgments will be able to use this version without holding any special state. Thanks for the grammatical review, I'll fix those up.
NAME an application wanting to be able to update a message will need to keep the topic of this message, so it will need to keep this state. I don't think keeping a topic or the push message URI is a large difference. However, it's true that simple applications could use only 1 topic, which would be predefined (or a few predefined topics).
NAME an application can hard-code a topic or small set of topics. They can also derive a topic from context. A URL needs to be first learned, then memorized.
NAME do you have any opinions on this change?
Updated based on feedback from NAME Note that I haven't changed the name. Not sure that we have consensus on that yet.
Conversation starts : How does the PS know that AS can accept more receipts, and how does it know a receipt has been accepted by the AS ?
Two-Pipe model a la mode de TIP? URL
NAME started on HTTPbis
Costin : we discussed my concerns on flow control for push promises, and I think it's reasonable to have them addressed either as part of http2 or as a separate document. I'm closing this issue for webpush since it's no longer actionable - NAME - re-open if you want to track for "futures". I'll tag appropriately. +1 - we discussed my concerns on flow control for push promises, and I think it's reasonable to have them addressed either as part of http2 or as a separate document. Other than that I think it's reasonable and stable base - extensions and features can be added on top of it. Costin Richard Maher wrote: >
+1 But I'm not sure we can support the mode that Martin described, so I think we may take advantage of "PS MAY return a new receipt subscription if it is unable to reuse". Buffering and flow control are complicated - the choice is between dropping receipts or sending them to a different DC. I haven't checked, but I think there is no guarantee on saving receipts if AS doesn't have enough ingress capacity. One question for HTTP/2 experts: I assumed the receipt promises are subject to normal 'max concurrent streams' ( and this will be the main mechanism to do flow control/balancing from PS to AS). However I see rfc7540: ... " Note: The client never sends a frame with the END_STREAM flag for a server push." How does the PS know that AS can accept more receipts, and how does it know a receipt has been accepted by the AS ? Costin Brian Raymor wrote: >

value MUST be less than or equal to the value provided by the application server. <ins> 6.3. A push message that has been stored by the push service can be replaced with new content.  If the user agent is offline during the time that the push messages are sent, updating a push message avoids the situation where obsolete or redundant messages are sent to the user agent. Only push messages that have been assigned a topic can be updated.  A push message with a topic replaces any outstanding push message with an identical topic. A push message topic is a string.  A topic is carried in a Topic header field.  A topic is used to correlate push messages sent to the same subscription, it does not convey any other semantics. The grammar for the Topic header field uses the "token" and "quoted- string" rules defined in RFC7230. Any double quotes from the "quoted-string" form are removed before comparing topics for equality. For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL- and filename-safe base64 set [RFC4648].  A push service that receives a request with a Token header field that does not meet these constraints SHOULD return an HTTP 400 (Bad Request) status code to an application server. A push message request creates a new push message resource, but simultaneously deletes any existing message resource that has a matching topic.  In effect, the information that is stored for the push message is updated, but a new resource is created to avoid problems with in flight acknowledgments for the old message.  The push service MAY suppress acknowledgement receipts for the replaced message. This mechanism doesn't allow for stored push messages to be deleted. An application server can remove a push message using a DELETE request to the push message URL. A push message with a topic that has a zero or absent time-to-live will cause a stored message with the same topic to be removed as well as not being stored itself, but the push service will attempt to forward the updated message to the user agent. A push message with a topic that is not shared by an outstanding message to the same subscription is stored or delivered as normal. The value of the Topic header field MUST NOT be forwarded to user agents.  Its value is not encrypted or authenticated. </ins> 7. A user agent requests the delivery of new push messages by making a


Question:
I've specified a Topic header field that we can use as a "collapse key".
Regarding max topics, I don't plan on limiting the max topics. I'm using a sharded db with a compound hash+range key for indexing, and plan on storing the topic in the range key for direct access to delete it for later messages with a topic field. There is the side-effect that the UA will get messages out-of-order as a result. ie. all messages with no topic will be delivered in order, then messages with a topic will be delivered in the order of their topic names.
We currently impose a limit of four topics (née collapse keys) +NAME I do like the change. GCM has a separate feature called Topics, i.e. subscriptions to a category, which may cause some confusion. Thinking about the name without taking this into account, I still think it makes sense in this context. URL
NAME yup, the common use case of sending "You have N messages in your mailbox", makes sense to just tell a developer to add the topic "Inbox", and the user will always get the last one sent in. I am curious about how systems having topic limits plan on communicating this to the app-server. Is there some minimum the spec should mandate just so that an app developer isn't surprised later when their app needing 5 topics doesn't work right on a browser that has topic limits?
Would 429 work for systems that run out of topics (or collapse keys)? That seems right to me.
429 seems to specific to be used for this scenario: The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting"). Could be a 500?
Is there a length limitation on the Topic? This could also be implementation-specific and signaled by: 431 Request Header Fields Too Large (RFC6585)
I think that NAME and I concluded that we could accept any size of topic. Up to the limits on header field sizes, that is, which would trigger 431. Maybe, but it is the best match I have. And I think that 4xx is better than 5xx.
If you continue with 429, how does an application server discern between 429 Rate Limiting and 429 Too Many Topics? By the presence of Retry-After?
Retry-After might be present in all cases. However, you raise a point that the definition of 429 leaves open: Is this too many requests globally? By the same client? To the same resource? To the same resource by the same client? Basically, the "scope" of applicability for 429 is hard - if not impossible - to determine. The scope is defined in some server specific terms. The question I'd ask is whether we want to provide some webpush-specific mechanism for identifying the scope of applicability for the rejection.
What about using a Scope header field in the response? In this case it will be 'Topic', maybe for too many messages for a subscription it could be 'Subscription', etc.
All these things are possible. The question is how important it is. Also, if we wanted to address the scope problem, I would want to address it more generally and then maybe add any push-specific extensions as necessary. This is a problem with 429 that - if it is worth fixing here - is probably worth fixing generally.
Maybe this was answered elsewhere, but why not just reusing the push message URI? To replace a previous message, the application would create a new message and include the previous message URI in the creation request, inside a "Replace" header. Otherwise, it would work in the same way as this proposal. This would be easy to handle on the Push Server side. On the application server side, this would mean storing the previous message URI. But the application server needs to store the topic of the previous message anyway.
NAME the idea here was that remembering the push message URI was a burden we didn't want to impose on applications. Those that aren't using acknowledgments will be able to use this version without holding any special state. Thanks for the grammatical review, I'll fix those up.
NAME an application wanting to be able to update a message will need to keep the topic of this message, so it will need to keep this state. I don't think keeping a topic or the push message URI is a large difference. However, it's true that simple applications could use only 1 topic, which would be predefined (or a few predefined topics).
NAME an application can hard-code a topic or small set of topics. They can also derive a topic from context. A URL needs to be first learned, then memorized.
NAME do you have any opinions on this change?
Updated based on feedback from NAME Note that I haven't changed the name. Not sure that we have consensus on that yet.
Conversation starts : How does the PS know that AS can accept more receipts, and how does it know a receipt has been accepted by the AS ?
Two-Pipe model a la mode de TIP? URL
NAME started on HTTPbis
Costin : we discussed my concerns on flow control for push promises, and I think it's reasonable to have them addressed either as part of http2 or as a separate document. I'm closing this issue for webpush since it's no longer actionable - NAME - re-open if you want to track for "futures". I'll tag appropriately. +1 - we discussed my concerns on flow control for push promises, and I think it's reasonable to have them addressed either as part of http2 or as a separate document. Other than that I think it's reasonable and stable base - extensions and features can be added on top of it. Costin Richard Maher wrote: >
+1 But I'm not sure we can support the mode that Martin described, so I think we may take advantage of "PS MAY return a new receipt subscription if it is unable to reuse". Buffering and flow control are complicated - the choice is between dropping receipts or sending them to a different DC. I haven't checked, but I think there is no guarantee on saving receipts if AS doesn't have enough ingress capacity. One question for HTTP/2 experts: I assumed the receipt promises are subject to normal 'max concurrent streams' ( and this will be the main mechanism to do flow control/balancing from PS to AS). However I see rfc7540: ... " Note: The client never sends a frame with the END_STREAM flag for a server push." How does the PS know that AS can accept more receipts, and how does it know a receipt has been accepted by the AS ? Costin Brian Raymor wrote: >

entities that are authorized to send messages on the channel.  The push service does not require access to this public key. <ins> The Topic header field exposes information that allows more granular correlation of push messages on the same subject.  This might be used to aid traffic analysis of push messages by the push service. </ins> 9.2. Push message confidentiality does not ensure that the identity of who


Question:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

push messages to the user agent.  Flow control SHOULD be used to limit the state commitment for delivery of large messages. <ins> 5.1. A push service can improve the reliability of push message delivery considerably by storing push messages for a period.  User agents are often only intermittendly connected, and so benefit from having short term message storage at the push service. Delaying delivery might also be used to batch communication with the user agent, thereby conserving radio resources. Some push messages are not useful once a certain period of time elapses.  Delivery of messages after they have ceased to be relevant is wasteful.  For example, if the push message contains a call notification, receiving a message after the caller has abandoned the call is of no value; the application at the user agent is forced to suppress the message so that it does not generate a useless alert. An application server can use the TTL header field to limit the time that a push message is retained by a push service.  The TTL header field contains a value in seconds that describes how long a push message is retained by the push service. Once the TTL period elapses, the push service MUST remove the push message and cease any attempt to deliver it to the user agent.  A push service might retain values for a short duration after the TTL period to account for time accounting errors in processing.  For instance, distributing a push message within a server cluster might accrue errors due to clock variation, or processing and transit delays. A push service is not obligated to account for time spent by the application server in sending a push message to the push service, or delays incurred while sending a push message to the user agent.  An application server needs to account for transit delays in selecting a TTL header field value. Absence of the TTL header field is interpreted as equivalent to a zero value.  Push messages with a zero TTL indicate that storage is not needed and that the message can be dropped if the user agent isn't immediately available to receive the message.  Push messages with a zero TTL can be delivered very efficiently. A push service MAY choose to retain a push message for a shorter duration than that requested.  It indicates this by including a TTL header field in the response that includes the actual TTL.  This TTL value MUST be less than or equal to the value provided by the application server. </ins> 6. A user agent requests the delivery of new push messages by making a


Question:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

7.2. <del> Push services typically store messages for some time to allow for limited recovery from transient faults.  If a push message is stored, but not delivered, the push service can indicate the probable duration of storage by including expiration information in the response to the push request. </del> <ins> Storage of push messages based on the TTL header field comprises a potentially significant amount of storage for a push service.  A push service is not obligated to store messages indefinitely.  A push service is able to indicate how long it intends to retain a message to an application server using the TTL header field (see ttl). </ins> <del> A push service is not obligated to store messages indefinitely.  If a user agent is not actively monitoring for push messages, those messages can be lost or overridden by newer messages on the same subscription. </del> <ins> A user agent that does not actively monitor for push messages will not receive messages that expire during that interval. </ins> <del> Push messages that were stored and not delivered to a user agent are </del> <ins> Push messages that are stored and not delivered to a user agent are </ins> delivered when the user agent recommences monitoring.  Stored push messages SHOULD include a Last-Modified header field (see Section 2.2 of RFC7232) indicating when delivery was requested by an application


Question:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

Push services might need to limit the size and number of stored push messages to avoid overloading.  In addition to using the 413 (Payload Too Large) status code for too large push messages, a push service <del> MAY expire push messages prior to any advertised expiration time. </del> <ins> MAY expire push messages prior to any advertised expiration time.  A push service can reduce the impact push message retention by reducing the time-to-live of push messages. </ins> 7.3.


Question:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

9. <ins> This protocol defines new HTTP header fields in iana.header.fields. New link relation types are identified using the URNs defined in iana.urns. 9.1. HTTP header fields are registered within the "Message Headers" registry maintained at <https://www.iana.org/assignments/message- headers/>. This document defines the following HTTP header fields, so their associated registry entries shall be added according to the permanent registrations below (see RFC3864): The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". 9.2. </ins> This document registers three URNs for use in identifying link relation types.  These are added to a new "Web Push Identifiers" registry according to the procedures in Section 4 of RFC3553; the