Re: [secdir] SecDir review of draft-ietf-msec-tesla-for-alc-norm-07

Vincent Roca <> Wed, 09 September 2009 13:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 362FF28C14F; Wed, 9 Sep 2009 06:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B6j0hPYtP-6Q; Wed, 9 Sep 2009 06:44:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BE87E3A69CF; Wed, 9 Sep 2009 06:44:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,358,1249250400"; d="scan'208";a="32463740"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Sep 2009 15:44:31 +0200
Message-ID: <>
Date: Wed, 09 Sep 2009 15:44:31 +0200
From: Vincent Roca <>
User-Agent: Thunderbird (X11/20090817)
MIME-Version: 1.0
To: Yaron Sheffer <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset=windows-1255
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Thu, 10 Sep 2009 00:20:49 -0700
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [secdir] SecDir review of draft-ietf-msec-tesla-for-alc-norm-07
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Sep 2009 13:44:14 -0000

Dear Yaron,

Thanks a lot for your detailed review and comments. Please, find below
our answers and explanations on how we addressed them.

> General
> Overall this is a good document, but I suspect that it has too many options
> and leaves too many things open as to be truly interoperable. So
> Experimental is the right designation. From a security point of view, things
> seem to be well covered, but see my two comments below.

We agree there are too many options.  This is one of our concerns
and beyond interoperability, complexity is also a source of security

To address this, at least partially, we have removed the four
compact authentication tags, i.e. the compact formats where the
32-bit "i" interval index is not provided and is "replaced" by 1
or 3 of the least significant bytes with the i_LSB/i_NSB fields
(section 3.4.7. "Format of the Compact Authentication Tags").

Doing so significantly simplifies the proposal:
- there are only 4 different authentication tags instead of 8,
- the "i" computation logic through the i_LSB/i_NSB fields in
  section 4.3 is removed,
- the whole section 4.3.1. "Wrong Guess of the i Parameter" is
  removed too.
It does not fundamentally change the protocol, and the main drawback
is a mandatory 32-bit overhead (the "i" field) in each authentication
tag. That's an acceptable price to pay IOHO. The second drawback is
a renumbering of the "Type" field (section 5.1) but we believe it's
still acceptable given the "work in progress" status of the document.

Historically, when we proposed the compact versions, HMAC-SHA1 was
the default and we felt it was interesting to replace the 3 reserved/
padding bytes by 3 bytes of "i". Now that HMAC-SHA255 is the default
(and HMAC-SHA1 non recommended), i_NSB can no longer be used, only
i_LSB (1 byte). So it's in any case less attractive.

> Security Issues
> it is far from clear that if I trust you to send me packets (a
> movie, say), I also trust you to configure my NTP client (list of servers
> and trust anchors for them). So I wonder if using one of the offered NTP
> servers should really be MUST. Or are we really expecting a separate
> application level NTP layer, on top of that maintained by the OS?

You're right, the wording is not appropriate. We clarified this section
by adding the following paragraph, at the end of
Note that this scenario assumes that each client trusts the sender and accepts to
align its NTP configuration to that of the sender, using one of the NTP server(s)
suggested. If this assumption does not hold, the client MUST NOT use the NTP indirect
time synchronization method (Section 2.3.2.).

Section 2.3.2 specifies that some of the indirect synchronization methods
require that the clients trust the sender sufficiently:
It should be noted that the NTP/SNTP schemes assume that each client trusts
the sender and accepts to align its NTP/SNTP configuration to that of the
sender. If this assumption does not hold, the sender SHOULD offer an
alternative solution.

However, we think that "using one of the offered NTP server"
is a MUST for TESLA to remain secure. If the two NTP hierarchies
are totally disjoint, I don't see how secure time synchronization
could be achieved.

> 6. The Security Considerations have no discussion at all of the security of
> the back channel. I understand that such a channel does exist, at least for
> NORM. This channel remains unprotected (or its protection remains
> unspecified, see Sec. 1.1). Can it be used to DOS the sender? Other
> receivers? Are additional attacks possible?

You're right. We added a new section to discuss the security of the
back channel (section 6.3). We also added an informative reference to
a companion document, draft-ietf-rmt-simple-auth-for-alc-norm-01,
that expicits the use of such simple schemes as RSA/ECC digital signature
and/or group MAC in the context of ALC/NORM, using the same EXT_AUTH
header extension mechanisms.
(this document will soon enter RMT WGLC).
Section 1.1. "Scope of this Document" has also been improved in order
to better introduce these possibilities.

> Other Comments
> 2.2: leaving the bootstrapping step implementation-dependent means that the
> protocol is non-interoperable.

This is right. We added a sentence to say that it is RECOMMENDED that TESLA
implementations support bootstrap messages. However, we don't want to make
its support mandatory since there are use-cases where out-of-band is prefered
(see RFC4442).

> this section implies (last paragraph) that the use of periodic
> bootstrap information is only applicable for the case where direct time
> synchronization is used. Is this required by the TESLA protocol?

Good catch, thanks. This is indeed an error and anyway it contradicts
section 3.2.1. New text is as follows:

   The only solution for this
   receiver to catch up consists in receiving an additional bootstrap
   information message.  This can happen by waiting for the next
   periodic transmission (if sent in-band) or through an external
   mechanism (Section 3.2.1).

> 3.4.3: the description of the “Disclosed Key” field says it must be 0 in the
> first d intervals, which contradicts the last paragraph of the section,
> where it is forbidden to use this tag in those intervals.

We read the whole document several times, and this error slipped through.
Of course, the "set to 0" requirement comes from the time there was no
auth tag without key disclosure. Thanks.

> 3.4.7 (and elsewhere): I wonder about the design choice of making the length
> of the NSB (and hence, the explicit part of the interval index) depend on
> the size of the truncated MAC. The considerations for selecting one are
> primarily security-related, while for the other they are primarily about
> bandwidth and reliability. Why make them dependent?

We removed i_LSB/i_NSB altogether in the new version, for the sake of
simplicity (see our answer to the "General comment"). This comment does
not apply now.

> 4.1: the text “verify the Group MAC if present” is misleading (an attacker
> might remove it from the packet). It should be “if the G bit is set in the
> Bootstrap message”.

This is right, the wording is misleading. Corrected. New text is as follows:
   o  first of all, if the Group MAC is present and if the session uses
      this feature (e.g., if the G bit is set in the bootstrap
      information message), then verify the Group MAC.  A packet that
      does not contain a Group MAC tag whereas the session uses this
      feature MUST be immediately dropped.  On the opposite, if a packet
      contains a Group MAC tag whereas the session does not use this
      feature, this tag MUST be ignored;
Similarly we updated step 3 of section 4.3.

> 4.3, step 5: when doing congestion control, isn’t there value in keeping
> key-disclosure packets, even when other packets are dropped? The effect of
> key-disclosure packets being dropped may be dozens of other packets that are
> lost.

There is a misunderstanding here. By "the receiver performs
congestion control", one must understand that the sequence number
information contained in this packet is used by the congestion control
building block to detect possible packet losses. This happen even if
the packet is not authenticated at this step.
If the packet discloses a key, this key will be eventually used once
the packet is authenticated.
The text is clarified to better reflect this (and the DoS attack example
   5.  When applicable, the receiver performs any congestion control
       related action (i.e., the ALC or NORM headers are used by the
       associated congestion control building block, if any), even if
       the packet has not yet been authenticated [RMT-BB-LCT].  If this
       feature leads to a potential DoS attack (the attacker can send a
       faked packet with a wrong sequence number to simulate packet
       losses), it does not compromise the security features offered by
       TESLA and enables a rapid reaction in front of actual congestion

> 4.3: I find this text self-contradictory: “In this specification, a receiver
> using TESLA MUST immediately drop unsafe packets.  But the receiver MAY also
> decide, at any time, to continue an ALC or NORM session in unsafe mode,
> ignoring TESLA extensions.” I would have felt somewhat better about it if
> the text said something like “there SHOULD be explicit user action to move
> to unsafe (insecure) mode”.

Corrected as suggested, especially as it was the idea.

Thanks a lot for your valuable comments, and sorry for this
late answer.

    Vincent and Aurelien.

nb: I'll submit the new I-D later today.