Re: [TLS] Are we holding TLS wrong?

Martin Thomson <> Tue, 13 November 2018 03:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D18F212872C; Mon, 12 Nov 2018 19:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hePK9Zj1Xcnw; Mon, 12 Nov 2018 19:46:02 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3EB9E124408; Mon, 12 Nov 2018 19:46:02 -0800 (PST)
Received: by 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;; 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;; 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: <> <> <>
In-Reply-To: <>
From: Martin Thomson <>
Date: Tue, 13 Nov 2018 14:45:50 +1100
Message-ID: <>
To: David Schinazi <>
Cc: "<>" <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [TLS] Are we holding TLS wrong?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Nov 2018 03:46:04 -0000

On Tue, Nov 13, 2018 at 12:33 PM David Schinazi
<> 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.