Re: [dns-dir] some comments on draft-os-ietf-sshfp-ecdsa-sha2-04.txt

[Ondřej Surý <[e-mail]>]

On 15. 2. 2012, at 21:21, Ralph Droms wrote:

> I have a couple of followups in line
> 
> Otherwise, is the DNS Directorate OK with rev -07 of this document?
> 
> - Ralph
> 
> On Jan 27, 2012, at 3:00 AM 1/27/12, Ondřej Surý wrote:
> 
>> Hi Peter,
>> 
>> On 4. 1. 2012, at 19:17, Peter Koch wrote:
>> 
>>> Hi Ondrej,
>>> 
>>> i came across another review of <draft-os-ietf-sshfp-ecdsa-sha2-04.txt>
>>> and would like to add some remarks.  I've copied the DNS Directorate
>>> for information.  Not sure what the status of the draft is - the
>>> datatracker confuses me by claiming 'wg document', but i do not see
>>> which WG?  Generally the draft looks like a good idea!
>>> 
>>> To start with some formalities, the header and abstract claim the draft
>>> updates RFC 4255. I would suggest it does not.  It updates two IANA
>>> registries defined and seeded by RFC 4255, but it does not (to my
>>> reading) change any content of RFC 4255.   If it were to update 4255,
>>> it should probably adjust the registry policies from "IETF consensus"
>>> as per RFC 2434 to "IETF Review" as per RFC 5226, but that's probably
>>> for another venue to discuss.
>> 
>> Fixed.  Sound reasonable.
>> 
>>> Second, the document aims at Standards Track and I do not see why.
>>> An IETF/IESG reviewed RFC would be sufficient.  Not saying it
>>> should be less than ST, but what's the purpose here?  Later serving
>>> as normative reference?
>> 
>> I am not aware of such thing as IESG reviewed RFC. RFC 2026 is no
>> help here.  Maybe you can point me to a reading material?
> 
> E.g., an Informational RFC would suffice.

I am fine with Informational, but is that in line with RFC 5226?  It misses
the information (while explicitly cited in RFC Required) and all cited
RFCs under "IETF Review" are Standards track.

>>> In section 3.2 the use of an ECDSA fingerprint is defined.  I could
>>> not find the description of the Fingerprint in RFC 5656.
>>> Furtheron it reads
>>> 
>>> ECDSA public key fingerprints MUST use the SHA-256 algorithm for the
>>> fingerprint as using the SHA-1 algorithm would weaken the security of
>>> the key.
>>> 
>>> First, could the claim 'would weaken the security' be substantiated
>>> (maybe by reference) a bit?  Second, what is the consequence, i.e.
>>> who is supposed to act on a violation? Is it the DNS implementation
>>> (hard to achieve with 'transparent' RR types), the DNS operator or
>>> the consuming entity?  I would suggest to reverse the logic here and
>>> only demand that a consuming party MUST ignore SHA-1 FPs for ECDSA.
>> 
>> Sounds reasonable, but if I were to reverse the login, it would also
>> mean that if there's an implementation which generates ECDSA with SHA-1
>> it wouldn't work for consuming party and it breaks the robustness
>> principle.
>> 
>> I want to say - if you create the FP use SHA-256, if you receive SHA-1
>> key then you may use it unless you also receive SHA-256.
> 
> Section 3.2 seems to have changed.  What was the ultimate resolution of this discussion point?

I have decided to drop the pairing requirement after GEN-ART review, see the related thread:
http://www.ietf.org/mail-archive/web/gen-art/current/msg06979.html

and after some iterations:
http://www.ietf.org/mail-archive/web/gen-art/current/msg07133.html

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[e-mail]    http://nic.cz/
 tel:[phone]       fax:[phone]
 -------------------------------------------