Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-stateless-06: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

The ID submission system is closed, but we have a -08 ready.

You can view the diff against -06 at:
 
https://ietf.org/rfcdiff?url1=draft-ietf-core-stateless-06.txt&url2=https://raw.githubusercontent.com/core-wg/stateless/master/draft-ietf-core-stateless-08.txt

If you'd like to approve updating this document, the XML is at:
 
https://raw.githubusercontent.com/core-wg/stateless/master/draft-ietf-core-stateless-08.xml

The document is ready.

On 2020-04-20 5:06 p.m., Benjamin Kaduk via Datatracker wrote:
 > ----------------------------------------------------------------------
 > DISCUSS:
 > ----------------------------------------------------------------------
 >
 > Let's discuss whether the various and sundry conditional SHOULDs in 
Section
 > 3.1 are better written as conditional MUSTs (i.e., with the listed
 > exclusions being the only allowed exclusion).

Hi, we have left them as SHOULD.
AFAIK, a SHOULD is a conditional MUST, and I agree that exclusions need 
to be
listed.

The security considerations say:
    It maybe that in some very specific case, as a result of a careful
    and detailed analysis of any potential attacks, that there may be
    cases where such cryptographic protections do not add value.  The
    authors of this document have not found such a use case as yet, but
    this is a local decision.

There are no interoperability requirements around what the token format is.
I don't feel strongly one way or another but it seems like the text is
already pretty clear.

 > Also, Appendix A.2 seems to show "Len (extended)" as just 0-2 bytes when
 > IIUC it is 0-4 bytes.

This was fixed in the diagram.

 > ----------------------------------------------------------------------
 > COMMENT:
 > ----------------------------------------------------------------------
 >
 > Section 2.1
 >
 >     The new definition of the TKL field increases the maximum token
 >     length that can be represented in a message to 65804 bytes.  However,
 >     the maximum token length that sender and recipient implementations
 >     support may be shorter.  For example, a constrained node of Class 1
 >     [RFC7228] might support extended token lengths only up to 32 bytes.
 >
 > Is there anything to say about IP MTU here?

Not really.   Obviously, if you can't fit the bigger token into the packet,
then you can't use it.

 > This is a fairly subtle way of saying that core RFC 7252
 > procedures/semantics are being updated; I'd suggest calling out 
(alongside
 > the other updates) the new(?) requirement for distinguishing whether an
 > extension is unrecognized vs. an invalid value by producing reset vs. a
 > distinguished error code.  (I do see that the semantics for 5.03 and 4.00
 > are not changing, but the use of Reset vs. error code for feature
 > negotiation seems important for implementors to be aware of.)

This was opened as https://github.com/core-wg/stateless/issues/3
The document already Updates RFC7252.

comments on Section 3.1/3.2 already applied

 > Section 4
 >
 > Perhaps it's worth noting that this nesting of state will necessarily
 > increase the token size as it progresses along a chain of intermediaries?
 >
 > There's also some considerations relating to how the freshness window 
of the
 > client an intermediary interact, with the client effectively being 
limited
 > to the minimum of all windows in use by client and intermediate(s) on the
 > path.
 >
 > If the intermediary has a very long freshness window it could be tricked
 > into sending "replies" to addresses that it thinks are clients but 
may not
 > be any more, e.g., allowing a DoS attack to traverse a NAT or firewall.

Opened as https://github.com/core-wg/stateless/issues/4
closed as wontfix after some discussion in the issue and on the list

 > Section 4.3
 >
 > RFC 7252 doesn't really suggest that there's a protocol element that 
would
 > be set to "infinite" here; perhaps we should just say that "in this case,
 > the gateway cannot return such a response and as such cannot 
implement such
 > a timeout".

Text updated as suggested.

 > Section 5
 >
 > With no integrity protection on the rejection of trial-and-error (section
 > 2.2.2) it's susceptible to downgrade, IIUC even by an off-path attacker.
 > (I did not think too hard about whether OSCORE could protect the 
Resets in
 > question or not, though.)  It seems like such forced downgrade would have
 > second-order effects in causing clients to use more local state and 
thus be
 > more readily susceptible to other DoS vecros.
 >
 > Also, when integrity protection is not in use, the client is 
susceptible to
 > spoofed responses that had no corresponding request -- only a very 
limited
 > subset of request/response pairs are safe to convert to "unauthenticated
 > server push", as that would effectivley do, and we should probably 
mention
 > that explicitly.
 >
 > I'd also suggest noting that a self-encrypted state token bears 
significant
 > resemblance to a TLS self-encrypted session ticket, and reference the RFC
 > 5077 security considerations.  (Yes, I know that RFC 8446 Obsoletes RFC
 > 5077; it would be an informational reference only.)
 >
 > This could also lead to some discussion about having in general an
 > appropriate amount of sanity checks on the returned token that may or may
 > not reflect serialized state, to limit the scope of various attacks 
even in
 > the absence of cryptographic protections.

open as issue: https://github.com/core-wg/stateless/issues/5
Text updated as per:
https://github.com/core-wg/stateless/commit/83535c69958467099cd20ca49d9bbb8e8cc03068 
and
https://github.com/core-wg/stateless/commit/83535c69958467099cd20ca49d9bbb8e8cc03068

 > Section 5.1
 >
 >     size that need to be mitigated.  A node in the server role supporting
 >     extended token lengths may be vulnerable to a denial-of-service when
 >     an attacker (either on-path or a malicious client) sends large tokens
 >     to fill up the memory of the node.  Implementations need to be
 >     prepared to handle such messages.
 >
 > This seems particularly problematic given that we disallow sending 
Reset in
 > response to too-large tokens and instead imply that it should echo 
the large
 > token in a 4.00 response.  I guess technically this is a SHOULD and not a
 > MUST, so there is some leeway to do something else, but what would that
 > "something else" be in this case?  It seems like we have a hard 
requirement
 > to do something sane with a token as large as 65804 bytes.

opened as https://github.com/core-wg/stateless/issues/6
Discussion is that in order to receive such a large token, you have to
receive it.  If you can receive such a large packet, then you can answer it.
As the token is never stored, there is no exhaustion attack possible.
closed as wontfix

 > Section 5.2
 >
 >     The use of encryption, integrity protection, and replay protection of
 >     serialized state is recommended, unless a careful analysis of any
 >     potential attacks to security and privacy is performed.  [...]
 >
 > I suggest an alternative wording:
 >
 > % It is generally expected that the use of encryption, integrity 
protection,
 > % and replay protection for serialized state is appropriate.  However, a
 > % careful analysis of any potential attacks to the security and privacy
 > % properties of the system might reveal that there are cases where such
 > % cryptographic protections do not add value in a specific case.

Text used as part of rewrite.
 >
 >     a 64 bit tag is recommended, combined with a sequence number and a
 >     replay window.  Where encryption is not needed, HMAC-SHA-256,
 >     combined with a sequence number and a replay window, may be used.
 >
 > Can we give guidance on sizing the replay window?
 > Should the HMAC-SHA-256 output be truncated akin to the truncated CCM 
tag?
 > In what cases would one want to use an absolute timestamp instead of/in
 > addition to a sequence-based replay window?

issue opened as: https://github.com/core-wg/stateless/issues/7
Replay recommendation/analysis is at:
https://github.com/core-wg/stateless/commit/b019c61e2b44757a4427956af95e99fbec15180e
updated by:
https://github.com/core-wg/stateless/commit/a7157fea61c3948899ded7311b5b0920cbd1b1c2
and then today by:
https://github.com/core-wg/stateless/pull/15

 >     guarantees are voided.  Devices with low-entropy sources -- as is
 >     typical with constrained devices, which incidentally happen to be a
 >     natural candidate for the stateless mechanism described in this
 >
 > nit: "low-entropy sources" is a weird phrasing; "low-quality entropy
 > sources" would feel more natural to me.
 > Also, draft-irtf-cfrg-randomness-improvements may be of interest to 
at least
 > some such devices.

suggested text adopted.

 >
 >     provides the above uniqueness guarantee.  Additionally, since it can
 >     be difficult to use AES-CCM securely when using statically configured
 >     keys, implementations should use automated key management [RFC4107].
 >
 > This is BCP 107, so I think we could use stronger language than "should
 > use".  Also we should cite it as the BCP.

open as https://github.com/core-wg/stateless/issues/8
We removed the reference to RFC4107.
There is no reason to cite RFC4107, there is no key agreement needed.
The key is entirely a local manner, and a few pull requests referenced in
this ticket rewrite that text.

 > Section 6.1
 >
 > Should the table formatting be consistent between here and Section 2.2.1?

The tables look similar now.