[TLS] channel id and oob

Dirk Balfanz <balfanz@google.com> Fri, 02 August 2013 10:10 UTC

Return-Path: <balfanz@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 8C89C11E828C for <tls@ietfa.amsl.com>; Fri, 2 Aug 2013 03:10:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 0ZT5kn-9dlwR for <tls@ietfa.amsl.com>; Fri, 2 Aug 2013 03:10:24 -0700 (PDT)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5D84C11E8210 for <tls@ietf.org>; Fri, 2 Aug 2013 03:10:24 -0700 (PDT)
Received: by mail-ob0-f180.google.com with SMTP id up14so793658obb.25 for <tls@ietf.org>; Fri, 02 Aug 2013 03:10:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RRykl+aAUfZFGgjPXVArwe6SEYhjpUbo9Ek7YKz5w7I=; b=mAfopTY1ogOMksk0hnt1FkCBacWjeyFcbRB0KQjooA+jDipu30Db2PG+0Qcbkwmlu9 dWAPpR6wI9IYKqE6nJZzX5pMa0O2pi2urDaWvO25RmBUYmvCIg20CWBXMO21ZqTHsq9N YehsKlJkKoUu9Crqe5JzxZFSGwi4ualERE20R2vCQ8BfvT7yUkg2oFXsbdXSCzvEkGHQ FKQs7fKUS+OgS43amcK6ngpOZub6j9ciYi7oRCmyM7lTQyaQuwlZzAOyEomZZgKujX0h NVw6xfAbEECNkq2knYlRsGlbDQFD52/bwuDhYmpi07b60e3H4RpjWYYz7SRl588Km2AF jrgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=RRykl+aAUfZFGgjPXVArwe6SEYhjpUbo9Ek7YKz5w7I=; b=osAQYZotB9+5CUdnztyYkYLQjVjN1z13fpMkvtIuuMXQRsoNMzjDbHVpwrdVnEwfIx v/hV2WtqpWftzJCdzn7LLmq2zomxGITDxjzCWqeerzGkxgu6c3if4N7lcbg5IMY3Iwhx n2yjqaOhVP9uTvT6ibIRUgmN8eLEg2R87wUikl5/8wJVHmCgkS7kzhwGppBU0jdXqdkY nWjYMHM3/VLYvOSGGNJ6SdkeKKuI5c+t/MNRBCiXXuoJieSzJD690Ur17ts9RyrVqC67 0RnLsgbVrH3RzMRTcZFgvVKhU787gP+W302ygm1OlLVqIiEwu1Q9lCqiGuGmi0tEXTUz T4zg==
X-Gm-Message-State: ALoCoQmBR2pB0SYG3Vf42jRUUiccgl/U6SF8aUdZGC7mML4xujh8hdt/U0tWza7DGkpFCqrfa0KfxdioD8d/Mw1kL1JSuy74kHddztKe4QbDVzcRf9yQ0Dc+DkGTZsDKA8431HnLOVhmge1WYiz5D0/swaG4mXCGmsmftvUcdSViQjKFdV6ZjNNy2gio+GntjLJHn/h5c1l1
MIME-Version: 1.0
X-Received: by 10.50.16.102 with SMTP id f6mr221123igd.41.1375438223742; Fri, 02 Aug 2013 03:10:23 -0700 (PDT)
Received: by 10.64.33.107 with HTTP; Fri, 2 Aug 2013 03:10:23 -0700 (PDT)
Date: Fri, 02 Aug 2013 03:10:23 -0700
Message-ID: <CADHfa2A7jERE=UTudOLcWnH7KppYH+7hcbRJg4aGZuwFeLBqnw@mail.gmail.com>
From: Dirk Balfanz <balfanz@google.com>
To: IETF TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bdc0cf0bcb44204e2f42a67"
Subject: [TLS] channel id and oob
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, 02 Aug 2013 10:10:25 -0000

Hi guys,

I was asked to write a quick analysis of draft-ietf-tls-oob-pubkey, and
whether it can be applied to the use cases we have in mind for Channel ID.

My conclusion is that it can not, or that the necessary modifications to
the OOB draft would be too substantial to be considered during Last Call.

First, the similarities: both proposals allow the client to prove
possession of a key pair. The fact that this proof-of-possession is
forthcoming is negotiated using the TLS extension mechanism (during
ClientHello/ServerHello).

Now for the differences:

   - We don't want the client public key to be sent in the clear. It's a
   client identifier, and shouldn't be known to anyone but the client and the
   server.

   - We don't want the proof-of-keypair-possession to be part of the
   session state, for two reasons:
      - It blows up the session state, with ramifications on the size of
      the fleet of servers that cache this information. Remember that
in our use
      case, we don't intend this to be used for the occasional client
that wants
      to use non-password authentication with the server; it's designed to be
      used by _every_ client talking to big service providers like Google. Raw
      public keys are of course smaller than full certificates, but they still
      represent a significant increase in the size of session state.
      - We don't want someone who is not actually wielding the private key
      of the keypair to make it appear to the server as if they were in control
      of that private key. Session resumption, however, gives you that power:
      Let's assume that the private key of the keypair sits in a
      hardware-protected secure element, and is therefore out of reach of
      malware. Master secrets and other session information, however, is very
      likely kept in RAM and therefore available to thieves. If such a thief
      extracts the session data from the client and resumes the session, the
      server will treat the thief as the holder of the original private key. If
      the proof-of-keypair possession is explicitly declared not part of the
      session, then a client has to re-prove possession of the keypair even
      during abbreviated handshakes. Thus, a thief of session secrets
(but not of
      the private key) won't be able to convince a server that it is in control
      of that private key.

The oob-draft keeps the raw key in the session state, thus inheriting this
problem with session state and session resumption.


   - Channel ID keys are different from key material sent in the
   Certificate message, and the certificate message shouldn't be overloaded
   with this new semantics: Key material presented in the Certificate
   message (even if it's a raw key) presumably carries some semantics for the
   application: "this is a certain user", "this is an enterprise-issued
   machine", etc., while the Channel-ID keys are always self-generated and
   their semantics include (among other things) "this is the key that will be
   nuked when the user presses the 'reset my browsing state' button". It makes
   for tricky implementations when those two different semantics get mapped to
   the same protocol message. More importantly, applications may want to do
   both: authenticate a user with a client cert, and then set a channel-bound
   cookie as a result of the authentication. You can't do that if you only
   have one proof-of-possession available in the handshake.

As mentioned above, I don't really see how this issues could possibly be
addressed within the draft-ietf-tls-oob-pubkey draft, especially since it's
in last-call. Just the first point above alone seemed to be something that
folks didn't want to touch until TLS 1.3.

Thoughts?

Dirk.