Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00

Adam Langley <agl@google.com> Fri, 25 October 2013 15:00 UTC

Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B2011E8341 for <tls@ietfa.amsl.com>; Fri, 25 Oct 2013 08:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTM7pc6jTWsH for <tls@ietfa.amsl.com>; Fri, 25 Oct 2013 08:00:45 -0700 (PDT)
Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B603711E81C9 for <tls@ietf.org>; Fri, 25 Oct 2013 08:00:40 -0700 (PDT)
Received: by mail-vb0-f46.google.com with SMTP id 10so2555186vbe.33 for <tls@ietf.org>; Fri, 25 Oct 2013 08:00:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8q9vyLdH7Lt0eFINKssbZLMOAon674CWAyJKmVLohAA=; b=hgwdOW1Eo4EdZ7gWsV3rCsugQErBCl4j5gLlvCoYutHbuA/m668rTYxlotQt+LcbNE aJf8VoqxUMKp6w5EW8jYFyUJ/ltTV1XGBuyFEfQLyv1vZlY2RnrgvNnggjzxBZGTO/FN 6YZPEgVh2RG1dsfG9Jo/TAbyzItr9Oq3b/EQ6BIQN8XKlygNRgs6vDNR3203JZZjTioo Sqwf0MhklsFjCuqmEqPy9G9e+S1vbUiN9ee051/M4lJQn8D0qPAc/5EburxSqg251QwO Ttq1rDnEGH05YFmYJF/OkiqFhAvch80/WcPMLaUqYUWSfSQs8Txz1idXnVO/s4k6qo8I Il2w==
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=8q9vyLdH7Lt0eFINKssbZLMOAon674CWAyJKmVLohAA=; b=cqLx0L6gkW7HSnMsbRERs80YLjmaSp0TkhcpRfHEH85mqDPnT9HF34jXs0S1gLIx4t E6SilXaQkJqeleRX9FE+6mVHkXuLR6+yJ/TypWjc0QpnDT16m44VtDyT1KTVS4itLxKZ GWaKr9jLp6z+yp7uRQevlxTp2C9r7lBaHlzO8Yo+su36H+QXI9Mkpr3oUVzeF76FdVHm D+SmSivfqXn4xHqT1BZzYKEEjjDD/4f8p7NXKrEopJUd7AJMviYdgj5LkBK77AvLJ4OP NpJz8nGH8Kf4jraDItNNUFmn1TyJz/q4t8VXZF9BndOuV82EC9xU3plpjgJVKBJ3XYoh yv6Q==
X-Gm-Message-State: ALoCoQmVKp11BpivVD1BdqTkUufngM5EtvU6KO2Cl2+0NIq1H60v9N4aFNuQiS/yyL1vGEcYyGtXegw7dV7akpngycy+TC63gr6GUbvj9OU4A2EDpbbaQih1AZK7x+y52IUTbmwXw8qGmQ24mOxDsq46LKr3Pf+RfJ3ZJtMeS+UFSxv7w+kLmGCxj9VW3UGoTMxH38YNv8ju
X-Received: by 10.220.244.132 with SMTP id lq4mr591656vcb.31.1382713205042; Fri, 25 Oct 2013 08:00:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Fri, 25 Oct 2013 07:59:44 -0700 (PDT)
In-Reply-To: <CACsn0c=z2iUe3hinqmtuTAY4R=r64BXvg=t_o3JTWLhQtOVJrw@mail.gmail.com>
References: <CACsn0cnzTuyezaCj0AmxtV_-6a04TZeAJtbBovAUQQfy16ua7w@mail.gmail.com> <CAL9PXLxdAGK2E5577xHJGexQpEWwrbC_Y+otEQmWfv2pV211HQ@mail.gmail.com> <CACsn0c=4HHw3PfCsRxnuHf+Rca1GrOSi60OjJQ4qoJKGcP60Pw@mail.gmail.com> <CAL9PXLxq91G+Es0J+tvPFO9BAyedA6Z0CmMqPqq4UC6hAbtSbw@mail.gmail.com> <CACsn0c=z2iUe3hinqmtuTAY4R=r64BXvg=t_o3JTWLhQtOVJrw@mail.gmail.com>
From: Adam Langley <agl@google.com>
Date: Fri, 25 Oct 2013 10:59:44 -0400
Message-ID: <CAL9PXLzoNgTT9qxKmokHSoBkAgQWB1FOHDggMRgkQ_OK5Gh=+g@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 25 Oct 2013 15:00:46 -0000

On Thu, Oct 24, 2013 at 3:52 PM, Watson Ladd <watsonbladd@gmail.com>; wrote:
> Nope: the attacker could provide their own ChannelID and force the
> user to reauthenticate,
> thus causing their secret key to be trusted.
> They could disable ChannelID entirely and force fallback to cookies,
> which they then steal.

Likewise, someone could undermine the confidentiality of TLS by
failing to set the secure flag on a cookie.

Just because you could design a system that uses ChannelID and has
these drawbacks isn't terribly meaningful.

> Online attack cleans
> out a bank account just as quickly as offline.

That is rarely true in my experience. Rate limiting of transfers seems
to be common practice.

> Steal a resumption ticket and you have the same attacker issue for $n minutes.

Session resumption tickets do not carry the authority of the
ChannelID. The (hypothetical) reauthorisation idea prevented an
attacker from taking over a connection, perhaps because the computer
continues to run even though the user has stepped away.


Cheers

AGL