Subject: [stir] Thought on Alg

From: Eric Burger <[email-masked]>
Date: Sun, 27 Sep 2015 12:41:51 -0400

Is there a scenario where hacking the Alg parameter would result in a successful verification? I suppose with enough computing power couple with perhaps a reverse dictionary attack, one could step down the Alg and insert what one wanted into the Identity-Info header and keep the signature unchanged. However, I am assuming that is a vanishingly small possibility.

The current text (Section 10.3) leads one to start wondering why we do not include Alg in the signature calculation. It’s just a few more bytes. The answer is, “because it makes no difference.” I would offer that instead of talking about how we might be vulnerable to bid-down, we show why it does not matter. Something like:

INSERTED TEXT:
   The ‘alg’ parameter is not protected because doing so adds no additional value. If a MITM modifies the ‘alg’ parameter in an attempt to force a downgrade, the signature will fail, as the verifier will not use the proper algorithm to verify if the signature is correct. At a bare minimum, the verifier will know the message has been tampered with.

   This does mean that a MITM can deny the sender service. However, if a MITM is in that position in the network, they can simply blackhole the traffic and as such, protecting against this adds no value.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 28 Sep 2015 22:49:11 +0000

rfc4474bis 10.3 (following the STIR problem statement) is pretty clear
that the scope of STIR does not include preventing these sort of MitM
attacks. That's why the bid-down attack is given only a cursory mention:
it was ruled out of scope. If we were to open the scope of rfc4474bis to
MitM attacks, it would require adding more text (and probably mechanism)
to address things other than "alg". That much said, I don't disagree with
your assessment of how a MitM might deny service through the "alg"
mechanism.

Jon Peterson
Neustar, Inc.

On 9/27/15, 9:41 AM, "Eric Burger" <[email-masked]> wrote:

>Is there a scenario where hacking the Alg parameter would result in a
>successful verification? I suppose with enough computing power couple
>with perhaps a reverse dictionary attack, one could step down the Alg and
>insert what one wanted into the Identity-Info header and keep the
>signature unchanged. However, I am assuming that is a vanishingly small
>possibility.
>
>The current text (Section 10.3) leads one to start wondering why we do
>not include Alg in the signature calculation. It¹s just a few more bytes.
>The answer is, ³because it makes no difference.² I would offer that
>instead of talking about how we might be vulnerable to bid-down, we show
>why it does not matter. Something like:
>
>INSERTED TEXT:
>   The Œalg¹ parameter is not protected because doing so adds no
>additional value. If a MITM modifies the Œalg¹ parameter in an attempt to
>force a downgrade, the signature will fail, as the verifier will not use
>the proper algorithm to verify if the signature is correct. At a bare
>minimum, the verifier will know the message has been tampered with.
>
>   This does mean that a MITM can deny the sender service. However, if a
>MITM is in that position in the network, they can simply blackhole the
>traffic and as such, protecting against this adds no value.