IETF Logo Mail Archive

[TLS] Server-side missing_extension MUSTs

David Benjamin <davidben@chromium.org> Wed, 13 July 2016 01:58 UTC

Return-Path: <davidben@google.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 7595212DB94 for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 18:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.182
X-Spam-Level:
X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RISK_FREE=2.804, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 aoVwdSvgJbzj for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 18:58:57 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2316912DB80 for <tls@ietf.org>; Tue, 12 Jul 2016 18:58:56 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id m101so33589211ioi.2 for <tls@ietf.org>; Tue, 12 Jul 2016 18:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=nF5Z506qI6Gr29k3dNWtAaIMXvhvHhJ97AExj8MZm9s=; b=fkgU8zLacbMAMihLnB9GFHfUrHEQZi6eRTm3bYmeoNRJJesYIbqbn7M0I2yl9tjWZY iHPDmOePTx68ZxnfKRERqnLDn3eNs95LTSQtJnbYjf8PGwFsJ8kRdUBR8GSayqqPct42 zLXkTB4mX2j7i9j9H+b/T3ENwbjAVF9Jr4IRY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nF5Z506qI6Gr29k3dNWtAaIMXvhvHhJ97AExj8MZm9s=; b=SF/n5IhY/q73I9E5EvVX2HdFop5onK3R3jUZZJuC789ByJaWodUGZKBCfc33SHUQpM NSEbTDS/DjaMqyNxeoP+RIF9pfMi+7oH+ukDC0jFrx39nh8JbQgWtMm79Bfgy+bsMK/W ksx42EQAavgCwGxIetXdQ0kxPzNSJyXYhdhdpz05Q2Nu0x2iDGWhypvDMXCZQge7oodX S0xQ7gWWFv5giLkOgV6txyK9whSTOfZkU9D7SmJ0DOCl/6teZZUSrfNPoI4W/zZQgV3W OgLlwxighA/1qtmBAZZW5dmZSjl0vw55ALAoLsvnNhC49XUJ3AsxyjKPQtaUEGTtw6Kq 9xrQ==
X-Gm-Message-State: ALyK8tJ7dLs44m2nvfy2S5yvnJ0h7c6Ndv4IHPvEhbmjB/ZkXhv79boBlH3bTFHgD0JK193pk2wdBQNI2AdIKwtV
X-Received: by 10.107.13.82 with SMTP id 79mr6887224ion.97.1468375136138; Tue, 12 Jul 2016 18:58:56 -0700 (PDT)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Wed, 13 Jul 2016 01:58:46 +0000
Message-ID: <CAF8qwaAAw6zA9jRPMQ5MXqHptBtsarhNPcH6KJzzSE-h1XiFDg@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113fdb5e635cbc05377abaa8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sqWYPkMJ3TRdzkmnl0rBy_7dVQo>
Subject: [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 01:58:58 -0000

Hey folks,

I would like to remove the missing_extension MUSTs on the server side. Full
justification in the PR.
https://github.com/tlswg/tls13-spec/pull/544

On the client, it is perfectly feasible to mandate a particular alert
value. The check is very straight-forward. On the server, however, this is
a mistake. Servers do not necessarily have full information if not all
advertised ciphers are known, and a natural implementation of the
negotiation algorithm will not output this case. Even without this clause,
the handshake is already required to fail, so there is no risk of invalid
clients being deployed.

Adding more complexity to an already hairy negotiation algorithm (the
pseudocode I mentioned is incomplete) just to diagnose what is an invalid
ClientHello anyway is not worth it. It buys too little for the complexity
cost.

David

v2.23.0 | Report a Bug | By Email