Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CDA130DEE for ; Wed, 26 Sep 2018 23:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bjJ8wlc6hQO for ; Wed, 26 Sep 2018 23:04:54 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB90126DBF for ; Wed, 26 Sep 2018 23:04:54 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id s5-v6so1078095pfj.7 for ; Wed, 26 Sep 2018 23:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+sckrESCLhN7EdnKotsLzzT1WyeD2JC89s+S70Zqp/8=; b=tadDEveU85udLfIejsqhtBI3BJ1LoGfb3s1/2iyHP1T7GQiUcS0OpvOyRi5ZdBvmVG /YJWH20qAHfVWHwe1aFUZL28KsA5ci2ytTGGsjOVDtDSlKRaTusSA5z1Ddp0hIgofRfb s5n1L6XVsvqdz20SLc1LCtOmNXFPlKmNhHXc4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+sckrESCLhN7EdnKotsLzzT1WyeD2JC89s+S70Zqp/8=; b=AUG329d7KQwaswzh+wEyiBikabBilEjSCxHy0WTeTueb4XeuIi7yTrfkFDLj3KRGiB IjXjG/Z52G9ES7sysYtMeyl5l779RLdCQ2d+c0QopgogVG9UkhOW2NwZWwYjaiu0olg3 N2CSSZdvQS5M+o3YtYEqIqzckCVcL05vfscGJjzlBhOHS8JO2nLMJwMhrn04kO2JKRoO s+qlwFZlURNS5/D4RUK9d6dtXLMMgHOBkA/ymXnDSj6ol0FdIXPiRtui8OPn+o+hVzQu za4XtvCZ4WPyKP9HfqLIyWYIFkr0mA/JX4ycufznYWhKkKkAAck5zW42fctjocevMtEX 2biA== X-Gm-Message-State: ABuFfohmhf4yRX6TjnMIi7Bcsg/u2mMG8QXirCcGuDw3YznIKPptNgMk hUalRdUF/t5rwhy/FiV9rfFmNHRnYtI6nw== X-Google-Smtp-Source: ACcGV62XQOMLzUMXZ6Dz7TzhQuWyfU/UydlvNKlP2GbTi92wxiBTUVi3iaxX/hgGnL7mE0tmKYIJpA== X-Received: by 2002:a17:902:2:: with SMTP id 2-v6mr9432478pla.178.1538028293748; Wed, 26 Sep 2018 23:04:53 -0700 (PDT) Received: from ?IPv6:2601:646:c601:83b0:3c5b:ed67:dd95:933a? ([2601:646:c601:83b0:3c5b:ed67:dd95:933a]) by smtp.gmail.com with ESMTPSA id c1-v6sm1086107pgp.34.2018.09.26.23.04.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Sep 2018 23:04:53 -0700 (PDT) From: Brendan McMillion Message-Id: <0A6E4266-DACE-4F0A-AF31-855FFB33B106@cloudflare.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1A2F7BC6-6502-4F65-9422-67E242260034" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Wed, 26 Sep 2018 23:04:52 -0700 In-Reply-To: <20180927001617.16e26b5a@T-200> Cc: mls@ietf.org To: Dennis Jackson References: <20180926223043.106fb209@T-200> <20180927001617.16e26b5a@T-200> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [MLS] Proposal: Change AES-GCM to AES-SIV X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 06:04:59 -0000 --Apple-Mail=_1A2F7BC6-6502-4F65-9422-67E242260034 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Handling nonces is a tricky part of any implementation and easy to get = wrong in the presence of state loss I think this is the core reason to consider using SIV. Since nonces are = generated deterministically and statefully, is it possible for state = loss (caused by an app crash) to cause nonce reuse? If so, SIV is = necessary assuming implicit nonces. Another solution is to use explicit random IVs, as this prevents nonce = reuse (statistically, with a correct implementation) and means we can = keep using abundantly available AES-GCM implementations. > On Sep 26, 2018, at 4:16 PM, Dennis Jackson = wrote: >=20 > Hi Richard,=20 >=20 > The use of implicit nonces is complementary to SIV, but certainly > doesn't replace it. To be precise, implicit nonces ensures all > implementations use the same scheme for nonce generation. It does not > ensure that nonce generation scheme is correct. >=20 > One possible source of error is an edge case in which the > implementation unintentionally deviates from the standard. This is = hard > to catch in practice. With AES-GCM, an attacker able to detect (or > force) this edge case would be able to derive the authentication key > and attack the protocol. With AES-SIV, the attacker would gain very > limited information about the message sent and the protocol would = abort > normally.=20 >=20 > A second, more serious source of error is when the nonce generation > scheme is not correctly designed. This was the case in the KRACK = attack > on WPA2. Despite the comparative simplicity of a 4-message 2-party > handshake and WPA2's wide deployment, every single implementation had > at least one nonce reuse attack. Although WPA2 does use explicit = nonces > (since it is over a lossy medium), implicit nonces would not have > caught the KRACK attack, as both parties reset their nonce > counter in accordance with the specification.=20 >=20 > Given we are implementing a novel multi party asynchronous group key > exchange from scratch, I don't think we should shrug this away. Not > when the code level difference for implementors is only whether to = pick > EVP_CIPH_GCM_MODE or EVP_CIPH_SIV_MODE.=20 >=20 > All the best, > Dennis=20 >=20 > On Wed, 26 Sep 2018 23:53:24 +0200 > Richard Barnes > wrote: >=20 >> Hi Dennis, >>=20 >> 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. >>=20 >> 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. >>=20 >> --Richard >>=20 >>=20 >> On Wed, Sep 26, 2018 at 11:31 PM Dennis Jackson >> wrote: >>=20 >>> Proposal: Change AES-GCM to AES-SIV >>>=20 >>> Rationale: >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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]. >>>=20 >>> + 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) >>>=20 >>> References: >>>=20 >>> [1] >>> = https://www.usenix.org/system/files/conference/woot16/woot16-paper-bock.pd= f >>>=20 >>> [2] https://www.krackattacks.com/ >>>=20 >>> [3] http://web.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf >>>=20 >>> [4] https://datatracker.ietf.org/doc/rfc5297/ >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>>=20 >=20 >=20 >=20 > --=20 > PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_1A2F7BC6-6502-4F65-9422-67E242260034 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 > Handling nonces is a tricky part of any = implementation and easy to get wrong in the presence of = state loss

I think this is the core reason to consider using SIV. Since = nonces are generated deterministically and statefully, is it possible = for state loss (caused by an app crash) to cause nonce reuse? If so, SIV = is necessary assuming implicit nonces.

Another solution is to use explicit random IVs, as this = prevents nonce reuse (statistically, with a correct implementation) and = means we can keep using abundantly available AES-GCM implementations.

On Sep 26, 2018, at 4:16 PM, Dennis Jackson = <dennis.jackson@cs.ox.ac.uk> wrote:

Hi = Richard, 

The use of = implicit nonces is complementary to SIV, but certainly
doesn't = replace it. To be precise, implicit nonces ensures all
implementations= use the same scheme for nonce generation. It does not
ensure that = nonce generation scheme is correct.

One possible source of error is an edge case in which = the
implementation = unintentionally deviates from the standard. This is hard
to catch in = practice. With AES-GCM, an attacker able to detect (or
force) this = edge case would be able to derive the authentication key
and attack = the protocol. With AES-SIV, the attacker would gain very
limited = information about the message sent and the protocol would = abort
normally. 

A second, = more serious source of error is when the nonce generation
scheme is not = correctly designed. This was the case in the KRACK attack
on WPA2. = Despite the comparative simplicity of a 4-message 2-party
handshake and = WPA2's wide deployment, every single implementation had
at least one = nonce reuse attack. Although WPA2 does use explicit nonces
(since it is = over a lossy medium), implicit nonces would not have
caught the = KRACK attack, as both parties reset their nonce
counter in = accordance with the specification. 

Given we are = implementing a novel multi party asynchronous group key
exchange from = scratch, I don't think we should shrug this away. Not
when the code = level difference for implementors is only whether to pick
EVP_CIPH_GCM_MODE or EVP_CIPH_SIV_MODE. 

All the = best,
Dennis 

On Wed, 26 = Sep 2018 23:53:24 +0200
Richard Barnes <rlb@ipv.sx> wrote:

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-pa= per-bock.pdf

[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




-- PGP = Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC

_______________________________________________
MLS mailing = list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

= --Apple-Mail=_1A2F7BC6-6502-4F65-9422-67E242260034--