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 5E435130F0B; Mon, 12 Nov 2018 17:33:09 -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 8LrfDEQmEZx2; Mon, 12 Nov 2018 17:33:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEFD1130ECA; Mon, 12 Nov 2018 17:33:06 -0800 (PST)
Received: by with SMTP id 80so4882736pge.4; Mon, 12 Nov 2018 17:33:06 -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=LJiYJZpLK2rB4m61qVS4IY025z2yqJHx7CtG9BhPsjs=; b=a0MFOgtxGlgNzsoTJNjUchRR2upJCsN2BnTcrl4ouhgpmtiG7jRn6K82K/5JIVK+3V w9X+Os7E6giKtc/p6zrAD4/QURXXsfJNIAc59gykJLfTYes75Fbq1YkQdy4tQpKRzTgJ /A13Ww+HsYjMbyj7cR1Ogc/u6OHZyp8azzx67nfbYfUBtn6BfcE6n4/8Um4sQ+FUfiLp yGz/wCTefohzcTERCigBXUd+pqzn6cBPR1ArFTBtu1xsxBpWGJ7QX+8bmJYbUHxS/Gg9 xgphoPDSpvuqvD5Sh5uuQLe/Ct+JQInT0BTcTd6rG14NMPvM69kB/XbGYwq4zXnp7n91 kvNQ==
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=LJiYJZpLK2rB4m61qVS4IY025z2yqJHx7CtG9BhPsjs=; b=r79wpVsi5ucOCYSnz/7o7EfUjqXDVSJqa/hC13H26R+mJAESEo7VjeAw8J4u/ZWlfq kmuSyhhKlYK0QpZezg5zsIggcIp4TAvHV1wrxC7ZAvLlUT8Ux9QuNuIgaf0VCRhujSyF 3CRGjLU5S106myvMsV2UGUkm/dbJDxv8/RAb54l8dHPMK7iMWttOQQdC6sIoKn3nLGDu WMqt4DLVKj6kb0eZdOLtYIecPc3zxkGEc3QRu8AZUEelsHIrfJEF76chueY4P5k6bO46 RCvhAhdmWqj6nHGmVW9LyIZEXNr8TnNhcWKDYYRRQG7qy8Wo4sPLrKPPjWngZ4IoJbaQ 8oeg==
X-Gm-Message-State: AGRZ1gI0UMNythYr6+gzoSvBFkzdiUUn5+r8sugiZrFgd+d41T3AgjUR Tx2GX2Fc2tVstPldaZD5UPAybVCVRhN3nDMr+d0=
X-Google-Smtp-Source: AJdET5fpurhy05wUjMVDMNcpcbuRxDrQR+JegXcEhDhwhrwOiJFbxjaNryxhLHD7a8dDgGf8Xb+JMLIKhfD79x2XD8Y=
X-Received: by 2002:a65:55ca:: with SMTP id k10mr2894578pgs.448.1542072786521; Mon, 12 Nov 2018 17:33:06 -0800 (PST)
MIME-Version: 1.0
References: <> <> <trinity-2d31619c-321d-45a0-8871-385bd95fb8aa-1541652800774@3c-app-gmx-bs74>
In-Reply-To: <trinity-2d31619c-321d-45a0-8871-385bd95fb8aa-1541652800774@3c-app-gmx-bs74>
From: David Schinazi <>
Date: Mon, 12 Nov 2018 17:32:55 -0800
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000a8953d057a81cc4f"
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:13 -0000

Thanks for your comment Hannes!

One of the motivations for Babel-HMAC (the custom format only offering
integrity protection) is to have a simple mechanism with smaller
dependencies for inclusion in small embedded devices that do not
necessarily have a DTLS stack.

We could define a mechanism that performs Babel-DTLS and then leverages a
keying material exporter to have keys for Babel-HMAC and use that for
multicast, but potentially in a later draft -- we're trying to minimize
complexity for this current pass.


On Wed, Nov 7, 2018 at 8:53 PM Hannes Tschofenig <>

> I took a quick look at the document and I don't know Babel.
> I see that you have two different proposals for securing Babel messages,
> namely
> * DTLS, and
> * a custom format offering integrity protection only.
> You correctly note in the document that DTLS offers more features. It is
> an authentication and key exchange protocol.
> One option to explore is to use DTLS to perform authentication and key
> exchange then use your custom format for integrity protection of packets
> with the keys exported from DTLS. Design-wise this approach is similiar to
> what we have done with DTLS-SRTP. This would also allow you to cover the
> multicast security case.
> Ciao
> Hannes
> *Gesendet:* Donnerstag, 08. November 2018 um 11:30 Uhr
> *Von:* "Fossati, Thomas (Nokia - GB/Cambridge)" <>
> *An:* "David Schinazi" <>
> *Cc:* "" <>rg>, "
>" <>
> *Betreff:* Re: [TLS] Are we holding TLS wrong?
> Hi David,
> A few quick notes below.
> Cheers
> The 11/08/2018 09:14, 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
> Premise: I don't know Babel -- apologies for any nonsense!
> One high level thing which I can't extrapolate from the draft (which is
> probably due to my ignorance with Babel) is whether you envisage that
> *every* node does DTLS on the unicast channel, IOW that non-DTLS nodes
> are excluded from the mesh? Or would it be acceptable to mesh HMAC and
> DTLS neighbours? What about clear-text speakers? (It'd seem unwise to
> let them in an otherwise secured enclave.)
> You should probably provide some guidance about the kind of
> credentials do you plan to use (certs, raw pkeys)?
> It seems to me that the P2P nature of the protocol requires mutual
> authentication, could you confirm it? This seems to be a critical thing
> to prevent a rogue node to spoof the lowest (highest, I have already
> forgot, sorry) L-L address in a clear-text multicast Hello and bypass
> authentication.
> - s2.1
> "Nodes SHOULD ensure that new client DTLS connections use different
> ephemeral ports from recently used connections to allow servers to
> differentiate between the new and old DTLS connections."
> Maybe you could suggest using a sufficiently entropic connection id here
> as a more robust alternative.
> - s2.5
> Not sure what the ceremonies around flushing a neighbor are, but I'd
> make explicit signalling EOD at least a SHOULD? It seems more polite
> :-)
> - s.3
> Not sure which TLS stack Babel nodes will use (are you targeting
> extremely constrained devices with custom TLS implementations?), but all
> the stacks I know of let the application set the MTU and take care of
> splitting the messages in MTU sized chunks transparently.
> --
> Thomas
> _______________________________________________
> TLS mailing list