(1)
There's a serious issue deeply buried in this draft,
draft-ietf-dnsext-dnssec-gost-06.
Let's start from a general PoV:
The signature algorithm used by this document targeted for PS is an
elliptical curve cryptography (ECC) algorithm.
Most international and national standards, including Standards Track
RFCs, have adopted the generic presentation formats for the parameters
to be passed in and out of the (software/hardware) 'black boxes'
implementing ECC originally specified in the SEC-1 Standard.
What matters for DNSSEC is the representation of ECC public keys.
These are points on an elliptic curve over a finite field.
In DNSEXT I had requested that this draft also make use of the
basic ECpoint format commonly used in other protocols and most
standards for the representation of its public keys in DNSSEC
resource records. This should further modularity and thus likely
increase software quality and hence security.
However, the authors have harshly rejected this call for uniformity,
based on a few specialized implementations where the implementers
apparently have not been aware of more than a decade of standardization
efforts for ECC.
I did not keep this discussion on namedroppers because IMHO this is
a question at the architectural level that needs to be dealt with in
the IETF at large.
I therefore repeat here my request to replace the ad-hoc representation
of the EC public keys in the draft with the ECpoint format described in
the SEC-1 standard; in particular, Algorithms 2.3.3 and 2.3.4 of SEC-1
describe the conversion of an abstract EC point into an octet string
and vice versa, respectively. These algorithms should be used to
encode/decode the wire format of the EC points used as publik keys.
The abstraction provided by these algorithms allows implementations
to use any internal representation of EC points they seem fit but
make use of an interface that is not different from that for other
EC algorithms.
Admittedly, the IETF had been lulled some time ago and missed putting
emphasis on homogenous interfaces when RFCs 4490 and 4491 have been
adopted, and these two RFCs suffer from a similar deficiency.
I have filed defect reports as Technical Errata against these RFCs
(EID=1884 and 1885, respectively) to raise awareness of this issue.
I expect that a document that seeks adoption on the Standards Track
does not violate current IETF Full Standards.
STD 13, RFC 1035 specifies the byte order of all numeric quantities
used on the wire in the DNS. The last paragraph of Section 2.3.2
is rather explicit in specifying network byte order:
"Similarly, whenever a multi-octet field represents a numeric
quantity the left most bit of the whole field is the most
significant bit. When a multi-octet quantity is transmitted the
most significant octet is transmitted first."
The document in LC, as it stands, introduces mixed endian-ness into
the DNS wire protocol. This is not explicit in the draft because it
for this purpose refers to another RFC that suffers from a similar
defect.
I strongly oppose to this violation of architectural principles
and request a change of the wire format specification in the draft.
(2)
I also concur with Steve and Paul that it is premature to have a
SHOULD implementation requirement for a combination of cryptographic
algorithms that arguably are less strong than the state-of-the-art
assumes, and that only recently have seen starting in-depth
discussion in the scientific cryptanalytical community.
We should wait until the translations of the old specifications
of the basic GOST algorithms into English have been published
on the Independent Submission stream (all three documents have
already advanced to RFC-EDITOR state this week) and then for the
world-wide international cryptanalytical community having had
sufficient time to scrutinize the fundamental algorithms (or find
[more] weeknesses therein) before we ever consider making SHOULD
or MUST implement requirements for such algorithms' support in
fundamental Internet protocols (like the DNS).
Reportedly there are serious concerns regarding the small block
size used in the GOST hash algorithm. It sounds strange in the
age of announced dawn of SHA-1 for digital signatures to step back
now that a global open effort is on its way (under the auspices
of NIST) for the development and adoption of a state-of-the-art,
next-generation hash standard (dubbed preliminarily "SHA-3").
This is not a concern of practical cryptanalytical threats against
(rather short-lived) DNSSEC, but of a general desire to get rid of
weaker algorithms in crypto-toolkits, in order to avoid their
accidental use (e.g. by misguided poor configuration or as a result
of downgrading attacks) in circumstances where it _does_ matter.
(3)
I also concur with Andrew that having different requirement levels
in a fundamental protocol that does not allow negotiation of
crypto-algorithms also causes severe deployability concerns.
This 'inability to negotiate' is not a defect of DNSSEC; it is
a fundamental property designed-in for efficiency and security:
the signatures on RRsets are presumed to be pre-calculated for
a DNS zone, loaded into the primary authoritative server and
distributed to its secondaries that (for security reasons)
do not have access to the signature private key(s). Caching
resolvers even more only store these RRsets with their digital
signatures and forward them to end system resolvers; they do not
have access to signing keys and cannot negotiate crypto-algorithms.
Regularly providing multiple signatures based on different algorithms
increases the size of DNSSEC-aware responses and thus is likely
to increase the trouble with broken systems that do not follow
many years old TCP/IP and DNS standards.
The most efficient use of DNSSEC is with trust chains from the root
down to the 'leaf' signed zones, all actively using a single family
of crypto-algorithms.
I personally would prefer letting the root signing effort settle
and first await fixing of many broken systems at large before
introducing new side effects potentially impacting the scalability
and stability of the global DNS infrastructure even more.
If we want to admit use of 'non-mainstream' crypto-algorithms
in DNSSEC for political or tactical reasons whatsoever (and
AFAICS, we almost have concurred to do that already), we should
do so with a salt of grain and should perhaps try to limit the
applicability of such "experiments" to special close environments.
Such "MAY implement" perhaps should be accompanied as well with
an IESG note emphasizing the concerns.
Having crypto-agility in standards and implementation is a valid
objective on its own, and it must be exercised from time to time
to validate correctness at all stages, but for fundamental Internet
infrastructure like the DNS, stability and homogenous universal
support of a common basic feature set is (at least!) equally
important !
Therefore, I would appreciate a "MAY implement" requirement for
the draft, combined with a strong warning that its applicability
should be restricted to environments where global verification
of such DNSSEC signatures is not an objective.
Best regards,
Alfred Hönes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah@xxxxxxxxx |
+------------------------+--------------------------------------------+
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf