Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things
draft-ietf-dice-profile-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-07-08
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-06-24
|
17 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-06-20
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-05-18
|
17 | (System) | RFC Editor state changed to EDIT from MISSREF |
2015-10-19
|
17 | (System) | IANA Action state changed to No IC from In Progress |
2015-10-19
|
17 | (System) | IANA Action state changed to In Progress |
2015-10-19
|
17 | (System) | RFC Editor state changed to MISSREF |
2015-10-19
|
17 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-10-19
|
17 | (System) | Announcement was received by RFC Editor |
2015-10-19
|
17 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2015-10-19
|
17 | Amy Vezza | IESG has approved the document |
2015-10-19
|
17 | Amy Vezza | Closed "Approve" ballot |
2015-10-19
|
17 | Amy Vezza | Ballot approval text was generated |
2015-10-19
|
17 | Amy Vezza | Ballot writeup was changed |
2015-10-18
|
17 | Hannes Tschofenig | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-10-18
|
17 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-17.txt |
2015-10-14
|
16 | (System) | Notify list changed from dice-chairs@ietf.org, zach.shelby@arm.com, draft-ietf-dice-profile@ietf.org, draft-ietf-dice-profile.shepherd@ietf.org, draft-ietf-dice-profile.ad@ietf.org to (None) |
2015-10-09
|
16 | Gunter Van de Velde | Closed request for Telechat review by OPSDIR with state 'No Response' |
2015-10-08
|
16 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2015-10-01
|
16 | Amy Vezza | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2015-10-01
|
16 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-09-30
|
16 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-09-30
|
16 | Barry Leiba | [Ballot comment] Just some editorial comments here that the RFC Editor isn't likely to catch: -- Section 1 -- UDP is mainly used to … [Ballot comment] Just some editorial comments here that the RFC Editor isn't likely to catch: -- Section 1 -- UDP is mainly used to carry CoAP messages but other transports can be utilized This is worded oddly, as it looks as if it's saying that the main use of UDP is to carry CoAP messages. Please consider this instead: NEW CoAP messages are mainly carried over UDP, but other transports can be utilized END -- Section 3.1 -- However, since DTLS operates on top of an unreliable datagram transport, it must explicitly cope with the reliable and ordered delivery assumptions made by TLS. It must explicitly cope with the *absence of* reliable and ordered delivery. Please consider re-wording this. -- Section 4.4.4 -- There are various algorithms used to sign digital certificates, such as RSA, the Digital Signature Algorithm (DSA), and the Elliptic Curve Digital Signature Algorithm (ECDSA). As Table 1 indicates certificate are signed using ECDSA. This initially confused me. First, the "such as" modifier appears to apply to "digital certificates", when it's actually meant to apply to "algorithms". Then the second sentence seemed to contradict the first, until I realized that it's incomplete. Please consider this: NEW There are various algorithms used to sign digital certificates; those algorithms include RSA, the Digital Signature Algorithm (DSA), and the Elliptic Curve Digital Signature Algorithm (ECDSA). As Table 1 shows, in this profile certificates are signed using ECDSA. END -- Section 4.4.6 -- With certificate-based authentication a DTLS server conveys its end entity certificate to the client during the DTLS exchange provides. Something's wrong with this sentence (the part that begins with "during"), but I can't figure out what. -- Section 6 -- All error messages marked as RESERVED are only supported for backwards compatibility with SSL MUST NOT be used with this profile. You're missing "and" before "MUST NOT". -- Section 13 -- Implementations conformant to this specification MUST use AEAD ciphers. Hence, RFC 7366 and the Truncated MAC extension of RFC 6066 are not applicable to this specification and are NOT RECOMMENDED. To me, "not applicable" says more than "NOT RECOMMENDED". Why is this not "MUST NOT be used"? -- Section 17 -- 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. Doesn't the second sentence actually say that this specification REQUIRES (not "RECOMMENDS") disabling of the TLS renegotiation feature? -- Section 18 -- If at some time in the future this profile reaches the quality of SSL 3.0 a software update is needed since constrained devices are unlikely to run multiple TLS/DTLS versions due to memory size restrictions. I don't understand this. What does "reaches the quality of SSL 3.0" mean? |
2015-09-30
|
16 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-09-30
|
16 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-09-30
|
16 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-09-30
|
16 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-09-30
|
16 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-09-30
|
16 | Spencer Dawkins | [Ballot comment] I really like this document. I wish more working groups produced similar guidance. I did have a number of questions, that you might … [Ballot 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")? |
2015-09-30
|
16 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2015-09-30
|
16 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-09-30
|
16 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-09-29
|
16 | Ben Campbell | [Ballot comment] Thanks for a clear, easy to read document. At the start, I considered complaining about the page count, but I think you used … [Ballot comment] Thanks for a clear, easy to read document. At the start, I considered complaining about the page count, but I think you used those pages well. 4.4.1, paragraph after first numbered list: Can this be more precise than "breaks security"? Maybe something to the effect of "Comparing...is required to ensure the client is communicating with the intended server"? 4.4.3, and 23: Are there bootstrapping concerns with software update mechanisms? For example, what if you need to revoke a trust anchor on which the update mechanism depends? |
2015-09-29
|
16 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2015-09-29
|
16 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-09-29
|
16 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-09-28
|
16 | Kathleen Moriarty | [Ballot comment] Thanks for your work on this draft! It is very well written and provides helpful guidance with appropriate pointers that I hope gets … [Ballot comment] Thanks for your work on this draft! It is very well written and provides helpful guidance with appropriate pointers that I hope gets picked up by many IoT vendors. I even tweeted about this one! It would be good to raise awareness on this draft/RFC. Nice job! |
2015-09-28
|
16 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2015-09-25
|
16 | Brian Carpenter | Request for Telechat review by GENART Completed: Ready. Reviewer: Brian Carpenter. |
2015-09-24
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2015-09-24
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2015-09-17
|
16 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Tina Tsou |
2015-09-17
|
16 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Tina Tsou |
2015-09-15
|
16 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-09-14
|
16 | Stephen Farrell | Placed on agenda for telechat - 2015-10-01 |
2015-09-14
|
16 | Stephen Farrell | IESG state changed to IESG Evaluation from Waiting for Writeup |
2015-09-14
|
16 | Stephen Farrell | Changed consensus to Yes from Unknown |
2015-09-14
|
16 | Stephen Farrell | Ballot has been issued |
2015-09-14
|
16 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2015-09-14
|
16 | Stephen Farrell | Created "Approve" ballot |
2015-09-14
|
16 | Stephen Farrell | Ballot writeup was changed |
2015-09-11
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Tina Tsou. |
2015-09-10
|
16 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-16.txt |
2015-09-09
|
15 | Hannes Tschofenig | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-09-09
|
15 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-15.txt |
2015-09-04
|
14 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-09-02
|
14 | Brian Carpenter | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Brian Carpenter. |
2015-08-27
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2015-08-27
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2015-08-27
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dacheng Zhang |
2015-08-27
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dacheng Zhang |
2015-08-25
|
14 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2015-08-25
|
14 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-dice-profile-14, which is currently in Last Call, and has the following comments: We understand that this … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-dice-profile-14, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object. If this assessment is not accurate, please respond as soon as possible. |
2015-08-23
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tina Tsou |
2015-08-23
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tina Tsou |
2015-08-21
|
14 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-08-21
|
14 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (TLS/DTLS Profiles for the Internet … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (TLS/DTLS Profiles for the Internet of Things) to Proposed Standard The IESG has received a request from the DTLS In Constrained Environments WG (dice) to consider the following document: - 'TLS/DTLS Profiles for the Internet of Things' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-09-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensor or controls actuators for use in home automation, industrial control systems, smart cities and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram TLS (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in Internet of Things products that can easily be solved by using these well-researched and widely deployed Internet security protocols. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-08-21
|
14 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-08-21
|
14 | Stephen Farrell | Last call was requested |
2015-08-21
|
14 | Stephen Farrell | Ballot approval text was generated |
2015-08-21
|
14 | Stephen Farrell | Ballot writeup was generated |
2015-08-21
|
14 | Stephen Farrell | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2015-08-21
|
14 | Stephen Farrell | Last call announcement was generated |
2015-08-21
|
14 | Stephen Farrell | Last call announcement was generated |
2015-08-17
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-08-17
|
14 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-14.txt |
2015-07-06
|
13 | Stephen Farrell | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2015-07-06
|
13 | Stephen Farrell | IESG state changed to AD Evaluation from Publication Requested |
2015-07-01
|
13 | Amy Vezza | Notification list changed to dice-chairs@ietf.org, zach.shelby@arm.com, draft-ietf-dice-profile@ietf.org, draft-ietf-dice-profile.shepherd@ietf.org, draft-ietf-dice-profile.ad@ietf.org from "Zach Shelby" <zach.shelby@arm.com> |
2015-07-01
|
13 | Zach Shelby | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? draft-ietf-dice-profile-13.txt is a Standards Track specification. The intented status is indicated at the header page. The specification defines different TLS/DTLS profiles for use with Internet of Things devices. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensor or controls actuators for use in home automation, industrial control systems, smart cities and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram TLS (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in Internet of Things products that can easily be solved by using these well-researched and widely deployed Internet security protocols. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was no controversy about this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The document has been reviewed by various DICE working group participants. Due to the nature of the document additional review from the security community is essential. Various implementations of embedded TLS stacks exist on the market (open source as well as closed source implementations) that implement a subset of the functionality defined in the specification. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The responsible area director for DICE and for this document iks Stephen Farrell. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Zach Shelby is the document shepherd. Detailed reviews during the lifetime of the document have been done by the shepherd. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, the document has gone through several iterations due to review comments from various working group members. The last few revisions and related have resulted in only minor editorial improvements. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The document would benefit from further security reviews. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no concerns with this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. The authors have confirmed that any and all appropriate IPR disclosures have been filed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has wide working group support, and was the main focus of the DICE charter. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The shepherd checked the document for nits. All identified problems have been corrected. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal reviews are required by this document. (13) Have all references within this document been identified as either normative or informative? Yes. All references are separated into informative and normative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? Yes, there are two documents that are still in draft state: [I-D.ietf-tls-cached-info] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", draft-ietf-tls- cached-info-19 (work in progress), March 2015. [I-D.ietf-tls-session-hash] Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", draft-ietf- tls-session-hash-05 (work in progress), April 2015. [I-D.ietf-tls-session-hash] has been submitted to the IESG for publication and [I-D.ietf-tls-cached-info] will be submitted to the IESG soon. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are various downward references in this document. The following specifications are non-IETF documents: [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY", April 2010, . [GSM-SMS] ETSI, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Technical realization of the Short Message Service (SMS) (Release 7)", March 2007. [WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram Protocol", June 2001. This specification is an informational RFC: [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS", RFC 7251, June 2014. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document will not change the status of any other RFC. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This specification does not require actions by IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Not applicable. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no formal languages used in this specification. |
2015-07-01
|
13 | Zach Shelby | Responsible AD changed to Stephen Farrell |
2015-07-01
|
13 | Zach Shelby | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2015-07-01
|
13 | Zach Shelby | IESG state changed to Publication Requested |
2015-07-01
|
13 | Zach Shelby | IESG process started in state Publication Requested |
2015-07-01
|
13 | Zach Shelby | Intended Status changed to Proposed Standard from None |
2015-07-01
|
13 | Zach Shelby | Changed document writeup |
2015-07-01
|
13 | Zach Shelby | Notification list changed to "Zach Shelby" <zach.shelby@arm.com> |
2015-07-01
|
13 | Zach Shelby | Document shepherd changed to Zach Shelby |
2015-06-11
|
13 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-13.txt |
2015-05-28
|
12 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-12.txt |
2015-05-27
|
11 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-11.txt |
2015-03-08
|
10 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-10.txt |
2015-01-19
|
09 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-09.txt |
2014-12-21
|
08 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-08.txt |
2014-12-15
|
07 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-07.txt |
2014-12-08
|
06 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-06.txt |
2014-10-26
|
05 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-05.txt |
2014-08-31
|
04 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-04.txt |
2014-07-04
|
03 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-03.txt |
2014-07-04
|
02 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-02.txt |
2014-05-06
|
01 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-01.txt |
2014-03-31
|
00 | Hannes Tschofenig | New version available: draft-ietf-dice-profile-00.txt |