IETF Logo Mail Archive

[TLS] handling of duplication of extensions between ServerHello and EncryptedExtensions

Hubert Kario <hkario@redhat.com> Fri, 02 September 2016 17:31 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 6253912D1E0 for <tls@ietfa.amsl.com>; Fri, 2 Sep 2016 10:31: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 F5Z_UkE8CJ11 for <tls@ietfa.amsl.com>; Fri, 2 Sep 2016 10:31: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 6D20A128E18 for <tls@ietf.org>; Fri, 2 Sep 2016 10:31:54 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 36549C05680F for <tls@ietf.org>; Fri, 2 Sep 2016 17:31:54 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (vpn1-5-142.ams2.redhat.com [10.36.5.142]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u82HVqrq013207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Fri, 2 Sep 2016 13:31:53 -0400
From: Hubert Kario <hkario@redhat.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Fri, 02 Sep 2016 19:31:52 +0200
Message-ID: <2847810.DkTLEJYpS7@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="nextPart1655658.yI2a9M7EaO"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 02 Sep 2016 17:31:54 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YFTASZeEctXabmvLTftxl3K8XZg>
Subject: [TLS] handling of duplication of extensions between ServerHello and EncryptedExtensions
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 17:31:55 -0000

So, the draft has following text:

    The same extension types MUST NOT appear in both the ServerHello and
    EncryptedExtensions.  If the same extension appears in both locations,
    the client MUST rely only on the value in the EncryptedExtensions
    block. 

if the extension "MUST NOT" be in both ServerHello and EncryptedExtensions, 
why the client should continue with the handshake if a server makes such a 
major mistake? Why aborting the connection in such situation isn't safer?
-- 
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

v2.23.0 | Report a Bug | By Email