Re: [TLS] AEAD only for TLS1.3 revisit

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Tue, 30 September 2014 19:44 UTC

Return-Path: <jsalowey@cisco.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 8F66D1A8832 for <tls@ietfa.amsl.com>; Tue, 30 Sep 2014 12:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level:
X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 BkgEXgf5peVs for <tls@ietfa.amsl.com>; Tue, 30 Sep 2014 12:44:54 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D5D1A8831 for <tls@ietf.org>; Tue, 30 Sep 2014 12:44:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2526; q=dns/txt; s=iport; t=1412106294; x=1413315894; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UH5z9LR8xjXbVqWz4/0jtUFD5+2XFo81YS/oCmqEGNQ=; b=cNVYHPBTSegxyaVX4O2G8b5v1u7bIrdDP86UEZ/4/+L7+N6WSUkhNZdX P45QJfkBjqwl8LfvhOFqPmlppyy4Gq4IkXkOaEz77rs47AvM+D7zgkhui QasgSvgyGB2canrTBxK4Mr/HUzzt3DjMNH+G5+Ww/44C1vxo6TUrG+gqh I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiQFAAoIK1StJA2E/2dsb2JhbABggw5TVwTKHgqHTQKBDhYBe4QEAQEDAQEBATc0CwULAgEINhAnCyUCBA4FGYgdCA2+SgETBI9QGzMHgy6BHQWRaotFlXCDY2yBSIECAQEB
X-IronPort-AV: E=Sophos;i="5.04,628,1406592000"; d="scan'208";a="359587959"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP; 30 Sep 2014 19:44:53 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8UJirCW004399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 19:44:53 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 14:44:52 -0500
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: Michael StJohns <msj@nthpermutation.com>
Thread-Topic: [TLS] AEAD only for TLS1.3 revisit
Thread-Index: AQHP3AJ4lndEwGXmSE2+7AxRf6JNSZwaacsA
Date: Tue, 30 Sep 2014 19:44:52 +0000
Message-ID: <A46BA862-DEE1-46CF-9193-40D1EAAA14BE@cisco.com>
References: <542988C5.8050307@nthpermutation.com>
In-Reply-To: <542988C5.8050307@nthpermutation.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.33.248.136]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6E1C963016E5F54A91EDAF305E87D9B8@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3Ak05_sErYHNdqhemhvp3LMVg1s
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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: Tue, 30 Sep 2014 19:44:55 -0000

Allowing man-in-the-middle or integrity only cipher suites is not a valid reason to revisit the AEAD decision.  Allowing for man-in-the-middle and passive monitoring is in opposition to our current mandate.   As an aside, if this becomes a requirement in the future I don't think that AEAD actually limits either of these possibilities, although your choice of cipher may.  

Cheers,

Joe
On Sep 29, 2014, at 9:28 AM, Michael StJohns <msj@nthpermutation.com> wrote:

> 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
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls