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

[J Ignacio Alvarez-Hamelin <[e-mail]>]

Thanks Brian for your useful comments about ECDSA used on some type of hardware (in my case it doesn’t matter because they are endpoints and the signature is done in a deferred mode to not interfere with the clock synchronization process).
Thanks Greg for your solution. 


Best,

	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 7 Nov 2018, at 03:51, Greg Mirsky <[e-mail]> wrote:
> 
> 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]
>