[Dtls-iot] Spencer Dawkins' Yes on draft-ietf-dice-profile-16: (with COMMENT)
"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Wed, 30 September 2015 18:04 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2CC1A8856; Wed, 30 Sep 2015 11:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
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 uRBN7VKnQy3T; Wed, 30 Sep 2015 11:04:53 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 951791A8851; Wed, 30 Sep 2015 11:04:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150930180453.20560.45039.idtracker@ietfa.amsl.com>
Date: Wed, 30 Sep 2015 11:04:53 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/dtls-iot/PfDcXOTqDU4SCtQvRP6YDKvQoF0>
Cc: zach.shelby@arm.com, dtls-iot@ietf.org, dice-chairs@ietf.org, draft-ietf-dice-profile.shepherd@ietf.org, draft-ietf-dice-profile@ietf.org, draft-ietf-dice-profile.ad@ietf.org
Subject: [Dtls-iot] Spencer Dawkins' Yes on draft-ietf-dice-profile-16: (with COMMENT)
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 18:04:55 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-dice-profile-16: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I really like this document. I wish more working groups produced similar guidance. I did have a number of questions, that you might want to take a look at before the document is approved. This text UDP is mainly used to carry CoAP messages but other transports can be utilized, such as SMS Appendix A or TCP [I-D.tschofenig-core-coap-tcp-tls]. is somewhat ambiguous - is this supposed to say that "Most CoAP messages are carried in UDP, but other transports can be utilized, such as ..."? This document is pretty reference-rich, but For use with this profile the PSK identities SHOULD NOT assume a structured format (such as domain names, Distinguished Names, or IP addresses) and a constant time bit-by-bit comparison operation MUST be used by the server for any operation related to the PSK identity. doesn't have a reference or a definition for "constant time bit-by-bit comparison operation". Could you provide one? I wasn't quite sure what TLS/DTLS offers a lot of freedom for the use with ECC. means. At a minimum, "for the use with" needs help. I'm guessing from the rest of the paragraph that this is saying "TLS/DTLS offers a lot of choices when selecting ECC curves", or something like that. But I'm guessing. Is there a missing word in For deployments where public key cryptography is acceptable the raw public might somewhere around here? ^ offer an acceptable middle ground between the PSK ciphersuite in terms of out-of-band validation and the functionality offered by asymmetric cryptography. I think I understand The use of PFS is a trade-off decision since on one hand the compromise of long-term secrets of embedded devices is more likely than with many other Internet hosts but on the other hand a Diffie- Hellman exchange requires ephemeral key pairs to be generated, which is demanding from a performance point of view. For obvious performance improvement, some implementations re-use key pairs over multiple exchanges (rather than generating new keys for each exchange). However, note that such key re-use over long periods voids the benefits of forward secrecy when an attack gains access to this DH key pair. but, just to make sure - is this saying that when you gain access to a DH key pair, you can decrypt back to the last time the device generated new keys, but no further (so, "Imperfect Forward Secrecy")? I'm guessing that based on "trade-off" in the first sentence, but I'm not sure what's being traded for performance improvement. In this text, On the other hand, the way DTLS handles retransmission, which is per-flight instead of per-segment, tends to interact poorly with low bandwidth networks. I'm assuming you are using "per-flight" in the https://tools.ietf.org/html/rfc5681 sense of the term ("FLIGHT SIZE: The amount of data that has been sent but not yet cumulatively acknowledged"), but that's somewhat obscure, especially outside of TSV, and there's no definition or reference for it in this document. Perhaps you could say something like On the other hand, DTLS handles loss by retransmitting the entire amount of data that has been sent but has not been cumulatively acknowledged, and this tends to interact poorly with low bandwidth networks. Just to make sure I understand, The ClientHello and the ServerHello messages contains the 'Random' structure, which has two components: gmt_unix_time and a sequence of 28 random bytes. gmt_unix_time holds the current time and date in standard UNIX 32-bit format (seconds since the midnight starting Jan 1, 1970, GMT). Since many IoT devices do not have access to an accurate clock, it is RECOMMENDED to place a sequence of random bytes in the two components of the 'Random' structure when creating a ClientHello or ServerHello message and not to assume a structure when receiving these payloads. is recommending that all IoT devices use a sequence of random bytes, even if they do have access to an accurate clock - is that right? Could you help me understand why Implementing the Server Name Indication extension is RECOMMENDED unless it is known that a TLS/DTLS client does not interact with a server in a hosting environment. isn't REQUIRED? This seems like a violation of the Principle of Least Astonishment ("we moved our server into a hosted environment to save money, and our sensor network quit working"). I don't understand this paragraph. To prevent the re-negotiation attack [RFC5746] this specification RECOMMENDS to disable the TLS renegotiation feature. Clients MUST respond to server-initiated re-negotiation attempts with an alert message (no_renegotiation) and clients MUST NOT initiate them. If you MUST tell the server you won't renegotiate, and you MUST not try to renegotiate yourself, how does these turn into a RECOMMENDS ("SHOULD")?
- [Dtls-iot] Spencer Dawkins' Yes on draft-ietf-dic… Spencer Dawkins
- Re: [Dtls-iot] Spencer Dawkins' Yes on draft-ietf… FOSSATI, Thomas (Thomas)
- Re: [Dtls-iot] Spencer Dawkins' Yes on draft-ietf… Spencer Dawkins at IETF