[TLS] AEAD only for TLS1.3 revisit

Michael StJohns <msj@nthpermutation.com> Mon, 29 September 2014 16:28 UTC

Return-Path: <msj@nthpermutation.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 520971A8883 for <tls@ietfa.amsl.com>; Mon, 29 Sep 2014 09:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 RA7wQHW5hIwJ for <tls@ietfa.amsl.com>; Mon, 29 Sep 2014 09:28:47 -0700 (PDT)
Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7631A8872 for <tls@ietf.org>; Mon, 29 Sep 2014 09:28:47 -0700 (PDT)
Received: by mail-qc0-f170.google.com with SMTP id m20so1614843qcx.29 for <tls@ietf.org>; Mon, 29 Sep 2014 09:28:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=MG0spsaLgmPypx8/Hid3q3cUpf9ifKm9nGb93rzKJtk=; b=BoelQ9gkMs8Y9fm2SQVVl2RPkrKETXgtKbPkdmQJ1nMIjMMXiGnCjTFHUyAL9e4vcI cwaVDSiZA7IWvgVS7sGuNhGTb7uZ9Et1lrJ0d6qhodPUsBA8tyGN/ArWI+iRq+GBRY77 ZjTRHD+kBi//TmJHsNu0HD3KmfW9jgJrZIg0WtACiG6zsUOy9dgpVCWsoIC7eYrPaen4 qZtIQT7iijuQGqIXlTH+ukLiPK6R4U175gOjkjyySogcs5LGH2nWFcqbZH/ewy2mBDsf jLvao3ZQmzjbitvjK3kmpH+52A1Gd78fJNu8bIch1P067G0ouLAZDybS8BkVGuQ7+feA iwpQ==
X-Gm-Message-State: ALoCoQnzvvk1oAk5bn9VXVkU2DLOOnCvDPQ6+fwtzxeEhZjm/qe995tU16ckrEBjzB9fxZnOgLbE
X-Received: by 10.224.136.10 with SMTP id p10mr54889754qat.26.1412008126617; Mon, 29 Sep 2014 09:28:46 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:226:dcf6:7fcc:4024:34e3? ([2601:a:2a00:226:dcf6:7fcc:4024:34e3]) by mx.google.com with ESMTPSA id o6sm11574087qag.40.2014.09.29.09.28.46 for <tls@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Sep 2014 09:28:46 -0700 (PDT)
Message-ID: <542988C5.8050307@nthpermutation.com>
Date: Mon, 29 Sep 2014 12:28:53 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/06k8oAo-me2zVJLHWUE8-edNoXw
Subject: [TLS] AEAD only for TLS1.3 revisit
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Mon, 29 Sep 2014 16:28:49 -0000

Hi -

This isn't a proposal to change the decision to only include AEAD 
ciphers in TLS1.3.  But something crossed my desk that suggested I 
should at least mention a possible issue with this.

Background:  There are number of countries (and private networks) that 
have a requirement to decrypt any traffic passing through certain 
places.  There is not a corresponding requirement to allow them to 
imitate a sender or receiver.  This can be done through key escrow, 
LEAF-like fields or multiple encryption of the data for example.

Implication:  AEAD ciphers have a single key which is broken down for 
use both in the encryption and integrity processes.  Revealing that 
single key (to satisfy the decryption requirement) can reveal the 
credentials to allow masquerading.  If the TLS connection credentials 
are also being used as credentials for control actions (e.g. 
cyber-physical controls of power systems, control over a firewall, etc), 
fulfilling the decryption requirement provides an unintended attack 
surface for possibly life critical systems.


Thoughts:  At least one AEAD cipher (CCM) uses the exact same key for 
both integrity and encryption.  There is no way to reveal the encryption 
key without also revealing the integrity key.  But if you have the 
integrity key, you can masquerade as sender or receiver (controller or 
controlled).

Question:  In light of the above, should we revisit the AEAD-only 
decision for TLS1.3?


Question:  Is there absolutely no requirement for TLS1.3 integrity only 
cipher suites?

The fallback for systems in areas that have these requirements could be 
either TLS1.2, one of the other IETF security protocols, or something 
proprietary.

And yes, this was triggered by a real-world requirement.

Mike