Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt

[Phillip Hallam-Baker <[e-mail]>]

Rather than using the term 'strength' I suggest we use the term 'work factor'.

The term strength tends to be interpreted relative to the algorithm
concerned, 'what strength RSA key', it is not really defined as an
absolute measure.


Work factor using known best attack is much better defined. Although
there is always going to be a degree of slop since many attacks have
memory/CPu tradeoffs.


But all this is really outside the parameters of what DNSEXT should
have to concern itself with. What matters most in choice of
cryptographic algorithm is consistency. The attacker only needs to
break the weakest link in the chain. So if we have SHA3 in the DNSSEC
layer and MD5 in the S/MIME we are still vulnerable.


I would like to propose we change the model here. The IETF should get
out of the business for issuing DNSSEC code points for any algorithm
other than those which are mandatory to implement.

Mandatory to implement algorithms should be specified in RFCs that
apply to a collection of protocols. Working Groups would be free to
decide whether to specify their own algorithms or use the common
mandatory set. The advantage of using a common mandatory set being
that they would be subject to ongoing maintenance and revision.

So an implementation that offered DNSSEC with the 2012 crypto set
might specify RFC4043 + RFC 7xxx compliance.


All non-mandatory crypto would use ASN.1 OIDs to declare the algorithm
type. In the case of DNSSEC this would require an approach similar to
the one that the OID based CERT type uses. There would be a code point
reserved for identifying the algorithm by ASN.1 oid and a defined
mechanism for squeezing in the OID as a prefix to the crypto material.


Some people are going to complain about the lack of control here. But
that is worrying about the wrong problem. The only problems we should
be concerned with are interoperability and endorsement.

The only interoperability concern should be that applications that
support a common algorithm be able to use it to communicate. That
means that they all use the same code points to identify the same
algorithm. It is not a big concern to me as people who use non
standard crypto should know what to expect. It is their funeral, we
should not try to stop them attending.

The much bigger concern for me is endorsement. The problem with having
the IETF control the registry is that making an entry into the
registry implies an endorsement. Like it or not, the IETF has
effectively endorsed the use of GOST, a Soviet era crypto algorithm
that is being promoted for specific political reasons that I believe
to be contrary to the principles of an open Internet.

The fact that the OID registry is open and has no gating factor is a
good thing. No gate means no endorsement. If we had used ASN.1 OIDs to
identify algorithms there would be no RFC 5933, there would be no
mention of GOST in RFCs at all unless there was a decision to adopt it
as a mandatory to implement algorithm (which the GRU would not want in
any case since their whole purpose requires use of a different
algorithm).


On Wed, Jan 5, 2011 at 1:39 PM, Chris Thompson <[e-mail]> wrote:
> On Jan 5 2011, Edward Lewis wrote:
>
>> I'd like to see this stated in DNS terms - i.e., the notion of strength is
>> not one of them.
>>
>> I would suggest that
>>
>>  - the authoritative set of the DS record SHOULD include a DS RR for each
>> key that is of the same hash algorithm as is used in the key and MAY have
>> other hashes (and MAY even have only other hashes[1])
>>
>> [1] The parenthetical comment is redundant, put it there for emphasis.
>>
>>  - a validator SHOULD prefer the DS record of the same hash algorithm over
>> other hash algorithms for a key.
>
> You mean that a validator should prefer a digest type 1 (SHA-1) DS over
> a type 2 (SHA-256) DS if the key to be validated uses algorithm RSASHA1?
> This directly contradicts the SHOULD in RFC 4509 section 3, and also
> doesn't seem too sensible to me.
>
>>                                      Prefer means that it SHOULD be the
>> first tried and if it fails, the validator MAY declare failure without
>> examining the other applicable hash algorithms.  A validator MUST NOT
>> require that there be a hash of the same algorithm present, with require
>> meaning - if such a hash is absent, failure is not automatic.
>>
>> You may note that I spec "the same hash algorithm" because I don't know of
>> any way to say if one hash algorithm is stronger than the next.  I.e., bit
>> length might be an indicator but I bet it also isn't reliable.
>
> It's perfectly possible for an implementor, or an operator, to have
> opinions about this, though.
>
> --
> Chris Thompson               University of Cambridge Computing Service,
> Email: [e-mail]    New Museums Site, Cambridge CB2 3QH,
> Phone: [phone]       United Kingdom.
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>



-- 
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext