More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)
draft-ietf-curdle-ssh-modp-dh-sha2-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-12-13
|
09 | (System) | Hartke Expires August 17, 2012 [Page 12] Internet-Draft … Hartke Expires August 17, 2012 [Page 12] Internet-Draft Observing Resources in CoAP February 2012 additionally remove the client from the lists of observers of all resources in its namespace. The server SHOULD use a number of retransmit attempts (MAX_RETRANSMIT) such that removing a client from the list of observers before Max-Age ends is avoided. A server MAY choose to skip a notification if it knows that it will send another notification soon (e.g., when the state is changing frequently). Similarly, it MAY choose to send a notification more than once. For example, when state changes occur in bursts, the server can skip some notifications, send the notifications in non- confirmable messages, and make sure that the client observes the latest state change after the burst by repeating the last notification in a confirmable message. 5. Intermediaries A client may be interested in a resource in the namespace of an origin server that is reached through one or more CoAP-to-CoAP intermediaries. In this case, the client registers its interest with the first intermediary towards the origin server, acting as if it was communicating with the origin server itself as specified in Section 3. It is the task of this intermediary to provide the client with a current representation of the target resource and send notifications upon changes to the target resource state, much like an origin server as specified in Section 4. To perform this task, the intermediary SHOULD make use of the protocol specified in this document, taking the role of the client and registering its own interest in the target resource with the next hop. If the next hop does not return a response with an Observe Option, the intermediary MAY resort to polling the next hop, or MAY itself return a response without an Observe Option. Note that the communication between each pair of hops is independent, i.e. each hop in the server role MUST determine individually how many notifications to send, of which type, and so on. Each hop MUST generate its own values for the Observe Option, and MUST set the value of the Max-Age Option according to the age of the local current representation. Because a client (or an intermediary in the client role) can only be once in the list of observers of a resource at a server (or an intermediary in the server role) -- it is useless to observe the same resource multiple times -- an intermediary MUST observe a resource only once, even if there are multiple clients for which it observes the resource. Hartke Expires August 17, 2012 [Page 13] Internet-Draft Observing Resources in CoAP February 2012 Note that an intermediary is not required to have a client to observe a resource; an intermediary MAY observe a resource, for instance, just to keep its own cache up to date. See Appendix A.1 for examples. 6. Block-wise Transfers Resources observed by clients may be larger than can be comfortably processed or transferred in one CoAP message. CoAP provides a block- wise transfer mechanism to address this problem [I-D.ietf-core-block]. The following rules apply to the combination of block-wise transfers with notifications. As with basic GET transfers, the client can indicate its desired block size in a Block2 Option in the GET request. If the server supports block-wise transfers, it SHOULD take note of the block size for all notifications/responses resulting from the GET request (until the client is removed from the list of observers or the server receives a new GET request from the client). When sending a 2.05 (Content) notification, the server always sends all blocks of the representation, suitably sequenced by its congestion control mechanism, even if only some of the blocks have changed with respect to a previous value. The server performs the block-wise transfer by making use of the Block2 Option in each block. When reassembling representations that are transmitted in multiple blocks, the client MUST NOT combine blocks carrying different Observe Option values, or blocks that have been received more than approximately 2**14 seconds apart. See Appendix A.2 for an example. 7. Discovery A web link [RFC5988] to a resource accessible by the CoAP protocol MAY indicate that the server encourages the observation of this resource by including the target attribute "obs". This is particularly useful in link-format documents [I-D.ietf-core-link-format]. This target attribute is used as a flag, and thus it has no value component -- a value given for the attribute MUST NOT be given for this version of the specification and MUST be ignored if present. The target attribute "obs" MUST NOT be given more than once for this version of the specification. Hartke Expires August 17, 2012 [Page 14] Internet-Draft Observing Resources in CoAP February 2012 RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-10-16
|
09 | (System) | RFC Editor state changed to AUTH48 from EDIT |
2017-09-27
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-09-27
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-09-26
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2017-09-25
|
09 | (System) | RFC Editor state changed to EDIT |
2017-09-25
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-09-25
|
09 | (System) | Announcement was received by RFC Editor |
2017-09-25
|
09 | (System) | IANA Action state changed to In Progress |
2017-09-25
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2017-09-25
|
09 | Cindy Morgan | IESG has approved the document |
2017-09-25
|
09 | Cindy Morgan | Closed "Approve" ballot |
2017-09-25
|
09 | Cindy Morgan | Ballot approval text was generated |
2017-09-23
|
09 | Eric Rescorla | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2017-09-15
|
09 | Mark Baushke | New version available: draft-ietf-curdle-ssh-modp-dh-sha2-09.txt |
2017-09-15
|
09 | (System) | New version approved |
2017-09-15
|
09 | (System) | Request for posting confirmation emailed to previous authors: Mark Baushke |
2017-09-15
|
09 | Mark Baushke | Uploaded new revision |
2017-09-14
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-09-14
|
08 | Mark Baushke | New version available: draft-ietf-curdle-ssh-modp-dh-sha2-08.txt |
2017-09-14
|
08 | (System) | New version approved |
2017-09-14
|
08 | (System) | Request for posting confirmation emailed to previous authors: Mark Baushke |
2017-09-14
|
08 | Mark Baushke | Uploaded new revision |
2017-09-14
|
07 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2017-09-13
|
07 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2017-09-13
|
07 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-09-13
|
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-09-13
|
07 | Benoît Claise | [Ballot comment] I understand that a new version will be published based on Linda Dunbar's OPS DIR review. Thank you. |
2017-09-13
|
07 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-09-13
|
07 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2017-09-13
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-09-13
|
07 | Kathleen Moriarty | [Ballot comment] Thanks for your work on this draft. I agree with Alexey's comment on the normative reference and just have a tiny nit for … [Ballot comment] Thanks for your work on this draft. I agree with Alexey's comment on the normative reference and just have a tiny nit for the introduction: I suggest you remove the word recent since the reference on SHA-1 is 6 years old: s/Due to recent security concerns with SHA-1 [RFC6194]/Due to security concerns with SHA-1 [RFC6194]/ |
2017-09-13
|
07 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2017-09-13
|
07 | Alexey Melnikov | [Ballot comment] RFC 6234 must be normative, as it is required to implement this document. |
2017-09-13
|
07 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2017-09-12
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-09-12
|
07 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-09-12
|
07 | Adam Roach | [Ballot comment] Section 1, paragraph 2: New MODP groups are being introduced starting with the MODP 3072-bit group 15 all use SHA512 as … [Ballot comment] Section 1, paragraph 2: New MODP groups are being introduced starting with the MODP 3072-bit group 15 all use SHA512 as the hash algorithm. I can't parse this. Should there be a sentence break between "15" and "all"? I was surprised to find section 4 here; in part because it isn't related to the addition of new algorithms, but mostly because it's not mentioned in the abstract or the introduction. Please add mention of this erratum correction to both sections. I'm pretty sure RFC6234 needs to be normative. |
2017-09-12
|
07 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2017-09-12
|
07 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-09-04
|
07 | Mirja Kühlewind | [Ballot comment] 1) To me this sentence does not belong in the IANA section as it is basically the main point of the document: "This … |
2017-09-04
|
07 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-08-31
|
07 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Donald Eastlake. |
2017-08-28
|
07 | Eric Rescorla | Placed on agenda for telechat - 2017-09-14 |
2017-08-28
|
07 | Eric Rescorla | IESG state changed to IESG Evaluation from Waiting for Writeup |
2017-08-28
|
07 | Eric Rescorla | Ballot has been issued |
2017-08-28
|
07 | Eric Rescorla | [Ballot Position Update] New position, Yes, has been recorded for Eric Rescorla |
2017-08-28
|
07 | Eric Rescorla | Created "Approve" ballot |
2017-08-28
|
07 | Eric Rescorla | Ballot writeup was changed |
2017-08-22
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Linda Dunbar. |
2017-07-30
|
07 | Orit Levin | Request for Last Call review by GENART Completed: Ready. Reviewer: Orit Levin. Sent review to list. |
2017-07-30
|
07 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-07-26
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2017-07-26
|
07 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-curdle-ssh-modp-dh-sha2-07. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-curdle-ssh-modp-dh-sha2-07. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete. In the Key Exchange Method Names registry on the Secure Shell (SSH) Protocol Parameters registry page located at: https://www.iana.org/assignments/ssh-parameters/ five new method names are to be added as follows: Method Name: diffie-hellman-group14-sha256 Reference: [ RFC-to-be ] Note: Method Name: diffie-hellman-group15-sha512 Reference: [ RFC-to-be ] Note: Method Name: diffie-hellman-group16-sha512 Reference: [ RFC-to-be ] Note: Method Name: diffie-hellman-group17-sha512 Reference: [ RFC-to-be ] Note: Method Name: diffie-hellman-group18-sha512 Reference: [ RFC-to-be ] Note: The IANA Services Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
2017-07-20
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2017-07-20
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2017-07-20
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Orit Levin |
2017-07-20
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Orit Levin |
2017-07-17
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2017-07-17
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2017-07-16
|
07 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2017-07-16
|
07 | Cindy Morgan | The following Last Call announcement was sent out (ends 2017-07-30): From: The IESG To: IETF-Announce CC: ekr@rtfm.com, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, … The following Last Call announcement was sent out (ends 2017-07-30): From: The IESG To: IETF-Announce CC: ekr@rtfm.com, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com, draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)) to Proposed Standard The IESG has received a request from the CURves, Deprecating and a Little more Encryption WG (curdle) to consider the following document: - 'More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)' 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 2017-07-30. 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 This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-07-16
|
07 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested::AD Followup |
2017-07-16
|
07 | Eric Rescorla | Last call was requested |
2017-07-16
|
07 | Eric Rescorla | Last call announcement was generated |
2017-07-16
|
07 | Eric Rescorla | Ballot approval text was generated |
2017-07-16
|
07 | Eric Rescorla | Ballot writeup was generated |
2017-07-16
|
07 | Eric Rescorla | IESG state changed to Last Call Requested::AD Followup from Publication Requested::AD Followup |
2017-06-22
|
07 | Mark Baushke | New version available: draft-ietf-curdle-ssh-modp-dh-sha2-07.txt |
2017-06-22
|
07 | (System) | New version approved |
2017-06-22
|
07 | (System) | Request for posting confirmation emailed to previous authors: Mark Baushke |
2017-06-22
|
07 | Mark Baushke | Uploaded new revision |
2017-06-21
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-06-21
|
06 | Mark Baushke | New version available: draft-ietf-curdle-ssh-modp-dh-sha2-06.txt |
2017-06-21
|
06 | (System) | New version approved |
2017-06-21
|
06 | (System) | Request for posting confirmation emailed to previous authors: Mark Baushke |
2017-06-21
|
06 | Mark Baushke | Uploaded new revision |
2017-06-17
|
05 | Eric Rescorla | IESG state changed to Publication Requested::Revised I-D Needed from Publication Requested |
2017-06-17
|
05 | Eric Rescorla | IESG state changed to Publication Requested from AD Evaluation |
2017-06-17
|
05 | Eric Rescorla | IESG state changed to AD Evaluation from Publication Requested |
2017-06-09
|
05 | Daniel Migault | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. The draft updates RFC4250, RFC4253. This is indicated in the header as well as in the abstract and the introduction. (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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. 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? The document received few reviews on the mailing list. However, discussions occur on whether: - choosing IKE vs TLS primes - choosing fixed primes versus random. The consensus for this document was to restraint to the primes defined for IKE. 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 draft describes the following key exchange algorithms: * diffie-hellman-group14-sha256 * diffie-hellman-group15-sha512 * diffie-hellman-group16-sha512 * diffie-hellman-group17-sha512 * diffie-hellman-group18-sha512 These suites have been at least partially implemented. [00],[2] * OpenSSH has implemented and distributed at least diffie-hellman-group14-sha256 it already [0] * Dropbear has preliminary support for diffie-hellman-group14-sha256 by Matt Johnston [1] * RLogin supports dh-group{14,15,16}-sha256 since version 2.19.8 [3]. * Tera Term committed dh-group{14,15,16}-sha256 support committed to trunk, and it will be included in next release. [4] * Poderosa [5] committed to support dh-group{14,15,16}-sha256 support where a pull request has been sent [6]. [00] http://ssh-comparison.quendi.de/comparison/kex.html [0] https://jbeekman.nl/blog/2015/05/ssh-logjam/ [1] http://www.ietf.org/mail-archive/web/secsh/current/msg01119.html [2] http://www.ietf.org/mail-archive/web/secsh/current/msg01139.html [3] http://nanno.dip.jp/softlib/man/rlogin/ [4] https://en.osdn.jp/projects/ttssh2/scm/svn/commits/6263 [5] http://poderosa.sourceforge.net/ in [6] https://github.com/poderosaproject/poderosa/pull/17 Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Daniel Migault is the Document Shepherd, Eric Rescola is the Responsible Area Director. (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. The document shepherd reviewed the document and followed the discussion on mailing list and during the meeting. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (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. No. (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. I have no concerns. (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 author declared he is not aware of any IPR. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (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? I believe the we reached WG consensus. (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.) One person strongly disagrees with the statement that fixed primes are better than random. Although this discussion was not targeting the draft and was not opposed to the use of fixed primes for the draft. As a result, I see this more as a relevant discussion, than as a opposition to the draft. The "security considerations" section reflects the discussion with the text below: """ Using a fixed set of Diffie-Hellman parameters makes them a high value target for precomputation. Generating additional sets of primes to be used, or moving to larger values is a mitigation against this issue. Care should be taken to avoid backdoored primes ([SNFS]) by using "nothing up my sleve" parameters. """ People did not really care on using TLS or IKE primes. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The only nit mentioned is the one below. I believe this paragraph can be removed as I do not see material copied from previous document. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. These reviews were not needed. (13) Have all references within this document been identified as either normative or informative? Yes. (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? No. (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. No. (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. The draft updates RFC4250 and RFC4253. These RFC are listed in the header, abstract and introduction. (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). The IANA section is clear. It is consistent with the current draft and references have been clearly identified. The IANA section details how to update the Key Exchange Method Names table [1]. Registration requires the IETF consensus. There is no expert review. [1] https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16 (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. The IANA consideration provides the necessary parameters for the IANA registries. IANA registries requires IETF consensus. There is no Expert review. https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16 (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. This is not applicable. No checks were performed |
2017-06-09
|
05 | Daniel Migault | Responsible AD changed to Eric Rescorla |
2017-06-09
|
05 | Daniel Migault | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2017-06-09
|
05 | Daniel Migault | IESG state changed to Publication Requested |
2017-06-09
|
05 | Daniel Migault | IESG process started in state Publication Requested |
2017-06-09
|
05 | Daniel Migault | Changed document writeup |
2017-06-09
|
05 | Daniel Migault | Changed document writeup |
2017-06-05
|
05 | Daniel Migault | Changed document writeup |
2017-06-03
|
05 | Daniel Migault | Changed document writeup |
2017-06-03
|
05 | Daniel Migault | Changed document writeup |
2017-06-03
|
05 | Daniel Migault | Changed consensus to Yes from Unknown |
2017-06-03
|
05 | Daniel Migault | Intended Status changed to Proposed Standard from None |
2017-05-10
|
05 | Mark Baushke | New version available: draft-ietf-curdle-ssh-modp-dh-sha2-05.txt |
2017-05-10
|
05 | (System) | New version approved |
2017-05-10
|
05 | (System) | Request for posting confirmation emailed to previous authors: curdle-chairs@ietf.org, Mark Baushke |
2017-05-10
|
05 | Mark Baushke | Uploaded new revision |
2017-04-14
|
04 | Mark Baushke | New version available: draft-ietf-curdle-ssh-modp-dh-sha2-04.txt |
2017-04-14
|
04 | (System) | New version approved |
2017-04-14
|
04 | (System) | Request for posting confirmation emailed to previous authors: curdle-chairs@ietf.org, Mark Baushke |
2017-04-14
|
04 | Mark Baushke | Uploaded new revision |
2017-04-12
|
03 | Daniel Migault | Changed document writeup |
2017-04-12
|
03 | Daniel Migault | Changed document writeup |
2017-04-12
|
03 | Daniel Migault | Notification list changed to Daniel Migault <daniel.migault@ericsson.com> |
2017-04-12
|
03 | Daniel Migault | Document shepherd changed to Daniel Migault |
2017-03-27
|
03 | Daniel Migault | IETF WG state changed to In WG Last Call from WG Document |
2017-03-27
|
03 | Mark Baushke | New version available: draft-ietf-curdle-ssh-modp-dh-sha2-03.txt |
2017-03-27
|
03 | (System) | New version approved |
2017-03-27
|
03 | (System) | Request for posting confirmation emailed to previous authors: curdle-chairs@ietf.org, Mark Baushke |
2017-03-27
|
03 | Mark Baushke | Uploaded new revision |
2017-03-06
|
02 | Mark Baushke | New version available: draft-ietf-curdle-ssh-modp-dh-sha2-02.txt |
2017-03-06
|
02 | (System) | New version approved |
2017-03-06
|
02 | (System) | Request for posting confirmation emailed to previous authors: curdle-chairs@ietf.org, Mark Baushke |
2017-03-06
|
02 | Mark Baushke | Uploaded new revision |
2016-09-13
|
01 | Mark Baushke | New version approved |
2016-09-13
|
01 | Mark Baushke | New version available: draft-ietf-curdle-ssh-modp-dh-sha2-01.txt |
2016-09-13
|
01 | Mark Baushke | Request for posting confirmation emailed to previous authors: "Mark D. Baushke" , curdle-chairs@ietf.org |
2016-09-13
|
01 | (System) | Uploaded new revision |
2016-09-12
|
00 | Mark Baushke | Request for posting confirmation emailed to previous authors: "Mark D. Baushke" , curdle-chairs@ietf.org |
2016-09-11
|
00 | Mark Baushke | New version available: draft-ietf-curdle-ssh-modp-dh-sha2-00.txt |