Re: [TLS] (offline note) Re: Confirming Consensus on supporting only AEAD ciphers

mrex@sap.com (Martin Rex) Tue, 06 May 2014 16:20 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C8E1A00A2 for <tls@ietfa.amsl.com>; Tue, 6 May 2014 09:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 g_HXRgSiGinm for <tls@ietfa.amsl.com>; Tue, 6 May 2014 09:20:41 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8F1A0173 for <tls@ietf.org>; Tue, 6 May 2014 09:20:41 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s46GKWE4021425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 May 2014 18:20:32 +0200 (MEST)
In-Reply-To: <5368DAED.3020000@gmail.com>
To: Rene Struik <rstruik.ext@gmail.com>
Date: Tue, 6 May 2014 18:20:32 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140506162032.AEC6A1ACF7@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/f4jivrYmfTlmFeYC1-IbJXoizFc
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] (offline note) Re: Confirming Consensus on supporting only AEAD ciphers
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: <http://www.ietf.org/mail-archive/web/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: Tue, 06 May 2014 16:20:45 -0000

I can not correlate your most recent response to the prior question:

>Michael StJohns wrote:
>>
>> Sorry - I'm coming late here.  Does this also imply the complete 
>> elimination of the integrity only cipher suites?

I understand this to refer to these cipher suites:
    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };

which provide authentication PLUS integrity, but no confidentiality.

Rene Struik wrote:
> 
> In general, an AEAD mode takes as input two strings a and m and a key k, 
> and authenticates a and m, while encrypting m. If m is the empty string, 
> this results in an authentication-only mode.
> 
> Thus, AEAD modes can be used to provide suitable combinations of 
> authentication and/or encryption. Examples hereof include the GCM mode 
> and CCM mode.

Now this seems to refer to an idea to provide only (initial) authentication,
but no integrity protection of the actual application data (m).


-Martin