Re: [TLS] Are we holding TLS wrong?

David Schinazi <> Tue, 13 November 2018 01:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A407130F30; Mon, 12 Nov 2018 17:33:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 bhUrRXGOsK1K; Mon, 12 Nov 2018 17:33:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7126130EC3; Mon, 12 Nov 2018 17:33:10 -0800 (PST)
Received: by with SMTP id v68-v6so5186521pfk.0; Mon, 12 Nov 2018 17:33:10 -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=4K/USDYLDJxOLM7GB6ZBS0+ei9MtSjwl4s4qYRQft6A=; b=R/kNfBeArydGaHk9UxuyVH/54DLAWN/TgAQPZ8TlSA54zQ1E+qNCDyD4FG6PSpFl8U SRB5zn2n0RsNbNHkxddni98ixg4BZMe+oTIxilAUR2wUfMQzOUqKJtEnIHml1Naw0VTk Cf7zhHgirspsXIdVTFN8iWvsdAJBtfyOWmOYkxbNYmhqj+DI5FHatQhD+p6frccma251 hvJP+S1WlLdLJs/89BnL5tQnEeYLF2xDeMIZeyIou+1vUKkdENatmKSfDCGEDVIC0aKw Nr0Qey2aX8Rom2JSfi+vy40SumQEx6iopNAjhWrJqeJTfbMiX/3WloE7TpxKhuzmHUrJ 5Exg==
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=4K/USDYLDJxOLM7GB6ZBS0+ei9MtSjwl4s4qYRQft6A=; b=tkzenkeokbBFHbkcR+MiIoeOzIcNBvaJKXCR2j8fjz624ZE+CkCfbowTH9WsJOyCD+ J/fyaULTWsh7K1h0J9xoOoUFgctjiZ38hzhDJ66258ulEmDfohApJG6OQLjX/yFMit5g ui7JtbithfFsGQi8ob516TXcDazCHqdjcrWxNQ4CwIGVrDszF6YVTesATw6ywsudeWpk X6BA7e+Ju95RD6xi5mwq7SjytMg9viFlgIL4yGcEmALGSVRPog786zEMWrEQG78pyf6B ipm0OtKRFz8bruypYceY1vwqiton4TZoPkV49CW+M0PaHTz+xujYnAKv1nfQLBmgXtsj D3fQ==
X-Gm-Message-State: AGRZ1gJoRMc2vuZhDd3nA7H4LddiPEHhlBSjc2gTFxLNdEih//VLMGcS axZX0FwUCytrbLbHzUUCYWNMlpZHZ4IeK//OvM95wc+y
X-Google-Smtp-Source: AJdET5ew1bOomGSkasmKMCYLmJ5N38B6/RP9syXcnqLe1Oay3P8cF3zNlVhO4H80WIkK61Tvj6izOGXoGv5pe4hlOxY=
X-Received: by 2002:a63:4f20:: with SMTP id d32mr2926344pgb.47.1542072790389; Mon, 12 Nov 2018 17:33:10 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Mon, 12 Nov 2018 17:32:58 -0800
Message-ID: <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="000000000000e39726057a81cca6"
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 01:33:17 -0000

Hi Martin,

Thanks for looking into this.

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?

I've removed the mention of the certificate status request extension,
as I don't think it's relevant and don't remember why it was added.

PSK can either be used with:
- one key for the entire network, which does not allow revocation
- 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
so PSK would be suited in the simple case where revocation is not
wanted, but in that use-case we recommend Babel-HMAC.

I'll let the Babel-HMAC authors start a separate thread.


On Fri, Nov 9, 2018 at 4:26 AM Martin Thomson <>

> Hi David,
> I couldn't find any description of the threat model involved here, nor
> could I find any analysis of the security against that model.  Without
> that, I can't really say whether this is right or not.  For instance,
> there is specific mention of the certificate status request extension,
> but there is no mention of why.
> Given the configuration that I might infer from the hmac draft, I'm a
> little surprised that this doesn't use PSK.
> I'm somewhat dismayed by the firm recommendation to use the HMAC
> mechanism, which doesn't seem particularly robust.  Offhand, it seems
> like replays are possible if you allow the possibility of the node
> crashing and dumping state.  The same applies during a rollover of the
> 32-bit counter.  Of course, that might not be permitted by the threat
> model.
> On Thu, Nov 8, 2018 at 9:15 AM David Schinazi <>
> wrote:
> >
> > Hi everyone,
> >
> > Over in the Babel working group we have a draft about securing Babel
> with DTLS:
> >
> >
> > It's 5 pages long, could any TLS experts please give it a quick read and
> let us know if we're using DTLS correctly?
> >
> > Also, should the document contain guidance such as which DTLS version to
> use?
> >
> > Thanks,
> > David
> > _______________________________________________
> > TLS mailing list
> >
> >