Subject: [rtcweb] Require/Suggest AEAD GCM for SRTP

From: Sean DuBois <[email-masked]>
Date: Wed, 10 Jul 2019 19:06:22 +0100

Hello,
I am Sean DuBois, I work on Pion [0] a 100% Go implementation of
WebRTC. I have a user that is trying to do a large deployment, and
performance is very important to them. They see a 10x performance
improvement when using AEAD GCM for SRTP (thanks to HW acceleration)
and is the most obvious improvement we can make.

Having this would be a pretty fantastic improvement for very little
work. Especially for weak devices/scaling servers, AES-NI is a huge
deal. Also great for security, avoids possible timing attacks from
software implementation and just less for developers can mess up when
implementing SRTP themselves!

This also should be pretty painless change.
* FireFox already supports it
* Chromium is just behind a flag [1]
* Most other implementations also use libsrtp (where it is already available)
* Adding more protection profiles will have zero impact if they aren't
supported.

----
I have never been involved with the IETF before, but this seems the
best way to push implementations to support it.

[0] https://github.com/pion/webrtc
[0] https://bugs.chromium.org/p/chromium/issues/detail?id=713701#c20

---

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 10 Jul 2019 11:25:41 -0700

Hi Sean,

> On 10Jul, 2019, at 11:06, Sean DuBois <[email-masked]> wrote:
> 
> Hello,

As Firefox supports GCM already I’m in favor of adding it to the spec.

AFAIK GCM support in Chrome is behind a flag because they ran into some interop issues with early GCM implementations.

But it is pretty late in the standardization process to make/request such changes. I’ll leave it to other to judge this.

Best
  Nils Ohlmeier

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 10 Jul 2019 22:20:24 +0200

Am 10.07.19 um 20:25 schrieb Nils Ohlmeier:
<snip/>

> But it is pretty late in the standardization process to make/request such changes. I’ll leave it to other to judge this.

I don't think we need any mandatory requirement, we have negotiation 
built in. AES-NI does not require GCM though?

I tested GCM with both Chrome and Firefox, found a small bug in the 
latter (which was quickly fixed by you) but other than that it worked 
like charm.

How chrome solves their "stuff bitrotting behind flags forever" is not 
an IETF problem thankfully.

---

From: Sean DuBois <[email-masked]>
Date: Wed, 10 Jul 2019 23:28:00 +0100

On Wed, Jul 10, 2019 at 10:20:24PM +0200, Philipp Hancke wrote:
> I don't think we need any mandatory requirement, we have negotiation built
> in. AES-NI does not require GCM though?
Agree! I do get hw-accel right now when encrypting, but it is the HMAC-SHA1
for the authentication tag that takes up most of the time.

Lots of calls to HMAC-SHA1 for both send/recv

I don't know libsrtp well enough, but I assume the situation is the same?

>
> I tested GCM with both Chrome and Firefox, found a small bug in the latter
> (which was quickly fixed by you) but other than that it worked like charm.
>
> How chrome solves their "stuff bitrotting behind flags forever" is not an
> IETF problem thankfully.
I am happy to help with this case! I am just hoping if I go the
IETF route. It will make it easier to get things merged/enabled in projects.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 10 Jul 2019 16:02:59 -0700

We looked into this in Chrome in
https://bugs.chromium.org/p/chromium/issues/detail?id=713701, but we
decided not to proceed because of the resultant blowup from using the
non-truncatable AEAD MAC (16 bytes per packet vs 4/10 for HMAC-SHA1).

I think we'd be open to revisiting this if there were obvious performance
benefits, but your numbers for HMAC-SHA1 seem unusually bad. For example,
"openssl speed sha1" yields 500 MB/s for 256-byte packets on my MacBook
Pro, compared to the 28 MB/s that you noted in the bug. "openssl speed
aes-128-gcm" does yield 1500 MB/s, so there's clearly some upside here, but
it's hard to see this as a must-have.

On Wed, Jul 10, 2019 at 3:27 PM Sean DuBois <[email-masked]> wrote:

> > > AFAIK GCM support in Chrome is behind a flag because they ran into
> some interop issues with early GCM implementations.
> > >
> > > But it is pretty late in the standardization process to make/request
> such changes. I’ll leave it to other to judge this.
> >
> latter
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 11 Jul 2019 17:21:40 +1000

> non-truncatable AEAD MAC (16 bytes per packet vs 4/10 for HMAC-SHA1).

I don't find the extra bytes that big of a deal, across an entire PMTU-sized packet, it's not significant.  I'm sure you can say that it makes a difference in terms of responsiveness or number of packets, but it's <0.5% of a modest MTU for the 10 vs. 16 comparison.

32-bit auth tags are pretty ridiculous if you think that authenticity is a valid goal.  We're considering turning them off entirely.  That said, if we had a cipher with a shorter tag that wasn't awful, I'd probably concede that maybe we could have fewer than 128 bits of tag for time-sensitive applications.
 
> I think we'd be open to revisiting this if there were obvious 
> performance benefits, but your numbers for HMAC-SHA1 seem unusually 
> bad. For example, "openssl speed sha1" yields 500 MB/s for 256-byte 
> packets on my MacBook Pro, compared to the 28 MB/s that you noted in 
> the bug. "openssl speed aes-128-gcm" does yield 1500 MB/s, so there's 
> clearly some upside here, but it's hard to see this as a must-have.

Keep in mind that you are running AES in counter mode and HMAC-SHA1 will add an extra invocation per packet (which is small, but noticeable), so a better comparison would be GHASH with SHA1.  With acceleration GHASH is much faster.  Without, it's is slower, but most modern machines have carryless multiply instructions.  AES-GCM runs at about a cycle per byte with native instruction support.  SHA-1 can get close to that on the very latest CPUs, but even CPUs from last year are twice as slow.  So add AES-CTR and that is consistent with your measurements.

Only for the oldest machines (like a 2012 ARM chip, for instance) will AES-CTR+HMAC-SHA-1 start to be comparable to the performance of a constant-time AES-GCM.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 11 Jul 2019 09:22:16 +0200

Once cluster 238 is published, I'm in favor of looking at the
mandatory-to-implement ciphersuites in RTCWEB and consider updating
them. It's been a few years since we went through that exercise.

I am not in favor of proposing changes to the current documents.

---

From: Sean DuBois <[email-masked]>
Date: Thu, 11 Jul 2019 12:00:28 +0100

> it's hard to see this as a must-have.
Here are my numbers using libsrtp, still pretty significant I think!
People have fought a lot harder for much smaller improvements.

-- aes_cm_128_hmac_sha1_32
./a.out  1.83s user 0.01s system 99% cpu 1.843 total
./a.out  1.84s user 0.01s system 99% cpu 1.856 total
./a.out  1.83s user 0.00s system 99% cpu 1.837 total
./a.out  1.82s user 0.01s system 99% cpu 1.831 total
./a.out  2.04s user 0.01s system 99% cpu 2.065 total
./a.out  1.82s user 0.01s system 99% cpu 1.834 total
./a.out  1.84s user 0.01s system 99% cpu 1.857 total
./a.out  1.83s user 0.00s system 99% cpu 1.843 total
./a.out  1.85s user 0.01s system 99% cpu 1.860 total
./a.out  1.83s user 0.01s system 99% cpu 1.839 total

-- aes_gcm_128_16
./a.out  0.76s user 0.00s system 99% cpu 0.772 total
./a.out  0.81s user 0.00s system 99% cpu 0.814 total
./a.out  0.75s user 0.00s system 99% cpu 0.762 total
./a.out  0.75s user 0.01s system 99% cpu 0.760 total
./a.out  0.76s user 0.00s system 99% cpu 0.765 total
./a.out  0.76s user 0.00s system 99% cpu 0.765 total
./a.out  0.79s user 0.01s system 99% cpu 0.803 total
./a.out  0.77s user 0.01s system 99% cpu 0.780 total
./a.out  0.75s user 0.00s system 99% cpu 0.762 total
./a.out  0.79s user 0.01s system 99% cpu 0.796 total

Hopefully my test is good, whipped it up while waiting for my
flight. https://gist.github.com/Sean-Der/7a42bd70edfe1324ccc6ab399d653c0e

---

From: Sean Turner <[email-masked]>
Date: Thu, 11 Jul 2019 20:07:17 -0400

Hi,

I think there’s general consensus that we should be updating the algorithm requirements every couple of years after the specifications are published.  But, we have not yet actually published cluster 238 yet.  We need to get that done first and then we should entertain updates; it is never as easy as one thinks it is to update the MTIs.

spt

> On Jul 11, 2019, at 03:22, Harald Alvestrand <[email-masked]> wrote:
>

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 12 Jul 2019 20:19:52 +1000

On Fri, Jul 12, 2019, at 10:07, Sean Turner wrote:
> I think there’s general consensus that we should be updating the 
> algorithm requirements every couple of years after the specifications 
> are published.  But, we have not yet actually published cluster 238 
> yet.  We need to get that done first and then we should entertain 
> updates; it is never as easy as one thinks it is to update the MTIs.

This sounds like a great policy.  238 will take long enough that we should have some time to consider our options more fully.  Maybe we also have enough time to do something about finding an AEAD with a smaller authentication tag that can be used here.