Subject: Re: [Dtls-iot] Review of draft-ietf-dice-profile-10

From: Rene Hummen <[email-masked]>
Date: Mon, 9 Mar 2015 15:19:49 +0000

Hi Hannes,

On 07 Mar 2015, at 11:08, Hannes Tschofenig <[email-masked]> wrote:
>> 4) Section 5 (line 1025)
>> 
>> "SHA-256 is the recommended default PRF.”
>> 
>> In which document? The DTLS profile or the (D)TLS specification?
>> 
> 
> Actually, the story is a bit more complex since the PRF is part of the
> ciphersuite definition and while the TLS 1.2 spec says that new
> ciphersuites should use the SHA-256 based construction it also allows a
> ciphersuite to define else. I added extra text to the 'The Ciphersuite
> Concept' section.

This flexibility in PRF selection exactly was the reason for my comment. You now discuss the use of SHA-256 for Pre-Shared Secrets, but not in case of Raw Public Keys and Certificates. Is there a special need to highlight SHA-256 for Pre-Shared Secrets?

> 11) Section 21 (line 2089 and below)
>> "Offer access to building blocks in addition (or as an alternative) 
>> to the complete functionality.  For example, a chip manufacturer who
>> gives developers access to the AES crypto function can use it to
>> build an efficient AES-GCM implementations.  Another example is to
>> make a special instruction available that increases the speed of
>> speed-up carryless multiplications.”
>> 
>> Why not use ECB as a basic example of a building block?
>> 
> I didn't want to go too far with the recommendation about what should be
> done in hardware but rather state high-level principles.

Ok, I just realized that re-phrasing "AES crypto function” to "AES block cipher” above would fix my comment.

>> 12) Appendix A (line 2673 and below)
>> 
>> In contrast to the remaining profile, this (obviously) is very link
>> layer specific normative text. Why not move this to a short separate
>> document?
>> 
> 
> As Thomas noted the content of the appendix was actually in a separate
> document. When we presented it the recommendation was made to include it
> in here since the underlying message about the timeout values is
> applicable also to other radio technologies.

I completely agree about the integration of the timeout values. I just wonder about the rest (which now is the Appendix).

> I also believe that the text in the appendix does not disrupt
> readability for others who do not care about this type of usage.

That is true. I am not sure if the Appendix of the general IoT profile isn’t hiding this SMS-related information for interested parties. To me, it makes more sense to have Appendix A as a separate document that references the IoT profile. If others believe the Appendix is the way to go forward, I won’t stand in the way though.

Otherwise, I agree with your changes.

BR
René

> 
> Ciao
> Hannes
> 
>> 
>> 
>> BR, René
>> 
>> 
>> [1]
>> https://github.com/hannestschofenig/tschofenig-ids/commit/37d0cfa130904dcba6c2d470f286bdb98b81e41d
>> 
>> 
>> 
>> -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication
>> and Distributed Systems RWTH Aachen University, Germany tel: +49 241
>> 80 21426 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/
>> 
>> 
>> 
>> _______________________________________________ dtls-iot mailing
>> list [email-masked] 
>> https://www.ietf.org/mailman/listinfo/dtls-iot

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21426
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

---

From: Renzo Navas <[email-masked]>
Date: Thu, 12 Mar 2015 16:26:13 +0100

Good Evening,

This is my first message on this mailing list, I am a novice on the IETF
world.
Just my humble opinion as a reader about the SMS-appendix:

>That is true. I am not sure if the Appendix of the general IoT profile
isn’t hiding this SMS-related information for interested parties.
>To me, it makes more sense to have Appendix A as a separate document that
references the IoT profile. If others believe the Appendix is the way to go
forward, I won’t stand in the way though.

For me it was very useful to have this information in the appendix
of draft-ietf-dice-profile-10.txt , otherwise I doubt I will have read
(draft-fossati-dtls-over-gsm-sms-01)  it anytime soon, thought the
information there was very relevant to me (my goal is to implement dtls on
a non-udp datagram transport -non-ip neither-).

Thank you for all your effort on this WG.

Renzo NAVAS

On Mon, Mar 9, 2015 at 4:19 PM, Rene Hummen <
[email-masked]> wrote:

> This flexibility in PRF selection exactly was the reason for my comment.
> You now discuss the use of SHA-256 for Pre-Shared Secrets, but not in case
> of Raw Public Keys and Certificates. Is there a special need to highlight
> SHA-256 for Pre-Shared Secrets?
>
> I completely agree about the integration of the timeout values. I just
> wonder about the rest (which now is the Appendix).
>
> That is true. I am not sure if the Appendix of the general IoT profile
> isn’t hiding this SMS-related information for interested parties. To me, it
> makes more sense to have Appendix A as a separate document that references
> the IoT profile. If others believe the Appendix is the way to go forward, I
> won’t stand in the way though.
>
> _______________________________________________
> dtls-iot mailing list
> [email-masked]