Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)
draft-ietf-dnsext-dnssec-algo-signal-10

Note: This ballot was opened for revision 10 and is now closed.

(Sean Turner; former steering group member) Yes

Stephen's idea for text about an attacker exploiting client's that continue to use weak algorithms is a good idea.

(Ted Lemon; former steering group member) Yes

(Adrian Farrel; former steering group member) No Objection

(Barry Leiba; former steering group member) No Objection

(Benoît Claise; former steering group member) No Objection

(Brian Haberman; former steering group member) No Objection

This seems more like an Experimental document, but I will not stand in the way of the WG's view of its status.

(Jari Arkko; former steering group member) No Objection

(Joel Jaeggli; former steering group member) No Objection

(Martin Stiemerling; former steering group member) No Objection

(Pete Resnick; former steering group member) (was Discuss) No Objection

After discussion, it sounds like we're in agreement that some clarification on why a client MUST NOT send DAU/DHU/N3U if it's not setting DO would be a good thing, and some review of the other requirements language (in particular I suggest removing the "MUST send DO if you send DAU/DHU/N3U") is in order. I will work with the AD and authors to get this in before final approval.

Section 5, paragraph 2: s/DNSSEC-OK (OK)/DNSSEC-OK (DO)

(Richard Barnes; former steering group member) (was Discuss) No Objection

Why is there a need for separate DHU and N3U options?  It seems like if an implementation has a hash, then it has the has.  Are there real implementations for which these differ?

The combination algorithm for recursive resolvers seems backwards; it results in a list of algorithms such that at least one of the stub and recursive resolvers can validate.  It seems like you would want to know how many clients there are out there for which you MUST use a given algorithm.  Since either the stub or recursive resolver can fail the resolution on validation failure, you would thus want the intersection of the two lists, not the union.

(Stephen Farrell; former steering group member) No Objection

- abstract: the draft does stuff, it doesn't "set out to" do
stuff, at least not anymore

- section 4: not sure if the write-up is a bit out of date,
but personally I prefer the text in -10 of the draft to using
"[RFC525-422]" as given in the write-up

- section 7 or earlier: it'd be nice to point at the IANA
registries if those had stable URLs. I can never remember if
they do or not;-)

- section 8: I think you maybe ought add another security
consideration something like: 'If a client continues to
support a "broken" algorithm that would allow an attacker to
prepare bogus but cryptographically valid DNS responses then
advertising that fact via this extension could make it easier
for the attacker to exploit such a vulnerability. The
solution for such clients is to remove support for such
"broken" algorithms as soon as possible.'

- The secdir review [1] mentioned a possible DoS. I don't see
the threat myself, but it'd be good if the authors responded
to that, just in case. (Sorry if you've done that already and
I missed it.)

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03919.html

(Stewart Bryant; former steering group member) No Objection

There seemed to be a lot of UOFU TLAs and FLAs, hopefully these are all RFC Ed SEs.