[TLS] Specify handling of errors by peers
Hubert Kario <hkario@redhat.com> Fri, 02 September 2016 19:08 UTC
Return-Path: <hkario@redhat.com>
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 4B56D12D0FD for <tls@ietfa.amsl.com>; Fri, 2 Sep 2016 12:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.45
X-Spam-Level:
X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 W6SYUK9raB7V for <tls@ietfa.amsl.com>; Fri, 2 Sep 2016 12:08:54 -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 DBE4F12B071 for <tls@ietf.org>; Fri, 2 Sep 2016 12:08:53 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5A01480F7C for <tls@ietf.org>; Fri, 2 Sep 2016 19:08:38 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (vpn1-5-142.ams2.redhat.com [10.36.5.142]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u82J8aMA026905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Fri, 2 Sep 2016 15:08:38 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Fri, 02 Sep 2016 21:08:36 +0200
Message-ID: <35927502.rKvAgB1kFc@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; )
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2033204.ZD7nzgOmEn"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 02 Sep 2016 19:08:38 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bNHl8ztwlAvIz749ioWKglwAXio>
Subject: [TLS] Specify handling of errors by peers
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: Fri, 02 Sep 2016 19:08:55 -0000
While the specification already details a lot of situations that "MUST NOT" happen or that are errors, it doesn't specify how those situations should be handled by peers. Add information that they need to cause the receiving side to send a fatal alert with appropriate description. Most of the additions in this pull request[1] should be uncontroversial, one I'm not sure sure about is the alert type to send in case of invalid value in Finished message, do we want to hide it in bad_record_mac, or should it be typical for such cases illegal_parameter? (Currently what a peer is supposed to do if the Finished value does not match the expected one is not specified) 1 - https://github.com/tlswg/tls13-spec/pull/621 -- Regards, Hubert Kario Senior 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
- [TLS] Specify handling of errors by peers Hubert Kario