Subject: [saag] dnssec with ecdsa in the wild, very wild

From: Randy Bush <[email-masked]>
Date: Tue, 04 Nov 2014 11:47:07 +0000

moving to newer protocols is such a simple and rigorous experience

< with permission >
From: Geoff Huston <[email-masked]>
http://www.potaroo.net/presentations/2014-11-01-ecc.pdf

randy

---

From: ianG <[email-masked]>
Date: Tue, 04 Nov 2014 13:03:25 +0000

> http://www.potaroo.net/presentations/2014-11-01-ecc.pdf

If I read it right, which I probably don't, they measured a 23.6% ECDSA
validation failure rate, apparently due to IPR issues.

What I lack is the relevant starting point for ECDSA in DNS so we can
estimate the circumference of the OODA loop.

When did the RFC start work?  When did it get out the gate?

iang

---

From: Tony Finch <[email-masked]>
Date: Tue, 4 Nov 2014 14:42:35 +0000

> validation failure rate, apparently due to IPR issues.

Most of that is correctly working lack of support for ECDSA, which is sad
for us though not disruptive for the users. More worrying is the 1.6% of
users whose resolvers apparently treated the domain as bogus.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking: Northeast 7 to severe gale 9 decreasing 5 or 6 later. Rough or very
rough. Showers. Good.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 4 Nov 2014 15:55:10 +0000

> users whose resolvers apparently treated the domain as bogus.

FWIW, "unbound" versions without ECDSA support correctly treats
such domains as unsigned.  Also, for example, the DS RRs below
are signed by .net and thus validated by Google's public resolver:

    $ dig +noall +comment +ans +ad -t ds <censored>.net @8.8.8.8
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39125
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

    ;; ANSWER SECTION:
    <censored>.net.             21571   IN      DS      45769 14 2 69B3EB826977CEE1254AAC16A5EBA8F7703AE07FFA64975F8216374F E206FD59
    <censored>.net.             21571   IN      DS      51069 14 2 2B0D14AB811961026F12F0F469BBDFE6C5B19B20CEB13FC711D045A9 E8AAFD02

While the associated DNSKEY RR's are ECDSA signed, and not validated
by Google's resolver.

    $ dig +noall +comment +ans +ad -t dnskey <censored>.net @8.8.8.8
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 216
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

    ;; ANSWER SECTION:
    <censored>.net.             3599    IN      DNSKEY  256 3 14 eA6gtaxCmBSiMnvms3ikMHg2VzEFhc2sMWBPeEasBma71LE+JJEaWKts 3aidPjBiGrzwJxkS7PKhiUrI0v3OnSHq6WEr6QIaX/puxolbS56nrNGZ VTV7Mez3LxdCKtoR
    <censored>.net.             3599    IN      DNSKEY  257 3 14 /MgAOGYW1xmzImUc72xPxBJoKXoya3RExpljghgSYtS/XlfRohY+xECL bEHtIil6FkdJvhzXeAkNVp6Lu4lxnDlOIIz8sLlxpkUHaDuWEQI0tEjn YjG7qgwElpbi4qc1
    <censored>.net.             3599    IN      DNSKEY  257 3 14 zOmrgji5nLGZ11t+p2tQVPDiHqybpIw6UsGWeRIHmcJjtIVEnaPrJbZA N1Nkup3tlLM05DUwnSRp35NTZUS4LnSa8wvQmdgOUjfpxJd9gq3l11vx SgPp3F6ocEXRxBH3
    <censored>.net.             3599    IN      DNSKEY  256 3 14 LPa2EbmvyTe3dxXPL4p6j+deQBG27yeN7w35lGIQkASzDXx9FLH+z5ML l2Wh+zAESkHOOeZxgGDRBEiksx7yJSQH9vZQ0xLYh4OSenOT2wj1q0tE OkLjgn73Avhw1E8F

Bleeding edge deployments should also publish RSA/SHA1 or RSA/SHA256
keys along with the less widely implemented algorithm of their
choice.

Because DNSSEC key are published unilaterally, and not subject to
interactive negotiation, the set of algorithms that are not yet
deprecated needs to be kept relatively short at any given time,
with clear guidance on which set "MUST" be supported by resolvers,
and which are aspirational future "MUST"s as well as a set that
are aspirational future "SHOULD NOT"s.

Thus it seems we presently have a few algorithms too many, and
should stop adding new ones until some of the older ones are retired.

-- 
	Viktor.

---

From: ianG <[email-masked]>
Date: Tue, 04 Nov 2014 16:06:43 +0000

> I'm not familiar with the terminology you are using here so I cannot parse 
> "estimate the circumference of the OODA loop".

Ah Apologies.  Let me explain.

The OODA loop is from Col. Boyd [0]:

      Observe, Orient, Decide, Act.

Boyd was a post-WWII American military thinker who proposed that battle
went through a response loop.  His claim was that the fighter with the
tighter loop could out turn the other, and win the day.  His explanation
resonated broadly, and his own work fed into the F16, being the smaller,
lighter and tighter plane fielded in those days against heavier slower
adversaries.

The OODA loop turns out to apply broadly to many competitive and attack
situations [1].  In Internet security, we can look at the way attackers
evolve their attacks, and the hint seems to be that they can turn in the
order of a month.

In contrast, if the defender is stuck on standards-based,
library-deployed responses, his OODA loop can be measured in years...
Recently, we saw the renegotiation bug which I guessed at about a 3.5
year response to 80% deployment of fixes, whereas an exploit were
demonstrated (not used) against Twitter within 2 months [2].

(I should also measure the response to Heartbleed and Poodle, but there
aren't that many hours in the day, and winter is coming.)

The IETF standards effort can be considered as responding to some of
these threats to Internet security, and is part and parcel of why we
have such a long OODA response loop.

iang

[0] http://financialcryptography.com/mt/archives/000991.html
[1] https://en.wikipedia.org/wiki/OODA_loop
[2] http://financialcryptography.com/mt/archives/001210.html