Re: [TLS] Server-side missing_extension MUSTs

Hubert Kario <hkario@redhat.com> Wed, 13 July 2016 12:12 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 4321E12DF17 for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 05:12:43 -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 Y9yeKnsE9v0m for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 05:12:42 -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 5C72A12DF1C for <tls@ietf.org>; Wed, 13 Jul 2016 05:12:41 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 DF2FE3E2A4; Wed, 13 Jul 2016 12:12:40 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-204-99.brq.redhat.com [10.40.204.99]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6DCCddb005459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2016 08:12:40 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 13 Jul 2016 14:12:39 +0200
Message-ID: <209780076.Yzkn8lymcZ@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: <CAF8qwaDLkEKsy3eTfdMX-jxoaRbnFrs-_GWAtENPNtfvjg5b1Q@mail.gmail.com>
References: <CAF8qwaAAw6zA9jRPMQ5MXqHptBtsarhNPcH6KJzzSE-h1XiFDg@mail.gmail.com> <CABkgnnWp9W05d+iwOBAA9HVMnv7wNhJ4fQSO8jbY2E5WdjRu+g@mail.gmail.com> <CAF8qwaDLkEKsy3eTfdMX-jxoaRbnFrs-_GWAtENPNtfvjg5b1Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart146848134.jTCUAlIU8A"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 13 Jul 2016 12:12:41 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UksorSLuLLPX7560mKK7qAzMbj4>
Cc: David Benjamin <davidben@google.com>
Subject: Re: [TLS] Server-side missing_extension MUSTs
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 12:12:43 -0000

On Wednesday 13 July 2016 05:23:53 David Benjamin wrote:
> I don't believe an implementation which fails to send supported_groups,
> etc., in 1.3 would ever leave a developer's workstation. It would not
> interoperate with anything.

it would interoperate with itself, and for some deployments that's enough
of a passing grade... (Even if you do interoperatbility testing you
do not check all possible permutations of features and settings)

I wholeheartedly agree with Dave here, error definitions should be strict
(both on the when and what to do). One, because it allows to better
diagnose (in general, maybe not in this specific situation) problems.
Two, because you can write a strict negative test case that actually
checks for it.

-- 
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