Subject: [AVT] Comments on draft-feher-avt-approx-auth-srtp-00

From: Eric Rescorla <[email-masked]>
Date: Sat, 6 Nov 2010 14:58:26 -0700

This document specifies a framework for providing approximate integrity
checks on SRTP packets. The idea here is that SRTP packets might be
subject to bit errors that would still cause the media to play out
tolerably (albeit with some degradation) but the strong integrity
checks built into SRTP cause such packets to be rejected. An approximate
MAC will cause the packet to be accepted provided that the current
packet is not *too far* from the packet which was MACed.

MOTIVATION
First, it's not clear to me that this is a real problem. This document
merely asserts that many packets are errored, but many (most?) link
layer protocols include error checks, so I would like to see some
measurements indicating that an appreciable enough packets have
small bit errors to justify this work at all.

This document just indicates a framework not an algorithm. I'm not aware
of any such standard algorithm and the paper that the authors cite
on this topic is behind a paywall. Is there a widely available,
well-analyzed
approximate MAC algorithm. Otherwise, it's hard to see this work being
useful.

DESIGN
I don't understand the motivation for this design, and the security
analysis is fairly unclear. The natural design is an approximate
MAC that covers the payload and then have a strong MAC that covers the
headers and the weak MAC. Instead, the authors seem to be using a block
cipher to somehow protect the weak MAC. I don't see the motivation
for that.

-Ekr

---

From: Feher Gabor <[email-masked]>
Date: Sun, 07 Nov 2010 04:28:29 +0100

Dear Eric!

Thank you for your comment. I hope I can make this clear.

> packet is not *too far* from the packet which was MACed.
Yes, it is right.

> small bit errors to justify this work at all.
It is mostly for wireless networks. We have measurements on Wi-Fi 
networks that I can show during the meeting. This will show you, that in 
this environment we have situations (depending on distance, objects, 
devices, ...) where there are bit errors. Sometimes we have just a small 
number of them, while sometimes we have lot of them. The best to have 
not so much of them. Unfortunately today link protocols will filter out 
these errors, but in the future applications it would be possible to use 
them. Linux is already ready to receive these errors with no hacking. 
More on more end user device is based on Linux, just like Android or 
MeeGo. If you are interested, I can show it how, but that won't fit in 
10 minutes. But the Linux example also shows that this is not depends on 
the device, this is a software decision.

> approximate MAC algorithm. Otherwise, it's hard to see this work being
Yes, it was a purpose to indicate just a framework at first. We have an 
algorithm also, called APACE. Unfortunately due to copyright issues I'm 
not allowed to give you the articles, but I can talk about it briefly on 
the meeting. You will get an algorithm that has many counters and 
counting the bits using a counter associated to the actual bit. Finally 
we have a distance, measuring the difference of the counters. We know at 
least two more different approaches. They are also research papers. I 
try to google something available this evening.

> cipher to somehow protect the weak MAC. I don't see the motivation
We propose a strong MAC to protect the headers, but it is included in 
the final MAC. We protect the final MAC with encryption, because 
approximate authentication is not necessarily safe from manipulations 
(manipulating the MAC value). And we enforce block encryption, since 
stream cipher would still allow bit modifications. The whole thing is to 
protect the MAC value against modification. Of course, if we have even a 
single bit errors here, than authentication will fail.

Regards,
Gabor

>
> -Ekr
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 6 Nov 2010 20:52:45 -0700

On Sat, Nov 6, 2010 at 8:28 PM, Feher Gabor <[email-masked]> wrote:
> It is mostly for wireless networks. We have measurements on Wi-Fi networks
> that I can show during the meeting.
>

I won't be in Beijing. Can you please post them to the list.

> algorithm also, called APACE. Unfortunately due to copyright issues I'm not
> allowed to give you the articles, but I can talk about it briefly on the
> meeting.
>

This seems inherently problematic in terms of the WG being able to evaluate
this proposal.

You will get an algorithm that has many counters and counting the bits using
> a counter associated to the actual bit. Finally we have a distance,
> measuring the difference of the counters. We know at least two more
> different approaches. They are also research papers. I try to google
> something available this evening.
>

> We propose a strong MAC to protect the headers, but it is included in the
> final MAC. We protect the final MAC with encryption, because approximate
> authentication is not necessarily safe from manipulations (manipulating the
> MAC value). And we enforce block encryption, since stream cipher would still
> allow bit modifications. The whole thing is to protect the MAC value against
> modification. Of course, if we have even a single bit errors here, than
> authentication will fail.
>

Right. What I'm suggesting is the opposite. Protect the payload with an
approximate MAC
and then protect the approximate MAC with a strong MAC. Can you explain the
drawback
with that?

-Ekr

> Audio/Video Transport Working [email-masked]://www.ietf.org/mailman/listinfo/avt
>
>
>

---

From: Feher Gabor <[email-masked]>
Date: Sun, 07 Nov 2010 14:26:37 +0100

I have uploaded the working version of the publication I have referred: 
http://www.zshare.net/download/8244050930592d89/. The algorithm is not 
copyrighted, just the publication, but according to my best knowledge I 
can share a working copy with others interesting about the topic. Please 
do not redistribute it on other channels, I think that is not fair. In 
section I.C you can read about other approximate authentication codes 
and at the references you can find the publications. I try to search for 
some, and they were available on the Internet freely. (Sorry for 
inconvenience, our publication was used to available on Internet freely 
as well) In the article you can find the algorithm in Section II. In 
Section III you can find tests and measurement results. at that time we 
tried to make the algorithm secure enough. It was in 2008 (The first 
publication was around 2006) and today we already have some 
modifications in the algorithm. We still have counters, but the size and 
the number of them are different and also, the difference calculation is 
easier. We have not published it yet, because we are still working on 
the new measurements. it should be ready in a few months, and then we 
publish it. I also have a plan to create a draft on it.

I upload two presentations as well. They all all about WiFi 
measurements. In the fist presentation, jut like in the publication, you 
can see frames from the foreman video clip. It is from 2006, and now I 
cannot find the corresponding video sequences. Soon, we will have new 
ones and I post them here as well. Today we have better WiFi measurement 
tools (out of box Linux) and hopefully video decoding was advanced as 
well, so we expect even better results. The presentations:
http://www.4shared.com/document/VWKmkrrm/apace.html
http://www.4shared.com/document/MHrfbCp6/WiFiBitError.html

Sorry for the file sharing portals, I don't have profit on them, but 
here I have not found any better solution. If it does not work for you, 
mail me, I send the copy.

>     Yes, it was a purpose to indicate just a framework at first. We
>     have an algorithm also, called APACE. Unfortunately due to
>     copyright issues I'm not allowed to give you the articles, but I
>     can talk about it briefly on the meeting.
>
>
> This seems inherently problematic in terms of the WG being able to 
> evaluate this proposal.
I can post the non-final versions here, as I did now.

>     We propose a strong MAC to protect the headers, but it is included
>     in the final MAC. We protect the final MAC with encryption,
>     because approximate authentication is not necessarily safe from
>     manipulations (manipulating the MAC value). And we enforce block
>     encryption, since stream cipher would still allow bit
>     modifications. The whole thing is to protect the MAC value against
>     modification. Of course, if we have even a single bit errors here,
>     than authentication will fail.
>
>
> Right. What I'm suggesting is the opposite. Protect the payload with 
> an approximate MAC
> and then protect the approximate MAC with a strong MAC. Can you 
> explain the drawback
> with that?
I would like to have just one MAC in the message. Two MACs have more 
overhead. Or if you mean to hash the hash value, it is not working, 
since I need the original value of the approximate hash. I have one in 
the message and I calculate one at the receiver. To calculate the 
difference I need both values. If if encrypt it that is reversible, I 
have the inverse operation. If I hash it, then I cannot compare 
difference anymore.  I hope I did not misunderstand you. I protect the 
approximate MAC with encryption instead of hash. More complex, but 
reversible.

Regards,
Gume

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Nov 2010 21:17:23 -0800

On Sun, Nov 7, 2010 at 5:26 AM, Feher Gabor <[email-masked]> wrote:

> copyrighted, just the publication, but according to my best knowledge I can
> share a working copy with others interesting about the topic. Please do not
> redistribute it on other channels, I think that is not fair. In section I.C
> you can read about other approximate authentication codes and at the
> references you can find the publications. I try to search for some, and they
> were available on the Internet freely. (Sorry for inconvenience, our
> publication was used to available on Internet freely as well) In the article
> you can find the algorithm in Section II. In Section III you can find tests
> and measurement results. at that time we tried to make the algorithm secure
> enough. It was in 2008 (The first publication was around 2006) and today we
> already have some modifications in the algorithm. We still have counters,
> but the size and the number of them are different and also, the difference
> calculation is easier. We have not published it yet, because we are still
> working on the new measurements. it should be ready in a few months, and
> then we publish it. I also have a plan to create a draft on it.
>

Thanks.

I'm now clear on how the algorithm works. While it may be secure, this paper
really falls very
far short of the current standard of work in the cryptographic community.
Before we adopt
an algorithm of this type, I'd want to see it (1) have the sort of reduction
proof of security
that is now expected of this type of algorithm (2) be published in a
standard venue oriented
towards cryptography (3) have received extensive review and attempted attack
from
cryptographers.

 DESIGN
> overhead. Or if you mean to hash the hash value, it is not working, since I
> need the original value of the approximate hash. I have one in the message
> and I calculate one at the receiver. To calculate the difference I need both
> values. If if encrypt it that is reversible, I have the inverse operation.
> If I hash it, then I cannot compare difference anymore.  I hope I did not
> misunderstand you. I protect the approximate MAC with encryption instead of
> hash. More complex, but reversible.
>

More overhead in terms of what? Perhaps I don't understand your
construction. How are you planning to combine the strong MAC
and the approximate MAC? I had assumed it was concatenation, in which case
ISTM that the overhead is identical.

-Ekr

---

From: Feher Gabor <[email-masked]>
Date: Mon, 08 Nov 2010 06:46:19 +0100

Hi!
> I'm now clear on how the algorithm works. While it may be secure, this 
> paper really falls very
> far short of the current standard of work in the cryptographic 
> community. Before we adopt
> an algorithm of this type, I'd want to see it (1) have the sort of 
> reduction proof of security
> towards cryptography (3) have received extensive review and attempted 
> attack from
> cryptographers.
I would be happy to have cryptographers to work on this topic. But, on 
the other side, it is a different kind of security that the algorithm 
requires. The MAC is encrypted, so we can neglect all attacks targeting 
the MAC modification. Just like hash codes. The only problem is that the 
approximation procedure should be secure. We should prove that an 
attacker cannot fake the algorithm, by modifying a lot, while it would 
be detected as a small change by the algorithm.

> and the approximate MAC? I had assumed it was concatenation, in which 
> case ISTM that the overhead is identical.
>
No, this is a PLUS (addition operation). No concatenation. It works this 
way as well.

BR,
Gabor

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Nov 2010 22:01:28 -0800

On Sun, Nov 7, 2010 at 9:46 PM, Feher Gabor <[email-masked]> wrote:

> I would be happy to have cryptographers to work on this topic. But, on the
> other side, it is a different kind of security that the algorithm requires.
> The MAC is encrypted, so we can neglect all attacks targeting the MAC
> modification. Just like hash codes. The only problem is that the
> approximation procedure should be secure. We should prove that an attacker
> cannot fake the algorithm, by modifying a lot, while it would be detected as
> a small change by the algorithm.

I don't understand that. This is precisely the sort of question which
cryptographers work on.

-Ekr

---

From: Feher Gabor <[email-masked]>
Date: Mon, 08 Nov 2010 07:11:38 +0100

>
>         I'm now clear on how the algorithm works. While it may be
>         secure, this paper really falls very
>         an algorithm of this type, I'd want to see it (1) have the
>         sort of reduction proof of security
>         that is now expected of this type of algorithm (2) be
>         published in a standard venue oriented
>         towards cryptography (3) have received extensive review and
>         attempted attack from
>         cryptographers.
>
>     I would be happy to have cryptographers to work on this topic.
>     But, on the other side, it is a different kind of security that
>     the algorithm requires. The MAC is encrypted, so we can neglect
>     all attacks targeting the MAC modification. Just like hash codes.
>     The only problem is that the approximation procedure should be
>     secure. We should prove that an attacker cannot fake the
>     algorithm, by modifying a lot, while it would be detected as a
>     small change by the algorithm.
>
>
It is. I just said that it is different, than the usual security 
questions, but still it is a security question. We did studies with the 
previous algorithm, and we will study the new one. I hope we will end up 
a clear proof of security. But we are talking now about the approximate 
authentication. The current draft is, just like a framework accepting 
general approx. auth. algorithms. I hope the security of the MAC is 
clear there.

BR,
Gabor