Re: [core] integrity protection for trial-and-error determine of token length

[Michael Richardson <[e-mail]>]

    > #5 lack of integrity protection results in spoofed responses
    > https://github.com/core-wg/stateless/issues/5

bk> Also, when integrity protection is not in use, the client is susceptible
bk> to spoofed responses that had no corresponding request -- only a very
bk> limited subset of request/response pairs are safe to convert to
bk> "unauthenticated server push", as that would effectivley do, and we
bk> should probably mention that explicitly.

This is, I think, not about the responses to the trial-and-error, but about
fake/spoofed replies to queries that the client makes that have a token.

I'm not sure how stateless is intended to interact with OBSERVE, which I
think that this is about.   Have I understood this part?


bk> I'd also suggest noting that a self-encrypted state token bears
bk> significant resemblance to a TLS self-encrypted session ticket, and
bk> reference the RFC 5077 security considerations. (Yes, I know that RFC
bk> 8446 Obsoletes RFC 5077; it would be an informational reference only.)

It's certainly similar in that it is a self-encrypted thing in which state is
placed.  I don't think that a reference to RFC5077 will be helpful here, but
I can look for a good place to insert this if desired.

bk> This could also lead to some discussion about having in general an
bk> appropriate amount of sanity checks on the returned token that may or may
bk> not reflect serialized state, to limit the scope of various attacks even
bk> in the absence of cryptographic protections.

I think that an appropriate thing is to caution against using state tokens
that do not have integrity protection.  I think that we try to do this in
5.2, but maybe we do in text too cryptic:

5.2.  Stateless Clients and Intermediaries

...
   It is generally expected that the use of encryption, integrity
   protection, and replay protection for serialized state is
   appropriate.  In the absence of integrity and reply protection, an
   on-path attacker or rogue server/intermediary could return a state
   (either one modified in a reply, or an unsolicited one) that could
   alter the internal state of the client.  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.


https://github.com/core-wg/stateless/pull/13

diff --git a/draft-ietf-core-stateless.xml b/draft-ietf-core-stateless.xml
index aa44479..748ef21 100644
--- a/draft-ietf-core-stateless.xml
+++ b/draft-ietf-core-stateless.xml
@@ -856,10 +856,15 @@
           in a reply, or an unsolicited one) that could alter the internal state
           of the client.

-          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.
+          It is this reason that at least the use of integrity protection on
+          the token is always recommended.
+        </t>
+
+        <t>
+          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.
         </t>

         <t>



--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide