Subject: Re: [core] issues for stateless AD review

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Oct 2020 14:05:26 -0400

Carsten Bormann <[email-masked]> wrote:
    > On 2020-09-30, at 20:47, Michael Richardson <[email-masked]> wrote:
    >>
    >> I have created pull request #11 for this.  Please comment

    > A couple typos (pushed to the PR branch already) and two comments:

    > https://github.com/core-wg/stateless/pull/11/files

On the topic of "MAY" being BCP14 abuse, I was matching it to the RECOMMENDED
above.  based upon that, then I think that RECOMMENDED->recommended.

(Do you know about the "suggestion" part in github?)

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Oct 2020 14:23:03 -0400

>#10 60 minutes for address change
>   https://github.com/core-wg/stateless/issues/10

In this issue, Carsten wrote:

>  The number indeed sounds arbitrary. We could make use of the parameter
>  mechanics that RFC 7252 has (ACK_TIMEOUT and friends) and set the default
>  to 1800 s.

and I spent an hour pondering through RFC7252's timer section (which I was
intentionally ignorant of..) to try and figure out how to leverage
ACK_TIMEOUT.

My understanding of the concern it that the mapping of IPaddress -> maximum
token length might become invalid because the IPaddress might no longer be
associated with that host.

So we have to recheck things periodically, and the question is, what is a
useful period.  60 minutes seems arbitrary.  I don't see how ACK_TIMEOUT relates.

What I think would relate would be DHCPv[46] or Router Advertisement lifetimes.
I think that a node can assume that most *local* hosts will have a lifetime
similar to their own, so if one has a 7200s DHCP leases, then another host in
the same subnet will probably have a similar affity to an address.

Of course, this does *NOTHING* to help with hosts elsewhere.
So for non-local hosts, a default, as Carsten suggested of 1800s (30min)
seems as appropriate as 60 minute.
What we are looking for is a way to intelligently increase the value as high
as possible so as to reduce traffic.  DNS TTLs seem to fit here as a hint.

That fails if the connection is configured with raw IPs, but then back to the defaults.

Pull request: https://github.com/core-wg/stateless/pull/12

diff --git a/draft-ietf-core-stateless.xml b/draft-ietf-core-stateless.xml
index aa44479..1999971 100644
--- a/draft-ietf-core-stateless.xml
+++ b/draft-ietf-core-stateless.xml
@@ -417,10 +417,13 @@
           </t>

           <t>
-            Since network addresses may change,
-            a client SHOULD NOT assume that extended token lengths are supported
-            by a server later than 60 minutes after receiving the most-recent response with an extended
-            token length.
+            Since network addresses may change, a client SHOULD NOT assume that extended token
+            lengths are supported by a server for an unlimited duration.
+            Unless additional information is available, the client should assume that addresses (and therefore extended token lengths) are valid for a minimum of 1800s, and for a maximum of 86400s (1 day).
+            A client may use additional forms of input into this determination.
+            For instance a client may assume a server which is in the same subnet as the client has a similiar address lifetime as the client.
+            The client may use DHCP lease times or Router Advertisements to set the limits.
+            For servers which is not local, if the server was looked up using DNS, then the DNS resource record will have a Time To Live, and the extended token length should be kept for only that amount of time.
           </t>

           <t>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Oct 2020 14:36:08 -0400

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

bk> With no integrity protection on the rejection of trial-and-error (section
bk> 2.2.2) it's susceptible to downgrade, IIUC even by an off-path
bk> attacker. (I did not think too hard about whether OSCORE could protect
bk> the Resets in question or not, though.) It seems like such forced
bk> downgrade would have second-order effects in causing clients to use more
bk> local state and thus be more readily susceptible to other DoS vecros.

My understanding is that the Reset will have to echo the MID.
While they are probably incrementally assigned, and so not a lot of
protection, off path attackers do not see them.
RFC7252 section 5.3.1 says that they can be:
   (Note that
   the Message ID adds little in protection as it is usually
   sequentially assigned, i.e., guessable, and can be circumvented by
   spoofing a separate response.

but, I don't think the separate response is substitutable for the Reset.
The Reset includes the message ID, so I think that we have some minimal
defense against an off-path attacker that just sprays Resets.
It also seems that such an attack breaks many other things already.

My second observation, as a user of stateless in 6tisch-minimal-security.
We can not function when the token length is smaller than some amount.
We don't resort to keep state, we failover to another server, or we just break.
So, while this might be a DoS attack, this is not a downgrade attack.

Also, we assume L2 security across the wireless portion, but the attack could
originate on some wired segment from some infected "desktop" plant control
system.

I'm not too sure what text I can add, but I can include the above discussion.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Oct 2020 15:17:08 -0400

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Oct 2020 21:17:58 +0200

On 2020-10-01, at 20:23, Michael Richardson <[email-masked]> wrote:
> 
> I don't see how ACK_TIMEOUT relates.

It doesn’t.

The way that RFC 7252 manages (not-so) constants like that does.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Oct 2020 15:20:58 -0400

At this point, I will stop, and hope that the WG will comments on the threads
and github.

Carsten Bormann <[email-masked]> wrote:
    >> With Klaus' blessing, I have turned the remaining DISCUSS points into
    >> issues.

    > (And I sent some comments.)

    > Overall, I think we should generate I-D text for:

done.

    > We should replace confusing I-D text here:
    > #8 use automated key management due to AES-CCM/BCP107
    > https://github.com/core-wg/stateless/issues/8

done.

    > #4 how does freshness window of client/intermediate interact?
    > https://github.com/core-wg/stateless/issues/4

I can see some text added for this, commented.

    > I think we can simply explain a wontfix on:

    > #3 is stateless updating 7252 on distinguishing unrecognized vs invalid
    > extension?  https://github.com/core-wg/stateless/issues/3

    > #6 can larger tokens fill responder memory?
    > https://github.com/core-wg/stateless/issues/6

    > #7 how to size the replay window?
    > https://github.com/core-wg/stateless/issues/7

    > #9 look ma, no state!  https://github.com/core-wg/stateless/issues/9

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Oct 2020 16:22:11 -0400

> The way that RFC 7252 manages (not-so) constants like that does.

I thought that the suggestion was to have the value somehow be some function
of ACK_TIMEOUT.
I guess you mean, that it would be specified in the same fashion?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Oct 2020 23:08:58 +0200

> I thought that the suggestion was to have the value somehow be some function

No, I don’t see how they are related.

> I guess you mean, that it would be specified in the same fashion?

Yes, the transmission parameters in Section 4.8 are a good way to contain the “need to pick out of thin air” values we rely on… 

Grüße, Carsten

---

From: Jaime Jiménez <[email-masked]>
Date: Tue, 6 Oct 2020 18:26:51 +0300

Hi Michael,

I am curious, what was the issue with pip and xml2rfc

Ciao!
-- Jaime

On 30.09.2020 14:47, Michael Richardson wrote:
>_______________________________________________
>core mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/core

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2020 13:32:52 -0400

> I am curious, what was the issue with pip and xml2rfc

AFAIK, xml2rfc really needs python3 now.

Putting the following into .travis.yml:

+python:
+  - "3.8"
+

 install:
- - pip install xml2rfc
+ - pip3 install xml2rfc

Solved the problem, I think.
I also bumped the distro to "bionic", but it's not until ubuntu 20 (Foccil?)
that python3 is the default.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 8 Oct 2020 11:14:42 -0400

>     https://github.com/core-wg/stateless/issues/8

This discussion in today's meeting suggested that we replace some of the 
nonce discussion with a reference to OSCORE (RFC8613) Appendix B.1.1:

https://github.com/core-wg/stateless/pull/11/files shows the diff.
The resulting text for section 5.2 is:

    Transporting the state needed by a client to process a response as
    serialized state information in the token has several significant and
    non-obvious security and privacy implications that need to be
    mitigated; see Section 3.1 for recommendations.

    In addition to the format requirements outlined there,
    implementations need to ensure that they are not vulnerable to
    maliciously crafted, delayed, or replayed tokens.

    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 might not add value in a
    specific case.  For instance, if the state is an opaque (not
    sequential) index into a table of existing state.  The choice to
    employ encryption for the state token is purely a local decision
    based upon understanding of threats to internal state.

    It should further be emphasized that the encrypted state is created
    by the sending node, and decrypted by the same node when receiving a
    response.  The key is not shared with any other system.  Therefore
    the choice of encryption scheme and the generation of the key for
    this system is purely a local matter.

    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
    encryption is not needed, HMAC-SHA-256 [RFC6234], combined with a
    sequence number and a replay window, may be used.

    When using an encryption mode that depends on a nonce, such as AES-
    CCM, repeated use of the same nonce under the same key causes the
    cipher to fail catastrophically.

    If a nonce is ever used for more than one encryption operation with
    the same key, then the same key stream gets used to encrypt both
    plaintexts and the confidentiality guarantees are voided.  Devices
    with low-quality entropy sources -- as is typical with constrained
    devices, which incidentally happen to be a natural candidate for the
    stateless mechanism described in this document -- need to carefully
    pick a nonce generation mechanism that provides the above uniqueness
    guarantee.

    [RFC8613] appendix B.1.1 ("Sender Sequence Number") provides a model
    for how to maintain non-repeating nonces without causing excessive
    wear of flash.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 8 Oct 2020 13:05:46 -0400

> #3  is stateless updating 7252 on distinguishing unrecognized vs invalid extension?
>     https://github.com/core-wg/stateless/issues/3

It seems that the core of this comment is that stateless should "Update" 
(in the form of "Amends") RFC7252.   I think that is a reasonable thing 
to do.

>     https://github.com/core-wg/stateless/issues/4

The on-path attacker that can see the token, can send a reply first 
(dropping the real reply), using up the replay, and thus attack, like 
any UDP protocol.
The off-path attacker that can see the traffic (whatever we are going to 
call that, see saag), would have to race the legitimate response, 
otherwise they would get marked as a replay.
Marked wontfix.

>     https://github.com/core-wg/stateless/issues/6

Marked wontfix:  Klaus' reply explains that if one doesn't have a buffer 
big enough to receive the packet, then one can't get one's memory exhausted.

>     https://github.com/core-wg/stateless/issues/7

Upon re-reading, I think that we can answer this with: 
https://github.com/core-wg/stateless/pull/14/files

> #9  look ma, no state!
>     https://github.com/core-wg/stateless/issues/9

closed wontfix.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 8 Oct 2020 20:01:41 +0200

On 2020-10-08, at 19:05, Michael Richardson <[email-masked]> wrote:
> 
> The on-path attacker that can see the token, can send a reply first (dropping the real reply), using up the replay, and thus attack, like any UDP protocol.
> The off-path attacker that can see the traffic (whatever we are going to call that, see saag), would have to race the legitimate response, otherwise they would get marked as a replay.

Let’s try not to import the brokenness of the terminology being introduced in SAAG to this document.

An on-path attacker is on-path, but doesn’t necessarily have the power to suppress or modify messages (that would be an in-path attacker? We used to say MITM and this was clear).

An off-path attacker is not seeing the messages; they can only inject (blind attacker) or start new conversations (thus becoming a form of on-path for that conversation).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 Oct 2020 11:17:29 -0400

On 2020-09-29 2:14 p.m., Michael Richardson wrote:
> 
> With Klaus' blessing, I have turned the remaining DISCUSS points into issues.
> I list them below.
> I will begin posting them to the list for discussion in an hour or so along
> with some proposed changed text (pull requests).
> 
> Barry: Quite a number of points were already dealt with, but we need confirmation
>         from the AD that they were dealt with.  If needed, I can collect those into
>         an email.
> 
> It seems that all of the comments from Roman were dealt with, possibly with
> the exception of issue 9 ("look ma, no state"), which seems like a "wontfix".
> 
> Roman had cleared his DISCUSS.
> The second DISCUSS was from Erik Kline.
> 
> Here is the list of issues.  The titles are mine.

At this point, I would like to ask the WG to declare the work done.
There is one more pull request that could use some endorsement/review
     https://github.com/core-wg/stateless/pull/11

I'd like to post a new ID tomorrow.