Re: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt

[Greg Mirsky <[e-mail]>]

Hi Brian,
thank you for helpful insights. As this is the WG document, we'll follow
the decision of the experts that participate in the WG discussion. I like
the proposal to move encryption out of the STAMP base specification as it
helps in keeping timing measurements more accurate by reading the wall
clock closer to the packet transmission.

Dear All,
please consider stating your support/no support for the following options:

   - for the integrity protection:
      - use HMAC-SHA256 truncated to 128 bits
      - use  ECDSA  truncated to 128 bits
   - for the confidentiality protection:
      - keep the current text
      - remove, stating it is by higher layer(s).

Regards,
Greg

On Wed, Nov 7, 2018 at 10:50 AM Brian Weis (bew) <[e-mail]> wrote:

> Hi Ignacio and Greg,
>
> ECDSA is a digital signature algorithm, which is very expensive and
> because of this it is not traditionally used to protect network data
> packets.  I don’t recommend specifying it. Unless this is a rarely sent
> data packet sent, you would be consuming a substantial amount of the CPU by
> applying a digital signature to every packet sent with STAMP. Also, in
> order to get the value  you want, you actually have to create a hash of the
> packet (e.g., using SHA1/SHA256) and then sign the hash, where the result
> will be at least the length of a full HMAC output. So you’re not saving any
> space.
>
> Using HMAC-SHA1 or SHA256 on network data packets as shown in Figure 4 is
> very reasonable.  Section 5 of RFC 2104 (HMAC) says how it’s acceptable to
> truncate the hash output, and security protocols usually do this.  IPSec
> truncates HMAC-SHA-1 output to 96 bits (RFC 2404), and HMAC-SHA-256 is
> truncated to 128 bits (RFC 4868).  Since -03 was willing to apply a 128-bit
> truncated hash, I think you could safely specify using HMAC-SHA-256 with a
> 128 bit truncation. Note that if you specify the use of HMAC-SHA1, you will
> very likely run into SecDir complaints when you get to IETF last call.
>
> I did mention in the IPPM meeting that adding AES support is bit more
> problematic. I would recommend specifying that when confidentiality is
> needed that it be done a higher layer. If you do decide to keep it in this
> draft, you should describe what is the value of protecting only the first
> 16 octets. Also, you should know that cryptographers do not recommend using
> EBC. A Wikipedia page describes this plainly: "The disadvantage of this
> method is a lack of diffusion. Because ECB encrypts
> identical plaintext blocks into identical ciphertext blocks, it does not
> hide data patterns well. In some senses, it doesn't provide serious message
> confidentiality, and it is not recommended for use in cryptographic
> protocols at all.” (
> https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_(ECB))
> .
>
> The other mode -03 mentioned is using AES-CBC to protect the entire
> message. That’s a conventional use of AES, but when AES-CBC is used, both
> the encryptor and decrypt need the same Initialization Vector (IV) used
> with the method. Traditionally it is included in the packet, so that’s
> another 16 octets you probably need to add to the packet format. This
> should NOT replace the HMAC field, because cryptographers strongly state
> that it is bad practice to send an unauthenticated encrypted packet.
>
> I don’t see the rationale in -03 for needing confidentiality. So it might
> be best to stick with an HMAC-SHA256 hash, and if confidentiality is
> required to use a higher layer encryption. Otherwise, you’ll need to do a
> lot more specification of how the confidentially is done in this draft.
>
> I hope that helps.
>
> Brian
>
> On Nov 7, 2018, at 9:15 AM, Greg Mirsky <[e-mail]> wrote:
>
> Ho J.Ignacio,
> thank you for the comment and helpful suggestion. Will read the
> draft-alavarez-hamelin-tictoc-sic and respond accordingly in a short time.
> From the quick run through the draft, I agree with you that ECDSA offers
> advantages over the SHA1 of the same length. Just need to check for
> possible impact on YANG data model.
>
> Regards,
> Greg
>
> On Wed, Nov 7, 2018 at 2:26 AM J Ignacio Alvarez-Hamelin <
> [e-mail]> wrote:
>
>> Hi Greg,
>>
>> Today at the IPPM meeting I said that you could consider using SHA1 256
>> with bits for authentication, to respect some security standards. Your
>> comment that is expensive, and I agree with that.
>> I propose another alternative, is the one that I used in
>> draft-alavarez-hamelin-tictoc-sic-02, the Elliptic Curve Digital Signature
>> Algorithm (ECDSA), which yields in few bits and has some securities form de
>> cryptographic point of view.
>>
>>
>> Best withes,
>>
>>         J. Ignacio
>> _______________________________________________________________
>>
>> Dr. Ing. José Ignacio Alvarez-Hamelin
>> CONICET and Facultad de Ingeniería, Universidad de Buenos Aires
>> Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina
>> [phone] / 5285 0705
>> e-mail: [e-mail]
>> web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
>> _______________________________________________________________
>>
>>
>>
>> > On 16 Oct 2018, at 05:24, Brian Trammell (IETF) <[e-mail]>
>> wrote:
>> >
>> > hi Greg,
>> >
>> > We'll put this and a tentative start of WGLC on the Bangkok agenda..
>> >
>> > Thanks, cheers,
>> >
>> > Brian
>> >
>> >> On 16 Oct 2018, at 01:00, Greg Mirsky <[e-mail]> wrote:
>> >>
>> >> Hi Brian,
>> >> my apologies for the delayed response. The new version of the draft
>> has been just uploaded. The updates include the new section that describes
>> authentication and encryption operations on STAMP packets. I'd request the
>> presentation slot at the meeting and, if there are no significant concerns,
>> would ask to consider starting the WG LC on the base specification. The
>> work on the STAMP YANG data model still on-going and we're addressing the
>> comments from the early YANG Doctors review by Mahesh. I expect we'll have
>> the new version by the end of November.
>> >>
>> >> Regards,
>> >> Greg
>> >>
>> >> On Thu, Oct 4, 2018 at 8:12 AM Brian Trammell (IETF) <[e-mail]>
>> wrote:
>> >> hi Greg,
>> >>
>> >> following up a bit late, perhaps... when do you think this will be
>> ready for LC?
>> >>
>> >> Cheers,
>> >>
>> >> Brian (as WG co-chair)
>> >>
>> >>> On 8 Sep 2018, at 00:53, Greg Mirsky <[e-mail]> wrote:
>> >>>
>> >>> Dear All,
>> >>> minor editorial improvements to the document..
>> >>> Your comments, questions, and suggestions always welcome and much
>> appreciated.
>> >>>
>> >>> Regards,
>> >>> Greg
>> >>>
>> >>> ---------- Forwarded message ----------
>> >>> From: <[e-mail]>
>> >>> Date: Fri, Sep 7, 2018 at 2:56 PM
>> >>> Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt
>> >>> To: [e-mail]
>> >>> Cc: [e-mail]
>> >>>
>> >>>
>> >>>
>> >>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> >>> This draft is a work item of the IP Performance Measurement WG of the
>> IETF.
>> >>>
>> >>>        Title           : Simple Two-way Active Measurement Protocol
>> >>>        Authors         : Greg Mirsky
>> >>>                          Guo Jun
>> >>>                          Henrik Nydell
>> >>>                          Richard Foote
>> >>>        Filename        : draft-ietf-ippm-stamp-02.txt
>> >>>        Pages           : 14
>> >>>        Date            : 2018-09-07
>> >>>
>> >>> Abstract:
>> >>>   This document describes a Simple Two-way Active Measurement Protocol
>> >>>   which enables measurement of both one-way and round-trip performance
>> >>>   metrics like delay, delay variation, and packet loss.
>> >>>
>> >>>
>> >>> The IETF datatracker status page for this draft is:
>> >>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/
>> >>>
>> >>> There are also htmlized versions available at:
>> >>> https://tools.ietf.org/html/draft-ietf-ippm-stamp-02
>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-02
>> >>>
>> >>> A diff from the previous version is available at:
>> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-02
>> >>>
>> >>>
>> >>> Please note that it may take a couple of minutes from the time of
>> submission
>> >>> until the htmlized version and diff are available at tools.ietf.org.
>> >>>
>> >>> Internet-Drafts are also available by anonymous FTP at:
>> >>> ftp://ftp.ietf.org/internet-drafts/
>> >>>
>> >>> _______________________________________________
>> >>> ippm mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/ippm
>> >>>
>> >>> _______________________________________________
>> >>> ippm mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/ippm
>> >>
>> >
>> > _______________________________________________
>> > ippm mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ippm
>>
>> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>
>
> --
> Brian Weis
> Security, CSG, Cisco Systems
> Telephone: [phone]
> Email: [e-mail]
>
>