Subject: [dnsext] Report from chairs

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Jul 2010 17:39:23 -0400

Dear colleagues,                                                                
                                                                                
This is the DNSEXT Working Group status report from the Chairs.  As we
did for previous meetings, we are undertaking this report on the
mailing list rather than at the meeting.  Items not addressed in this
report should be part of the DNSEXT meeting at IETF 78.
                                                                                
Please be aware that, if there are issues you want to have addressed            
at the meeting and you feel they're not being addressed in this mail,           
you should not hesitate to raise them.                                          
                                                                                
Reminder: contributions to the WG are covered by the "Note Well"
statement, which can be found at
http://www.ietf.org/about/note-well.html.

1.  DRAFTS PUBLISHED

    draft-ietf-dnsext-dnssec-gost, RFC 5933

    draft-ietf-dnsext-axfr-clarify, RFC 5936

2.  DRAFTS IN OR PAST WG LAST CALL

    a.  RFC-Editor's queue

        draft-ietf-dnsext-dns-tcp-requirements

        draft-ietf-dnsext-dnssec-alg-allocation

    b.  IESG processing

        draft-ietf-dnsext-rfc3597-bis

        - waiting on AD action. 

    c.  WG LC
        
        draft-ietf-dnsext-dnssec-registry-fixes

        - This needed some further changes, it turned out, after the
          writeup was to be done.  They're in progress.

        draft-ietf-dnsext-rfc2672bis-dname

        - WGLC summary needed, and some document changes.  The
          shepherd dropped the ball on this.

3.  ACTIVE DRAFTS

draft-ietf-dnsext-dnssec-bis-updates

    - See discussion in meeting.

draft-ietf-dnsext-rfc2671bis-edns0

    - Needs new editor.  To be discussed in the meeting.

4.  EXPIRED DRAFTS

    - draft-ietf-dnsext-tsig-md5-deprecated

Is anyone still interested in this draft?  We have no movement on it.

5.  EXPERT REVIEW.  

    a.  OPEN EXPERT REVIEW REQUESTS

        RR code request for RR TYPE URI.  Assigned to Frederico Neves.

6.  OPEN WG ADOPTION REQUESTS

To be handled in the meeting (charter discussion).

7.  OTHER WG ADMINISTRATIVE ITEMS

    7.1 WG mailing list announced move

This will happen after the WG recharters, assuming it does.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Jul 2010 09:10:45 +0200

In your previous mail you wrote:

   4.  EXPIRED DRAFTS

   
=> there is a clear lack of support for this draft. I propose to give
the question to the security area so they should say if it is fine to
keep MD5 mandatory in an IETF protocol.

Two comments:
 - MD5 is used in a way (HMAC) it is not proved to be weak

 - the issue is MD5 it is forbidden for most (i.e., all I know of :-)
  certified cryptos so it is not possible to run a both certified (for
  the crypto) and conformant (to standards) TSIG tool.
  Now it seems to be only a formal concern...

Thanks

[email-masked]

---

From: Federico Lucifredi <[email-masked]>
Date: Mon, 26 Jul 2010 21:18:23 -0400

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

I support this draft and will be glad to put the footwork in to get it
passed if help is needed.

The issue seems overtly clear, Francis summed it up pretty well. I would
not underestimate the importance of security certification, so I would
be happy to help eliminating a paradox in that angle.

 Best -F

-- 

_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - http://www.lucifredi.com

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Jul 2010 12:11:21 -0400

My feeling is that we should shelve this and instead work on a key
exchange to compliment TSIG and then deprecate HMAC-MD5 for use in
that context.

The reason for this is that I think DNS-CURVE meets a real need, even
if the approach is not really sensitive to existing DNS code.
Suggesting a move to ECC is a good idea, suggesting transport layer
security is a good idea. Suggesting both in the same proposal is not.

For example, most enterprises use split DNS. They do not want their
internal DNS to be externally visible. But if (like me) the only
corporate facility you really need most of the time is email, you can
get perfectly adequate support by using SMTP and IMAP/POP over SSL.
Using IPSEC just to secure the DNS part is really quite painful. This
approach is much cleaner.

So given that we can expect to upgrade the whole TSIG area in an
important way, and given that there is no immediate security risk with
MD5, I think it makes sense to have one transition rather than two.

-- 
Website: http://hallambaker.com/

---

From: Francis Dupont <[email-masked]>
Date: Fri, 30 Jul 2010 18:56:44 +0200

My feeling is that we should shelve this

=> there is a consensus to do (shelve) this as today we can't find
a concrete need.

   and instead work on a key exchange to compliment TSIG

=> it already exists

   and then deprecate HMAC-MD5 for use in that context.

=> there is no technical reason to do that.
   
   The reason for this is that I think DNS-CURVE meets a real need

=> which need?

=> s/IPSEC/IPsec/

=> this is the (network) architecture security vs. the application
security. We have both even only the application one (TSIG/TKEY
and DNSSEC) is in the scope of the WG.

BTW I just have the feeling you don't know TKEY (RFC 2930).

Regards

---

From: Federico Lucifredi <[email-masked]>
Date: Fri, 30 Jul 2010 14:35:28 -0400

I disagree. The shelving of TSIG/MD5 makes sense on its own (albeit just
on stack certification grounds - we understand that MD5 is not
compromised in this use).

There are no transitions: providers who care about ("no MD5"
certifications will just be able to drop the support for this algorithm
and claim both compliance with certification and with RFC standard.

That is a simple, self-contained issue.

DNScurve, which I am not a detractor to, will be mired in the usual SEC
feuding for a time, regardless of outcome. Whichever side you may take
on it, you know that is inevitably going to be the case.

So, if a consensus can be reached on closing the smaller TSIG/MD5 issue
per draft-ietf-dnsext-tsig-md5, I would support that. And if the
original author is too busy to pursue it, I am willing to be the
"process monkey" who gets it done.

Could the chairs indicate what would be the next step for this draft.

Best -Federico

-- 

_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Sat, 31 Jul 2010 18:10:39 +0200

> compromised in this use).

For those whose native language is not English (and even those for whom it is) could we be more explicit about what precisely we mean by "shelve" in this thread?

In some contexts (and regions) "shelve" means "discard". In other context (and regions) "shelve" means "defer".

The meaning "to furnish or outfit with shelves" seems fairly universal, so apologies if that's what everybody is talking about.

Joe

---

From: Federico Lucifredi <[email-masked]>
Date: Sat, 31 Jul 2010 18:34:23 -0400

Hello Joe,

> The meaning "to furnish or outfit with shelves" seems fairly universal, so apologies if that's what everybody is talking about.

The objective of the draft is to deprecate MD5 as a TSIG HMAC algorithm.
 So shelve = retire in this context.

Best -Federico

--