Re: [TLS] Empty extensions don't go last
Wan-Teh Chang <wtc@google.com> Thu, 24 March 2016 07:04 UTC
Return-Path: <wtc@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 8A0F412D609 for <tls@ietfa.amsl.com>; Thu, 24 Mar 2016 00:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 4i_ImCCbBn-N for <tls@ietfa.amsl.com>; Thu, 24 Mar 2016 00:04:25 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 B266C12D146 for <tls@ietf.org>; Thu, 24 Mar 2016 00:04:25 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id h129so48551884ywb.1 for <tls@ietf.org>; Thu, 24 Mar 2016 00:04:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2e3EUxyA2GLVM59Y7QeEbmbMsr9UmxypkL5HI0LSWL4=; b=joh6lkUKhInW3bPQbi5bdODztl+rDHjsfq0qeL/k34KOggC782f8XaljfFim+Il58c tK4Etk07/Z4t7+raoTlvJ9N6Vi6KkSw2gJcZ9RhdJH9HSjboyCA3ThuB4hlzSDDgMwp8 ueS/dG4Fe34uc+CEjHWwjpQRSf7Mp0RAHcTcIAimocnIBg1D98oEpEL+nE8fItEVdi/8 YMqNdHJKJSE54Z47XkAGEweFjmME/ugrnYWwgFulcrIKM6/fEwR01YAEmXJvbuO8wnA7 VvXpSK2GjJIQwdL9wrHldYMdAB+nb7stTfu4hVFmUVXlf8MAqluHDRD0fVvYIqbbVdbm 8XKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2e3EUxyA2GLVM59Y7QeEbmbMsr9UmxypkL5HI0LSWL4=; b=KcffD/FVYnphNNFFGiF+gRPagy8eWxbZdHhPPDEPva6GsqzzXITw5tYF5RZINeTRrI 4CVnpzo+Dcn8tiAPFdUIAtYZv9bxOtLYVrDbk7NFN3SecXgc9KpkQhfpD+pF9ExIPQg2 xVZg2gJykY4YbmUnPN+6hGFg6s/6Y2EXsOftUpFimsoc2SgfBiFe8O/jVSMcUnF8pbx6 Y4GU4bYdiArGpzOoht2/DjmvYfVw6V45OcT0eqiKcwS+duICXfkaOnGTMc3FPMBY/WpB BLd9n+ISZ8JIprCjJ0t4UqloityXbjpjiK1AwvZ7R9E0K4GiNEa8fzk4deGBhdAKIXQE i3OQ==
X-Gm-Message-State: AD7BkJJc/ImWjyf8HiejMNUPu2EgIBfCzafnKDWLMdk+8ZgCIvpup4pWKBLspj5BfvOpY0NOvptdkOZg+LGfp7wn
MIME-Version: 1.0
X-Received: by 10.13.233.66 with SMTP id s63mr3454942ywe.36.1458803064736; Thu, 24 Mar 2016 00:04:24 -0700 (PDT)
Received: by 10.37.113.67 with HTTP; Thu, 24 Mar 2016 00:04:24 -0700 (PDT)
In-Reply-To: <CABkgnnW46PCE1xSk3oSs_Q1TDhv-dy20ya+Fn19EGeA+wvU7dA@mail.gmail.com>
References: <CABkgnnW46PCE1xSk3oSs_Q1TDhv-dy20ya+Fn19EGeA+wvU7dA@mail.gmail.com>
Date: Thu, 24 Mar 2016 00:04:24 -0700
Message-ID: <CALTJjxEMQPQgMsyxMVKQjBywb4LNnCMnCFhp7nDEUZzUA19JmA@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/xCRgStTMUwZkDgrR7bj9onCOvpw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Empty extensions don't go last
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: Thu, 24 Mar 2016 07:04:27 -0000
On Wed, Mar 23, 2016 at 10:30 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > (This is probably already known to a bunch of people, but it's > probably a good idea to put out there.) > > When deploying EMS, we recently discovered, with the help of our > friends at Google (who discovered this long before that) a quirk in > some implementations. > > Short story: Don't place an empty extension at the end of your > ClientHello. You will find that a small number of servers choke. This interop problem surfaces when we added to Chrome the signed_certificate_timestamp extension for Certificate Transparency (RFC 6962): https://bugs.chromium.org/p/chromium/issues/detail?id=353009#c4 https://bugs.chromium.org/p/chromium/issues/detail?id=363583#c13 https://codereview.chromium.org/240633006 The change that David Benjamin made to ssl3_CalculatePaddingExtensionLength() in his patch probably should also be considered if the padding extension (RFC 7685) is placed at the end: https://codereview.chromium.org/240633006/diff/110001/net/third_party/nss/ssl/ssl3ext.c Wan-Teh Chang
- [TLS] Empty extensions don't go last Martin Thomson
- Re: [TLS] Empty extensions don't go last Wan-Teh Chang
- Re: [TLS] Empty extensions don't go last Andrei Popov