Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting

Tom Ritter <tom@ritter.vg> Tue, 18 March 2014 03:23 UTC

Return-Path: <tom@ritter.vg>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9618E1A0349 for <tls@ietfa.amsl.com>; Mon, 17 Mar 2014 20:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
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 pVWm3jbPyW37 for <tls@ietfa.amsl.com>; Mon, 17 Mar 2014 20:23:34 -0700 (PDT)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 070031A0233 for <tls@ietf.org>; Mon, 17 Mar 2014 20:23:33 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id x10so6417608pdj.6 for <tls@ietf.org>; Mon, 17 Mar 2014 20:23:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fQ8tWT9RI87PcryOqNBD2WMEve0Ey9I3FLHtMsn29Ss=; b=wwUWRYyEcN7LG+8eD7rFf+eQT2rMskk23/7whrocPBx+5gDX8Wxy/fGtvkECiP2ZJb GbwwfJls3x2efM2RRe4Oz7qT5ZYKbkLixWYNTdS8MbSZy7tfSc/ESXsVcmMa5KFNHqcz 8KiygMjgk9/JyVjG4HYW2Ik9h4koJpO+tRFdk=
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:from:date :message-id:subject:to:cc:content-type; bh=fQ8tWT9RI87PcryOqNBD2WMEve0Ey9I3FLHtMsn29Ss=; b=jDgeG9Z7QZVDYtrcFCy+Lnqqm4IlCXDelk9KHx31discSf0C3XuX0MHI9Pw6P5Aau+ Qt9EQrelRMxTcPXtUZEJ9m+fWYrDmuDK7emV7vdF16QKvlFWRZ64CDHwY0FMsBxg8YFp hI/Zswtqins+FDkILwwp/k356WEBY3q52zvnOTiwdTbpCGzPBEbIrWXcMcaWLHDFrFI+ 5kTzndoAv+slQ1p3/sjCLlNgOw0V3NGZk2AZ47PDrJYosg7ZPwauR2Y/hvHjtYIXshDE D+MrJ3kMPDWNCuEc3RzsCtd2OPA4fLmFqWDUNJBunydOLERq2U8Pi8BdcivOvnf3T8PZ oX/w==
X-Gm-Message-State: ALoCoQnExk0/wXypkc4POdPuLfO+j/esN1zoyPkwpgyrUkxq1o4usgjhmxBk3CkZs1PrrnIhLp/L
X-Received: by 10.66.164.135 with SMTP id yq7mr12636233pab.126.1395113005238; Mon, 17 Mar 2014 20:23:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.198.68 with HTTP; Mon, 17 Mar 2014 20:23:04 -0700 (PDT)
In-Reply-To: <532709B1.6030800@nthpermutation.com>
References: <5325DDA0.9030006@nthpermutation.com> <CA+cU71mzCBMgEAtb1aamHUnP0kx1Ngu9NoCXV0ODQ8P2nVkO0Q@mail.gmail.com> <532709B1.6030800@nthpermutation.com>
From: Tom Ritter <tom@ritter.vg>
Date: Mon, 17 Mar 2014 20:23:04 -0700
Message-ID: <CA+cU71nef5OLdRg6z60u98Y4H8irDr2EcCCMAvuG7daiT1=Gjw@mail.gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oZsgEwxm_J77iaiKI7Qvu9YQKi4
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 18 Mar 2014 03:23:35 -0000

On 17 March 2014 07:41, Michael StJohns <msj@nthpermutation.com> wrote:
> On 3/16/2014 9:43 PM, Tom Ritter wrote:
>> What about protecting the certificate sent by the server?
>> What about protecting supported ciphersuites and extensions listed -
>> taking steps towards protecting what user agent is being used?
>> What about client certificates - protecting identity of the client?
>> What about extensions? SRP Data, Client/Server Auth data, Padding?
>
> Sorry - I should have put it like this (which AFAIK reflects the F2F
> discussion):
>
> SNI is the only one of these that needs to be sent upfront - the rest can be
> done (albeit expensively) at later stages of the negotiation.


That's fair, thanks.


>> If we had this before, the DHE exchange would be protected and we
>> wouldn't be exposing 1024 DH all over the place.
>
> I don't actually understand this point.  You're saying because the DH
> negotiation is encrypted under a key negotiated by a previous DH
> negotiation, then 1024 bit DH would be safe?

Nope, I'm saying if I'm waving a fairy wand and randomly
rearchitecting protocols in the past, TLS _might_ have had the DHE
negotiation occur inside a channel protected by the non-PFS RSA key.
In my alternate world, we're able to upgrade the RSA key (1024, 2048,
4096) but due to annoying client restrictions, not the 1024 DH. And in
the alternate world, the 1024 DH handshake is protected by the 2048
RSA - you can't attack the 1024 without breaking the 2048.  (Like you
can now.)

It's just an example where data that was sent in the clear, instead of
in a secure channel, enabled attacks in an unexpected way a decade or
more later.


>> If we spend all our time focusing on trying to protect individual
>> components, we'll find arguments against any of them.  I'd much rather
>> start from the perspective of protecting everything and address
>> problems on an individual basis.  When building a cryptographic
>> protocol you don't choose the smallest security margin you can think
>> of for the application.
>
>
> All of this is motherhood I agree with except with "protecting everything"
> because TANSTAAFL - there ain't no such thing as a free lunch - everything
> costs and sometimes provides little benefit.  But 1) what problem is this
> trying to solve?  2) How much cost is involved - on the client side and on
> the server side?  3) How much does this increase the attackers work factor?
> These are all question I look at before deciding to move forward with a
> solution.
>
> I'm unclear that we've agreed on the problem we're trying to solve (or
> problems), (And encrypt everything is not the problem, its the tool).

That's fair.  I imagine not everyone agrees with me when I see the
problem as "The client communicates version information, options, and
preferences outside a channel protected against a passive adversary.
The client is unable to communicate information it deems very
sensitive in a channel protected against an active adversary*."

* I suppose the caveat there would be "in a way performant enough for
anyone to use it" ;)

The arguements I really disagree with are the ones of the form:
 - There's no reason to try and hide the options one supports, because
the User-Agent will be sent at an earlier or later time in plaintext.
 - DNS lookups mean the data is exposed anyway, so who cares about it.

These arguements assume a specific operating environment and model.
While it's true it's common today, there is no guarentee that it will
be true tomorrow, or that someone won't try and tackle those problems
elsewhere.  It's also violating the principal of layering - I
shouldn't care what's happening at a different layer, I should make my
thing independent and secure.

I'm wondering if there is an approach here to hide the SNI against a
passive adversary, but not an active adversary - with the ability to
'bolt-on' strong authentication of 'ephemeral' keys if the stronger
protection is needed...

-tom