MIME-Version: 1.0
References: <20180926223043.106fb209@T-200>
In-Reply-To: <20180926223043.106fb209@T-200>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 26 Sep 2018 23:53:24 +0200
Message-ID: <CAL02cgQ4xRDy0DTT+x_vySY3VJRP64bdSn2utBPpOPV3c9EAJA@mail.gmail.com>
To: dennis.jackson@cs.ox.ac.uk
Cc: mls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000037723a0576cd411b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/bsdKNexKVN7SM-xwTWAyucuAXcM>
Subject: Re: [MLS] Proposal: Change AES-GCM to AES-SIV
Precedence: list

--00000000000037723a0576cd411b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dennis,

Thanks for writing this up.  One brief note: The B=C3=B6ck et al. paper you=
 cite
is about TLS 1.2 and earlier, which use explicit nonces.  In fact, that
paper cites the implicit nonce approach in TLS 1.3 as one of their two
recommended approaches.  That seems to support the idea that generating
nonces in the TLS 1.3 style is a reasonable solution here.

That, together with the persistent lack of implementation of AES-GCM-SIV,
makes me inclined to stick with normal AES-GCM, while assuring adequate
safeguards.

--Richard


On Wed, Sep 26, 2018 at 11:31 PM Dennis Jackson <dennis.jackson@cs.ox.ac.uk=
>
wrote:

> Proposal: Change AES-GCM to AES-SIV
>
> Rationale:
>
> AES-GCM requires a unique nonce for every message, otherwise it
> fails catastrophically by directly leaking the authentication key
> and consequently provides no resistance to active attacks on
> confidentiality.
>
> AES-SIV is a drop in replacement for AES-GCM which significantly
> mitigates the impact of repeated nonces. For a message pair with
> repeated nonces the attacker only learns if the two plaintexts were
> equal. There is no other loss of confidentiality or authenticity. This
> is provably the minimum leakage possible in the event of a repeated
> nonce.
>
> Handling nonces is a tricky part of any implementation and easy to get
> wrong in the presence of state loss or concurrency. Failures
> in nonce generation are both catastrophic and subtle. Richard Barnes
> has already improved the specification by moving from explicit to
> implicit nonces which can aid the discovery of faulty implementations.
> However, implicit nonces are not a silver bullet and recent papers have
> uncovered serious nonce reuse issues in both TLS [1] and WPA [2].
>
> + AES-SIV significantly mitigates the impact of nonce reuse
> + AES-SIV is a drop in replacement with the same interface as AES-GCM
> + AES-SIV makes use of the same hardware support as AES-GCM
> + AES-SIV has a proof of security [3] and is described in RFC 5297 [4]
> * AES-SIV has reasonable (but not extensive) library support (including
>   OpenSSL, BoringSSL, Intel IPP)
> * Despite being over 10 years old, AES-SIV has not seen widespread
>   deployment
> * AES-SIV Encryption is ~70% of the speed of AES-GCM Encryption
>   (Decryption is the same speed as AES-GCM)
>
> References:
>
> [1]
> https://www.usenix.org/system/files/conference/woot16/woot16-paper-bock.p=
df
>
> [2] https://www.krackattacks.com/
>
> [3] http://web.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf
>
> [4] https://datatracker.ietf.org/doc/rfc5297/
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>

--00000000000037723a0576cd411b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Dennis,</div><div><br></div><div>Thanks for writin=
g this up.=C2=A0 One brief note: The B=C3=B6ck et al. paper you cite is abo=
ut TLS 1.2 and earlier, which use explicit nonces.=C2=A0 In fact, that pape=
r cites the implicit nonce approach in TLS 1.3 as one of their two recommen=
ded approaches.=C2=A0 That seems to support the idea that generating nonces=
 in the TLS 1.3 style is a reasonable solution here.<br></div><div><br></di=
v><div>That, together with the persistent lack of implementation of AES-GCM=
-SIV, makes me inclined to stick with normal AES-GCM, while assuring adequa=
te safeguards.</div><div><br></div><div>--Richard</div><div><br></div><div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Sep 26, 2018 at 11:=
31 PM Dennis Jackson &lt;<a href=3D"mailto:dennis.jackson@cs.ox.ac.uk">denn=
is.jackson@cs.ox.ac.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">Proposal: Change AES-GCM to AES-SIV<br>
<br>
Rationale: <br>
<br>
AES-GCM requires a unique nonce for every message, otherwise it<br>
fails catastrophically by directly leaking the authentication key<br>
and consequently provides no resistance to active attacks on <br>
confidentiality. <br>
<br>
AES-SIV is a drop in replacement for AES-GCM which significantly<br>
mitigates the impact of repeated nonces. For a message pair with<br>
repeated nonces the attacker only learns if the two plaintexts were<br>
equal. There is no other loss of confidentiality or authenticity. This<br>
is provably the minimum leakage possible in the event of a repeated<br>
nonce. <br>
<br>
Handling nonces is a tricky part of any implementation and easy to get<br>
wrong in the presence of state loss or concurrency. Failures<br>
in nonce generation are both catastrophic and subtle. Richard Barnes<br>
has already improved the specification by moving from explicit to<br>
implicit nonces which can aid the discovery of faulty implementations.<br>
However, implicit nonces are not a silver bullet and recent papers have<br>
uncovered serious nonce reuse issues in both TLS [1] and WPA [2]. <br>
<br>
+ AES-SIV significantly mitigates the impact of nonce reuse<br>
+ AES-SIV is a drop in replacement with the same interface as AES-GCM<br>
+ AES-SIV makes use of the same hardware support as AES-GCM<br>
+ AES-SIV has a proof of security [3] and is described in RFC 5297 [4]<br>
* AES-SIV has reasonable (but not extensive) library support (including<br>
=C2=A0 OpenSSL, BoringSSL, Intel IPP)<br>
* Despite being over 10 years old, AES-SIV has not seen widespread<br>
=C2=A0 deployment<br>
* AES-SIV Encryption is ~70% of the speed of AES-GCM Encryption<br>
=C2=A0 (Decryption is the same speed as AES-GCM)<br>
<br>
References: <br>
<br>
[1] <a href=3D"https://www.usenix.org/system/files/conference/woot16/woot16=
-paper-bock.pdf" rel=3D"noreferrer" target=3D"_blank">https://www.usenix.or=
g/system/files/conference/woot16/woot16-paper-bock.pdf</a><br>
<br>
[2] <a href=3D"https://www.krackattacks.com/" rel=3D"noreferrer" target=3D"=
_blank">https://www.krackattacks.com/</a><br>
<br>
[3] <a href=3D"http://web.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf" rel=
=3D"noreferrer" target=3D"_blank">http://web.cs.ucdavis.edu/~rogaway/papers=
/keywrap.pdf</a><br>
<br>
[4] <a href=3D"https://datatracker.ietf.org/doc/rfc5297/" rel=3D"noreferrer=
" target=3D"_blank">https://datatracker.ietf.org/doc/rfc5297/</a><br>
<br>
_______________________________________________<br>
MLS mailing list<br>
<a href=3D"mailto:MLS@ietf.org" target=3D"_blank">MLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/mls" rel=3D"noreferrer" ta=
rget=3D"_blank">https://www.ietf.org/mailman/listinfo/mls</a><br>
</blockquote></div></div></div>

--00000000000037723a0576cd411b--