Re: [TLS] TLS padding breaks ironport

Brian Smith <> Thu, 17 April 2014 20:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 74CC01A019E for <>; Thu, 17 Apr 2014 13:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.856
X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CoD2tSTHXHxx for <>; Thu, 17 Apr 2014 13:47:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9A2731A0045 for <>; Thu, 17 Apr 2014 13:47:06 -0700 (PDT)
Received: by with SMTP id m5so862972qaj.6 for <>; Thu, 17 Apr 2014 13:47:02 -0700 (PDT)
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:date :message-id:subject:from:to:cc:content-type; bh=KjlzmlMa+Uwxl30uxZ6n1l2u+wOlVpbYYeioy25ByzE=; b=lofV5wJAf7QX79Ck0qNGuCuEwI6NanU725ttkrsVNuyiBDPMqTvEvzh2EmlWtl/9GL 34JhWt8nBuzQZuBXbQo/s4LfNe/OyM+d2Qg5Ywh6lGEnk66x/PjGxa81KDwjF/Il13xW pLN+T4Xwlfgeiwx9KzoRK4ajGr/M98FJWVSnk3LoEt4ZSv51nxCL1U2/oOFuXTzJ7Upk BWt30gU28NUGnX0JiEhUp5VKaiUUeIxVxV4jb+9L9hGLd46Zehhg/tgNjVoVbFODsf7C jd6FG/fvOBGcRIMHU6UO2yonuiys41caUVFLadtwhE2Pru/9IhLRB24vOVENMJ/V5jbu v4Sg==
X-Gm-Message-State: ALoCoQlm+MUzNTzmQRbdu5SCocze8cSoeuieV1teoEk3f0iE2Nv8uVyRU+C1b5Xs0LawYFDl3UO2
MIME-Version: 1.0
X-Received: by with SMTP id t6mr15962081qac.30.1397767622755; Thu, 17 Apr 2014 13:47:02 -0700 (PDT)
Received: by with HTTP; Thu, 17 Apr 2014 13:47:02 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 17 Apr 2014 13:47:02 -0700
Message-ID: <>
From: Brian Smith <>
To: Kurt Roeckx <>
Content-Type: multipart/alternative; boundary=047d7bdca66aa219ee04f7432279
Cc: "<>" <>
Subject: Re: [TLS] TLS padding breaks ironport
X-Mailman-Version: 2.1.15
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: Thu, 17 Apr 2014 20:47:11 -0000

On Thu, Apr 17, 2014 at 1:30 PM, Kurt Roeckx <> wrote:

> I've just been pointed to:

See also, which is also
about a compatibility issue with the padding extension, and which affects
HTTPS, not just email. In particular, some websites break in Firefox 29+
due to this, and those websites result in non-secure TLS version
intolerance fallback in some Chrome versions.

Wan-Teh Chang found that the server mentioned in the Mozilla bug report is
sensitive to the ordering of the extensions in the client hello, and that
changing the client hello extension order in NSS got the site working. But,
we have yet to figure out what the optimal ordering is for maximizing
compatibility with all products globally.

It seems like the Mozilla bug report and the OpenSSL bug report may be
referring to the same issue in the same server TLS stack. In that case, it
may be a good idea for OpenSSL to also consider fixing the issue by
changing the ordering of extensions in its ClientHello.

And/or, we may try one or both the three following workarounds:

(1) If the ClientHello size *without* the session ticket extension included
is less than 256 bytes, then don't send the padding extension, even if the
ClientHello is in the "danger zone" of 256-512 bytes. The assumption here
is that any product using session tickets that would cause the Client Hello
size to enter the danger zone would not have the incompatibility that the
padding extension works around.

(2) If the ClientHello would contain a session ticket *at all*, then don't
send the padding extension. The (unverified) assumption here would be that
the F5 products that had the compatibility issue with ClientHellos in the
danger zone do not support session tickets.

(3) Don't use the padding extension at all, and instead include a fake
session ticket in the session ticket extension, when the ClientHello size
is in the danger zone and there's no session ticket to send. The assumption
here, which is almost certainly invalid, is that server implementations all
silently discard malformed session tickets sent by the client.