Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records
draft-os-ietf-sshfp-ecdsa-sha2-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Sean Turner |
2012-02-29
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-02-29
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2012-02-28
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-02-22
|
07 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2012-02-22
|
07 | (System) | IANA Action state changed to In Progress |
2012-02-21
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2012-02-21
|
07 | Amy Vezza | IESG has approved the document |
2012-02-21
|
07 | Amy Vezza | Closed "Approve" ballot |
2012-02-21
|
07 | Amy Vezza | Approval announcement text regenerated |
2012-02-21
|
07 | Amy Vezza | Ballot writeup text changed |
2012-02-16
|
07 | Cindy Morgan | Removed from agenda for telechat |
2012-02-16
|
07 | Cindy Morgan | State changed to Approved-announcement to be sent from IESG Evaluation. |
2012-02-16
|
07 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2012-02-16
|
07 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2012-02-15
|
07 | Peter Saint-Andre | [Ballot comment] It might be helpful to mention that line breaks are not significant in the examples. |
2012-02-15
|
07 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2012-02-15
|
07 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
2012-02-15
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2012-02-14
|
07 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2012-02-14
|
07 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2012-02-14
|
07 | Sean Turner | [Ballot discuss] Curious if there ought to be a stronger constraint about not using SHA-1 on ecdsa-sha2-* public keys? If the implementations are going to … [Ballot discuss] Curious if there ought to be a stronger constraint about not using SHA-1 on ecdsa-sha2-* public keys? If the implementations are going to need to support SHA2 algs to process the signatures won't they also need it to process the fingerprint (i.e., if you're verifying the fingerprint to use the key then you're going to need to support the non-SHA-1 alg anyway)? To take it a bit further, why wouldn't you define the SHA-384/512 algs too and link them to the type ecdsa-sha2-* public key? |
2012-02-14
|
07 | Sean Turner | [Ballot discuss] Curious if there ought to be a stronger constraint about not using SHA-1 on ecdsa-sha2-* public keys? If the implementations are going to … [Ballot discuss] Curious if there ought to be a stronger constraint about not using SHA-1 on ecdsa-sha2-* public keys? If the implementations are going to need to support SHA2 algs to process the signatures won't they also need it to process the fingerprint (i.e., if you're verifying the fingerprint to use the key then you're going to need to support the non-SHA-1 alg anyway)? To take it a bit further, why wouldn't you define the SHA-384/512 algs too and link them to the type ecdsa-sha2-* public key? RSA/DSA you can't really do this because the hash alg's not in the key type. |
2012-02-14
|
07 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded |
2012-02-13
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2012-02-13
|
07 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2012-02-13
|
07 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2012-02-12
|
07 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-29
|
07 | Stephen Farrell | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup. |
2012-01-29
|
07 | Stephen Farrell | Placed on agenda for telechat - 2012-02-16 |
2012-01-29
|
07 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2012-01-29
|
07 | Stephen Farrell | Ballot has been issued |
2012-01-29
|
07 | Stephen Farrell | Created "Approve" ballot |
2012-01-27
|
07 | (System) | New version available: draft-os-ietf-sshfp-ecdsa-sha2-07.txt |
2012-01-27
|
06 | (System) | New version available: draft-os-ietf-sshfp-ecdsa-sha2-06.txt |
2012-01-27
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2012-01-27
|
05 | (System) | New version available: draft-os-ietf-sshfp-ecdsa-sha2-05.txt |
2012-01-04
|
07 | Stephen Farrell | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead. |
2012-01-03
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-12-21
|
07 | Amanda Baber | IANA understands that, upon approval of this document, there are two IANA Actions which must be completed. First, in the SSHFP RR Types for public … IANA understands that, upon approval of this document, there are two IANA Actions which must be completed. First, in the SSHFP RR Types for public key algorithms registry in the DNS SSHFP Resource Record Parameters registry located at: http://www.iana.org/assignments/dns-sshfp-rr-parameters/dns-sshfp-rr-parameters.xml a value is to be added to the registry as follows: Value: 3 Description: ECDSA Reference: [ RFC-to-be ] Second, in the SSHFP RR types for fingerprint types registry in the DNS SSHFP Resource Record Parameters registry located at: http://www.iana.org/assignments/dns-sshfp-rr-parameters/dns-sshfp-rr-parameters.xml a value is to be added to the registry as follows: Value: 2 Description: SHA-256 Reference: [ RFC-to-be ] IANA understands that these two actions are the only ones required to be completed upon approval of this document. |
2011-12-15
|
07 | Francis Dupont | Request for Last Call review by GENART Completed. Reviewer: Francis Dupont. |
2011-12-12
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Dave Cridland |
2011-12-12
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Dave Cridland |
2011-12-08
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2011-12-08
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2011-12-06
|
07 | Amy Vezza | Last call sent |
2011-12-06
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (Use of SHA-256 Algorithm with RSA, DSA and ECDSA in SSHFP Resource Records) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Use of SHA-256 Algorithm with RSA, DSA and ECDSA in SSHFP Resource Records' as a 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 2012-01-03. 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 updates RFC 4255, which defines a DNS resource record - SSHFP that contains a standard SSH key fingerprint used to verify Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). This document defines additional options supporting Secure Shell (SSH) public keys using the Elliptic Curve Digital Signature Algorithm (ECDSA) and the use of fingerprints computed using the SHA- 256 message digest algorithm in SSHFP resource records. The file can be obtained via http://datatracker.ietf.org/doc/draft-os-ietf-sshfp-ecdsa-sha2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-os-ietf-sshfp-ecdsa-sha2/ No IPR declarations have been submitted directly on this I-D. |
2011-12-05
|
07 | Stephen Farrell | Last Call was requested |
2011-12-05
|
07 | Stephen Farrell | State changed to Last Call Requested from Publication Requested. |
2011-12-05
|
07 | Stephen Farrell | Last Call text changed |
2011-12-05
|
07 | (System) | Ballot writeup text was added |
2011-12-05
|
07 | (System) | Last call text was added |
2011-12-05
|
07 | (System) | Ballot approval text was added |
2011-12-05
|
07 | Stephen Farrell | PROTO write up from Elwyn (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed … PROTO write up from Elwyn (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Elwyn Davies (elwynd@googlemail.com) I have personally reviewed the document and believe that it is ready for the IESG. (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed in the saag working group and was sent to to the secsh wg (concluded) mailing list. It has received some support in both lists. The document can be viewed as 'uninteresting' since it is 'merely' adding one code point to two registries. However it does 'join up the dots' in one case by filling in a hole that was missed when ECDSA public key support was added to SSH (RFC 6090) and provides a digest algorithm with stronger security to overcome recently identified problems the only previously supported algorithm (SHA-1). (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No, the draft only updates IANA registries for SSHFP RRType to match the algorithm support in the SSH protocol, which was updated separately. (1.d) Does the Document Shepherd have any specific concerns or issues 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 interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? The community has previously demonstrated that in the event of provable weakness problems with security algorithms, it is important to invoke the algorithm flexibility of existing protocols and provide stronger algorithms as necessary. SHA-256 is generally agreed to be an appropriate choice for a next generation digest algorithm after problems were identified with SHA-1. (1.f) 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 entered into the ID Tracker.) No discontent has been expressed. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The draft satisfies all ID nits. No other formal review criteria are relevant. (1.h) Has the document split its references into normative and informative? 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 strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. It does split the references appropriately. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA consideration section exists and is consistent. The reservations are requested in appropriate IANA registries and they are clearly identified. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: This document updates RFC 4255, defining how to provide fingerprints for Secure Shell (SSH) Elliptic Curve Digital Signature Algorithm (ECDSA) public keys, as per RFC 6090, and to use the SHA-256 manifest digest algorithm for public key fingerprints in SSHFP Resource Records. These algorithms have been already added into the Secure Shell protocol and this document adds support for the newly supported algorithms in the DNS SSHFP Resource Records. There is an existing implementation available as a patch for OpenSSH that allows OpenSSH to use the new SSHFP capabilities. This patch has been provided by the author of this document and it is available under the same licensing terms as OpenSSH. |
2011-12-05
|
04 | (System) | New version available: draft-os-ietf-sshfp-ecdsa-sha2-04.txt |
2011-12-05
|
03 | (System) | New version available: draft-os-ietf-sshfp-ecdsa-sha2-03.txt |
2011-12-01
|
07 | Stephen Farrell | Elwyn Davies is the document shepherd Elwyn Davies |
2011-12-01
|
07 | Stephen Farrell | State Change Notice email list has been changed to ondrej.sury@nic.cz, draft-os-ietf-sshfp-ecdsa-sha2@tools.ietf.org, elwynd@googlemail.com from ondrej.sury@nic.cz, draft-os-ietf-sshfp-ecdsa-sha2@tools.ietf.org |
2011-11-28
|
02 | (System) | New version available: draft-os-ietf-sshfp-ecdsa-sha2-02.txt |
2011-11-23
|
01 | (System) | New version available: draft-os-ietf-sshfp-ecdsa-sha2-01.txt |
2011-11-23
|
07 | Stephen Farrell | Setting stream while adding document to the tracker |
2011-11-23
|
07 | Stephen Farrell | Stream changed to IETF from |
2011-11-23
|
07 | Stephen Farrell | Draft added in state Publication Requested |
2011-06-16
|
00 | (System) | New version available: draft-os-ietf-sshfp-ecdsa-sha2-00.txt |