Re: [TLS] Thoughts on Version Intolerance

Peter Gutmann <> Thu, 21 July 2016 12:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F95712DB7D for <>; Thu, 21 Jul 2016 05:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 1pLeG0zQIs92 for <>; Thu, 21 Jul 2016 05:25:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B7A212DB8B for <>; Thu, 21 Jul 2016 05:25:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1469103954; x=1500639954; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8Y25ge4mOnv0Sk0WWkW9Jjc0KnRrjPB56y7DhLKOYn0=; b=rU64FbcOGxKKBtSG2yAJB7VS7dgAVMIggVr7SSM6yfFEd8RVXsI6kRi7 oQQbPfpJI3C4vl0mpV7h/jPEgfWpOSlANhdO9nYx4LK3s55CRa0GFdUfb 1+ht0exEJ3iApI66LKNYwWAiaBAIymB1ZHWJTP8fgpqk1TblxTNp3R4NT m+kkXxp1aHZSG5ZTvSfOyEZ9+kbeWjQsYQSe2AssGyzFkm/WF77O4QdS+ +TyDR8W8XOgo84A/hZMIhekjNszPlkHM2PJFlZMKT+I2LgB5h55iQwSqu N4pS9ruBvmG6SMbPlJdBjaN/cV8os+PRxt1j9EfiUroQrmSffUrGcC+2p g==;
X-IronPort-AV: E=Sophos;i="5.28,399,1464609600"; d="scan'208";a="98012712"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 22 Jul 2016 00:25:49 +1200
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Fri, 22 Jul 2016 00:25:49 +1200
From: Peter Gutmann <>
To: "" <>, Hubert Kario <>
Thread-Topic: [TLS] Thoughts on Version Intolerance
Thread-Index: AQHR4OTM2eSp/VUo4Ee5kqtv5bpkQaAdX+GAgALlKQCAAAtbgIAAA4WAgAAnswCAAFI+gIACBjhZ
Date: Thu, 21 Jul 2016 12:25:48 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Thoughts on Version Intolerance
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: Thu, 21 Jul 2016 12:25:58 -0000

Martin Rex <> writes:

>Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour.
>X.509v3 certificates can theoretically include CAT MPEGs and amount to

We really need a TLS scanner that does this just to see what happens.  When I
created that cat-MPEG cert, I fed it to both MSIE and Netscape.  Both happily
accepted it, and then essentially become nonfunctional because although they
saw nothing wrong with accepting a cert of that size, they couldn't actually
deal with it.  In Netscape's case I had to delete the .db file before it could
be used again.  I wouldn't be surprised if you can quite effectively DoS
assorted TLS implementations with stuff like this.

(This is one of the design features of TLS-LTS, if both sides do -LTS then the
Hello only needs a single extension to specify everything.  Combine that with
PSK, so no certs, and you get quite an efficient protocol, the only thing of
any size is the keyex and server signature).