Re: [TLS] Enforcing Protocol Invariants

Ryan Carboni <> Fri, 09 November 2018 00:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05EFC130E05 for <>; Thu, 8 Nov 2018 16:02:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lmWe0DS5h-Vr for <>; Thu, 8 Nov 2018 16:02:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3CD5130DDE for <>; Thu, 8 Nov 2018 16:02:47 -0800 (PST)
Received: by with SMTP id n140-v6so89326yba.1 for <>; Thu, 08 Nov 2018 16:02:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ln2BFx2nzycQk1h2wL9/ABJaLbpaxPO2CHr1lgWSha8=; b=oGed0NnD+Oxuza3GK+g+Xa/68XE8b/fIx78wEBkjaAyxGJAdYGltCBiygDFqOFsgYk Zt1k1DgyfrH3bi9fQhSRgoArfeChLOutSuLBRgWf4W/XRQpz6OOexhYaaD5vXTTtwWka IWw7w7Odziw6berS2WNZb15slq12gJ/SLXHgj9m5ZS6N9J6QCp9FfKEuY4AWHkLBU432 omXZRHh3SMKQlLzPYr54ZLngqF64i9cIbZ8opJclgY0+AiA9xsfxkhQkT1HMSfnN0xjI kG91NJADY5+qT/r/NdL1ytlAoRhan8yHKFouoW/RuAM1hHHG6kljdZE2AapZcqTpj7kv PquA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ln2BFx2nzycQk1h2wL9/ABJaLbpaxPO2CHr1lgWSha8=; b=mytk4mXRFgY8vMomtwC2PN0g8YuJ5G0Kf1EDQb+3wy55wLLZ9XXDmYqRjv3/XX5Yf9 jtx1GPMiSQ5oniZvlGqd8cAW7AWxdxdvb0htz0sI12cH2B2sLn1FpOt2wmAFCieYRXpf DDtQHdljha3m8ZvnT2HzjxUgmdmDkj9cEO87vFG5svQC1s6x9IorzKmff4LYZbCmaBol 2cUWNs9G7Nsbn41pqFiB7iNKMVQuZ+R1/SricX0TEtVUDbH3hvwyamFtz80c3LefKQ0V LrHWZKh/31oWpZu8tE+LLVCKkzXwiKDAVMYOF4UVGMiaVtmG53ATrCoLDXQpV3jV2yc8 mM9g==
X-Gm-Message-State: AGRZ1gIq4sic6z0GGI92gREm/1JyQrf/GvDtBfYOp+3VgCVKQy9SMW0N 0KuLF4wSgQjo0mZkQiGoNnrt7KUM8fcCKorWOlm/lQ==
X-Google-Smtp-Source: AJdET5do3Q309BnbfemfzFLjU7d52342gLmxHQJE7tiUlEX9K6whySXB8LYr1GocjT9RS8sdV5+w9s1VLPj3b7nJapo=
X-Received: by 2002:a25:ce12:: with SMTP id x18-v6mr6719800ybe.111.1541721767043; Thu, 08 Nov 2018 16:02:47 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a0d:ffc7:0:0:0:0:0 with HTTP; Thu, 8 Nov 2018 16:02:46 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Ryan Carboni <>
Date: Thu, 08 Nov 2018 16:02:46 -0800
Message-ID: <>
To: "Salz, Rich" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000004469b9057a3012ee"
Archived-At: <>
Subject: Re: [TLS] Enforcing Protocol Invariants
X-Mailman-Version: 2.1.29
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: Fri, 09 Nov 2018 00:02:50 -0000

I think I have implied that ClientHello is unneccesary to an extent, it can
be replaced by a DNS TXT record.

I think I implied that self-signed certificates are acceptable given the
precedent of Let’s Encrypt and the use of DNSSEC (has there been evidence
of DNS spoofing attacks against a CA?).

I think my suggestion has the implication that protocol negotiation is
unnecessary, although it can be kept.

I think my suggestion would have automatic backwards compatibility. A TLS
1.2-only client (likely to be found in regulated sectors that requires
middlebox inspection and decryption) would attempt to connect using port
443, while my proposed protocol would attempt to look up using DNS first to
obtain DNS records relevant. By using separate ports for each new protocol,
it maintains a greater level of cross-compatibility and allows for future

These compounded extensions make the protocol less secure by making it
harder to implement, particularly given the recent spate of attacks against
unintuitively implemented state machines for key negotiation.

The entire protocol should be removed and replaced by something far simpler.

Is this sufficiently specific?

I hope in the future, the IETF TLS working group will reach out to
middlebox designers to understand what they are exactly doing to TLS so
that these things won’t be unexpected.

I must also say that CBC isn’t bad, as long as the padding is considered to
be part of the message to be authenticated.

On Thursday, November 8, 2018, Salz, Rich <> wrote:

> *>*Hmm. TLS has gotten too complex.
> What makes you say that?  Please be specific about what you think should
> be taken out.