[TLS] Zero length fragments and fragmented Alert messages
Hubert Kario <hkario@redhat.com> Tue, 18 October 2016 10:28 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 410AB1295DD for <tls@ietfa.amsl.com>; Tue, 18 Oct 2016 03:28:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.353
X-Spam-Level:
X-Spam-Status: No, score=-7.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, 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 4ngRFdsnX5h3 for <tls@ietfa.amsl.com>; Tue, 18 Oct 2016 03:28: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 CFB0E1295DA for <tls@ietf.org>; Tue, 18 Oct 2016 03:28:54 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 202B3C057FAD for <tls@ietf.org>; Tue, 18 Oct 2016 10:28:54 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9IASqmK027370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Tue, 18 Oct 2016 06:28:53 -0400
From: Hubert Kario <hkario@redhat.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Tue, 18 Oct 2016 12:28:46 +0200
Message-ID: <2491854.n0oRtYzp7Y@pintsize.usersys.redhat.com>
User-Agent: KMail/5.3.1 (Linux/4.7.7-200.fc24.x86_64; KDE/5.26.0; x86_64; ; )
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart123087856.MGi1IgC8WB"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 18 Oct 2016 10:28:54 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7t39ywEw2YEqfs3epshKCDzNGxs>
Subject: [TLS] Zero length fragments and fragmented Alert messages
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: Tue, 18 Oct 2016 10:28:56 -0000
Current draft states:
Alert messages ({{alert-protocol}}) MUST NOT be fragmented across records.
and
Implementations MUST NOT send zero-length fragments of Handshake or
Alert types, even if those fragments contain padding.
But I don't see what is the expected behaviour of the side receiving such
malformed messages.
Especially the fragmented alerts are unique in that any other message type can
be fragmented, so no rules define how to handle incorrectly fragmented
messages. Or at least I don't see them.
--
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] Zero length fragments and fragmented Alert … Hubert Kario
- Re: [TLS] Zero length fragments and fragmented Al… Eric Rescorla