Re: [TLS] TLS Digest, Vol 108, Issue 10

Joseph Birr-Pixton <jpixton@gmail.com> Tue, 16 July 2013 20:15 UTC

Return-Path: <jpixton@gmail.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 818C421F8438 for <tls@ietfa.amsl.com>; Tue, 16 Jul 2013 13:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 zC1J9lc9vZXZ for <tls@ietfa.amsl.com>; Tue, 16 Jul 2013 13:15:09 -0700 (PDT)
Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 60DB221F9EF5 for <tls@ietf.org>; Tue, 16 Jul 2013 13:15:09 -0700 (PDT)
Received: by mail-qc0-f182.google.com with SMTP id e10so636742qcy.41 for <tls@ietf.org>; Tue, 16 Jul 2013 13:15:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GAKwuORk/uW0kfofgIUh2rOtV6QBUG4seha2FvNceuI=; b=uTBuI6hGI3b+W3aovJmrxqJ6xD2ZljePq9TlRLErLjK/4AEmOz1gXAzXYY7Lj4AKkJ G44If2QS7isoM6QSYk23+eguxSuMj85yC+L/gbjmBrZNM9fgkaYw2asNxbC5EcXofKby V6DPn6fgV7K+XhlDvnIn0Xso2YmZYpZBVcKwHMXcBnImILt/x7YSB67XXZjfcpUcA11C ZlY56u1GCyEge3l8OEpeaDiE6o2AGgU3GJ6+E9ieauEy3ktfMUjcjetnVJiAUMJS0KN6 1CnqelCMjDUHjweYArQvr3y1+Qtzv9n0gC0c55FCKA48JgE2mNycmvi093nW6Lp1M1Sd 2SyA==
MIME-Version: 1.0
X-Received: by 10.224.66.2 with SMTP id l2mr5638380qai.28.1374005708843; Tue, 16 Jul 2013 13:15:08 -0700 (PDT)
Received: by 10.224.45.199 with HTTP; Tue, 16 Jul 2013 13:15:08 -0700 (PDT)
In-Reply-To: <mailman.193.1374001258.9671.tls@ietf.org>
References: <mailman.193.1374001258.9671.tls@ietf.org>
Date: Tue, 16 Jul 2013 21:15:08 +0100
Message-ID: <CACaGAp=RZyswP32Ljq=cMx849CquuCMOPru53AwrpgzjcwMAdA@mail.gmail.com>
From: Joseph Birr-Pixton <jpixton@gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: Re: [TLS] TLS Digest, Vol 108, Issue 10
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: Tue, 16 Jul 2013 20:15:10 -0000

On Mon, 15 Jul 2013 16:11:27 -0700,  <internet-drafts@ietf.org> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Transport Layer Security Working Group of the IETF.
>
>         Title           : Out-of-Band Public Key Validation for Transport Layer Security (TLS)
>         Author(s)       : Paul Wouters
>                           Hannes Tschofenig
>                           John Gilmore
>                           Samuel Weiler
>                           Tero Kivinen
>         Filename        : draft-ietf-tls-oob-pubkey-08.txt
>         Pages           : 15
>         Date            : 2013-07-15
>
> Abstract:
>    This document specifies a new certificate type and two TLS
>    extensions, one for the client and one for the server, for exchanging
>    raw public keys in Transport Layer Security (TLS) and Datagram
>    Transport Layer Security (DTLS) for use with out-of-band public key
>    validation.

What is the rationale for having the public key communicated /both/
authentically out-of-band and inauthentically in-band?

Avoiding any inauthentic communication of the public key means failure
to establish the correct key out-of-band will mean a connection is
impossible, even in the presence of implementation bugs.

Possible rationale could include:

- allowing leap-of-faith authentication.
- allowing an endpoint to vary the public key it returns with time or
other extension content (like SNI, EC curves, etc.)
- allowing an endpoint which cannot or does not store an authentic
public key for its counterpart, but can store (say) a hash of it.

In any case, I think including the real rationale in the RFC could
prove instructive.

Cheers,
Joe