IETF Logo Mail Archive

[TLS] No cypher overlap (was: ban more old crap)

Hubert Kario <hkario@redhat.com> Tue, 28 July 2015 15:42 UTC

Return-Path: <hkario@redhat.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 42E8F1ACD22 for <tls@ietfa.amsl.com>; Tue, 28 Jul 2015 08:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 yRVancKRTo7W for <tls@ietfa.amsl.com>; Tue, 28 Jul 2015 08:42:09 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045541ACD14 for <tls@ietf.org>; Tue, 28 Jul 2015 08:42:08 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 80398A37FE for <tls@ietf.org>; Tue, 28 Jul 2015 15:42:08 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-197.brq.redhat.com [10.34.0.197]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6SFg7qP007016 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Tue, 28 Jul 2015 11:42:08 -0400
From: Hubert Kario <hkario@redhat.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Tue, 28 Jul 2015 17:41:58 +0200
Message-ID: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.9 (Linux/4.0.8-300.fc22.x86_64; KDE/4.14.9; x86_64; ; )
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart6545367.A87tjg4WYV"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/DLm98TfNVYOwf6X3cGjXEhdwUR0>
Subject: [TLS] No cypher overlap (was: ban more old crap)
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: <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: Tue, 28 Jul 2015 15:42:10 -0000

I see one possible problem with TLS1.3 not being a superset of TLS1.2.


Consider the following:
  Server which supports TLSv1.3 but is configured to accept only AES256 
ciphers.
  Client which advertises TLSv1.3, but no support for AES256-GCM. The client 
advertises also CBC ciphers (both AES128 and AES256) as it wants to be able
to connect to legacy servers too.

Should such a connection end up with TLS1.2 with AES-CBC ciphersuite, or 
should it be aborted?

I think we should go for continue connection with downgraded protocol, but 
explicitly say that it may not happen if the negotiated ciphersuite would be 
DES, RC4, export grade...

That would allow us to reiterate in the TLS1.3 spec that they are a big no-no, 
and that if you claim support for TLS1.3 you should never negotiate them with 
a similarly modern peer.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

v2.23.0 | Report a Bug | By Email