Re: [TLS] Server-side missing_extension MUSTs

Martin Thomson <> Wed, 13 July 2016 04:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F5D512D187 for <>; Tue, 12 Jul 2016 21:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5sDj7l7X6Mxc for <>; Tue, 12 Jul 2016 21:18:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8851E12B02B for <>; Tue, 12 Jul 2016 21:18:29 -0700 (PDT)
Received: by with SMTP id p74so33415045qka.0 for <>; Tue, 12 Jul 2016 21:18:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MUcnXgmyFS6HQHqWPUg1kZ7TbIvOhMiDZMpkTWfONTY=; b=tD2zGQ0rImFJu9p3NjXvEda/7m3jUh0Xlgncg6B+qs/DqfSQ8QnhzHHhK6nI2u2DoQ EwDKMMRZYlqNQ9JMYSlbV+gcvm9ub2Hhgvy6E4je+gYsJ61wvtjRKgka75ARCRiiOclL LpPYhGLXJu7+LmhXFdbmEAlxZiUZaQRZ+LYYKl7EfMladB0d8o/OjJWy6FsoFyRJ99oN LcKDboGpiZVXe+LxN/3sk7942ftATIOhCPFt6mBkidyl5MMlaTRrr9qXhA08v7Z7KNP8 /yijQ800iJbeTr3EvXOTOejpoj9Mxi6zy6A4JZVF+4uArBu0ZQkuhwt5SHbCRySVdMqt VWWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MUcnXgmyFS6HQHqWPUg1kZ7TbIvOhMiDZMpkTWfONTY=; b=AY2AESoCEeUO48SDeRqaVg43xX0gI/Kxe3uvuhT7krwVSWQ9xXOlCXWRHAZCa4EWKt 0GxwDhgGuFuUcE9LIVdZiBy2IowybtlebvTeOryVfM3mg83t2y8DC6ZGtQ+LHKVeCCnh YMVvUvPe/r3XUWgzVoNTgxBhb8x4Vz7V+IygyuZxJ5BFjiVDECCqBUQiHJbcKuVmbUJ1 UoKAs8aeIdOl/ifYKG4Zqh92NYiM7dE6KJlXwK2cXqXDPE17rajm6e04E96f9DD5MpAd KHhx5LSXuMSX7K6UDwyTh8kR37Dh0r5bU0Eoo07V5Y7YaBwuJhUjeTmFZfs4VXI8sVCp hXsA==
X-Gm-Message-State: ALyK8tLk4iLz75EPEjb5g+Hi5BHp1RnVmyscE8xht0kawJEJTDc3/adTVKDG2tICBc2HDGhvuWD41WZ1S62+jw==
X-Received: by with SMTP id t74mr7879904qki.80.1468383508713; Tue, 12 Jul 2016 21:18:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 12 Jul 2016 21:18:28 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Martin Thomson <>
Date: Wed, 13 Jul 2016 14:18:28 +1000
Message-ID: <>
To: Dave Garrett <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Server-side missing_extension MUSTs
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jul 2016 04:18:31 -0000

On 13 July 2016 at 13:22, Dave Garrett <> wrote:
> I am aware that discussion ended up on accepting sloppy error reporting as acceptable. Changing the disputed missing_extension alerts to SHOULDs would be an acceptable compromise if that decision is still actually going through.

"sloppy" is a bit of a mischaracterization.  There are good reasons
for this decision.

It allows implementations to be structured differently.  In
particular, if there are two relevant error conditions, different
implementations could discover them in different orders.
MUST-strength requirements on alerting for one of those conditions
means that you have to order your checking in a particular way;
MUST-strength requirements on multiple concurrent conditions are
basically impossible to meet.

It also allows an implementation to decide that abrupt cessation of
communications is preferable to generating a report.  That can be
important for DoS mitigation.

In the end, we concluded that you shouldn't lie about error
conditions; if you determine that there is a missing extension and you
decide to send an alert, then it has to be the missing_extension

David's PR goes to the core of the first of my reasons here.  The ways
in which servers decide on the things like version and cipher suite
when presented with a ClientHello is in practice hugely different
between implementations.  That's healthy, but it does mean that we
need flexibility.