Subject: [saag] potential new wg - curdle...

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Nov 2015 11:23:56 +0000

Hiya,

Following on from the earlier discussion about adding curves
etc. a few folks (*) helped Kathleen and I craft an initial cut
at charter text. [1]

I think we have people (well, mostly Simon:-) to do the editing
work for this.

If you'd be willing to be a chair, please send an offlist mail
to Kathleen and I.

If you think this is useful and would review documents please
respond to this mail saying so. I'd like to see that we have
enough folks interested to make this work.

If you have changes to charter text to suggest please do so,
preferably in OLD/NEW form.

If you think this is a bad idea, I'm sure you'll not be shy in
saying so too:-)

If there's not enough interest or if there're sound objections then
we can abandon the idea and fall back to processing this stuff more
slowly and more ad-hoc as AD sponsored drafts. (The main point of
curdle is to be more organised and hopefully quicker at this.)

Thanks,
S.

[1] https://datatracker.ietf.org/doc/charter-ietf-curdle/

(*) Thanks to Simon Josefsson, Yoav Nir, Russ Housley and
Sean Turner for help with the text. The fault however is mine,
if it's bad text or a dumb idea:-)

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Nov 2015 12:52:51 +0100

Hi Stephen, Kathleen, Russ, Sean, and others,

I really like the charter, and I support the group going forward.  I'd
be willing to review documents.

Just one point about the charter:  I could very easily imagine this
becoming a standing working group, for instance, as the state of the art
advances or where other protocols are identified over time as needing
work.  I could also very easily see the group closing either before or
after completing the proposed charter.  My suggestion would be to remain
silent on its duration and see how things go.

I do have one additional question: what will be the relationship between
this group and the CFRG?

Eliot

On 11/18/15 12:23 PM, Stephen Farrell wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Nov 2015 12:13:39 +0000

> be willing to review documents.

Excellent, thanks.

> silent on its duration and see how things go.

Fair point. OTOH, aiming for short-lived is good too, but sure, if
there are relevant changes to the state of the art, we'll need to
consider those as they arise.

I do think we want to keep the list of stuff-that-can-be-added in
the charter though so that we can be confident we're only adding
stuff that has broad implementer interest.

> I do have one additional question: what will be the relationship between

The way I think of it is that this is taking some specific things
from CFRG's recent fine output and instantiating those in IETF
protocols, as and when IETF participants want that to be done.
I've checked with the CFRG chairs and they said they like the
idea too.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Nov 2015 17:03:44 +0000

On 18/11/15 16:48, Paul Hoffman wrote:
> How can this WG be "short-lived" when you have the following in the
> charter?

My assumption (possibly wrong) was that the curdle wg would do
the work on adding things and if, whilst doing that, they find
stuff that can be deprecated, then they can choose to go do the
work to deprecate stuff. But that the plan is to close when the
new stuff is done.

My intent fwiw was not that this wg hang around for ever figuring
out what to deprecate next.

Does that help? If so, figuring out how to say it better would
be an improvement. (Any suggestions?)

> 
> As  the CURDLE working group will be handling changes to protocols and
> registries some of which include what are now considered outdated 
> algorithm
> options, the working group can also choose to propose deprecation of such
> algorithms.  Such deprecation needs to be done with care, ensuring that
> interoperability and the needs of existing implementers and deployments are
> properly considered. Where deprecation is practical, the working group is
> encouraged to deprecate.
> 
> Arguing about what is outdated always takes a long time. "It's still
> good enough for the next five years." "No one ever changes their
> software so we need to do this early." "We have people who need to use
> this for another ten years and they understand the consequences." "We
> can ignore this small set of users." "We cannot ignore this small set of
> users." "We got rid of that algorithm in TLS and it didn't hurt." "Our
> users are different than web browser users." "The charter says we must
> do this 'with care' and you are being careless." "No, you're just being
> stubborn."

We would have that argument again yes. Maybe we'd get better at
handling it if we do it in a more concentrated fashion? I'm not
sure we would, but I figure it may be worth trying, esp as I'd
bet that we do find things we'd want to deprecate.

> Without that paragraph in the charter, I'm pretty sure consensus will be
> easy.

Do you mean consensus on the charter? (I think you do, just checking)

S

> --Paul Hoffman

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 18 Nov 2015 09:24:34 -0800

Hi Stephen,

> preferably in OLD/NEW form.

The charter seems reasonable to me.

> if it's bad text or a dumb idea:-)

I wonder if RFC 5647 which is an information RFC for "AES Galois Counter
Mode for the Secure Shell Transport Layer Protocol" could be cleaned up
to address the problems of the key exchange as expressed by the OpenSSH
team and made into a standard track document?

To quote the objection from the OpenSSH PROTOCOL document:

| 1.6 transport: AES-GCM
| 
| OpenSSH supports the AES-GCM algorithm as specified in RFC 5647.
| Because of problems with the specification of the key exchange
| the behaviour of OpenSSH differs from the RFC as follows:
| 
| AES-GCM is only negotiated as the cipher algorithms
| "[email-masked]" or "[email-masked]" and never as
| an MAC algorithm. Additionally, if AES-GCM is selected as the cipher
| the exchanged MAC algorithms are ignored and there doesn't have to be
| a matching MAC.

Given that current implementatons of this informational RFC are using
AEAD_AES_128_GCM and AEAD_AES_256_GCM and all of the standards track
Cipher algorithms use lowercase with '-' as word separators, I would
suggest that 'aes128-gcm' and 'aes256-gcm' may be more appropriate and
that they should NOT be added to the MAC Algorithms Names in IANA.

This same objection would arise to any AEAD Cipher, so I think it might
be well to do something similar for SSH for standardize
"chacha20-poly1305" for Secure Shell again as a Cipher name only with
the MAC Algorithm Name ignored.

	Thank you,
	-- Mark

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 18 Nov 2015 08:48:05 -0800

As  the CURDLE working group will be handling changes to protocols and
registries some of which include what are now considered outdated  
algorithm
options, the working group can also choose to propose deprecation of 
such
algorithms.  Such deprecation needs to be done with care, ensuring that
interoperability and the needs of existing implementers and deployments 
are
properly considered. Where deprecation is practical, the working group 
is
encouraged to deprecate.

--Paul Hoffman

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Nov 2015 18:38:11 +0100

Hi Stephen,

Just one further thought...

> be an improvement. (Any suggestions?)

Thinking out loud...

One possible way to think about the trajectory of this group is that it
could transition from a WG to some sort of directorate so that when it
deems the time is right it can propose next steps, either piecemeal or
wholesale as the circumstances warrant.  Building up and maintaining
that sort of capability for the IETF IMHO would be a good thing.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Nov 2015 17:41:57 +0000

Hiya,

> that sort of capability for the IETF IMHO would be a good thing.

I think that's a fair point to consider after the wg is up and
running and has demonstrated success for a bit so maybe getting
the curves etc additions done first and then considering this as
a possible re-charter would be reasonable. One thing to consider
then would be whether or not folks would have sufficient energy
for such ongoing efforts. For now though, I think we do seem to
have folks willing to do the initial work, so starting with that
seems like a good place to start.

Cheers,
S.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 18 Nov 2015 10:35:42 -0800

> work to deprecate stuff. But that the plan is to close when the

If that's the plan, it should be stated in the charter. Some people in 
our community really like to focus on deprecating outdated algorithms 
and garnering publicity for shaming those who continue to use them.

A different thought is to have two WGs: curdle for "add new EC" and 
depoldalg for "deprecating old algorithms". The latter could be given a 
one-year charter.

> out what to deprecate next.

With the NSA's newly-stated belief that 2048-bit RSA/DH is not good 
enough for protection against post-quantum crypto (I'm purposely not 
giving my opinion on any part of that statement...), you probably need 
to be firmer in stating what is out of scope for deprecation.

> be an improvement. (Any suggestions?)

See above. There might even be a third "depalgforpqc" WG.

> bet that we do find things we'd want to deprecate.

We haven't gotten any better in the past 15 years of experience with 
that. I'm willing to bet we're doing our best now, and that our best 
includes thrashing about this topic every time it comes up.

> Do you mean consensus on the charter? (I think you do, just checking)

Yes.

--Paul Hoffman

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 18 Nov 2015 20:53:25 +0100

> to be firmer in stating what is out of scope for deprecation.

I suppose the intention is to deprecate "obviously bad" algorithms like
rc2, rc4, md2, md4, md5, collision-resistant uses of sha1, single-des,
small block (<128b) size block ciphers, <=1024 bit DSA/RSA/DH, <224bit
ECC, etc, should we realize any of these examples when going through
protocols.  Borderline cases may include HMAC-MD5 and 224-bit ECC.

I am, though, also uncertain there will be a lot of overlap between the
activity of removing old algorithms and introducing new algorithm.  I
believe the idea that these activities are related stem from the IMO
incorrect notion that adding new ECC curves to existing protocols is
mostly about allocating code points -- I believe we've seen with SSH,
JSON, TLS, PKIX and OpenPGP already that there are several other
difficulties (e.g., alignment with ECDSA specs).  If indeed WG
chartering is low-cost, having a separate WG to deal with updating of
old specs may be cleaner.

I don't believe recommending against 2048-bit RSA/DH will do any good.
It will slow adoption of decent crypto where weak crypto is deployed.

/Simon

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Nov 2015 14:58:23 -0500

> How can this WG be "short-lived" when you have the following in the charter?
> 
> registries some of which include what are now considered outdated  algorithm

Good point.  Maybe this group should only tackle the registries and the conventions for using existing protocol fields.  If a change to the protocol is needed, maybe that should go to a separate protocol maintenance group.

Russ

---

From: John Mattsson <[email-masked]>
Date: Wed, 18 Nov 2015 20:12:03 +0000

>> to be firmer in stating what is out of scope for deprecation.

I think the current formulation “where there is IETF consensus to do so”
is quite good. When to deprecate depends on so many factors such as new
cryptanalysis and the support of new algorithms.

I think basically everybody is believing that RSA/DH/ECC is utterly broken
by quantum computers for any usable key lengths. Both NIST and ECRYPT
recommends to stop using 2048-RSA/DH no later than 2030 but that is not
because of quantum computers.

>protocols.  Borderline cases may include HMAC-MD5 and 224-bit ECC.

+1 (But add two-key tripple-des and change to <2048 bit DSA/RSA/DH).

>It will slow adoption of decent crypto where weak crypto is deployed.

Agree, the current focus should be to upgrade <2048-bit RSA/DH to 2048-bit
RSA/DH.

/John

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Nov 2015 20:16:30 +0000

On Wed, Nov 18, 2015 at 02:58:23PM -0500, Russ Housley wrote:

> Good point.  Maybe this group should only tackle the registries and the
> conventions for using existing protocol fields.  If a change to the protocol
> is needed, maybe that should go to a separate protocol maintenance group.

I don't see why deprecating where appropriate makes the group
"long-lived".  It might take longer, but it is not an indefinite
commitment.  

------------------
For example, with DNSSEC, if new algorithm IDS are added for the
new curves, it would I think be time to do a bit of house-keeping
and explicitly designate some algorithms as outdated.  With DNSSEC
too many algorithms serve only to create islands of interoperability.

So it may be time to update:

    https://tools.ietf.org/html/rfc6944#section-2.3

which does not at present distinguish between "implement" (in
validating and authoritative servers) and "publish" (deploy DS/DNSKEY
records with a given algorithm).

To phase out old or introduce new algorithms, they need to be in
a SHOULD IMPLEMENT state for some time with a SHOULD NOT publish,
so that they can later be moved to not implemented or published
respectively.

Specifically, I'd propose that algorithms 3 and 6 should be deprecated
(MAY implement, SHOULD NOT publish).  I'd also like to see algorithm
12 join their ranks.
------------------

The point of the above is not (in this thread) to digress into the
gory details of DNSSEC, but rather to highlight that considerations
of the complete life-cycle of algorithms come into play, so that we
don't just keep on adding, and never removing.

-- 
	Viktor.

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Nov 2015 19:19:42 +0000

> one-year charter

Surely we can be more creative - "die3" [for "Die!Die!Die!"] seems appropriate :-).

Seriously, I like the idea of separate WGs for clearly needed additions vs.
debates on what to remove when.

Thanks,
--David

> -----Original Message-----
> From: saag [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Wednesday, November 18, 2015 1:36 PM
> To: Stephen Farrell
> Cc: [email-masked]
> Subject: Re: [saag] potential new wg - curdle...
>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 18 Nov 2015 20:43:16 +0000

> On Nov 18, 2015, at 12:19, Black, David <[email-masked]> wrote:
> 

Or "Deprecating Ineffective Algorithms from Frameworks" (DIAF).

> debates on what to remove when.

I think separating them makes sense, too.

--
- m&m

Matt Miller <[email-masked]>
Cisco Systems, Inc.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 19 Nov 2015 00:27:50 +0200

So speaking only for the deprecate part, I’m wondering if it should be in-scope to scour IANA registries looking for obscure algorithms to deprecate.

Looking at the TLS and IPsec registries I can find RC5, IDEA, CAST, Blowfish, Tiger, and of course some national ciphers such as camellia, ARIA, SEED, and GOST. I’m pretty sure we don’t want to go there with the national ciphers, but deprecating a bunch of the others that are rarely if ever in use seems like a good idea.

Yoav

> On 18 Nov 2015, at 1:23 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Nov 2015 23:29:18 +0000

On 18/11/15 18:35, Paul Hoffman wrote:
> If that's the plan, it should be stated in the charter. 

I agree, but thought it was stated there already. Can you send
OLD/NEW text to help?

> Some people in

Meh. Frankly I doubt that there'd be willing workers for such a
deprecating-only WG, I reckon it'd be far too likely to languish
not at the top of anyone's todo list. I'd argue to see what happens
with curdle and then maybe revisit if nobody has the energy to
deprecate anything in that context we can revisit the issue.

But I could be wrong of course. If folks want to write drafts that
deprecate things and if there're enough of those queued up I'd be
very happy to help start a wg on that topic. So far though, such
drafts are fairly rare.

And to save scrolling, post-quantum stuff is a topic for cfrg and
not (yet) the IETF as far as I'm concerned.

So I hope we're ok with the (to me anyway) simpler plan of enabling
the work that folks clearly want to get done and also leaving space
for deprecating stuff as and when people are feeling the love for a
bit of deprecatiion.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Nov 2015 23:33:34 +0000

On 18/11/15 19:58, Russ Housley wrote:
> Good point.  Maybe this group should only tackle the registries and
> the conventions for using existing protocol fields.  If a change to
> the protocol is needed, maybe that should go to a separate protocol
> maintenance group.

I agree there's a line that could be crossed here, but I think
the charter as written describes that well enough and doesn't
cross that line. If there's better wording though, happy to make
changes that make that clearer. I'm not sure if "not modifying
existing PDUs" or similar language would be that much clearer
but maybe it would. (OLD/NEW text welcome.)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Nov 2015 23:35:25 +0000

On 18/11/15 20:12, John Mattsson wrote:
> Simon said:

I think the above characterises the deprecation stuff well. This part
of the work is meant to tidy up and not be revolutionary:-)

S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 18 Nov 2015 18:43:08 -0500

Sent from my iPhone

> On Nov 18, 2015, at 6:29 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

I agree.  We can see what happens and the energy level for each first.

Thanks,
Kathleen

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Wed, 18 Nov 2015 15:57:02 -0800

FWIW I’m in favor of only one WG, and I would hope that people would feel the need to depreciate algorithms at the same time they add new ones. I stop short of wanting the symmetry in the charter since I think there are probably a lot of situations where you may want to add/deprecate different numbers of algorithms.

> On Nov 18, 2015, at 3:35 PM, Stephen Farrell <[email-masked]> wrote:
> 

Personal:  [email-masked]
Business: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 19 Nov 2015 01:40:30 +0000

> depoldalg for "deprecating old algorithms". The latter could be given a

I don't think that's a good idea.  It is good to have some balance
to avoid a WG that just stacked with die-hard deprecators.  Too
much deprecationt too fast can be counter-productive.  In any case
there have to be realistic alternatives, and I think a single group
can be better focused on how to improve security than just where
to slash and burn.

-- 
	Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 19 Nov 2015 05:16:30 +0000

>It will slow adoption of decent crypto where weak crypto is deployed.

+1.  There are still organisations struggling to upgrade to 1024-bit
(from 512-bit), giving them a totally unreachable goal beyond that 
will just make them feel better about ignoring it.

Another thing about 2048 bit is that asymmetric isn't symmetric,
you don't double its strength every time you add another bit, so
there's no need to progress by doubling the bit size, all that does
is vastly increase the amount of work required.  There's little
actual practical security difference between a 1536-bit key and a 
2048-bit one, while there's a large difference in the amount of
CPU power required.

Peter.

---

From: John Mattsson <[email-masked]>
Date: Thu, 19 Nov 2015 08:00:26 +0000

>will just make them feel better about ignoring it.

I don’t think we should recommend against 2048-bit RSA/DH at all, but my
experience is the complete opposite, unless you state MUST NOT, some
people tend to think there is no panic. To them SHOULD NOT indicate that
usage is acceptable for a while longer and that they can spend development
money on something else.

>2048-bit one, while there's a large difference in the amount of

At least regarding DH (and signatures), somebody very concerned with CPU
cycles should migrate to ECC long term. The practical security differences
between DH with 1024 MODP and curve25519 is huge, and there is a large
difference in the amount of CPU power required (curve25519 is much
faster). http://bench.cr.yp.to/primitives-dh.html

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 19 Nov 2015 15:06:45 +0100

Yoav Nir <[email-masked]> writes:

> So speaking only for the deprecate part, I’m wondering if it should be
> in-scope to scour IANA registries looking for obscure algorithms to
> deprecate.

I believe that activity would be useful, but with limited overlap with
the activity of introducing new mechanisms.

That said, if we are only forming one WG around these topics, I prefer
to have deprecation in scope of that WG rather than removing that part
of the charter.

> Looking at the TLS and IPsec registries I can find RC5, IDEA, CAST,
> Blowfish, Tiger, and of course some national ciphers such as camellia,
> ARIA, SEED, and GOST. I’m pretty sure we don’t want to go there with
> the national ciphers, but deprecating a bunch of the others that are
> rarely if ever in use seems like a good idea.

I believe the IETF's position should be to describe and encourage an
upgrade-path for algorithms that doesn't meet a reasonable technical
design criteria.

Some of the ciphers in your list fail reasonable requirements (e.g.,
having >=128-bit block size for block ciphers) and should therefor be
actively recommended against.

Further, I don't see any example in your list that would be a defendable
technical choice for a new protocol today.  If that is the case, we
should actively recommend against prolonged use of the algorithm, and
specify and recommend an upgrade path.  It is not like it is ever going
to be a good technical idea to start to use ARIA/SEED/GOST if you aren't
forced to use it or is using it today.

/Simon

---

From: [email-masked] (Niels Möller)
Date: Thu, 19 Nov 2015 07:12:45 +0100

> that they should NOT be added to the MAC Algorithms Names in IANA.

THe openssh way of ignoring the mac negotiation completely, if an aead
cipher is negotiated, seems nice and simple. How does it interact with
first_kex_packet_follows logic, does that need any clarification (a
simple rule is to say that if both sides advertise the same aead cipher
as the first cipher, then for first_kex_packet_follows purposes, the mac
negotiation is considered successful and correctly guessed)?

Not sure if it has a place in the same rfc, but I think a proper
specification for use aead is quite inportant.

Regards,
/niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 19 Nov 2015 08:59:38 -0800

> negotiation is considered successful and correctly guessed)?

I am not sure that first_kex_packet_follows would guess properly because
the first listed algorithm must be the same on both sides and I am not
sure that will be true very often given the number of different host key
algorithms that exist.

> specification for use aead is quite inportant.

Okay.

	Thanks,
	-- Mark

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 20 Nov 2015 10:51:07 +0000

Mark D. Baushke <[email-masked]> writes:

>I am not sure that first_kex_packet_follows would guess properly because the
>first listed algorithm must be the same on both sides and I am not sure that
>will be true very often given the number of different host key algorithms
>that exist.

How widely is first_kex_packet_follows used in practice?  That's another thing
I'd like to see deprecated in any future changes (see the SimpleSSH proposal I
mentioned a week or so back), it vastly complicates the handshake when you
have to guess at things and potentially roll back to the previous state and
try again.  Best-case if you've got identical, identially-configured
implementations at both ends you save a whole RTT, but more common case you
have a lot of extra complexity and overhead as you roll back from the
incorrectly-guessed keyex and try again.

Peter.

---

From: John Mattsson <[email-masked]>
Date: Fri, 20 Nov 2015 21:21:51 +0000

>of the work is meant to tidy up and not be revolutionary:-)

Another algorithm that should be deprecated is "AES-GCM with a 8 octet
ICV” if it is specified anywhere else than for ESP and IKEv2, which is not
in scope for curdle. RFC4106 was published shortly after Fergusson
published his paper on authentication weaknesses on the use of GCM with
short tags. 
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Fergu
son2.pdf

RFC4106 does therefore not fulfil the mitigation requirements that NIST
specified for the use of short tags (Annex C of SP 800-38D).

Furthermore, most deployments of IPsec does not fulfil the NIST guidelines
of not providing information of successful forgeries. This is shown in the
following analysis that I will soon upload to the Cryptology ePrint
Archive (Update of https://eprint.iacr.org/2015/477):

------------------

[RFC4106] specifies the use of GCM with 64, 96, and 128 bit tags. The
specification does not discuss the problems with short tags and does not
require implementations to restrict the maximum message length L or the
maximum number of invocations q of the authenticated decryption function.
While ESP limits the AAD to necessary header information and silently
discards datagrams that fail the integrity check, ESP does not silently
discard datagrams that passes the integrity check and information leakage
regarding the integrity of individual packets is therefore possible in
many deployments.

- If any request-response protocol is sent over an IPsec protected path,
an attacker can attempt forgery by modifying a datagram containing a
request (e.g. HTTP GET). If integrity fails, the IPsec implementation will
silently discard the datagram. If the datagram passes the integrity check,
a response (e.g. 200 OK) will be sent. The datagram containing the
response will also be encrypted, but assuming small amounts of other
traffic (the attacker may e.g. block certain traffic) the attacker can see
that a response was sent and conclude that the forgery was successful.

- If tunnel mode is used, the attacker may modify the inner destination IP
address so that the packet in case of a successful forgery is routed to
the adversary itself.

If multicast is used [RFC5374], the attacker may attempt forgery towards
several instances of the GCM decryption function in parallel, and the
maximum number of invocations q of the decryption function would need to
be calculated over all instances of the decryption function. Theoretically
this could be done with synchronization, but in practice the only solution
would be to restrict the number of invocations of each instance to q/r
where r is the total number of receivers. This makes q/r impractically
small and makes the system vulnerable to denial-of-service attacks.

IPsec ESP with GCM and 64-bit tags offers 64 bits of security against
online authentication key recovery attacks and IPsec ESP with GCM and
96-bit tags offers 96 bits of security. The attacks seem possible in
practice.

------------------