Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

Jacob Appelbaum <> Sun, 06 December 2015 01:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 13B711B2E5C for <>; Sat, 5 Dec 2015 17:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NZXHDV5UuYZw for <>; Sat, 5 Dec 2015 17:52:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F8461B2E5D for <>; Sat, 5 Dec 2015 17:52:46 -0800 (PST)
Received: by iouu10 with SMTP id u10so154233582iou.0 for <>; Sat, 05 Dec 2015 17:52:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hWlwl5ohTaJQrIn+E6b0/LtvqJnBtEIZm5pWD9bFuTg=; b=OHy3vtlAlIoB4bwG0f4cjpd9XCVJhBQZgumU/6E4iKWEMATBZTFVEqwVBY4769CEMZ m6HTpP75173taRGLQVSgxRG3TXQkVl9wSK6Q58bBQ9/RyYpEfqdgVkdjnDMBxhC/r0a0 rOYvx4RLb0tpFPdV6QOFVTNjgnP1Ucti8hCsr0D1ZppXETja6zdsFRwEOsE2J9iSe31P bVIKtd04zEoUSaFtTJTxGeym3fdxt4Id5bF3GO9svTGr4meQnDdKdgTVtOA/a8P0NFo3 YW5OLIQQ4odyip0BU9Hs4dXAFymUOnYJi9zqv+Dv/eEbr3pwujGCQNFiZd20+7C+1O2q 8zFg==
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=hWlwl5ohTaJQrIn+E6b0/LtvqJnBtEIZm5pWD9bFuTg=; b=AMb03mwS7HYVWywuohFdytOsYjQcida8nu3YNjtux2weOx4QYdHOICt4HgJQyQhggl jUZIMHRPb5YNyBvVhT532XrYs1w86v8yz74XbS1qErFDy09LI8Z2KJKTzjCp1lHhdCYJ iwKU4LXAFL8NcXDTkshK/5fjFjIOLKad3cktc07bZ+xRt+8dc9+2BCGhug+8vFSFOsfF QfpOqINvzSMNhlWU6PirBFuLEpNw40mJOIV/1OyfhYpmtD4aES6RS5wn+HSxfYXO8xxD WGhvRR4zKF9IzHUgRfNm2PjBHI3hP3BG9oJ+X3E8ORIa79p5FyfHBQZh4wMlRMpNEHwa lxSA==
X-Gm-Message-State: ALoCoQkSZBeH9W0P7Fcv4cZuSkT1gHB9UJx0h7bOKK62cwHW5I/v8wVQ7bHBoxdJwxMtM2Szec1N
MIME-Version: 1.0
X-Received: by with SMTP id g79mr19914942ioi.81.1449366765459; Sat, 05 Dec 2015 17:52:45 -0800 (PST)
Received: by with HTTP; Sat, 5 Dec 2015 17:52:44 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Sun, 06 Dec 2015 01:52:44 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Peter Gutmann <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
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: Sun, 06 Dec 2015 01:52:50 -0000

On 12/6/15, Peter Gutmann <> wrote:
> Jacob Appelbaum <> writes:
>>On 12/4/15, Peter Gutmann <> wrote:
>>> Jacob Appelbaum <> writes:
>>>>TCP/IP and DNS are out of scope, though obviously related.
>>> Why are they out of scope?
>>They are out of scope for the TLS working group as far as I understand the
>>organization of the IETF in terms of mandate. Am I incorrect?
> They're out of scope in that TLS can't impose behaviour on DNS, but they're
> not out of scope when it comes to considering what impact DNS has on TLS.

Of course. Thankfully there is work to fix DNS by... using TLS!

> For
> example the whole reason why TLS has certificates is because the TLS (well,
> SSL then) folks realised that DNS wasn't secure, and that TLS had to deal
> with
> that issue.  Otherwise, the SSL folks could have just said that DNS issues
> are
> out of scope, and we'll wait for DNSSEC to appear at some point and fix
> things
> (this is speaking from a 1995 time frame).

Hopefully someday, we'll have the DNS security problem solved. Until
then, I look forward to the TLS working group to not making name
privacy _harder_ to implement. The great irony of DNS potentially
using TLS for privacy is... oh, so much for that strategy.

>>Or they could just call MinimaLT or CurveCP with mandatory Elligator TLS
>> 1.3
>>and be done with it.
> That would probably be an easier process than the current one, provided
> you're
> ready to commit completely to the Bernstein monoculture.

I admit, I'm biased here. I'd rather have a monoculture of security
than polyculture of insecurely designed by commitee.

All the best,