Re: [TLS] Are we holding TLS wrong?

David Schinazi <dschinazi.ietf@gmail.com> Tue, 13 November 2018 01:33 UTC

Return-Path: <dschinazi.ietf@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 5E435130F0B; Mon, 12 Nov 2018 17:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: 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 8LrfDEQmEZx2; Mon, 12 Nov 2018 17:33:07 -0800 (PST)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 EEFD1130ECA; Mon, 12 Nov 2018 17:33:06 -0800 (PST)
Received: by mail-pg1-x530.google.com with SMTP id 80so4882736pge.4; Mon, 12 Nov 2018 17:33:06 -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=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; d=1e100.net; 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: <CAPDSy+7-ceNNLJpFK0Z4SitBaUgxTpxiea8Z0QtpeSr+MNLKFg@mail.gmail.com> <20181108043010.GA11967@nokia.com> <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 <dschinazi.ietf@gmail.com>
Date: Mon, 12 Nov 2018 17:32:55 -0800
Message-ID: <CAPDSy+6xojteZHDn7T2CZPaURm=WwwQiNTyf+JN0639ntTia1Q@mail.gmail.com>
To: Hannes.Tschofenig@gmx.net
Cc: thomas.fossati@nokia.com, draft-ietf-babel-dtls@ietf.org, tls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a8953d057a81cc4f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MbxHu0UCFeEYSTUjQocQqv6kNBQ>
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 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.

David

On Wed, Nov 7, 2018 at 8:53 PM Hannes Tschofenig <Hannes.Tschofenig@gmx.net>;
wrote:

> 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)" <thomas.fossati@nokia.com>;
> *An:* "David Schinazi" <dschinazi.ietf@gmail.com>;
> *Cc:* "draft-ietf-babel-dtls@ietf.org"; <draft-ietf-babel-dtls@ietf.org>;, "
> tls@ietf.org"; <tls@ietf.org>;
> *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:
> > https://tools.ietf.org/html/draft-ietf-babel-dtls-01
> >
> > 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>