Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

[Matthijs Mekking]

On 27-06-17 14:28, Dick Franks wrote:
> 
> On 26 June 2017 at 15:30, Matthijs Mekking  > wrote:
> 
> 
> 
> On 26-06-17 13:29, Dick Franks wrote:
> 
> You misunderstood: Variable length in octets, but not variable in
> number of RDATA elements
> 
> 
> I did.
> 
> Am I correct in thinking that you want some acknowledgement that 4
> fields exist, but do not really care what the final item is?

RFC 7344 specifies that the CDS RDATA format is the same as DS RDATA
format. RFC 4034 speficies the DS RDATA format contains 4 fields. So by
definition the CDS RDATA contains 4 fields. Same logic applies for
DNSKEY/CDNSKEY.

I suggested indeed one time that we should ignore the Digest (or Public
Key in case of CDNSKEY) if Algorithm is 0, but that is unrelated to this
issue. Since "0" is not valid base64, I would like to see this erratum
accepted to fix the notation in RFC 8078.

Best regards,
  Matthijs


> So an implementer has little choice but to make CDS/CDNSKEY work
> in accordance with the standard as written until IESG approves
> something else.
> 
> 
> Sure, but that is why we are discussing it, not?
> 
> 
> That is what we should be discussing, but this erratum seems to be
> steering us along a road full of potholes that I certainly do not want
> to fall into. IMHO this is based on a misunderstanding of your "mandated
> notation" argument.
>  
>  
> 
> And when that something else arrives, users will be mightily
> upset if RFC8078 CDS/CDNSKEY suddenly stops working, so the code
> will need to cope with both versions.  The only realistic way to
> achieve that is to determine the entire content of the DELETE
> CDS/CDNSKEY from the zero algorithm field. Beyond that, the
> content of the "mandated notation" is irrelevant because it can
> be left unparsed.
> 
> 
> My first suggestion for the draft was indeed: In case the DNSSEC
> algorithm is 0, the Digest/Public Key MUST be ignored.
> 
> 
> I would go further, and say that all fields (except algorithm) MUST be
> ignored
> 
>  
> 
> But there were concerns that if someone mistyped the algorithm field
> the DS accidentally gets removed. So now the RFC says that the
> contents of the CDS or CDNSKEY RRset MUST contain one RR and the "0
> [0,3] 0 0" notation is mandated.
> 
> 
> The one RR requirement is not in dispute.
> 
> Let us make a start with the following 3 use cases, to see if we can
> come to some common understanding of what we are trying to achieve.
> 
> (1)  CDS arrives on the wire
> 
> cds.example. IN CDS  \# 5 1234 00 56 78  ; silly numbers in most fields
> 
> RDATA as received:
> 
>  'algorithm' => 0,
>  'digestbin' => 'x',
>  'digtype' => 86,
>  'keytag' => 4660,
> 
> Algorithm = 0, so presentation format uses "RFC8078 mandated notation":
> 
> cds.example.INCDS0 0 0 0

> (2)  DELETE CDS read from zone file, transmitted to parent
> 
> cds.example.INCDS0 0 0 0
> 
> Algorithm = 0, so this is a DELETE CDS.
> 
> Check that RDATA string matches "mandated notation".
> 
> Coerce all RDATA numerical fields to zero, digest empty.
> 
> Transmitted CDS RR:
> 
> cds.example. IN CDS  \# 4  00 00
> 
> 
> (3)  Normal CDS read from zone file, but with accidental 0 in algorithm
> field
> 
> cds.example. CDS 6485 0 1 2bb183af5f22588179a53b0a98631fad1a292118
> 
> Algorithm = 0, so this is apparently a DELETE CDS.
> 
> Exception raised - RDATA does not match "mandated notation"
> 
> DS saved from accidental deletion:-)
> 
> 
> Obviously, similar logic applies to CDNSKEY.
> 
> --Dick

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] FW: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-05.txt

[Daniel Migault]

Hi, 

Please find a new version for the DNSSEC validators requirements. Our 
understanding is that the current version has considered all received comments.

We appreciate your comments and feed backs. 

Yours, 
Daniel 

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Wednesday, June 28, 2017 11:46 AM
To: Edward Lewis ; Daniel Migault 
; Dan York ; y...@isoc.org 

Subject: New Version Notification for 
draft-mglt-dnsop-dnssec-validator-requirements-05.txt


A new version of I-D, draft-mglt-dnsop-dnssec-validator-requirements-05.txt
has been successfully submitted by Daniel Migault and posted to the IETF 
repository.

Name:   draft-mglt-dnsop-dnssec-validator-requirements
Revision:   05
Title:  DNSSEC Validators Requirements
Document date:  2017-06-27
Group:  Individual Submission
Pages:  13
URL:
https://www.ietf.org/internet-drafts/draft-mglt-dnsop-dnssec-validator-requirements-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/
Htmlized:   
https://tools.ietf.org/html/draft-mglt-dnsop-dnssec-validator-requirements-05
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mglt-dnsop-dnssec-validator-requirements-05
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-mglt-dnsop-dnssec-validator-requirements-05

Abstract:
   DNSSEC provides data integrity and source authentication to a basic
   DNS RRset.  Given a RRset, a public key and a signature, a DNSSEC
   validator checks the signature, time constraints, and other, local,
   policies.  In case of mismatch the RRSet is considered illegitimate
   and is rejected.

   Accuracy in DNSSEC validation, that is, avoiding false positives and
   catching true negatives, requires that both the signing process and
   validation process adhere to the protocol, which begins with external
   configuration parameters.  This document describes requirements for a
   validator to be able to perform accurate validation.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

[Ondřej Caletka]

Hello,

I have an erratum to this reported erratum. This proposed corrected
paragraph:

>Strictly speaking, the CDS record could be "CDS X 0 X 00" as only the
>DNSKEY algorithm is what signals the DELETE operation, but for
>clarity, the "0 0 0 00" notation is mandated -- this is not a
>definition of DS digest algorithm 0.  The same argument applies to
>"CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by
>[RFC4034], Section 2.1.2.

should actually look like this (difference is the first CDS example):

>Strictly speaking, the CDS record could be "CDS X 0 X X" as only the
>DNSKEY algorithm is what signals the DELETE operation, but for
>clarity, the "0 0 0 00" notation is mandated -- this is not a
>definition of DS digest algorithm 0.  The same argument applies to
>"CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by
>[RFC4034], Section 2.1.2.

Otherwise, the statement "only the DNSKEY algorithm is what signals the
DELETE operation" would not make any sense.

--
Regards,
Ondřej Caletka





smime.p7s
Description: Elektronicky podpis S/MIME
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

[Ondřej Caletka]

Hello,

>Dick Franks:
>> What is needed now is methodical use-case analysis based on RFC8078 as it
>> exists now and tested against a real implementation.  The time to rewrite
>> the RFC will come if/when we discover we are unable to live with it. We
>> have not reached that point yet.
Mark Andrews:
> I can't go from RFC8078 to a working implementation because the
> existing description is not clear enough to do it.  I don't think
> anyone can do it.
> 
> With the proposed errata fix I could write code.  For CDS the RRset
> is a single RR with a rdata of 0x00 0x00 0x00 0x00 0x00.  For CDNSKEY
> the RRset is a single RR with a rdata of 0x00 0x03 0x00 0x00 0x00.

I have a confirmation from the real implementation of RFC8078 in the .CZ
domain registry (cc jaromir.talir) that their understanding of CDNSKEY
DELETE operation is exactly the set of RDATA quoted by Mark Andrews,
which translates to the presentation form CDNSKEY 0 3 0 AA==

I don't think there is a big room to interpret RFC 8078 differently,
since it does not define any new presentation/wire format for
CDS/CDNSKEY record. Therefore, even future versions of software that
(de-)serializes RRs between wire and presentation format will have
issues if there are not all fields mandated by RFC 4034 present in the
rdata.

--
Ondřej Caletka



smime.p7s
Description: Elektronicky podpis S/MIME
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-06.txt

[Russ Housley]

Please correct this typo:
  s/certs for such names/certificates for such names/


> On Jun 27, 2017, at 8:57 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
> 
>Title   : Special-Use Domain Names Problem Statement
>Authors : Ted Lemon
>  Ralph Droms
>  Warren Kumari
>   Filename: draft-ietf-dnsop-sutld-ps-06.txt
>   Pages   : 28
>   Date: 2017-06-27
> 
> Abstract:
>   The Special-Use Domain Names IANA registry policy defined in RFC 6761
>   has been shown through experience to present unanticipated
>   challenges.  This memo presents a list, intended to be comprehensive,
>   of the problems that have been identified.  In addition it reviews
>   the history of Domain Names and summarizes current IETF publications
>   and some publications from other organizations relating to Special-
>   Use Domain Names.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-06
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sutld-ps-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-06
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop