Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Hubert Kario <hkario@redhat.com> Wed, 13 July 2016 11:51 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 4A57012DECF for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 04:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.209
X-Spam-Level:
X-Spam-Status: No, score=-8.209 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=-1.287, 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 I9K08feI90wW for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 04:51:32 -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 50F6312DE93 for <tls@ietf.org>; Wed, 13 Jul 2016 04:51:31 -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 87F0412E05F; Wed, 13 Jul 2016 11:51:30 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-204-99.brq.redhat.com [10.40.204.99]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6DBpSoi020559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2016 07:51:29 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 13 Jul 2016 13:51:28 +0200
Message-ID: <4743747.aJSUQRlHeP@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.5.7-202.fc23.x86_64; KDE/4.14.20; x86_64; ; )
In-Reply-To: <57855399.70201@akamai.com>
References: <CABcZeBMiLmwBeuLt=v4qdcJwe5rdsK_9R4-2TUXYC=sttmwH-g@mail.gmail.com> <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <57855399.70201@akamai.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1638506.2UfQhpHZdG"; 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]); Wed, 13 Jul 2016 11:51:30 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/D9QoUDkZ60VdohH5qS3_Egq7Iv8>
Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
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: Wed, 13 Jul 2016 11:51:33 -0000

On Tuesday 12 July 2016 15:31:21 Benjamin Kaduk wrote:
> >> ###  Encrypted Extensions
> >>
> >> 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.  All server-sent extensions other than those explicitly listed
> >> in {{server-hello}} or designated in the IANA registry MUST only
> >> appear in EncryptedExtensions. Extensions which are designated to
> >> appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients
> >> MUST check EncryptedExtensions for the presence of any forbidden
> >> extensions and if any are found MUST terminate the handshake with an
> >> "illegal_parameter" alert.
> 
> > This seems inconsistent. In implementation, I would write explicit disjoint
> > whitelists of extensions for both (and non-whitelisted one is a fatal
> > error). Explicit whitelisting is safe even on client side, since the
> > extensions are bounded by client-supported ones.
> 
> You would have an explicit whitelist of all (including encrypted)
> extensions for the server, so that it chokes when a client starts
> sending a new one?  Or just that it would not be considered for further
> processing [and potential inclusion in ServerHello]?
> 

I'd rather not see a mechanism that will introduce TLS extension intolerance
in compliant implementations.

IMNSHO this is the uncommon situation where a blacklist is the correct
solution
-- 
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