Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 06 Aug 2014 09:09:58 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-appsawg-nullmx-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Just curious - do we know or are we guessing that
this won't be an issue for DNSSEC (implementations)?
I've no info either way, so its purely curiosity,
really:-)

---

From: Barry Leiba <[email-masked]>
Date: Wed, 6 Aug 2014 12:29:41 -0400

> I've no info either way, so its purely curiosity,

I don't understand what might be an issue for DNSSEC
(implementations).  What are you thinking?

Barry

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Aug 2014 12:57:50 -0400

> I've no info either way, so its purely curiosity,

If it is, they're utterly broken.  I doubt anyone has tested, but it
would be wrong for an implementation to spit up on the RDATA like that.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Aug 2014 20:53:50 +0100

> (implementations).  What are you thinking?

I've seen code break when assumptions that to-be-signed
(sub)fields are non-zero length get changed. This'd be a
possible case like that.

I fully agree that its quite unlikely that much code
would break like that and I assume overwhelmingly unlikely
there's a protocol issue and I hope nobody goes to trouble
checking it out.

S.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 Aug 2014 13:53:14 -0700

> there's a protocol issue and I hope nobody goes to trouble

Dear Stephen,

John Klensin has already noted the possible confusion caused by the resource name.  The value is not null, but rather represents a pointer to root "."  John Levine argued changing its name after many years of unofficial references would be counter productive.

Regards,
Douglas Otis

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Aug 2014 22:33:43 +0100

Doug,

On 06/08/14 21:53, Douglas Otis wrote:
>>>> Just curious - do we know or are we guessing that this won't be
>>>> an issue for DNSSEC (implementations)? I've no info either way,
>>>> so its purely curiosity, really:-)
>>> 
>> I've seen code break when assumptions that to-be-signed (sub)fields
>> are non-zero length get changed. This'd be a possible case like
>> that.
>> 
>> I fully agree that its quite unlikely that much code would break
>> like that and I assume overwhelmingly unlikely there's a protocol
>> issue and I hope nobody goes to trouble checking it out.
> 
> Dear Stephen,
> 
> John Klensin has already noted the possible confusion caused by the
> resource name.  The value is not null, but rather represents a
> pointer to root "."  John Levine argued changing its name after many
> years of unofficial references would be counter productive.

Mine is a different non-issue. I'm fine with the name.

S.

> Regards, Douglas Otis

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Aug 2014 11:38:38 +0100

> (sub)fields are non-zero length get changed. This'd be a

In the null MX case the target field is one octet, not zero octets. From
the point of view of a DNSSEC signer the relevant field is the entire
RDATA which is priority+target i.e. 3 octets. If you want to try a DNSSEC
signer with a zero octet RDATA field, put an empty TXT record in your
zone.

There are no DNSSEC implications to the null MX draft.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: West or northwest becoming variable, 3 or 4, then becoming cyclonic 4
or 5, occasionally 6 later. Slight or moderate. Occasional rain. Moderate or
good.