Subject: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-03.txt

From: [email-masked]
Date: Wed, 18 Jan 2017 09:30:31 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Crypto Forum of the IETF.

        Title           : AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
        Authors         : Shay Gueron
                          Adam Langley
                          Yehuda Lindell
	Filename        : draft-irtf-cfrg-gcmsiv-03.txt
	Pages           : 45
	Date            : 2017-01-18

Abstract:
   This memo specifies two authenticated encryption algorithms that are
   nonce misuse-resistant - that is that they do not fail
   catastrophically if a nonce is repeated.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-gcmsiv/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-gcmsiv-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: John Mattsson <[email-masked]>
Date: Wed, 18 Jan 2017 21:05:36 +0000

Hi,

Very well written. Some comments and suggestions:

- In addition to listing the performance penalty compared to GCM. The
  draft should also mention that compared to GCM, some nice properties
  disappear:
  - Neither Encryption nor Decryption is online as encryption/decryption
    cannot start before the whole plaintext/ciphertext is known.
  - GCM-SIV removes the possibility to preprocess static headers (AAD).

- “The result of the encryption is the resulting ciphertext (truncated
   to the length of the plaintext) followed by the tag."

  I suggest that the tag is placed first instead of last in the
  ciphertext. This makes decryption online, which makes a large
  difference. Suggestion:

  “The result of the encryption is the tag followed by the ciphertext
   (truncated to the length of the plaintext)"

- "within 5% of the speed of AES-GCM."
  Should state when this is the case, e.g. long plaintext/aad.

- I think the draft should give performance data also for short
  plaintexts/aad or even better list the performance in number of
  operations:

  GCM:
    Block Cipher Operations = p + 1
    GF(2^128) Multiplications = p + a + 1

  GCM-SIV-128
    Block Cipher Operations = p + 5
    GF(2^128) Multiplications = p + a + 1

  GCM-SIV-256
    Block Cipher Operations = p + 7
    GF(2^128) Multiplications = p + a + 1

  (if I got it right...)

  Where p is the block length of the plaintext and a is the block length
  of the additional authenticated data,

  I doubt that encryption of short messages are anywhere near 5% of GCM.
  
- The "++" and "[:8]" operation should probably be defined.

- What it the security/performance tradeoff with truncation in the key
  derivation? What would the security properties be if "[:8]" was
  removed?

- The definition of U32LE seems unnecessary and only adds complexity.
  I suggest:
    OLD "U32LE(3) ++ nonce"
    NEW "03 ++ 000000 ++ nonce

- The term K1 is only used in Test Vectors. I guess it is an old term
  that should be removed.

Some editorials:

- OLD "The record-authentication key is 128-bit and the
       record-authentication key"
  NEW "The record-authentication key is 128-bit and the
       record-encryption key"

- "} else if bytelen(key-generating-key) == 32 {
     record-encryption-key = AES128(key = key-generating-key,"

  Should be AES256
  
- Spacing around "+" and "*" are not consistent.

- "the the"

- yeilds

- remainding

- RFC7322 says "A comma is used before the last item of a series"

Cheers,
John

On 2017-01-18, 18:30, "Cfrg on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>Cfrg mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/cfrg

---

From: Brian Smith <[email-masked]>
Date: Wed, 18 Jan 2017 13:46:14 -1000

> https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-03

The intro defines nonce-misuse-resistant AEADS as ones that are
safe(r) to use when "two distinct messages are encrypted with the same
nonce". However, in reality we usually don't care only about the case
where *two* (==2) distinct messages are encrypted with the same (key,
nonce), but rather we care about the case where *multiple* (>=2)
messages are encrypted with the same (key, nonce). In particular the
new draft makes a distinction between encrypting <2^8 vs >=2^8
messages with the same (key, nonce), not a distinction between 1 vs 2
messages with the same (key, nonce).

The practical motivation for POLYVAL is unclear. In an email message
in an earlier mailing list thread, Shay said "We chose to use POLYVAL
so that 128-bit blocks can be viewed as field elements and as AES
ciphertexts in a consistent way (with respect to the order of the bits
inside each byte))," and I think that this should be included in the
spec, along with a more plain explanation that this is done (IIUC)
simply to avoid byte byteswapping on little-endian systems that GHASH
requires.

It isn't clear how the nonce length of 96 bits was chosen. I can see
some advantages, e.g. it is more of a drop-in replacement for AES-GCM,
which is almost exclusively used with 96-bit nonces in IETF protocols,
but is there any other reason? Since nonce-misuse-resistance is not a
binary property, but rather a gradiant, it seems better to optimize
for minimizing the chance of accidental nonce misuse, or minimizing
the number of times a nonce is likely to be misused, which AFAICT
means choosing a nonce length that is as long as is practical. The
rationale in the other thread says "In order to make room for the
counter, the nonce size has been reduced to 96 bits," but the counter
for the key derivation only needs to be 3 bits long, IIUC, so it seems
like the nonce length was reduced more than necessary?

The email also said "We now generate keys by using counter mode and
discarding half of each ciphertext block." The motivation for
discarding half of each ciphertext block should be added to the draft
(maybe in security considerations), along with a reference of how
discarding half of each ciphertext block achieves that goal.

The draft makes an argument about safety when "nonces are selected
uniformly at random." However, isn't a key motivation for AES-GCM-SIV
our lack of confidence in our ability to select nonces uniformly at
random? I personally would like to see discussion of the case where we
can't assume nonces are selected uniformly at random. (While I can't
come up with one off the top of my head right now, it seems likely
that there would be simpler and less invasive ways of defining a
nonce-misuse-resistant AEAD based on AES-GCM if we can also assume we
have a good random number generator and we're willing to accept the
birthday bound analysis in the draft. Thus, based on intuition it
seems like AES-GCM-SIV must be useful in contexts where nonces aren't
chosen uniformly at random in order to justify its complexity.)

Cheers,
Brian
--
https://briansmith.org/

---

From: Adam Langley <[email-masked]>
Date: Wed, 18 Jan 2017 16:13:48 -0800

>     cannot start before the whole plaintext/ciphertext is known.

I agree that this is true for encryption, but I don't believe that
AES-GCM should be *de*crypted in a streaming fashion, but rather that
records should be sized so that this isn't a problem. (At which point
the benefit for streaming encryption becomes small or moot.)

I've a long spiel about the dangers of processing unauthenticated
ciphertext which I'll spare you :) But, even for small machines, the
memory needed to safely buffer the decrypted plaintext to avoid
releasing it before it's authenticated is equal to the memory to
buffer the ciphertext followed by decrypting in-place.

So I actually quite like that the tag is at the end of the message
with AES-GCM-SIV because it makes it harder to do what I think is the
"wrong" thing.

>   - GCM-SIV removes the possibility to preprocess static headers (AAD).

Indeed.

(I wasn't sure where to put these points in the spec so, for the
moment, I've added an appendix for "Additional comparisons with
AES-GCM". I'm collecting changes in GitHub before making a new
version. For this message, see
https://github.com/agl/gcmsiv/commit/c6c7fd388dd122251264222b7491c6212e818319.)

>    (truncated to the length of the plaintext)"

(See above.)

>   Should state when this is the case, e.g. long plaintext/aad.

Done.

>     GF(2^128) Multiplications = p + a + 1

I think that's correct and I've added that to the new appendix.

> - The "++" and "[:8]" operation should probably be defined.

Done.

>   derivation? What would the security properties be if "[:8]" was

I'll have to let Shay answer this, but the rough idea is that, since
AES is a permutation, not two ciphertexts can be equal given that
we're encrypting different plaintexts using the KDF phase. However,
ideally we would want a PRF where outputs can be the same. By taking
only the first eight bytes of each ciphertext block, we better
approximate a PRF.

>     NEW "03 ++ 000000 ++ nonce

Good point.

> - The term K1 is only used in Test Vectors. I guess it is an old term

Done.

> Some editorials:

Thank you for all these. They should be taken care of.

>      record-encryption-key = AES128(key = key-generating-key,"

Indeed, and record-authentication-key is wrong too!

> - RFC7322 says "A comma is used before the last item of a series"

I think I've leave this one to the RFC Editor!

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Wed, 18 Jan 2017 16:24:07 -0800

> messages with the same (key, nonce).

You're correct that the problem is multiple messages (potentially)
encrypted with the same (key, nonce) pair. But the number is very
small since the number of random nonces that need to be sampled from a
96-bit space in order to expect at least one to appear > x times,
rises *very* fast with x. As noted in the draft, for x=256, it's about
2^102.

The main thrust of that section in the spec is to say "pick nonces at
random". The 2^8 number was picked out of the aim to emphasize this
over fixing a specific nonce and not encrypting too many messages.

> simply to avoid byte byteswapping on little-endian systems that GHASH

I'll let Shay add something about this if he wishes, but I think the
bit ordering in GHASH is weird and it''s not just a big/little endian
thing. I know, having spoken to other people who have dealt with
GHASH, but I'm not unique in this either.

POLYVAL straightens this out :)

> but is there any other reason?

It used to be 128 bits, but we wanted to change the KDF to use counter
mode. Thus we needed three bits for the counter. However, a 125-bit
nonce would be too weird so we rounded down to 96 bits.

An analysis of the probabilities of repeats shows that, even with 96
bits, there is a vast security margin so we're happy with that length.

> discarding half of each ciphertext block achieves that goal.

Agreed and I'm hoping that a more concrete comparison of how the new
KDF affects the bounds will come from Shay and Yehuda soon :)

> random?

No. The motivation is that selecting nonces at random with AES-GCM
isn't very comforting. NIST recommends a limit of 2^32 plaintexts for
a given key in this case, and that still has a 2^-33 chance of serious
failure.

> I personally would like to see discussion of the case where we

Off the top of my head, I think we would need a cipher with a 256-bit
block in order for a scheme that doesn't depend on nonces being
(mostly) distinct to have comfortable security margins. AES-GCM-SIV is
not such a scheme.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Shay Gueron <[email-masked]>
Date: Wed, 18 Jan 2017 17:05:05 -0800

Hello everyone,

I will try to address, really briefly, two of the points raised here and
deferred to me.

The definition of POLYVAL: there is an inherent discrepancy in the
definition of AES-GCM. 128-bit blocks need to be viewed as polynomials, and
also as 16 bytes for input/output for AES (AES is defined over bytes). The
way that the polynomials are defined leads to bytes that have the reverse
order of bits, compared to how AES views a bytes. I will publish a
 detailed paper on this issue. For now, there is some explanation in my
talk at RWC 2011 [1].
POLYVAL is defined in a way that is consistent with AES.

The other topic is why truncate the AES (throw away half of the bits) when
generating per-nonce keys. The idea is to get indistinguishabilityle bounds
that do not have a term that is quadratic in the number of queries (like
the ones we would get if we used all of the bits). Roughly speaking the
truncation gets us a term that looks like q/2^(96) instead of q^2/2^{129}.
The bounds and discussion can be seen at  [2].

Anyway an organized paper with a statement on the security bounds, is going
to come out in a paper that we are working on these very days. We will post
it soon.

Thank you, Shay

[1] https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf

[2] S. Gilboa, S. Gueron, “The Advantage of Truncated Permutations”,
https://arxiv.org/abs/1610.02518   (submitted on 8 Oct 2016).

---

From: John Mattsson <[email-masked]>
Date: Thu, 19 Jan 2017 08:22:33 +0000

Thanks Shay,

See reply inline.

Cheers,
John

From: Shay Gueron <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 19 January 2017 at 02:05
To: Adam Langley <[email-masked]<mailto:[email-masked]>>
Cc: John Mattsson2 <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Shay Gueron <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-03.txt

Hello everyone,

I will try to address, really briefly, two of the points raised here and deferred to me.

The definition of POLYVAL: there is an inherent discrepancy in the definition of AES-GCM. 128-bit blocks need to be viewed as polynomials, and also as 16 bytes for input/output for AES (AES is defined over bytes). The way that the polynomials are defined leads to bytes that have the reverse order of bits, compared to how AES views a bytes. I will publish a  detailed paper on this issue. For now, there is some explanation in my talk at RWC 2011 [1].
POLYVAL is defined in a way that is consistent with AES.

The other topic is why truncate the AES (throw away half of the bits) when generating per-nonce keys. The idea is to get indistinguishabilityle bounds that do not have a term that is quadratic in the number of queries (like the ones we would get if we used all of the bits). Roughly speaking the truncation gets us a term that looks like q/2^(96) instead of q^2/2^{129}. The bounds and discussion can be seen at  [2].

Asymptotically yes, but in this case we have q=2 and q=3 and any disadvantage of using a PRP should be negligible.
In fact, if the above terms were true for small q (which they are likely not) the the then quadratic term is preferable as  2^2/2^{129} = 1/2^{127} << 2/2^{96} = 1/2^{95}
Feels like doubling the amount of AES operations may be overkill and not worth the negligible security increase. GCM is popular for its performance, not for high security bounds.

Anyway an organized paper with a statement on the security bounds, is going to come out in a paper that we are working on these very days. We will post it soon.

Thank you, Shay

2017-01-18 16:13 GMT-08:00 Adam Langley <[email-masked]<mailto:[email-masked]>>:
On Wed, Jan 18, 2017 at 1:05 PM, John Mattsson

Indeed.

(See above.)

Done.

Done.

Good point.

Done.

Cheers

AGL

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Richard Outerbridge <[email-masked]>
Date: Thu, 19 Jan 2017 04:47:01 -0500

Just sitting here on the sidelines, but already my complexity meter has gone into the infra red.
__outer

---

From: John Mattsson <[email-masked]>
Date: Thu, 19 Jan 2017 10:19:45 +0000

Hi Adam,

Thanks for addressing my comments so fast! One more comment:

- The use of one-time authentication keys has the benefit that it
mitigates Fergusson’s authentication key recovery attack on GCM in the
two-party case. In case of multicast the attack remains (but significantly
restricted). This makes GCM-SIV a little bit more suitable for truncated
tags than GCM. I think these advantages should be mentioned.

- See reply on tag placement inline.

Cheers,
John

>with AES-GCM-SIV because it makes it harder to do what I think is the

I would agree with you if placing the tag last actually improved anything,
but the fact is that GCM-SIV actually forces processing of unauthenticated
ciphertext by design (a change from GCM). I cannot see any security
benefits with (C, T) compared to (T, C). The only difference I can see is
that (C, T) increases the latency for decryption on multicore.

---

From: Shay Gueron <[email-masked]>
Date: Thu, 19 Jan 2017 05:50:06 -0800

Dear John,

The bounds in the reference that I pointed to (re. the KDF) bound with the
max between the quadratic and linear term (and 1).

I agree with your comment about q=3. If a usage is supposed to send q=3
messages (i.e., q=3 different nonces) with one key, it makes no point to
have a KDF before GCM-SIV (regardless of its design). Better use GCM-SIV
directly (the one described in the CCS15 paper).

In fact, even for a usage that has only very short messages (e.g., key
wrapping), GCM-SIV can be used directly (no KDF) and with a fixed nonce.

However, AES-GCM-SIV is constructed by a KDF step before the GCM-SIV
processing, with the intention to extend the lifetime of a given key,
beyond 2^{32}, (as it is with GCM-SIV, as explained in the text). In such
cases, it is useful to have a KDF with a small bound on the distinguishing
advantage. We chose the one that is described in the spec.

Thanks, Shay

2017-01-19 0:22 GMT-08:00 John Mattsson <[email-masked]>:

> Thanks Shay,
>
> See reply inline.
>
> Cheers,
> John
>
>
> From: Shay Gueron <[email-masked]>
> To: Adam Langley <[email-masked]>
> Cc: John Mattsson2 <[email-masked]>, "[email-masked]" <
> [email-masked]>, Shay Gueron <[email-masked]>
> Asymptotically yes, but in this case we have q=2 and q=3 and any
> disadvantage of using a PRP should be negligible.
> In fact, if the above terms were true for small q (which they are likely
> not) the the then quadratic term is preferable as  2^2/2^{129} = 1/2^{127}
> << 2/2^{96} = 1/2^{95}
> Feels like doubling the amount of AES operations may be overkill and not
> worth the negligible security increase. GCM is popular for its performance,
> not for high security bounds.
>
>
>
> Anyway an organized paper with a statement on the security bounds, is
> going to come out in a paper that we are working on these very days. We
> will post it soon.
>
> Thank you, Shay
>

---

From: Adam Langley <[email-masked]>
Date: Thu, 19 Jan 2017 09:14:58 -0800

> tags than GCM. I think these advantages should be mentioned.

Thanks. I've added a TODO locally to think about this. I'm not sure
that we want to mention truncating authentication tags because that
seems contrary to the general thrust of robustness here. I'll see
whether I can say something about the advantages of the one-time
authentication keys in general however.

> that (C, T) increases the latency for decryption on multicore.

I don't understand why AES-GCM-SIV forces the processing of
unauthenticated plaintext. I think we might have different
definitions.

To me, processing authenticated plaintext means that the crypto API
releases plaintext for other processing before it has authenticated
it. It doesn't mean that the plaintext cannot sit in memory during
decryption while the AEAD checks the tag. (Indeed, many GCM
implementations interleave decryption and calculation of the GHASH
value.)

So putting the tag at the end prevents such APIs from being written,
which I think is a benefit.

A second benefit to putting tags at the end is that it's generally
easier to have extra space at the end of a buffer than the beginning.
This is not precise and might be a result of my C/C++/Go-based
environment, but I'm going to claim that a (buf, len, max) pattern is
easier for people to do with in an API than a (buf,
initial-padding-length, len).

In a case where space at the end of a buffer is easier to deal with,
putting the tag at the end is nicer because, otherwise,
encryption-in-place has to write ciphertext blocks 16 bytes in advance
of where it read them. In order to avoid clobbering the next plaintext
block, that has to copied first. I admit it's only a minor problem.

On the other hand, I'm not sure that I see the benefits of putting the
tag first in terms of latency on multicore machines. The AEAD model is
that the whole ciphertext is in memory when the operation is called so
it's as easy to read the tag from the end as from the beginning.

I can see an advantage in cases where the system could start
decrypting while the remainder of the record was still being read. Was
that what you had in mind? At least for multicore machines, I don't
think records should be so large that it makes a difference though.

Cheers

AGL

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Mon, 23 Jan 2017 18:43:03 +0000

Shay, Adam and Yehuda,

There are 2 things I hope to discuss in this email below.

1) The draft said that "We recommend a limit of 2^50 plaintexts encrypted with a given key. Past this point, AES-GCM-SIV may be distinguishable from an ideal AEAD.  (This is based on standard assumptions about AES.)".

To keep the probability of having a collision among 128-bit blocks in the ciphtertexts below 1/2^32 (practically zero), it has been suggested that under a given key, the amount of ciphertexts is not more than 2^48 128-bit blocks for the GCM in TLS 1.3.

With 2^50 plaintexts (equivalent amount of ciphertexts) and each ciphertext can be up to 2^32 128-bit blocks in the GCM-SIV draft, there can be collision situations.

A. When the ciphertext size is only 1 128-bit block, the probability for a collision is already higher than 1/2^32.

B. The probability for a collision gets bigger when the size of a ciphertext gets bigger.

With the GCM-SIV, the collision issue is under multiple AES encryption keys when the corresponding nonces are unique which is different from the collision situation described at the beginning for the GCM in TLS 1.3 which is under only one key.

I can't think of a damage to the data owner who sends their encrypted data over a TLS session caused by collision(s) among 128-bit blocks of the ciphertexts. So, I don't have an opinion here.

2) The draft said that " However, we feel that the 2^32 limit for AES-GCM is too risky in a multi-key setting.  Thus with AES-GCM-SIV we recommend that, for a specific key, a nonce not be repeated more than 2^8 times.  (And, ideally, not be repeated at all.)" .

Currently, the GCM with 96-bit random nonces situation, NIST requires the number of encryptions to be not more than 2^32, so that the probability of a repeat of a pair (key and nonce) is below 1/2^32, under a given key.

With m keys, the probability for a repeat of a pair of (key and nonce) is about m/2^32.

Therefore, it is best to use  96-bit counter-nonces for GCM.

With the GCM-SIV, when a nonce is repeated 2^8 times, the AES-128 encryption key is repeated 2^8 times. The 96-bit nonces for the AES counter mode encryption are practically (pseudo)-random nonces (derived from plaintexts and the master key). The probability for a repeat of a pair of (key and nonce) is about 2^16/2^96 = 2^(-80).

If someone cares about the multi-key situation such as the amount of keys being 2^50 (2^50 sessions),  call the number of sessions 2^x, the probability for a repeat of a pair of (key and nonce) is about 2^(x - 80).

The actual break happens when a pair of (key and nonce) repeats AND at least one 32-bit counter value also repeats with this pair. This problem happens  with 100% chance when the ciphertext size is (2^31 + 1) 128-bit blocks or larger.

Call the size of a ciphertext 2^y 128-bit blocks, the probability for having at least one 32-bit counter value to repeat is about 2^(y + 1)/2^32 = 1/2^(31 - y) = 2^(y - 31).

So, the number 2^(x - 80) x 2^(y - 31) = 2^( x + y - 111) must be not greater than 2^(-32) in order to keep the probability for a complete break to be below 2^(-32).

2^( x + y - 111) <= 2^(-32)   <==>  x + y <= 79.

When y = 32, x <= 79 - 32 = 47.

So, when plaintext/ciphetext size is 2^32 128-bit blocks, the GCM-SIV might be not good enough for 2^47 (or more) sessions when each session has 2^8 repeated nonce if a user's objective is to protect all of those 2^47 (or more) sessions.

In short, this condition "x + y <= 79" should be respected for the current GCM-SIV: draft 3 when the mode is used to protect a large number of sessions (multiple users).

To protect a lot more than 2^47 sessions when the ciphertext size is about 2^32 128-bit blocks, maybe it would be good to require that nonce must not be repeated. A specific number of repetitions of a nonce allowed can be derived from each pair of x and y if desired.

Best,

Quynh.

________________________________
From: Cfrg <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Wednesday, January 18, 2017 12:30:31 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-03.txt

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-gcmsiv/
draft-irtf-cfrg-gcmsiv-02 - datatracker.ietf.org<https://datatracker.ietf.org/doc/draft-irtf-cfrg-gcmsiv/>
datatracker.ietf.org
AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption (Internet-Draft, 2016)

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 24 Jan 2017 12:22:34 +0000

One way to improve the misuse of repeated nonces situation is to derive the AES encryption key from the S_s value, the nonce and the master key.

Quynh.

________________________________
From: Cfrg <[email-masked]> on behalf of Dang, Quynh (Fed) <[email-masked]>
Sent: Monday, January 23, 2017 1:43 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-03.txt

Shay, Adam and Yehuda,

Best,

Quynh.

Abstract: