IETF Logo Mail Archive

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

Aaron Zauner <azet@azet.org> Sun, 15 May 2016 06:39 UTC

Return-Path: <azet@azet.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A8612B033 for <tls@ietfa.amsl.com>; Sat, 14 May 2016 23:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org
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 KifSblzvL-6D for <tls@ietfa.amsl.com>; Sat, 14 May 2016 23:39:16 -0700 (PDT)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (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 62B3412B00D for <tls@ietf.org>; Sat, 14 May 2016 23:39:16 -0700 (PDT)
Received: by mail-qg0-x22d.google.com with SMTP id w36so76750415qge.3 for <tls@ietf.org>; Sat, 14 May 2016 23:39:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=3v0j4Wt1bh0bbdnkB+lLN0g+BH6gF3Vhh0mFmKQOl7M=; b=jJyScSJPRWB2uaUNJpyK018csedMKq1lkQp2Q1zUpDEkpUCa0KFH/7+N4DuFIYkgUp gpx5N7V6YgrzAC+ajtmVpYGwdhhABEv+co7LO0gluYKJRxG/3oDmYJ23fYGIJc5ag3kC SXb/8mTyMPRMBdQ46lK861iTLbo9jWHFgIGus=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3v0j4Wt1bh0bbdnkB+lLN0g+BH6gF3Vhh0mFmKQOl7M=; b=ivvoHQnUxKT9y/PVRPZHnDExUBOHxIFIfT66WIJLnmd+FyoGxQN8KeVrdNnvOTAtzC 1WasBfTMVkJiEsvi0npZD3FnSqFycv+rYP1xqvf2mbStDkvn/FZyscbaDJpXUGiFBWCz /co94r0Xw3nR4bislfXAArPq+NNkQi3Nse8oIfMEgPT+nRbS0lWMc+LDYU3/4xXmUhxi Si/0Pywjn5sBKWvYVDhg+XOo9z7g/Iwt+1fnANVKQvfrwHf7mi2J//2qclkGwI2W3/z3 dixrfWv50ZUid9bm4pT2TDKOzcj7myyEhgX57jFxrXIvGPGv4U4xYHMe0kJORCoALklu rAgw==
X-Gm-Message-State: AOPr4FVKmtJYi87W25AAuS1e0v542kNsuIOoSmjpQgv8dDfezjJEsm9sZhrHo0nw18R1Cfq93IvV99LDdMhomQ==
MIME-Version: 1.0
X-Received: by 10.140.163.85 with SMTP id j82mr24603363qhj.40.1463294355516; Sat, 14 May 2016 23:39:15 -0700 (PDT)
Received: by 10.200.40.69 with HTTP; Sat, 14 May 2016 23:39:15 -0700 (PDT)
Received: by 10.200.40.69 with HTTP; Sat, 14 May 2016 23:39:15 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz>
References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz>
Date: Sun, 15 May 2016 13:39:15 +0700
Message-ID: <CAN8NK9EaDQ-Pugi2j=3KcXrn5G-8mcXVs4O2HGCkH7h7GSKbbA@mail.gmail.com>
From: Aaron Zauner <azet@azet.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary="001a113a3a344346510532dbc458"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rvWXPrvzTQVAyuWAwvQXmeG2oSY>
X-Mailman-Approved-At: Sun, 15 May 2016 17:38:32 -0700
Cc: "sean+ietf@sn3rd.com" <sean+ietf@sn3rd.com>, "Kathleen.Moriarty.ietf@gmail.com" <Kathleen.Moriarty.ietf@gmail.com>, "mcgrew@cisco.com" <mcgrew@cisco.com>, "jsalowey@cisco.com" <jsalowey@cisco.com>, "tls@ietf.org" <tls@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>, "abhijitc@cisco.com" <abhijitc@cisco.com>
Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 May 2016 06:39:20 -0000

Hi,

On May 15, 2016 10:28, "Peter Gutmann" <pgut001@cs.auckland.ac.nz> wrote:
>
> RFC Errata System <rfc-editor@rfc-editor.org> writes:
>
> >The following errata report has been submitted for RFC5288, "AES Galois
> >Counter Mode (GCM) Cipher Suites for TLS".
>
> I think the erratum needs an erratum.

No problem, but:
>Firstly, "nonce" doesn't mean "number
> used once", and secondly nonce re-use in AES-GCM doesn't just result in
> "catastrophic failure of it's authenticity", it results in catastrophic
> failure of the entire mode, both confidentiality and
integrity/authenticity.
>

What do you think nonce stands for?
https://en.wikipedia.org/wiki/Cryptographic_nonce

In TLS nonce reuse allows us to attack the authentication key of GCM. Not
the actual master secret. There's no direct break of the confidentiality,
just authenticity (and thus integrity). For HTTPS this allows us to inject
content which then may lead to a compromise of the session confidentiality.

Maybe I misunderstood what you meant.

Aaron

> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email