Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Christian,

My apologies for the slow response as well.  I don't think I have as good
of an excuse...

I am really happy with the direction taken in the -13 and will reballot
after sending this, with some editorial/nit remarks.

On Sun, Jul 18, 2021 at 10:38:17PM +0200, Christian Amsüss wrote:
> Hello Ben,
> 
> thanks for your input on echo-request-tag, and apologies for the delay
> in processing them to completion -- I should have taken your note on
> "fairly substantive comments that might result in significant text
> changes" more seriously.
> 
> Please see [1] for a few general comments; here are individual responses
> to your comments (with suggested terms / phrases that were accepted and
> similar small items removed from the list):
> 
> > Thank you for working on this document; these mechanisms are important
> > and will help fill some long-standing gaps in CoAP operation.  That
> > said, I do have some fairly substantive comments that might result in
> > significant text changes.
> > 
> > While I recognize that there is going to be a spectrum of requirements
> > for determining freshness, I would have expected the far extreme of that
> > spectrum to include a strongly time-limited single-use cryptographic
> > nonce (akin to what the ACME protocol of RFC 8555 uses but with time
> > limit), as well as discussion of some points on the spectrum and which
> > ones might be more or less appropriate in various cases.  I do see some
> > discussion of different use cases, but not much about the tradeoffs
> > along the spectrum, and no discussion at all about the strongest
> > properties that it is possible to obtain with this mechanism.
> 
> This spectrum, with the axes kind-of-freshness and
> authority-over-synchronized-property, is now described in a new
> Characterization of Echo Applications subsection, which includes
> limited-time-single-use as a combined form of kind-of-freshness.
> 
> Particularly the part that deals with unique-but-predictable Echo values
> is frequently referenced later, and also mentioned in [1] as
> GENERIC-SHORT-ECHO.
> 
> (It also addresses Roman's "helpful to explicitly state".)
> 
> > In several places we mention that the Echo option enables a server to
> > "synchronize state", which to me is a confusing or misleading
> > characterization -- as I understand it, both additional (application)
> > protocol mechanism and constraints are required in order for state
> > synchronization to occur.  Specifically, the client has to be the
> > authority for the state in question, and the application protocol needs
> > to specifically indicate under what conditions and which state is to be
> > synchronized.  In essence, the Echo option provides a mechanism for
> > ensuring request freshness, and that mechanism is leveraged by the
> > application protocol to make a synchronzed transfer of state from client
> > to server.  But AFAICT it is not a generic state synchronization
> > mechanism, the state to be synchronized is not conveyed in the option
> > body, etc.  My preference would be to take "synchronize state" out of
> > the primary list of what is possible and mention it in a separate
> > sentence as something that can be constructed using the functionality
> > that the Echo option provides.
> 
> State synchronization is indeed something that can be done with
> freshness; text was tweaked to make that more visible. It's still
> mentioned often together with freshness, as it is a very important class
> of use cases. That the state is not carried inside the Echo option is
> now emphasised in the applications list.
> 
> On the topic of authority, this is now covered in the characterization
> of Echo applications (see also GENERIC-SHORT-ECHO).
> 
> > There are a couple places where we recommend (implicitly or explicitly)
> > a sequential counter in contexts that might otherwise use a randomized
> > value.  I think I mention them all in my section-by-section comments,
> > but in general the sequential counter might be placing too strong a
> > requirement on the value, and the considerations of
> > draft-gont-numeric-ids-sec-considerations seem relevant.
> 
> Under the threat model of pearg-numeric-ids-generation, relevant
> identifiers are outer Request-Tag and outer Echo values of OSCORE (as
> inner and DTLS protected ones are protected by message integrity, and
> Token rules are only updated for DTLS where it is protected as well).

The network attacker is definitely the most important case to cover, and I
agree with your assessment for that case.  I think the PEARG work does also
consider some other cases where there can be information leakage even to
the intended recipient, but those tend to result from a counter on one
endpoint that is global across all endpoints (and thus can reveal
information about what's happening with endpoints other than the one
receiving the values).  It would be a bit of a stretch for that to apply
here (I guess it could happen for something like an integrity protected
timestamp that has the actual timestamp in the clear, but where the
timestamp is only updated in a way that depends on the global traffic
pattern at the server, and so if the client sees timestamps that don't
correspond to its own traffic the client can learn something about other
traffic), though...

> For the remaining cases, a paragraph has been added to the privacy
> considerations section.

...so I think it's fine to call this "good enough" and leave it as-is.

> > I think it would also be enlightening to have a comparison between the
> > anti-replay/freshness properties provided by the optional DTLS replay
> > protection mechanism and the Echo option.  I know they have differences,
> > but I think there is also some commonality, and giving readers guidance
> > on whether one vs the other suffices or both are needed could be useful.
> 
> Such a comparison was attempted, but found to be tied too deeply into
> core-coap-attacks; an issue has been opened at
> https://github.com/EricssonResearch/coap-actuators/issues/8.

Ok.  Thank you for attempting the comparison (and it's interesting even to
learn that it's tied into the core-coap-attacks work!)

> That comment did inspire a paragraph on the relationship between
> Request-Tag and replay protection, which did get more interesting when
> the document was adapted in awareness of DTLS's option to not use replay
> protection at all.

Yes, that paragraph seems quite helpful to have!

> > Section 2.3
> > 
> >    Upon receiving a 4.01 Unauthorized response with the Echo option, the
> >    client SHOULD resend the original request with the addition of an
> >    Echo option with the received Echo option value.  [...]
> > 
> > [just noting that IIUC the revised requirements on token generation made
> > later in this document are needed in order for this "resend the original
> > request" to be safe" ... I am not sure if it needs to be called out here
> > specifically, though.]
> 
> If the client does not increment the token, it would be susceptible to
> the 4.01 response being reinjected, so it may try again -- but as it is
> not incrementing tokens, the server processes the request only once
> anyway (but the client is left ignorant of its success).
> 
> So yes there are some light implications (and more severe ones in corner
> cases), but the trouble from token reuse is so much bigger than this one
> case that pointing it out specifically would probably distract more than
> help.

Ok, makes sense.

> > I don't think the example of this in Figure 3 meets the requirements,
> > though, since the echo option value is just a counter that is easily
> > spoofable.
> 
> It does meet the particular requirement of the above paragraph
> ("different except with negligible probability") as it is just counting
> up (where after 255 events it'd overflow to two bytes and further).
> 
> For the general requirements, these should now be clearer (see
> GENERIC-SHORT-ECHO).
> 
> >    [...] When used to demonstrate
> >    reachability at a claimed network address, the Echo option SHOULD
> >    contain the client's network address, but MAY be unprotected.
> > 
> > What does "contain" mean, here?  Plaintext?  That seems potentially
> > problematic; using it as an input to the MAC that is not transmitted (as
> > I mention later) is more conventional, in my understanding.
> 
> That's what it should have said in the first place; fixed.
> 
> >                              The CoAP client side of HTTP-to-CoAP
> >    proxies SHOULD respond to Echo challenges themselves if they know
> >    from the recent establishing of the connection that the HTTP request
> >    is fresh.  Otherwise, they SHOULD respond with 503 Service
> >    Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive
> >    connection.  If the HTTP request arrived in Early Data, the proxy
> >    SHOULD use a 425 Too Early response instead (see [RFC8470]).  They
> >    MAY also use other mechanisms to establish freshness of the HTTP
> >    request that are not specified here.
> > 
> > Where is the MUST-level requirement to actually ensure freshness (by
> > whatever mechanism is available/appropriate)?
> 
> That was indeed missing; the "they SHOULD respond with" was intended to
> leave room for other methods of obtaining freshness, not to just ignore
> the issue and respond to the Echo challenge unchecked. A "MUST NOT
> repeat an unsafe request and [SHOULD]" was added.
> 
> (The exception for safe methods allows filling caches, similar to how
> item 3.1 of the Applications of the Echo Option section describes
> CoAP-CoAP proxies that forward to their client interface though they
> reject on their server interface).
> 
> >        *  If a server reboots during operation it may need to
> >           synchronize state or time before continuing the interaction.
> >           For example, with OSCORE it is possible to reuse a partly
> >           persistently stored security context by synchronizing the
> >           Partial IV (sequence number) using the Echo option, see
> >           Section 7.5 of [RFC8613].
> > 
> > In light of my toplevel comment, I'd suggest rewording this to clarify
> > that the protocol specified in RFC 8613 includes a mechanism for
> > resynchronizing the partial IV state, that uses the Echo option in a
> > specific controlled protocol interaction.
> >
> > (A similar consideration would apply to the group communication example,
> > though it might be a little harder to write clearly.)
> 
> The "authority over synchronized property" concept intoduced in response
> to the toplevel comment (GENERIC-SHORT-ECHO) covers most of this. Thus,
> also the time synchronization given can be valid here -- provided the
> client is a recognize authority for it. Which, in a group case, it will
> likely not be; thus, removing the example from there. (Also upgrading
> the "see" to an "as specified" to softly indicate that this is not done
> easily).
> 
> >    3.  A server that sends large responses to unauthenticated peers
> >        SHOULD mitigate amplification attacks such as described in
> >        Section 11.3 of [RFC7252] (where an attacker would put a victim's
> >        address in the source address of a CoAP request).  The
> >        RECOMMENDED way to do this is to ask a client to Echo its request
> >        to verify its source address.  [...]
> > 
> > (editorial) this usage of "ask a client to Echo its request" seems
> > rather divorced from the actual mechanicis of the Echo option...in the
> > rest of the document (bar one other instance noted below) we restrain
> > ourselves to saying that the Echo option is what is echoed, divorced
> > from the containing request/response.
> 
> It kind of makes sense, but (with the current terminology) would really
> need terminology introduction. This particular occurrence has been
> cleared up in unrelated edits already; the later is changed.
> 
> >                                       This needs to be done only once
> >        per peer [...]
> > 
> > How is the "peer" identified in this case?  Is it tied to a single
> > (security) association, or the identity (if any) associated with that
> > security association, or IP address (and port?), or something else?
> > How long can/should the reachability information be cached for?
> 
> Different strategies are valid here, and to be honest it may need some
> additional deployment experience to give hard and fast criteria here.
> 
> The distinction only starts to matter when an attacker finds a potential
> amplification helper that already is in legitimate contact with its
> victim.  Picking "the endpoint" as peer definition (which is host and
> port on both sides, plus the security association), as that curbs the
> attack at least in the case in which the amplification-helper-to-be does
> the OSCORE itself, and will then be suspicious of unprotected requests
> for large responses from the attacker.
> 
> There is some wiggle room in the interpretation of endpoint, especially
> in layered setups (I like to think of a CoAP library as a proxy that
> translates CoAP-over-API to CoAP-over-transport), and some room for
> optimization (if the unsecured endpoint is good, no need to check for
> reachability of the secured equivalent), but that at last *will* need
> the deployment experience to be gathered over the next months and years
> to see what is practical.

I see this is quite a bit more complicated than I thought at first!  Thanks
for explaining the situation for me.

> > Section 3.1
> > 
> >                                            In order for a security
> >    protocol to support CoAP operations over unreliable transports, it
> >    must allow out-of-order delivery of messages using e.g. a sliding
> >    replay window such as described in Section 4.1.2.6 of DTLS
> >    ([RFC6347]).
> > 
> > My understanding is that the requirement is only to allow out-of-order
> > delivery of messages (not necessarily including replay detection), so
> > the clause about the sliding window is not needed. here.
> 
> Indeed. Realizing that DTLS can be used with replay protection off made
> this half-sentence go away and caused some follow-up adaptions.
> 
> > Section 3.2
> > 
> >    In essence, it is an implementation of the "proxy-safe elective
> >    option" used just to "vary the cache key" as suggested in [RFC7959]
> >    Section 2.4.
> > 
> > The referenced section of RFC 7959 covers Block2 operation, but my
> > understanding is that the Block1 operation (covered in Section 2.5 of
> > that same document) would be a more applicable reference.
> 
> Section 2.4 is where the cited suggestion is made. This is the relevant
> reference because there it is made clear that "the resource" to which
> block operations are keyed is the cache key and not the URI.
> 
> Section 2.5 explains the general Block1 phase behavior. Its last
> paragraph is on concurrent transfers, but does not add anything to the
> understanding of Request-Tag, whereas the 2.4 statements contain the
> justification for why this can work that way (which applies to Block1
> and Block2 alike).

(Okay, I see now that you are correct.)

> > Section 3.3
> > 
> >                                          Also, a client that lost
> >    interest in an old operation but wants to start over can overwrite
> >    the server's old state with a new initial (num=0) Block1 request and
> >    the same Request-Tag under some circumstances.  Likewise, that
> >    results in the new message not being part of the old operation.
> > 
> > Where are those "some circumstances" enumerated?
> 
> This could precisely this could say "if the client can recycle the
> request tag" -- but that has not been introduced at this point, and more
> importantly the paragraph is about server behavior (examplifying how
> "equal request tags" doesn't necessarily mean "same operation").
> 
> >    *  The client MUST NOT regard a block-wise request operation as
> >       concluded unless all of the messages the client previously sent in
> >       the operation have been confirmed by the message integrity
> >       protection mechanism, [...]
> > 
> > nit: confirmed as what?  Delivered?
> 
> With the DTLS replay window realization, this would have become
> unwieldly, and thus was simplified to the "when the client knows the
> server won't accept it" that was already there. What that means in
> practice is spelled out for OSCORE and DTLS in the following paragraphs
> anyway.
> 
> >       In DTLS, this can only be confirmed if the request message was not
> >       retransmitted, and was responded to.
> > 
> > Similarly, this would be "When security services are provided by DTLS"
> > -- DTLS does include a native retransmission layer, but only for DTLS
> > handshake messages, so this phrasing is needlessly ambiguous as to
> > whether it is the CoAP request that got retransmitted.
> 
> The point about retransmission is on CoAP here; made more explicit in
> the rephrasing.
> 
> The line was also changed to include the necessity for the server to
> perform replay protection (which until the RD review I was unaware was
> even optional).  The over-all statement (which leaves the door open for
> request tag recycling in DTLS) is left open, even though this new
> constraint is making it *even* harder to be sure -- but the situations
> in which that could previously done were already pretty niche, and in a
> setup where the application can alreay know what got ACKed and what got
> retransmitted, it is not out of the question that it knows the server
> well enough to assert that it has replay protection active as well.
> 
> >    Authors of other documents (e.g. applications of [RFC8613]) are
> >    invited to mandate this behavior for clients that execute block-wise
> >    interactions over secured transports.  In this way, the server can
> >    rely on a conforming client to set the Request-Tag option when
> >    required, and thereby conclude on the integrity of the assembled
> >    body.
> > 
> > Could you clarify which client behavior would be mandated?  The overall
> > "body integrity based on payload integrity" procedures, or the specific
> > "typically, in OSCORE" behavior?
> 
> The behavior is the whole subsection's. (Many such specifications WOULD
> PROBABLY also mandate a particular security mechanism, narrowing it down
> to one of the cases, but the intention is to use the abstract behavior)
> 
> Now clarified.
> 
> > Section 3.6
> > 
> >    The Request-Tag option is repeatable because this easily allows
> >    several cascaded stateless proxies to each put in an origin address.
> >    They can perform the steps of Section 3.5.3 without the need to
> >    create an option value that is the concatenation of the received
> >    option and their own value, and can simply add a new Request-Tag
> >    option unconditionally.
> > 
> > Thanks for including this!  However, it wasn't clear to me from reading
> > https://tools.ietf.org/html/rfc7252#section-5.4.5 and this document
> > whether the order of repeated Request-Tag options was significant.
> > Some clarification might be helpful.
> 
> The order of CoAP options is significant in the information model (and
> if any doubt on this arises, core-corr-clar would be the place to to
> dispell them).
> 
> As Request-Tag has no own semantics, intermediaries can put theirs in
> the front or back (or not use repeatability at all), but as implementers
> can pick any, I don't see much to point out.

Makes sense.

> > Section 3.7
> > 
> >    That approach would have been difficult to roll out reliably on DTLS
> >    where many implementations do not expose sequence numbers, and would
> >    still not prevent attacks like in [I-D.mattsson-core-coap-actuators]
> >    Section 2.5.2.
> > 
> > (I agree that DTLS implementations largely don't expose sequence numbers
> > and that is unlikely to change.  But) I am not sure I fully understand
> > the scenario referenced in draft-mattsson-core-coap-actuators §2.5.2.
> > Perhaps it is not what was intended to be conveyed, but it seems like in
> > a setup that is tracking both sequence and fragment numbers, it would be
> > pretty easy to enforce that a fragment-0 block will only start a new
> > request if the sequence number is larger than the sequence number of the
> > current/previous blockwise request.  IIUC that would reject the
> > "withheld first block" as being too old.
> 
> Enforcing that means that not only state about ongoing block-wise
> operations is kept (which is about as much state as can be tolerated),
> but that in addition also state about block-wise transfers that are not
> pursued any more would need to be kept -- and that's too much to ask (as
> it'd be per-client times per-resource information).

There might be a variant that only needs per-client state, but we're pretty
far off in the weeds here so I don't think we should spend more time
thinking about it.

> > Section 3.8
> > 
> >                     and MUST NOT use the same ETag value for different
> >    representations of a resource.
> > 
> > (side note) I was a little surprised that this was not already a
> > requirement, but I couldn't find an equivalent statement in a quick
> > review of RFC 7252.  (It's definitely correct that this is required
> > behavior to get the protection in question.)
> 
> Neither was any found in RFC 7959.
> 
> > Section 4.1
> > 
> >    In HTTPS, this type of binding is always assured by the ordered and
> >    reliable delivery as well as mandating that the server sends
> >    responses in the same order that the requests were received.  [...]
> > 
> > I believe this description applies to HTTP/1.1 over TLS, but not to
> > HTTP/2 or HTTP/3 (both of which provide other mechanisms for reliably
> > binding requests and responses in the form of stream IDs).
> 
> Changed to refer to HTTP/1.1. Covering what /2 and /3 do might be
> interesting comparison material, but given we're just tweaking the Token
> mechanism here (and not introducing it anew, which would warrant the
> detailed related-work comparison over the setting-the-mental-frame
> reference to HTTP/1.1), that should suffice.
> 
> > Section 4.2
> > 
> >    One easy way to accomplish this is to implement the Token (or part of
> >    the Token) as a sequence number starting at zero for each new or
> >    rekeyed secure connection.  This approach SHOULD be followed.
> > 
> > I note that sequential assignment often has some additional undesirable
> > properties, as discussed in draft-gont-numeric-ids-sec-considerations.
> > Would a different method (e.g., one listed in
> > draft-irtf-pearg-numeric-ids-generation) provide the needed properties
> > with fewer side effects?
> > In particular, sequential increment is at odds with the "nontrivial,
> > randomized token" recommended for clients not using TLS (that is
> > intended to guard against spoofing of responses).
> > ("use of a sequence number" and "a sequence number approach" also appear
> > in §5.1, if this is changed.)
> 
> These recommendations are for secured transports without
> request-response binding, i.e. DTLS. As the identifiers are protected by
> the DTLS integrity protection, they are outside the scope of the threat
> model described in numeric-ids-generation. (On the other hand, the
> nontrivial, randomized token recommended for non-TLS cases, and this
> document makes no updates for them.)
> 
> The concepts of numeric-ids did result in additions to the privacy
> considerations for outer Echo and Request-Tag values.
> 
> >    For the purpose of generating timestamps for Echo a server MAY set a
> >    timer at reboot and use the time since reboot, in a unit such that
> >    different requests arrive at different times.  [...]
> > 
> > Something about this sentence confuses me, possibly around "in a unit".
> 
> "choosing the granularity such that". (Which may not be necessary for all
> applications, but is convenient when using both time and events).
> 
> > Section 5.1
> > 
> >    Tokens that cannot be reused need to be handled appropriately.  This
> >    could be solved by increasing the Token as soon as the currently used
> >    Token cannot be reused, or by keeping a list of all blacklisted
> >    Tokens.
> > 
> > editorial: perhaps "unsafe to reuse" is more clear than "blacklisted"?
> 
> Changed simillarly ("keeling a list of all Tokens unsuitable for reuse").
> 
> > Section 6
> > 
> > This seems to be the first (and only) place where we use the term
> > "preemptive Echo values"; it might be worth a bit more exposition that
> > these are ones piggybacked on non-4.01 responses (assuming that's
> > correct, of course).
> 
> It is, and now properly introduced.
> 
> > Section 8.1
> > 
> > I note that DTLS 1.3 is in IETF Last Call.  I did not notice anything in
> > this document that's specific to a DTLS version, which suggests that it
> > woudl be safe to change the reference according to relative publication
> > order of these documents.  It would be good for the authors to confirm
> > that at their leisure, so as to not be rushed into a decision if/when
> > the RFC Editor asks during their processing.
> 
> DTLS 1.3. works just as fine, a note to the editor has been added.
> 
> > Section 8.2
> > 
> > I note that draft-mattsson-core-coap-actuators is referenced from
> > several locations (for useful additional discussion, to be clear), but
> > it is only an individual draft that expired almost two years ago.  Is
> > there any likelihood that it will ever progress to an RFC?
> 
> Work on the document has been taken up again as
> draft-mattsson-core-coap-attacks-00, the references are updated.
> 
> > One might argue that "SHOULD use a 425 Too Early response" is enough to
> > promote RFC 8470 to being a normative reference (see
> > https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/).
> 
> Given there is no way to indicate modularity here, yes, that's what the
> rules say; changed.
> 
> > Section A
> > 
> >    2.  Integrity Protected Timestamp.  The Echo option value is an
> >    integrity protected timestamp.  The timestamp can have different
> >    resolution and range.  A 32-bit timestamp can e.g. give a resolution
> >    of 1 second with a range of 136 years.  The (pseudo-)random secret
> >    key is generated by the server and not shared with any other party.
> >    The use of truncated HMAC-SHA-256 is RECOMMENDED.  With a 32-bit
> >    timestamp and a 64-bit MAC, the size of the Echo option value is 12
> >    bytes and the Server state is small and constant.  The security
> >    against an attacker guessing echo values is given by the MAC length.
> >    If the server loses time continuity, e.g. due to reboot, the old key
> >    MUST be deleted and replaced by a new random secret key.  Note that
> >    the privacy considerations in Section 6 may apply to the timestamp.
> >    Therefore, it might be important to encrypt it.  Depending on the
> >    choice of encryption algorithms, this may require a nonce to be
> >    included in the Echo option value.
> > 
> > I note that a MAC construction allows additional information to be
> > covered under the MAC that is not sent alongside it, e.g., identity
> > information about the client to which the Echo option value is being
> > associated.  Are there common situations in which including such
> > additional contextual information under the MAC would be valuable (to
> > prevent an echo option value received on one connection from being
> > usable on a different one)?
> 
> There is one -- demonstrating network reachability. It's not a common
> case (often the large responses are from GETs that don't need freshness
> anyway), but educational in the sense that it helps fill the continuum
> between MAC-the-address (RECOMMENDED for reachability) and
> time-and-MAC-of-time (RECOMMENDED for freshness) to guide the reader
> towards understanding the whole and not just coding down the recipes.
> Added.
> 
> >    3.  Persistent Counter.  This is an event-based freshness method
> >    usable for state synchronization (for example after volatile state
> >    has been lost), and cannot be used for client aliveness.  It requires
> >    that the client can be trusted to not spuriously produce Echo values.
> > 
> > I have severe qualms about specifying a protocol mechcanism that relies
> > on trusting a client to this extent.  It seems to expose a lot of latent
> > risk; even if we think there should be mechanisms in place to protect
> > against that risk, they might fail, or the mechanism might get used
> > outside its intended context, etc.; if there are other mechanisms
> > available for similar cost that provide the needed properties it seems
> > more robust to suggest their use in place of the persistent counter.
> 
> The additions of GENERIC-SHORT-ECHO, especially on "authority over
> synchronized property", should help in describing this and limiting any
> ill-effects.

It does help, and thanks again for writing it up so nicely.

Thanks again for all the changes and responses here -- even though I didn't
reply to all of them, I did read them.

-Ben

> If the client is *not* trusted, we're fast into the order of magnitude
> of 64-bit MACs; anything less might just give a false sense of security.
> Where these are transported regularly (as in [RD]), that quickly adds up
> in total bytes on the air. Thes cases *do* need good analysis, and it is
> hoped that with the new text the tools for this are there, but when the
> result is that trusting the client on this freshness is fine, then a
> counter should be too and has the least cost.
> 
> Best regards
> Christian
> 
> [1]: https://mailarchive.ietf.org/arch/msg/core/SIHjiM5AjFRZJRZGUjf3cW1sUu4
> [RD]: https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28.html#name-request-freshness
> 
> -- 
> This may seem a bit weird, but that's okay, because it is weird.
>   -- perldata(1) about perl variables