RFC Errata System | 14 Dec 16:08 2015

[Errata Verified] RFC4034 (4552)

The following errata report has been verified for RFC4034,
"Resource Records for the DNS Security Extensions". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4034&eid=4552

--------------------------------------
Status: Verified
Type: Technical

Reported by: Ben Laurie <benl <at> google.com>
Date Reported: 2015-12-04
Verified by: Brian Haberman (IESG)

Section: Appendix B

Original Text
-------------
These groups are then added together, ignoring any carry bits.

Corrected Text
--------------
These groups are then added together with at least 32-bit precision,
retaining any carry bits.
The carry bits are then added to the result, and finally, only the lower
16 bits of the result are used as the key tag. Note that this means any
carries generated during the addition of the carry bits are ignored.
This, in turn, means that the keytag calculation is often the same as
reduction modulo 65535, but not always.
(Continue reading)

RFC Errata System | 4 Dec 13:01 2015

[Technical Errata Reported] RFC4034 (4552)

The following errata report has been submitted for RFC4034,
"Resource Records for the DNS Security Extensions".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4034&eid=4552

--------------------------------------
Type: Technical
Reported by: Ben Laurie <benl <at> google.com>

Section: Appendix B

Original Text
-------------
These groups are then added together, ignoring any carry bits.

Corrected Text
--------------
These groups are then added together with at least 32-bit precision,
retaining any carry bits.
The carry bits are then added to the result, and finally, only the lower
16 bits of the result are used as the key tag. Note that this means any
carries generated during the addition of the carry bits are ignored.
This, in turn, means that the keytag calculation is often the same as
reduction modulo 65535, but not always.

Notes
-----
Errata 2681 already proposes a fix to Appendix B, however the proposed fix is not quite clear. The first part
(Continue reading)

RFC Errata System | 9 Nov 17:12 2015

[Errata Held for Document Update] RFC4635 (4526)

The following errata report has been held for document update 
for RFC4635, "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm
Identifiers". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4635&eid=4526

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: Richard Hansen <rhansen <at> bbn.com>
Date Reported: 2015-11-09
Held by: Brian Haberman (IESG)

Section: 2

Original Text
-------------
      Optional       hamc-sha384

Corrected Text
--------------
      Optional       hmac-sha384

Notes
-----
Simple typo (transposed characters).

(Continue reading)

RFC Errata System | 9 Nov 10:00 2015

[Editorial Errata Reported] RFC4635 (4526)

The following errata report has been submitted for RFC4635,
"HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4635&eid=4526

--------------------------------------
Type: Editorial
Reported by: Richard Hansen <rhansen <at> bbn.com>

Section: 2

Original Text
-------------
      Optional       hamc-sha384

Corrected Text
--------------
      Optional       hmac-sha384

Notes
-----
Simple typo (transposed characters).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
(Continue reading)

RFC Errata System | 14 Oct 15:33 2015

[Errata Verified] RFC3110 (4502)

The following errata report has been verified for RFC3110,
"RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3110&eid=4502

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Mikko Rantanen <rfc-dog <at> hole.fi>
Date Reported: 2015-10-14
Verified by: Brian Haberman (IESG)

Section: 4

Original Text
-------------
conservative choice would be 65537 (F4, the fourth fermat number).

Corrected Text
--------------
conservative choice would be 65537 (F4, the fifth Fermat number).

Notes
-----
Numbering of Fermat numbers starts from zero. F4 and 65537 agree, but F4 is fifth Fermat number in the
series, not fourth.

(Continue reading)

RFC Errata System | 14 Oct 15:27 2015

[Technical Errata Reported] RFC3110 (4502)

The following errata report has been submitted for RFC3110,
"RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3110&eid=4502

--------------------------------------
Type: Technical
Reported by: Mikko Rantanen <rfc-dog <at> hole.fi>

Section: 4

Original Text
-------------
conservative choice would be 65537 (F4, the fourth fermat number).

Corrected Text
--------------
conservative choice would be 65537 (F4, the fifth Fermat number).

Notes
-----
Numbering of Fermat numbers starts from zero. F4 and 65537 agree, but F4 is fifth Fermat number in the
series, not fourth.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
(Continue reading)

Rick van Rein | 3 Sep 17:36 2015
Picon

New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02.txt

Hello,

I am working on an I-D that allocates a new RRtype in DNS, named
KREALM.  This RR is meant to store Kerberos realm descriptions in DNS;
this has hitherto been desired but impossible to do securely, but
nowadays the broad acceptance of DNSSEC permits this facility.

Please let me know if you have any feedback or questions!

Cheers,

Rick van Rein
for ARPA2.net

> A new version of I-D, draft-vanrein-dnstxt-krb1-02.txt
> has been successfully submitted by Rick van Rein and posted to the
> IETF repository.
>
> Name:		draft-vanrein-dnstxt-krb1
> Revision:	02
> Title:		Kerberos Realm Descriptors in DNS (KREALM)
> Document date:	2015-09-03
> Group:		Individual Submission
> Pages:		15
> URL:            https://www.ietf.org/internet-drafts/draft-vanrein-dnstxt-krb1-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-vanrein-dnstxt-krb1/
> Htmlized:       https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-vanrein-dnstxt-krb1-02
>
> Abstract:
(Continue reading)

Loganaden Velvindron | 7 Apr 07:25 2015
Picon
Gravatar

Updating Security Considerations in RFC 6762

Dear All,

Following the release of a security vulnerability by CERT:

https://www.kb.cert.org/vuls/id/550620

It might be worth considering updating RFC 6762 to advise implementors
against amplification attacks by rate-limiting responses or refusing
to reply to queries from outside local link.

Quote:

"Impact

An mDNS response to a unicast query originating outside of the local
link network may result in information disclosure, such as disclosing
the device type/model that responds to the request or the operating
system running such software. The mDNS response may also be used to
amplify denial of service attacks against other networks."

Feedback welcomed.
//Logan
C-x-C-c

--

-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

_______________________________________________
dnsext mailing list
(Continue reading)

Kumar Ashutosh | 30 Mar 11:04 2015
Picon

RFC 6604 Clarification

Hi

As per RFC 6604, section 3

      When an xNAME chain is followed, all but the last query cycle

      necessarily had no error.  The RCODE in the ultimate DNS response

      MUST BE set based on the final query cycle leading to that

      response.  If the xNAME chain was terminated by an error, it will

      be that error code.  If the xNAME chain terminated without error,

              it will be zero.

 

This is a little vague on two accounts:

1. What would be the error code if the server decides to curtail the CNAME chain after a certain length (say 20). Is it still success or do we indicate in some other way.

2. If the CNAME chain points to a Qname for which the auth server is non-authoritative (and recursion is disabled on the auth server.) The server in this case cannot get the response. A direct query for this Qname will result in SERV_FAIL. Should the auth server return SERV_FAIL in this case? Will resolvers respect answers with SERV_FAIL in RCODE and cache the partial response?

 

Can we put a clarification?

 

Thanks

Ashu

Program Manager | Windows Networking| DNS

 

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
Wessels, Duane | 21 Feb 02:19 2015
Picon

TTL on DS records

Section 5 of RFC 4034 says:

   The DS RR has no special TTL requirements.

While RFC 4035 Section 2.4 says:

   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset

Due the "SHOULD" I'm not sure this is worthy of an errata, but seems rather unfortunate.

Apologies if this is a previously known issue.

DW

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
RFC Errata System | 12 Jan 14:25 2015

[Errata Rejected] RFC6840 (4191)

The following errata report has been rejected for RFC6840,
"Clarifications and Implementation Notes for DNS Security (DNSSEC)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6840&eid=4191

--------------------------------------
Status: Rejected
Type: Editorial

Reported by: Edward Lewis <edward.lewis <at> icann.org>
Date Reported: 2014-12-02
Rejected by: Brian Haberman (IESG)

Section: 5.11

Original Text
-------------
...

A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  The
      zone MUST also be signed with each algorithm (though not each key)
      present in the DNSKEY RRset.  

Corrected Text
--------------
A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  Each
      authoritative RRset in the zone MUST be signed with each 
      algorithm (though not each key) present in the DNSKEY RRset.  

Notes
-----
Zones aren't signed (per se), the data sets within them are.  But not cut point (NS) and glue.
 --VERIFIER NOTES-- 
 This erratum is being rejected as the nomenclature being updated is understood within the community and is
used in other DNSSEC specifications.  

--------------------------------------
RFC6840 (draft-ietf-dnsext-dnssec-bis-updates-20)
--------------------------------------
Title               : Clarifications and Implementation Notes for DNS Security (DNSSEC)
Publication Date    : February 2013
Author(s)           : S. Weiler, Ed., D. Blacka, Ed.
Category            : PROPOSED STANDARD
Source              : DNS Extensions
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext


Gmane