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

[Benjamin Kaduk <[e-mail]>]

Hi Michael,

Thanks; this looks good and I'm happy to clear the discuss (and will do so
shortly).

A couple notes inline, and also one on the (nicely) expanded §5.2:

   When encryption is used, the use of AES-CCM [RFC3610] with a 64-bit	
   tag is recommended, combined with a sequence number and a replay	
   window.  This choice is informed by available hardware acceleration	
   of on many constrained systems.  If a different algorithm is	
   available accelerated on the sender, with similar strength, then it	
   SHOULD be preferred.  Where privacy of the state is not required, and	

(similar strength or stronger, presumably).

On Thu, Nov 05, 2020 at 11:16:18AM -0500, Michael Richardson wrote:
> The ID submission system is closed, but we have a -08 ready.

(It's open again now!)

> 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.

Okay, thanks for thinking about it.

> 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.

nit: I see what you are trying to say, but the current wording looks like
there's supposed to be cause/effect between doing the analysis and lack of
value in cryptographic protection.  Maybe s/as a result of/as revealed by/?

Thanks again!

-Ben

> 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.
>