Re: [babel] Some open HMAC issues
David Schinazi <dschinazi@apple.com> Mon, 02 July 2018 04:48 UTC
Return-Path: <dschinazi@apple.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFC9130E23 for <babel@ietfa.amsl.com>; Sun, 1 Jul 2018 21:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 sCZF00IPKlOY for <babel@ietfa.amsl.com>; Sun, 1 Jul 2018 21:48:35 -0700 (PDT)
Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1527120049 for <babel@ietf.org>; Sun, 1 Jul 2018 21:48:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530506915; x=2394420515; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=W2u9rkBQ8tlVlhS5yjE0D5lVhpSmpwv5S9Rew5+l80s=; b=si3EIbwp4A/2mUq1uCNGCUJDB12XfufKBeoe77Pucr4Fuhbs/mox5Cl6fNOr1EEk AQaJ7ktP3m79HsssBTmzUJHRdcVGHjBTr386eQaMq0XLUsET2nvIVgiMEQxFbr5a 58nrwh0UOtHhB6z44xoWb2hef7bd9jB3C9tsMBYLDwb/zgoWovx6ff/hgejfXU2z xzB+n+lAk5qwu3q8/teuYvr8lU5f8aDrzWdjpGZxKaT2eviBVjZI0mwBeqh8yDAq 0b5xfo/bzGMrhYqYKBtLvjTuBlmsegz3TjiSqZ2iSmh7+xL3b02cqAe3FUB6zLeT DstOdYkaYWa5fYwxqeX4+Q==;
X-AuditID: 11973e13-62dff7000000242c-ae-5b39aea308d1
Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 21.AB.09260.3AEA93B5; Sun, 1 Jul 2018 21:48:35 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PB8004OI2OZLZ10@mr2-mtap-s02.rno.apple.com>; Sun, 01 Jul 2018 21:48:35 -0700 (PDT)
Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB800L002BZNB00@nwk-mmpp-sz11.apple.com>; Sun, 01 Jul 2018 21:48:35 -0700 (PDT)
X-V-A:
X-V-T-CD: 7d6566e1ce32e60bd701207e1252a9a5
X-V-E-CD: 25db9c8def847da5f3c8f83d464a40b5
X-V-R-CD: fbd4a3ecf174248f2009b74dbcdd7cb8
X-V-CD: 0
X-V-ID: 4ba36698-0bf3-4f41-8192-283fb87b90a7
Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB800H0026YWH00@nwk-mmpp-sz11.apple.com>; Sun, 01 Jul 2018 21:48:30 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-02_01:,, signatures=0
X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp15.corp.apple.com-10000_instance1
Received: from [17.234.113.65] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PB80098A2OTAM20@nwk-mmpp-sz11.apple.com>; Sun, 01 Jul 2018 21:48:30 -0700 (PDT)
Sender: dschinazi@apple.com
From: David Schinazi <dschinazi@apple.com>
In-reply-to: <87sh545st3.wl-jch@irif.fr>
Date: Sun, 01 Jul 2018 21:48:29 -0700
Cc: babel@ietf.org, Weronika Kołodziejak <weronika.kolodziejak@gmail.com>, Clara Dô <clarado_perso@yahoo.fr>
Content-transfer-encoding: quoted-printable
Message-id: <411E2C9F-A910-4899-8DD7-92C0C85EBC54@apple.com>
References: <87sh545st3.wl-jch@irif.fr>
To: Juliusz Chroboczek <jch@irif.fr>
X-Mailer: Apple Mail (2.3445.9.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUiuPlRm+7idZbRBnealCy2LOpmsdhweR2z xfzWZWwWHz7dYXVg8dg56y67x5IlP5k8Fm95y+jxavpD9gCWKC6blNSczLLUIn27BK6Mht4m poJjjhUvzx1gbGDca9TFyMkhIWAisXHnJ9YuRi4OIYEDTBKf1n5mAknwCghK/Jh8j6WLkYOD WUBdYsqUXIia9UwSJ15+ZIRwupgk7h5bzQQxiU1i/YklULaWxNPtz1lh7N4LC1hg7PY/P6Di nBLnv0xkh7B1JN4uuMEEMbSTSeL0qu3sIJslBLIldmwQhagJlvhzqIcZouYro8SeFY1gy4QF pCW6LtxlBakXBlpwYYUViMkGZB5YA/Ykp4CGxPn2WWAnsAioStxZNJkFZAyzwERGifsPG9hA EswC2hJP3l1ghXjeRuLG76NgcSGg5zct+Q0WFxFQkVg+7RnUzYoS/WsOsU1glJ6FFF6zEOE1 C8nUBYzMqxiFchMzc3Qz80z1EgsKclL1kvNzNzGCIni6nfAOxtOrrA4xCnAwKvHwLhCzjBZi TSwrrsw9xCjNwaIkzmuWZBotJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTFy3twzvyYYzH13 v/PmD07lrTY3eVk2sRw7YHXjTKOfzGeF99r36iVOMT+IbrHbu9/EYdrCM1tOhdmsLpVda/9N l61p/1H9iQc267u6P6j/ePjwTK6pRln8emmMHQ2Ldr+33yt8se3eF2WlQ0+V/j/evD7hZoJv +S+Ow+c/zIm/cLI2fo5H8uN0JZbijERDLeai4kQArtH26MECAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/i-XOBD9yoJlX_Fkv5GgBgy1B45o>
Subject: Re: [babel] Some open HMAC issues
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jul 2018 04:48:39 -0000
> On Jun 30, 2018, at 06:04, Juliusz Chroboczek <jch@irif.fr> wrote: > > 0. Explicit vs. implicit Indices > > The discussion between explicit (DKC variant) and implicit (Stenberg > variant) indices is still open. Just because we've made DKC code > available doesn't mean the WG needs to follow our idiosyncrasies. > > (I'll try to find the inner strength to summarise the discussion at some > point.) > > > 1. Implemented and MTI HMACs > > We've followed Denis' text, and implemented SHA1 and RIPEMD160. Could any > security specialists please advise: > > - which algorithms should be implemented; > - which algorithms should we propose to the WG as Mandatory to > Implement (MTI)? I think SHA2-256 should be the only MTI, as it is considered secure and is widely available. > On a related note, should we be looking at algorithms other than HMAC? > The challenge mechanism is fairly generic, and the actual hashing is just > a tiny part of the protocol. What other algorithms did you have in mind? I think HMAC fits what we need here. > 2. Should the HMAC cover the packet header? > > The Babel packet header has the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Magic | Version | Body length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Right now, Version is fixed at 2, but if we ever define Babel version 3, > we might become susceptible to downgrade attacks. I don't recall why we > skipped the header in HMAC computation, but I think it's a bug. > > (As far as I can tell, 7298bis hashes the whole packet, including the > packet trailer.) Yes, it should cover the header to avoid tampering. > 3. Packet format > > There are three new TLVs (HMAC, Challenge, Challenge Reply). They are > variable-length and therefore non-terminating in the sense of rfc6126bis > Section 4.4, which means that they cannot carry sub-TLVs. This follows > Denis' original design, and I think it's the right thing to do since it > makes the packet format simpler. > > Does anyone envision a need to carry sub-TLVs on these TLVs? I don't have any ideas for that. > 4. Challenge timeout > > How long does a receiver have to reply to a challenge? We see no > vulnerability here, but we feel that a challenge reply coming a few hours > late is at the very least suspicious. > > (Our code apparently uses 300ms, but I think it's a bug -- it should be on > the order of tens of seconds, since a peer is allowed to aggregate its > challenge reply with other unicast TLVs -- that's the first time I see > a convincing use-case for Unicast Hellos, by the way. Note that we don't > necessarily know the peer's Hello and IHU intervals when we challenge. > Perhaps we should make the timeout explicit in the challenge TLV?) Having an Interval in the ChallengeRequest would be similar to Acknowledgment Requests, so that makes sense to me. > 5. Use of the packet trailer > > The HMAC TLV is carried in the packet trailer, which makes it clear which > part of the packet is protected by HMAC and avoids the need to clear parts > of the packet body before hashing. (Think about extensibility -- there > might be other TLVs in the future that must not be protected, and if > different extensions require clearing different parts of the packet, we're > going to end up with some pretty enjoyable code obfuscation.) > > Does anyone have technical arguments against the use of the packet > trailer? For the record, Denis didn't use a packet trailer, and David has > expressed some mild reservations about its use (he feels that we're > trading specification simplicity for implementation simplicity and > extensibility, and while I agree with this, I happen to think it's the > right tradeoff in this particular case). > > If we keep the trailer, well need to add something to 6126bis. I suggest > the following RFCese: > > - the packet trailer is a sequence of TLVs, just like the packet body, > and the TLV number space is the same; > - a TLV that appears in the packet trailer MUST be ignored on reception > unless its definition explicitly states that it is allowed in the > packet trailer; So far I agree. > - the mandatory bit MUST NOT be acted upon when it appears in the packet > trailer; as a consequence, an implementation that doesn't grok any > TLVs that can appear in the trailer MAY simply ignore the packet > trailer without ever parsing it. I'm not sure I understand this. Why wouldn't mandatory sub-TLVs in the trailer behave like they do in the body? > 6. Cryptographic Seqno increase > > A peer is allowed to increase its Cryptographic Seqno by an arbitrary > value (more than 1). This allows the use of fast-running counters, for > example based on a hardware clock. > > For example, an implementation might encode a 1µs-granularity clock in > the Cryptographic Seqno, end encode the top-order 16 bits in the Index. > There would be a spurious challenge every 72 minutes, and the Index would > overflow every 9 years (meaning you'd need to perform key rotation at > least that often). > > Does anyone see a problem with that? SGTM > 7. Cryptographic Seqno size Can we call this the Packet Counter? We already have two seqnos in Babel. > The Cryptographic Seqno is of a fixed size; if it overflows, the sender > must pick a new index and suffer packet loss during at least one RTT > (while it's waiting for a new challenge). > > The Cryptographic Seqno is currently 32 bits long. Does it make sense to > reduce it to 16 bits? That would shave 2 octets from each packet, at the > cost of more frequent challenges. I think it should stay at 32 bits, > since it makes it possible for people to use a fast-running counter (see > point 5 above). > > (In a stable network with 1000 nodes and the default parameters, babeld > should be sending on the order of 1.2 packets per second. A 16-bit > counter will overflow after 15 hours, a 32-bit counter will overflow after > 113 years. All bets are off if you use a fast-running counter, of course.) Agree for 32bits. > 8. Index and Nonce size > > Indices and Nonces are of variable size (up to the maximum TLV size): our > implementation selects 80-bit values, but it will handle values of up to > 251 resp. 255 octets (as much as fits in a TLV). > > While having variable-length values slightly complicates the implementation, > I think it's a good idea: > > - an implementation might want to encode a cookie in the Nonce in order > to have stronger DoS protection, thus needing a larger Nonce; > - an implementation with a stable clock might want to use a tiny Index > (see point 5 above). Agree. > I suggest we should limit indices and nonces to 192 octets, indices and > nonces larger than that MUST NOT be sent. This gives enough margin to > carry a nonce or index in a sub-TLV (which we're not currently planning to > do, but what the heck). Not sure I see the benefit of this limitation. > (This means we allow 0-octet Nonces. Haha.) Nothing wrong with that, each node is responsible for their own security choices. > 9. Lack of an ANM > > Since the new protocol is not vulnerable to replay, we don't use > a separate ANM, but keep all the per-peer state in the ordinary Neighbours > Table -- if a neighbour entry expires, we'll need to challenge again. > We intend to put this in the spec, and add an implementation note to > explain that implementations that wish to avoid spurious challenges may > use a persistent ANM to keep the neighbour state. > > Does anyone see a problem with that? SGTM I'd also add: 10. KeyID I think there is value in having a KeyID next to the HMAC to allow better performance when using multiple keys. RFC7298 had a 16bit KeyID, and that sounded reasonable to me. David
- Re: [babel] Some open HMAC issues Markus Stenberg
- [babel] Some open HMAC issues Juliusz Chroboczek
- Re: [babel] Some open HMAC issues Juliusz Chroboczek
- Re: [babel] Some open HMAC issues David Schinazi
- Re: [babel] Some open HMAC issues Juliusz Chroboczek
- Re: [babel] Some open HMAC issues Toke Høiland-Jørgensen
- Re: [babel] Some open HMAC issues David Schinazi
- Re: [babel] Some open HMAC issues David Schinazi
- Re: [babel] Some open HMAC issues Toke Høiland-Jørgensen
- Re: [babel] Some open HMAC issues David Schinazi
- Re: [babel] Some open HMAC issues Toke Høiland-Jørgensen
- Re: [babel] Some open HMAC issues Dave Taht
- Re: [babel] Some open HMAC issues Toke Høiland-Jørgensen
- Re: [babel] Some open HMAC issues Juliusz Chroboczek
- Re: [babel] Some open HMAC issues Juliusz Chroboczek
- Re: [babel] Some open HMAC issues David Schinazi
- Re: [babel] Some open HMAC issues Toke Høiland-Jørgensen
- Re: [babel] Some open HMAC issues Juliusz Chroboczek
- Re: [babel] Some open HMAC issues Toke Høiland-Jørgensen
- Re: [babel] Some open HMAC issues Juliusz Chroboczek
- Re: [babel] Some open HMAC issues David Schinazi
- [babel] Packet trailer [was: Some open HMAC issue… Juliusz Chroboczek
- Re: [babel] Packet trailer [was: Some open HMAC i… David Schinazi
- Re: [babel] Some open HMAC issues Toke Høiland-Jørgensen
- Re: [babel] Packet trailer [was: Some open HMAC i… Toke Høiland-Jørgensen
- Re: [babel] Some open HMAC issues Juliusz Chroboczek
- Re: [babel] Some open HMAC issues Toke Høiland-Jørgensen