Re: [TLS] Are we holding TLS wrong?

Martin Thomson <martin.thomson@gmail.com> Tue, 13 November 2018 03:46 UTC

Return-Path: <martin.thomson@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 D18F212872C; Mon, 12 Nov 2018 19:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hePK9Zj1Xcnw; Mon, 12 Nov 2018 19:46:02 -0800 (PST)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB9E124408; Mon, 12 Nov 2018 19:46:02 -0800 (PST)
Received: by mail-oi1-x22c.google.com with SMTP id e19-v6so9107429oii.13; Mon, 12 Nov 2018 19:46:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=keC9ty//2AET0dLh0hL0RvBQt8gJ6Z+bj4FcbslwLHo=; b=rvZPnIIaFBvw/m2IXW22BX/6uwH37UjPkyDkh94diMdn+QbGRJgfaozKGA5j1PERlK ucYYuEFFXqEpQh/zEnup0Sz3tNBhtTe3iEcxgfe7PB+4ETxCOcEb8TWpMaXwOS6FKI2p aDMR0ZXhE5WyZnFTFH991T6vaCVUsSby62sUDpdxG1HO4Upqnip7Ei/SrHr5/PKGIrZ+ ARlUs5yOo1/bAJtYzZ67fVTwQNNWH8L6uk3b2hkIbsG6W06Rx4naXThGBHnskQNUsTj3 /nitfUIj/WIuTwAiaPpmHvYUxmY6BlcueRaW6Lv7tsINJzB47aqgkMo208r8PXzZ2Zxr jd3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=keC9ty//2AET0dLh0hL0RvBQt8gJ6Z+bj4FcbslwLHo=; b=kXosanyWXVvMc1cMVVQa5xFXKtTKDUL0m0/GaN5zDacG459EvaNkc4ZPIAY6ZOne2e 4QciFmWhDpZds/WJQyINTp6sNrbod4KKabN+vpUglsb4qhI6/f9qVwx0lpgy3LFXWyFn Vr2MCMCKlLrkbId3C/SpJhnMhO1sGoLwJXbxVckUIPpnJ0UXxIdLLTPZ3t2auN6RddXW ReLDtSr2Nz4PNxoz5+YiqpyRouOIfnNAJMh3hevks9en6/zxpiHSKGKUmP4QKqPptE9W 2mZtiZNIHU4MuEP0lvP8Ivdc/6dTcbqPdIA5hoYXB9oDRLnO6j1kzr3+u9jx9dbpgKzK dUdA==
X-Gm-Message-State: AGRZ1gJsGR1dZycIgzp5LuyG7qacO6nHPKXP1/JUS3IbDvGSZ/eaQcXq 81CdKLMvuk5sf4a2m7TXm0z/KnXOLtPJxNd4ob8=
X-Google-Smtp-Source: AJdET5daBu/XYBaH5MkW4fzbr/ITZ84uOCG1twW1+dNyZdsYJ7Xs/9mLxXsWjDcn+fl+xtwIpvfPMa9EYbzMwZ/ZPbc=
X-Received: by 2002:aca:c792:: with SMTP id x140-v6mr2125948oif.129.1542080761476; Mon, 12 Nov 2018 19:46:01 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+7-ceNNLJpFK0Z4SitBaUgxTpxiea8Z0QtpeSr+MNLKFg@mail.gmail.com> <CABkgnnWF6_cqhMCKMWHYNcdOTU=4BjRYaYMtfz-A3jtxprRAHA@mail.gmail.com> <CAPDSy+7pwaGX-5Si37JHTuBxygPN4sF9bseM-zHDLaFzEPP8cw@mail.gmail.com>
In-Reply-To: <CAPDSy+7pwaGX-5Si37JHTuBxygPN4sF9bseM-zHDLaFzEPP8cw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 13 Nov 2018 14:45:50 +1100
Message-ID: <CABkgnnUsd3wzNhwo+eNwW7n8bPzpYTsxMrN8EsPmOMRO7R-2ig@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>, draft-ietf-babel-dtls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2MS8mCF26jYNCbnc29bdru44OSU>
Subject: Re: [TLS] Are we holding TLS wrong?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 13 Nov 2018 03:46:04 -0000

On Tue, Nov 13, 2018 at 12:33 PM David Schinazi
<dschinazi.ietf@gmail.com>; wrote:
> Our threat model should be described in the introduction. From your
> comments I'm guessing it isn't clear, so we should fix that. The basic
> idea is that any on-link device can change the routing of the entire
> network, and that's bad for hopefully obvious reasons. The goal of
> Babel over DTLS is to prevent that. Can you suggest a better way
> to convey that?

It might pay to describe who is involved, and what prior information
is assumed.  There might be a few different deployment assumptions,
which probably means pointing at other documents.

Your list of PSK options (below) assumes a range of options, each
assuming a different threat model.  I hadn't even considered that
option - the draft mentions asymmetric-key-based authentication.
Which you should probably pin down to either certificates or raw
public keys.  Not choosing is a different sort of choosing.

> PSK can either be used with:
> - one key for the entire network, which does not allow revocation

In this case, you would assume that there is no possibility of
compromise or defection of any entity in a "network".  That doesn't
seem like a reasonable threat model.

> - one key per node (N), but that requires all nodes to know all keys
>     which allows impersonation
> - pairwise (N^2) keys, which does not scale well

Yep, all of which speaks to some serious shortcomings of the
HMAC-based protocol.  If N^2 is feasible, it would be good to hear how
those keys are managed.  1 and N similarly don't seem feasible from a
deployment and operational perspective.