Re: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt

[Dick Franks]

On Tue, 2 Jan 2024 at 07:34, zuop...@cnnic.cn  wrote:
>8

>  This draft suggests a lightweight and backward-compatible mechanism to 
> mitigate the risk of these attacks.
>
>  Any comments are welcome!
>

The proposal contains internal inconsistencies and contradictions
which need to be addressed:

  4.2.  Responding to a request

 DDC request option should be responded by a DDC-aware authoritative
 server.  For a DDC-not-aware server, the presence of a DDC request
 option is ignored and the server responds as if no DDC request option
 had been included in the request.


  4.3.  Processing Responses

 If the client(usually a Recursive server) is expecting the response
 to contain a DDC respond option and it is missing, the response MUST
 be discarded.

The client has no way of knowing in advance if the server is DDC-aware.
Considering 4.2, merely sending a DDC request does not create any
reliable expectation that there will be a corresponding DDC response.



   Regarding the processing of the DNS delegation respond option by a
   recursive server, there are 4 possibilities:

   (1)  The client is expecting the response to contain a DDC respond
option and it is missing.  In this case, the client processes
the response as normal and does not implement DNS delegation
confirmation.

This contradicts the MUST in the opening paragraph of 4.3


--rwf

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

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Dick Franks]

On Tue, 20 Jun 2023 at 22:20, Roy Arends  wrote:
>8

>
> The change was from -03 to -04 and discussed in the WG IIRC. The specific 
> sentence your refer to was a lingering oversight in the changes from -03 to 
> -04. I have consulted many developers on this, and so far I had no push back.
>
> > explicitly querying the authoritative server for the appropriate
> > report channel to a dependence on authoritatives attaching an
> > (unsolicited) EDNS0 report channel option to each and every query.
>
> No.
>
> An authoritative server includes the option if configured to do so AND if it 
> has the a non-null domain name configured as the reporting channel. It will 
> then reply to each query. This is IMHO better than having a resolver include 
> the option each and every time. Note that resolvers will ignore options that 
> are unknown to them.

6.2.  Authoritative server specification
Contains not a shred of normative language saying any of that.

The preliminary waffle in the overview could apply to either the
solicited or unsolicited regime.

> > I withdraw my earlier statement that the document is almost ready.
> > Now, clearly it is not.
>
> I hear you. I do not agree though, and I hope you reconsider
Not without further work

--rwf

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

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Dick Franks]

Correction

 Deleting that one sentence changes the meaning of the proposal from
 explicitly querying the authoritative server for the appropriate
 report channel to a dependence on authoritatives attaching an
-(unsolicited) EDNS0 report channel option to each and every query.
+(unsolicited) EDNS0 report channel option to the reply for each and
every query.

--Dick

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

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Dick Franks]

On Tue, 20 Jun 2023 at 12:21, Roy Arends  wrote:
>8

> > On 20 Jun 2023, at 12:14, Willem Toorop  wrote:
>8

> > I have one nit.
> >
> > In the Example in section 4.2., a request still "includes an empty ENDS0 
> > report channel". The third paragraph of that same section states something 
> > similar: "As support for DNS error reporting was indicated by a empty EDNS0 
> > report channel option in the request". But Section 6.1. Reporting Resolver 
> > Specification states: "The EDNS0 report channel option MUST NOT be included 
> > in queries."
> >
> > I believe the text in the Example section is a left over from an earlier 
> > version and should be corrected.
>
> Ah, yes, I will remove that sentence completely!

WGLC is supposed to be a review, nit-picking and clarification process.

Deleting that one sentence changes the meaning of the proposal from
explicitly querying the authoritative server for the appropriate
report channel to a dependence on authoritatives attaching an
(unsolicited) EDNS0 report channel option to each and every query.

That is a fundamental change to the document, and certainly not a nit-pick.

I withdraw my earlier statement that the document is almost ready.
Now, clearly it is not.


--rwf

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

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Dick Franks]

On Tue, 20 Jun 2023 at 12:14, Willem Toorop  wrote:
>8

> In the Example in section 4.2., a request still "includes an empty ENDS0
> report channel". The third paragraph of that same section states
> something similar: "As support for DNS error reporting was indicated by
> a empty EDNS0 report channel option in the request".

The only way to discover the destination for the error report is to
repeat the original failed query adding the empty EDNS0 report channel
option.  The subsequent error report relates to the original failed
query and in no way depends upon the failure or otherwise of the
second attempt.

> ... But Section 6.1.
> Reporting Resolver Specification states: "The EDNS0 report channel
> option MUST NOT be included in queries."

-   The EDNS0 report channel option MUST NOT be included in queries.
+   The EDNS0 report channel option MUST NOT be included in report queries.


--rwf

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

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Dick Franks]

All

I have reviewed the document which appears to be almost ready for
submission to IESG.


Subsection 6.1.1 uses QNAME to refer to two different entities.
The opening sentence needs to say nothing more than that the report
query is a concatenation of the listed items.
The conflicting usage is easily resolved by rewording the third item.

 6.1.1.  Constructing the Report Query

The QNAME for the report query is constructed by concatenating the
-   following elements, appending each successive element in the list to
-   the right-hand side of the QNAME:
+   following elements:

*  A label containing the string "_er".

*  The QTYPE that was used in the query that resulted in the extended
   DNS error, presented as a decimal value, in a single DNS label.

-   *  The QNAME that was used in the query that resulted in the extended
-  DNS error.  The QNAME may consist of multiple labels and is
-  concatenated as is, i.e. in DNS wire format.
+   *  The list of non-null labels representing the query which is the
+  subject of the DNS error report.

*  The extended DNS error, presented as a decimal value, in a single
   DNS label.


Regards

Dick Franks


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

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Dick Franks]

On Thu, 16 Feb 2023 at 01:14, Masataka Ohta
 wrote:

>8

>
> So, there is no specification to mention queries with QDCOUNT>1,
> either informatively, optionaly or normatively.
>
> Then, 3425 titled "Obsoleting IQUERY" updated 1035.
>
> As such, after 3425, QDCOUNT nomatively must always be 1.
>

The last statement is informatively and normatively mistaken.
The counterexample is to be found in RFC8490(5.4):

  A DSO message begins with the standard twelve-byte DNS message header
  [RFC1035] with the OPCODE field set to the DSO OPCODE (6).  However,
  unlike standard DNS messages, the question section, answer section,
  authority records section, and additional records sections are not
  present.  The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT,
  ARCOUNT) MUST be set to zero on transmission.


Dick Franks


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

Re: [DNSOP] Call for Adoption: Structured Data for Filtered DNS

[Dick Franks]

On Tue, 24 Jan 2023 at 19:28, Tim Wicinski  wrote:
>8

> One thing which concerns me is the updating of RFC8914. RFC8914 has only been 
> out a short while, and we're just starting to see deployment out in the world.


It does seem distasteful to pile structured data into a field which
RFC8914 declares to be explanatory text.

The basic idea behind this draft is a good one which could also be
useful in other contexts.

I hope that the authors of RFC8914 might be persuaded to produce an
RFC8914-bis allowing JSON structured data to appear in the EXTRA-TEXT
field.  The wire-format remains the same, the structured case being
distinguished by the appearance of a "{" or "[" as the leading
character.  The EXTRA-TEXT field should perhaps be renamed EXTRA-INFO
to reflect its more general content.

A quick and dirty modification to perl Net::DNS then produces the following:

  ;; {"EDNS-VERSION":0,
  ;;"FLAGS":"",
  ;;"RCODE":0,
  ;;"UDPSIZE":0,
  ;;"OPTIONS":[
  ;;{ "EXTENDED-ERROR": { "EXTRA-TEXT": { "c": [ "tel:+358-555-1234567",
  ;;"sips:b...@bobphone.example.com",
  ;;"https://ticket.example.com?d=example.org=1650560748; ],
  ;;"j": "malware present for 23 days", "o":
"example.net Filtering Service", "s": 1
  ;;}, "INFO-CODE": 123 } } ]
  ;;}


--Dick

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

Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on glue definition

[Dick Franks]

On Thu, 3 Nov 2022 at 21:49, Benno Overeinder  wrote:

> >8
>
> Q2. Definition of Glue provided by Duane Wessels on the DNSOP WG mailing
> list:
>
> "Glue is non-authoritative data in a zone that is transmitted in the
> additional section of a referral response on the basis that the data
> might be necessary for resolution to proceed at the referred name
> servers."
>
> On the mailing list, we have seen a discussion about "necessary"
> versus "useful".  In this context glue is defined to be exclusively
> A/ records (traditional understanding), or do we also consider
> other RRtypes to be glue, e.g. SCVB/HTTPS or DS records?  Concern is
> that "useful" may lead to a definition that is too broad.
>

The ink is not yet dry on SVCB/HTTPS.
I fail to see why DS would be a part of this topic.

Suggest the following redrafting to make explicit what it is and why it is
needed:

  "Glue is the set of non-authoritative A/ records in a zone
  that are transmitted in the additional section of a referral response
  on the basis that these might be necessary for a resolver to reach
  the target name servers."


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

Re: [DNSOP] Representing DNS Messages in JSON (RFC 8427): ugly EDNS

[Dick Franks]

On Wed, 14 Sept 2022 at 16:54, Petr Špaček  wrote:

> >8


> I agree that full structured JSON is lots of work, and honestly I don't
> see the need for it.
>
>  From my perspective more useful is to standardize unambiguous
> presentation formats for all EDNS options first. Maybe we will find out
> that it is enough. Or maybe not, but the presentation formats could be a
> corner stone, and are useful by itself.
>

FWIW:  Perl Net::DNS makes a stab at a presentation form for OPT in a
pseudo-perl sort of way:

;; HEADER SECTION
;; id = 38542
;; qr = 0 aa = 0 tc = 0 rd = 0 opcode = QUERY
;; ra = 0 z  = 0 ad = 0 cd = 0 rcode  = NOERROR
;; qdcount = 1 ancount = 0 nscount = 0 arcount = 0
;; do = 0
;; EDNS version 0
;; flags: 
;; rcode: NOERROR
;; size: 512
;; option: LLQ => ( 7261776279746573 )
;; UL => ( 7261776279746573 )
;; NSID => ( 7261776279746573 )
;; 4 => (  )
;; DAU => ( 8, 10, 13, 14, 15, 16 )
;; DHU => ( 1, 2, 4 )
;; N3U => ( 1 )
;; CLIENT-SUBNET => ( FAMILY => 1, SOURCE-PREFIX-LENGTH => 23,
;; SCOPE-PREFIX-LENGTH => 0, ADDRESS => 123.123.122.0 )
;; EXPIRE => ( EXPIRE-TIMER => 604800 )
;; COOKIE => ( VERSION => 1, RESERVED => 00, TIMESTAMP => 1589785412,
;; HASH => 1122334455667788 )
;; TCP-KEEPALIVE => ( TIMEOUT => 200 )
;; PADDING => ( OPTION-LENGTH => 100 )
;; CHAIN => ( CLOSEST-TRUST-POINT => com. )
;; KEY-TAG => ( 29281, 30562, 31092, 25971 )
;; EXTENDED-ERROR => ( INFO-CODE => 123, EXTRA-TEXT => "" )
;; CLIENT-TAG => ( 7261776279746573 )
;; SERVER-TAG => ( 7261776279746573 )
;; UMBRELLA-IDENT => ( 7261776279746573 )
;; DEVICEID => ( 7261776279746573 )


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt

[Dick Franks]

On Thu, 7 Apr 2022 at 19:44, Joe Abley  wrote:
>
> On Apr 7, 2022, at 21:10, Paul Vixie  
> wrote:
>
> > but it seems to me you'd be better off with a zero-length option called 
> > SERIAL which if set in the query causes the SOA of the answer's zone to be 
> > added to the authority section (similar to an RFC 2308 negative proof) and 
> > which option would only be echoed in the answer's OPT if the option was 
> > supported. you'd want to specify that the SOA in this case is not optional 
> > and that its truncation would cause the TC bit to be set.
>
> That sounds like a lovely and clean way to do this. I like it.
>

This is an excellent idea, requiring trivial client-side support.

PV did not say so, but I would expect the SOA's RRSIG to be included
in the response.

--Dick



> Joe
> ___
> 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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt

[Dick Franks]

On Thu, 7 Apr 2022 at 14:48, Paul Vixie
 wrote:

>
> because IXFR and NOTIFY and UPDATE use serial numbers, the DNS protocol
> itself is aware of serial numbers. i hope that any recognition of
> non-traditional serial numbers will be an optional addition to the
> RRSERIAL response, and that if a zone has no actual serial number (so,
> it cannot participate in IXFR, NOTIFY, and UPDATE) the RRSERIAL value
> will just be a magic number like zero, or just missing altogether.
>

Magic numbers are messy.
Zero-length option preferred, same as the outbound request.
Need explicit statement somewhere that zero-length response means that
IXFR, NOTIFY, and UPDATE are not supported.

Not keen on the implementation-specific blob idea, which is of little
use to the general user. Implementers and power users will already
have more appropriate debugging tools.

--Dick

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

Re: [DNSOP] New Version Notification - draft-ietf-dnsop-svcb-https-06.txt

[Dick Franks]

On Mon, 5 Jul 2021 at 03:11, Mark Andrews  wrote:
>8

>
> Opaque key form isn’t subject to double parsing despite the hint6 having
> commas in the presentation form.  That’s about the only way you could be
> seeing that difference.  The opaque key form knows nothing about the
> internal structure, you don’t double parse opaque key form.  It’s
>

My current analysis model certainly does not rely upon double-parsing
of the opaque form.

Whatever else we might disagree about, there is one feature we can depend upon.
The devout double-escapologist believes that "standard string
processing" occurs before any SVCB-specific code is reached.
This introduces plenty of weaknesses to be exploited.

1) Chuck in an extra digit
example.com.SVCB1 foo.example.com. port=1234\053
produces
example.com.IN  SVCB( \# 25 0001; 1
03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
0003 0002 3039 )

instead of the expected error message.

2) Break number parsing
example.com.SVCB1 foo.example.com. port=1234\078

  Argument "1234N" isn't numeric in pack at
blib/lib/Net/DNS/RR/SVCB.pm line 192,  line 2.
  file GLOB(0x556193c89ea0) line 2
  at test.pl line 23.

3) Break argument parsing
example.com.SVCB1 foo.example.com. port=12\04434

  SVCB: unexpected number of values for "key3" at
blib/lib/Net/DNS/ZoneFile.pm line 531.
  file GLOB(0x559fdbb90d80) line 2
  at test.pl line 23.


--rwf

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

Re: [DNSOP] Fwd: New Version Notification - draft-ietf-dnsop-svcb-https-06.txt

[Dick Franks]

Feedback on SVCB draft 06 as requested.

On Mon, 28 Jun 2021 at 02:39, Tim Wicinski  wrote:
>8
>
> The chairs would like the WG to review these changes, and give us some 
> feedback.


6.1.  "alpn" and "no-default-alpn"

   The presentation "value" SHALL be a comma-separated list
   (Appendix A.1) of one or more "alpn-id"s.  Zone file implementations
   MAY disallow the "," and "\" characters instead of implementing the
   "value-list" escaping procedure, relying on the opaque key format
   (e.g. "key1=\002h2") in the event that these characters are needed.

If implementations MAY ignore the escape mechanism Appendix A.1 completely,
there is little incentive to do otherwise.

However, implementations that do not exercise that option expose themselves
to a litany of potential security weaknesses:

These range from argument strings which produce corrupt content:

   example.com.   SVCB   1 example.com. ipv6hint="2001:db8:5c:5c5c::1"

not ok 29 - SVCB ipv6hint shrinkage
#   Failed test 'SVCB ipv6hint shrinkage'
#   at test.pl line 149.
#  got: 'example.com.INSVCB( \# 33 0001
076578616d706c6503636f6d00 ; example.com.
# 0006 000e 20010db8005c0001 )'
# expected: 'example.com.INSVCB( \# 35 0001
076578616d706c6503636f6d00 ; example.com.
# 0006 0010 20010db8005c5c5c0001 )'

to crafted RRs which silently subvert the parsing process in undesirable ways:

   example.com.   SVCB   1 example.com.
ipv4hint="92.48.55.48,92.48.56.53,92.48.54.54,92.48.56.50"

not ok 30 - SVCB ipv4hint subversion
#   Failed test 'SVCB ipv4hint subversion'
#   at test.pl line 149.
#  got: 'example.com.INSVCB( \# 23 0001
076578616d706c6503636f6d00 ; example.com.
# 0004 0004 46554252 )'
# expected: 'example.com.INSVCB( \# 35 0001
076578616d706c6503636f6d00 ; example.com.
# 0004 0010 5c3037305c3038355c3036365c303832 )'


D.3.  Failure cases

The following additional test vectors are listed below the
corresponding requirement.

 [9, para 1]
 In presentation format, the value is a [SINGLE] ECHConfigList encoded
in Base64.

  example.com.  SVCB  1 foo.example.com. ech; missing argument
  example.com.  SVCB  1 foo.example.com. ech=b25l,dHdv  ; multiple arguments

 [6.2, para 2]
 The presentation "value" of the SvcParamValue is a [SINGLE] decimal
integer between 0 and 65535 in ASCII.

 Note: Character set cannot be specified here; it is whatever the
platform or zone file uses (EBCDIC for example).

  example.com.  SVCB  1 foo.example.com. port=1234,4678 ; multiple arguments

 [6.1, para 6]
 When "no-default-alpn" is specified in an RR, "alpn" must also be
specified in order for the RR to be "self-consistent" (Section 2.4.3).

  example.com.  SVCB  1 foo.example.com. (
  no-default-alpn   ; without expected alpn
  )

D.2.  Service form

The test vector for unsorted SvcParams would be better expressed using
numerical keys and disentangled from extraneous clutter.

  example.com.  SVCB  1 foo.example.org. (  ; unsorted SvcParam keys
  key23609 key23600 mandatory=key23609,key23600
  )

--rwf



>
> -- Forwarded message -
> From: 
> Date: Wed, Jun 16, 2021 at 10:29 AM
> Subject: New Version Notification - draft-ietf-dnsop-svcb-https-06.txt
> To: Tim Wicinski 
>
>
>
> A new version (-06) has been submitted for draft-ietf-dnsop-svcb-https:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-06.txt
> https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-06.html
>
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
>
> Diff from previous version:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-06
>
> IETF Secretariat.
>
>
> ___
> 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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Dick Franks]

On Mon, 24 May 2021 at 15:52, Ben Schwartz  wrote:
>
> For those who prefer Github's UI, I've posted Dick's diff to a branch commit 
> in our repository [1].
Thanks

>
> The diff contains a number of editorial suggestions, such as removing use of 
> ABNF, which we can consider separately.  The key substantive change, as 
> discussed earlier in this thread, is to make comma-escape handling for value 
> lists happen during character-string escape parsing, instead of afterward.
>
The ABNF defines the acceptable characters as a range of ASCII codes.
This ignores the inconvenient fact that zone files can be written
using some other non-ASCII codeset.
The character codes for 'a'...'z' will be different, and in the case
of EBCDIC not even contiguous.

The key substantive change is to make the draft conform to the
long-standing escape conventions enshrined in RFC1035.

> In the implementations I've worked on so far, this change would be highly 
> inconvenient to implement, as it conditionally modifies the core 
> character-string parsing loop that has thus far been entirely 
> RR-type-independent and shared by all zone-file parsing contexts.
>
> The only way I can see to accommodate both of these implementation 
> perspectives is to allow implementors to avoid the offending special case, 
> which, as I've noted before, is not currently needed, and may never be 
> needed.  I have proposed a change [2] that would add this option (now updated 
> to avoid conditioning requirements on the IANA registry, in response to 
> feedback from Paul Wouters).

For this to qualify as an issue sufficiently general to merit special
consideration in the spec, then it would need to be an insurmountable
obstacle encountered by every implementation.
BIND, NSD, PowerDNS, and Net::DNS are well able to deal with escapes
as described in RFC1035, all of them conspicuous counter-examples to
any argument that special treatment of double escapes is an essential
requirement.

Repeating the same fatuous argument ad nauseam will not make the issue go away.


--Dick



>
> --Ben
>
> [1] 
> https://github.com/MikeBishop/dns-alt-svc/commit/5d3d651230de06adce10625d0dfb70ce8e938a39
> [2] https://github.com/MikeBishop/dns-alt-svc/pull/325/files
>
> On Sat, May 22, 2021 at 12:58 PM Dick Franks  wrote:
>>
>> On Sat, 22 May 2021 at 17:06, Paul Hoffman  wrote:
>> >
>> > On May 22, 2021, at 1:58 AM, Dick Franks  wrote:
>> >
>> > > Please find attached the promised words to resolve the conflict
>> > > between current draft and RFC1035.
>> > >
>> > > This is presented as a context diff.
>> >
>> > Where do we find the original Markdown file so we can evaluate the diff?
>>
>> https://github.com/MikeBishop/dns-alt-svc
>>
>> --Dick
>>
>> ___
>> 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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Dick Franks]

On Sat, 22 May 2021 at 17:06, Paul Hoffman  wrote:
>
> On May 22, 2021, at 1:58 AM, Dick Franks  wrote:
>
> > Please find attached the promised words to resolve the conflict
> > between current draft and RFC1035.
> >
> > This is presented as a context diff.
>
> Where do we find the original Markdown file so we can evaluate the diff?

https://github.com/MikeBishop/dns-alt-svc

--Dick

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Dick Franks]

All,

Please find attached the promised words to resolve the conflict
between current draft and RFC1035.

This is presented as a context diff.

Dick Franks



draft-ietf-dnsop-svcb-https.diff.gz
Description: application/gzip
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Dick Franks]

All,

As part of a side discussion, I was admonished for my rather flippant
approach to a significant security issue and failure to explain
clearly how it manifests itself..

On Sun, 9 May 2021 at 13:01, Dick Franks  wrote:
>8
>
> Pre-processing of '\\,' into the RFC1035 standard '\,' is
> superficially attractive, but also fraught with danger.
>
> A parser could have some fun with this one:
>
> $ORIGIN example.com
> @   SVCB   1 foo
> key6="\032\001\013\184\000\000\000\000\000\000\000\000,\000"
> ; a.k.a.   ipv6hint=2001:db8::5c5c:2c00
>

Although a few sharp-eyed people recognised the security implications
immediately, I realise that I should have included the broken result
to illustrate the problem more clearly.

 example.com.INSVCB( \# 38 0001 ; 1
03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
0006 000f 20010db85c2c00 )

instead of the expected:

 example.com.INSVCB( \# 39 0001 ; 1
03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
0006 0010 20010db85c5c2c00 )

Observe that the IPv6 address is shortened to 15 octets.

(Note these results were produced by my development Net::DNS and may
not be repeatable with the latest published version 1.31)



--Dick

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Dick Franks]

On Mon, 10 May 2021 at 00:28, Paul Hoffman  wrote:
>
> On May 9, 2021, at 11:26 AM, Paul Wouters  wrote:
> > This is all pretty terrible. I agree with Tim that we should not inflict 
> > this onto the users. Or perhaps we can already pre-allocate some CVE 
> > numbers for the security issues this will generate.
> >
> > Keep the record simple, we are not going for Turing complete here. I 
> > recommend to authors take this discussion as advise to improve / simplify 
> > this aspect of the draft.
>
> I don't think this request is actually doable. The requirements for the SVCB 
> Rdata are:
> 1. Must be entered by the zone operator as ASCII text (not all a jumble of 
> hex values)
> 2. Is a list of key/value pairs
> 3. Values are likely to be a list of items
>

It is very much doable.
BIND, NSD, and PowerDNS can already parse values containing '\,'
escapes, and each of these has a substantial installed base.

My objections can be entirely satisfied by modest changes to reconcile
the document with RFC1035.


> Given these three things, it seems that there will *always* be an escaping 
> problem for the item delimiter in #3. In the current draft, the item 
> delimiter is a comma, so there has to be a way to escape a comma that is in 
> an item. Few types of items would ever need a comma in their values. If a 
> different character is chosen for the item delimiter, it too will need to be 
> escaped.
>
> If I'm wrong about this being as good as it can be, there must be an item 
> delimiter that is better than a comma. I am not thinking creatively enough to 
> figure out what might be better than a comma. I'd be happy to hear proposals 
> for a better item delimiter.

My objection is narrowly focussed on the escape mechanism, nothing
more.  Changing the delimiter is neither necessary nor relevant.

I am happy to contribute the necessary words.



--Dick

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Dick Franks]

On Mon, 10 May 2021 at 00:42, Joe Abley  wrote:
>
> On May 9, 2021, at 19:27, Paul Hoffman  wrote:
>
> > If I'm wrong about this being as good as it can be, there must be an item 
> > delimiter that is better than a comma. I am not thinking creatively enough 
> > to figure out what might be better than a comma. I'd be happy to hear 
> > proposals for a better item delimiter.
>
> I am quite behind on this topic, but I presume there's a reason to put all 
> these key-value pairs in a list in one RR?
>
> If we compare the two fictional RRTypes EG1 and EG2 illustrated below:
>
> example.com. EG1 key1=value1,key2=value2,...
>
> example.com. EG2 key1 value1
> example.com. EG2 key2 value2
>
> It seems to me that EG2 avoids the need for delimiters at all. There's a bit 
> of overhead resulting from the need for a larger RRSet but it's not obvious 
> that that's a problem.

The current draft can reach the finishing line without tearing it to pieces.

>8

>
> Perhaps this horse has already sailed but I thought I'd mention it.

Perhaps this horse needs to be tested for banned substances!


--Dick

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Dick Franks]

On Fri, 7 May 2021 at 16:52, Paul Hoffman  wrote:
>
> On May 7, 2021, at 3:21 AM, Pieter Lexis  wrote:
> > For PowerDNS, we treat the parsing of SVCParams as a two-step process.
> > First we use the normal rfc1035 character decoder on the full SVCParam
> > value, after which we apply the value-list parser. The former parses
> > 'foo\\,bar' into 'foo\,bar' that is then parsed to a list of length 1
> > with value {'foo,bar'}. So nothing changes from the perspective of the
> > rfc 1035 parser.

Pre-processing of '\\,' into the RFC1035 standard '\,' is
superficially attractive, but also fraught with danger.

A parser could have some fun with this one:

$ORIGIN example.com
@   SVCB   1 foo
key6="\032\001\013\184\000\000\000\000\000\000\000\000,\000"
; a.k.a.   ipv6hint=2001:db8::5c5c:2c00

> >
> > I can see how this might be confusing to those writing zone contents and
> > would support a solution that either prohibits comma's in SVCParam list
> > values or a different value separator that is not allowed to be embedded
> > in values.
>
> Pieter has a point here: to parse correctly, you need a two-step (or 
> two-level) process. The *only* way to prevent that in the spec would be to 
> say that commas are forbidden in  parameter values. However, even if the spec 
> said that, someone would mess up and put a comma in a parameter value, and 
> then different parsers will yield different values based on whether or not 
> they took that shortcut.
>
> Escaping is hard.

Undeniably.

The spec only needs to say that a comma needs to be escaped  ( \, ) in
order to be disregarded as a separator.

BIND, NSD, Net::DNS, and PowerDNS can all do this, so there is little
mileage in claiming that it is not possible.

The "impossible" can be made possible by doing the right things in the
correct order.
Selecting the right things and the correct order is left as an
exercise for the student.




--Dick

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Dick Franks]

On Fri, 7 May 2021 at 11:21, Pieter Lexis  wrote:
>
>8
>
> I can see how this might be confusing to those writing zone contents and
> would support a solution that either prohibits comma's in SVCParam list
> values or a different value separator that is not allowed to be embedded
> in values.

Tim W. pointed out earlier in this thread that "those writing zone
contents" are the majority stakeholders and rarely familiar with the
finer points of DNS.
If we are inflicting confusion on these people by departing from
standard and well-understood character escapes for no other reason
than the convenience of developers, then we have our priorities
seriously wrong.


--Dick

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Dick Franks]

On Thu, 6 May 2021 at 19:11, Ben Schwartz  wrote:
>
> On Thu, May 6, 2021 at 8:50 AM Dick Franks  wrote:
>> But that is precisely what you are NOT doing.
>> You have assigned a special significance to the character sequence
>> "\\," contrary to RFC1035.
>>
>> The language of RFC1035 is crystal clear that an escaped character is
>> parsed as plain text, independently, without regard to context, and
>> that any special meaning does not apply.
>>
>> Strict application of the RFC1035 rules causes string   "...\\,..."
>> to be equivalent to "...\092,...".
>
>
> I'm not sure what you're describing.  Those two inputs are universally 
> equivalent in zone files under the current draft.  They are both reduced to 
> {'\', '"'} by char-string parsing, which is applied uniformly and without 
> modification to all SvcParamValues.

... and the '\' without any special meaning fails to protect the comma
from the attention of the argument splitter.


> Each SvcParamValue has its own input format.  For some SvcParamValues, '\' 
> and ',' may not be allowed characters.  For others, they may be ordinary 
> characters to be copied into the output, or they may have special 
> significance.
>
... and I might, or might not, have a boiled egg for breakfast!


>> BIND, NSD, and Net::DNS are all able to arrive at implementations of
>> SVCB using the RFC1035 standard escape conventions, which demonstrates
>> beyond reasonable doubt that recognising "\\," is not an essential
>> requirement.
>
> I disagree: what you are proposing is a deviation from RFC1035 escape 
> conventions, and what the draft does is specifically to ensure that no such 
> deviation is required.

I am advocating strict adherence to RFC1035 escape conventions.  You
are the one proposing to deviate.


> ...  I have now encountered multiple codebases where modifying the RFC1035 
> char-string parsing in the way that you suggest would be prohibitively 
> complex, and that complexity will only grow over time as new SvcParamValues 
> are defined.

If the development cost is prohibitive, the obvious solution is to use
BIND, NSD, or one of the other respectable implementations which are
certain to be not far behind.  If Google cannot afford the license
fee, a six line perl Net::DNS script could be used to translate
RFC1035 compliant SVCB RRs into RFC3597 format at nil cost.

>
> The "value-list" format is a bit like a (much simpler) cousin of the SPF 
> macro language (https://tools.ietf.org/html/rfc7208#section-7.1).  In both 
> cases, the char-string decoder's output contains embedded commands that allow 
> the next processing stage to distinguish between delimiters (comma and space, 
> respectively) and escaped delimiters ("\," and "%_", respectively).

That is no justification at all.   SPF people can do whatever they
like within the arguments of a TXT record.


--Dick

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Dick Franks]

On Tue, 4 May 2021 at 21:18, Ben Schwartz  wrote:
>
> On Tue, May 4, 2021 at 12:09 PM Dick Franks  wrote:
>>
>> The brutal reality is that the char-string parser has already
>> obliterated the distinction between escaped and unescaped commas
>> before the value-list parser is invoked.
>
> Yes, hence the use of "\\," for embedded commas in value-list values.

No, this is better characterised as the wound dressing covering the
bullet hole in your foot!

...

>>
>> For the sanity of all concerned, SVCB should adhere to the same
>> standard RFC1035 escape conventions as the other 50+ RRTYPEs.
>
> I think that's a good description of why this arrangement was chosen.

But that is precisely what you are NOT doing.
You have assigned a special significance to the character sequence
"\\," contrary to RFC1035.

The language of RFC1035 is crystal clear that an escaped character is
parsed as plain text, independently, without regard to context, and
that any special meaning does not apply.

Strict application of the RFC1035 rules causes string   "...\\,..."
to be equivalent to "...\092,...".

BIND, NSD, and Net::DNS are all able to arrive at implementations of
SVCB using the RFC1035 standard escape conventions, which demonstrates
beyond reasonable doubt that recognising "\\," is not an essential
requirement.

Appendix A and related features should be removed from the draft.

--Dick

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Dick Franks]

On Mon, 3 May 2021 at 18:23, Ben Schwartz  wrote:
>
> The purpose of this two-layer escaping is to allow key-independent tokenizing 
> of SvcParam values.  For example, I just wrote an implementation of the 
> parser that works as follows:
>
> 1. Tokenize
>   a. Scan forward looking for whitespace or "=".  This is the key name.
>   b. If "=" was found, run the standard char-string parser.  Its output is 
> the SvcParam presentation value.
> 2. Create a SvcParam representing (key name, value).
>   a. Choose a value parser based on the key name.
> - Parsers that use the "value-list" pattern call a subroutine with a tiny 
> chunk of escaping logic for handling backslash and comma.
>   b. Run the parser on the value.

Thanks for the explanation.

The brutal reality is that the char-string parser has already
obliterated the distinction between escaped and unescaped commas
before the value-list parser is invoked.

>
> If we use single-layer escaping, this arrangement is not possible.  Instead,
> (1) we would need to add complexity to the char-string parser that is shared 
> by many RR types.
> (2) we would need to integrate key-type-specific behavior into the tokenizer, 
> complicating the interface between the parsing function and the SvcParams 
> implementation.

>
> In the draft's arrangement, those implementation choices are allowed, but not 
> required.

By publishing test vectors including escaped escapes effectively makes
these required, inflicting your questionable design choice on other
developers who opted for a different strategy.

>
> For the administrators, this all seems likely to remain irrelevant.  There is 
> no known use case where escaping is or will be used in a value-list element.  
> The functionality is defined only to preserve ALPN as 8-bit-clean, as 
> requested by some TLS experts, but there will likely never be a defined ALPN 
> that contains these characters.

If you truly believe that, then the pragmatic solution is to accept
the unfortunate fact that your implementation is limited to
value-lists not containing escaped commas.  The residual risk that
someone, somewhere, will discover a need for an escaped comma is
likely to be small.  At worst, you will need to revisit your design,
at best you need do nothing at all.

For the sanity of all concerned, SVCB should adhere to the same
standard RFC1035 escape conventions as the other 50+ RRTYPEs.

Regards

--Dick

>
> On Sun, May 2, 2021 at 5:27 PM Mark Andrews  wrote:
>>
>> I agree with you Dick, but some developers complained that they "couldn’t
>> re-use their string parsers" (despite no existing parser supporting 
>> key=“value”)
>> so now we have to double escape backslashes.  I very much feel that this is 
>> tail
>> wagging the dog.
>>
>> > On 3 May 2021, at 01:25, Dick Franks  wrote:
>> >
>> > All,
>> >
>> > I have considerable difficulty with these test vectors at the end of
>> > Appendix D.2:
>> >
>> >16 foo.example.org. alpn="foo\\,bar,h2"
>> >16 foo.example.org. alpn=f\\\092oo\092,bar,h2
>> >
>> >\# 35 (
>> >00 10  ; priority
>> >03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target
>> >00 01  ; key 1
>> >00 0c  ; param length 12
>> >08 ; alpn length 8
>> >66 5c 6f 6f 2c 62 61 72; alpn value
>> >02 ; alpn length 2
>> >68 32  ; alpn value
>> >)
>> >
>> > which appear to be incompatible with RFC1035 5.1 paragraph 10:
>> >
>> >Because these files are text files several special encodings are
>> >necessary to allow arbitrary data to be loaded.  In particular:
>> >
>> >...
>> >
>> >\X  where X is any character other than a digit (0-9), is
>> >used to quote that character so that its special meaning
>> >does not apply.  For example, "\." can be used to place
>> >a dot character in a label.
>> >
>> >\DDDwhere each D is a digit is the octet corresponding to
>> >the decimal number described by DDD.  The resulting
>> >octet is assumed to be text and is not checke

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Dick Franks]

All,

I have considerable difficulty with these test vectors at the end of
Appendix D.2:

16 foo.example.org. alpn="foo\\,bar,h2"
16 foo.example.org. alpn=f\\\092oo\092,bar,h2

\# 35 (
00 10  ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target
00 01  ; key 1
00 0c  ; param length 12
08 ; alpn length 8
66 5c 6f 6f 2c 62 61 72; alpn value
02 ; alpn length 2
68 32  ; alpn value
)

which appear to be incompatible with RFC1035 5.1 paragraph 10:

Because these files are text files several special encodings are
necessary to allow arbitrary data to be loaded.  In particular:

...

\X  where X is any character other than a digit (0-9), is
used to quote that character so that its special meaning
does not apply.  For example, "\." can be used to place
a dot character in a label.

\DDDwhere each D is a digit is the octet corresponding to
the decimal number described by DDD.  The resulting
octet is assumed to be text and is not checked for
special meaning.

The intention appears to be to include (a) a single arbitrary octet in
the argument, and (b) a plain text comma not being a delimiter in the
argument list. The specimen result is consistent with that assumption.

Armed with the weapons supplied by RFC1035, the obvious way to
represent such an argument is:   alpn="f\092oo\,bar,h2"


A parser adhering strictly to RFC1035 zone file escape conventions:

#!/usr/bin/perl
use Net::DNS 1.31;
use Net::DNS::ZoneFile;

my $zonefile = new Net::DNS::ZoneFile(\*DATA);
while ( my $rr = $zonefile->read ) {
$rr->print;
}
exit;

__DATA__
rfc1035-compliant.example.  SVCB16 foo.example.org.
alpn="f\092oo\,bar,h2"

produces the desired wire-format image:

rfc1035-compliant.example.  IN  SVCB( \# 35 0010; 16
03666f6f076578616d706c65036f7267 00 ; foo.example.org.
0001 000c 08665c6f6f2c626172026832 )

Other parsers are available.


The test vectors, as written, appear to rely upon somehow reactivating
the special meaning of the escape character which is explicitly
disallowed by RFC1035.

The result in each case is:

non-compliant.example.  IN  SVCB( \# 37 0010; 16
03666f6f076578616d706c65036f7267 00 ; foo.example.org.
0001 000e 06665c5c6f6f5c03626172026832 )

the escaped escape characters being inserted as uninterpreted text per RFC1035.


Dick Franks


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt

[Dick Franks]

On Fri, 19 Mar 2021 at 10:15, Willem Toorop  wrote:
>8
>
>
> The Net::DNS perl library does have parsing and printing of SVCB and
> HTTPS based on draft-ietf-dnsop-svcb-https-01 since version 1.26
> (released on August 6, 2020). @Dick, what is your position on this?

Change of name only affects parsing. Easy to accept both until RFC put to bed.

Printing uses lightly toasted RFC3597 format:

x1.example. IN  SVCB0 foo.example.com.

x2.example. IN  SVCB1 .

x3.example. IN  SVCB( \# 25 0010; 16
   03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
0003 0002 0035 )

x4.example. IN  SVCB( \# 28 0001; 1
03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
; key667=...
029b 0005 68656c6c6f )

x5.example. IN  SVCB( \# 32 0001; 1
03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
; key667=...
029b 0009 68656c6c6fd2716f6f )

x6.example. IN  SVCB( \# 55 0001; 1
03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
0006 0020 20010db80001
20010db800530001 )

x7.example. IN  SVCB( \# 46 0010; 16
03666f6f076578616d706c65036f7267 00 ; foo.example.org.
 0002 0001
0001 0009 0268320568332d3139
0004 0004 c201 )

--rwf

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

Re: [DNSOP] DNS Error Reporting

[Dick Franks]

[Section 5]

 o  REPORTING AGENT DOMAIN, a Domain name [RFC8499
<https://tools.ietf.org/html/rfc8499>].

should read:

 o  REPORTING AGENT DOMAIN, a Domain name [RFC8499
<https://tools.ietf.org/html/rfc8499>] in the format prescribed by
[RFC1035 <https://tools.ietf.org/html/rfc1035>].


Dick Franks

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

Re: [DNSOP] HTTPS and SVBC key names.

[Dick Franks]

HTTPS and SVCB in Net::DNS 1.25_01 coming soon to a CPAN server near you.

Documentation needs more attention.

Thanks for the helpful comments, most of which are in there in some form or
another.

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

Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS

[Dick Franks]

On Thu, 23 Jul 2020 at 08:33, Mark Andrews  wrote:

> On 23 Jul 2020, at 16:51, Petr Špaček  wrote:
>
 >8

>
> > I'm not native English speaker and I personally find confusing that
> sequence of characters "mandatory" is used as verb and also as name of the
> key. "optional mandatory" sounds like a joke.
>
s/verb/adjective/

>
> > To clarify this I propose to rename "mandatory" field to "critical",
> which terminologically aligns with X.509 and also LDAP.
>
> Please don’t change field names.  Master files are interchange documents
> (see STD13) and the presentation format is theoretically fixed when the
> type code is allocated.
>

+1

Apart from "mandatory" itself, which cannot avoid being mandatory, what
distinguishes an "automatically mandatory" key from any other optional key
not listed in key0?

If there is no distinction, why persist with this "automatically mandatory"
nonsense.


--Dick




> ___
> 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

Re: [DNSOP] HTTPS and SVBC key names.

[Dick Franks]

On Mon, 20 Jul 2020 at 22:54, Ben Schwartz  wrote:

The unknown-key format is designed more for authoring than reading.  As an
> author, it works somewhat better than your example.  For instance, your
> key1 could be written as
>
> key1=\005h3-29\005h3-28\005h3-27\002h2
>

It is not as easy as you might think.  This all needs to work on EBCDIC and
UTF8 platforms.
I plan to kick the problem into the long grass for now.

 That seems more intelligible than hex or base64.

Am I correct in thinking that the key5 base64 is decoded at RR creation,
not by the eventual consumer?

In short, the unknown-key format is fairly usable for authoring fields
> whose values are plain text or numeric octets, since a human author can
> choose escape codes or ASCII characters as appropriate.  A renderer (by
> definition) has no idea what the contents mean, so it can work well for
> plain text or numeric octets but not both.
>

Exactly!   Which is why I am where I am.

With the addition of comments for the recognized keys and fields, I think
> you're probably right.  However, when authoring a zone file I would hate to
> have to use RFC 3597 hex for the whole record just to add one key that my
> parser doesn't support yet.  Also, if most future keys turn out to have
> ASCII plaintext values (e.g. URLs), an unknown key renderer that uses ASCII
> symbols where possible might turn out to work quite well.
>

I am not suggesting that you fish about in RFC3597 format.

If you are authoring from scratch than you can use this form:

my $rr = new Net::DNS::RR <<'END';
example.net.300 IN  HTTPS   1 target.example.net.
alpn=h3-29,h3-28,h3-27,h2
no-default-alpn
...
key65333=...
END

If thou coverteth thy neighbour's RR in RFC3597 format (contrary to Exodus
20:17), there are the necessary tools to modify it:
$value = $rr->keyNN();  # access a value (in your favoured
format)
$rr->keyNN($value); # assign a value
$rr->keyNN(undef);  # delete a key

--Dick

___
>>>
>> 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

Re: [DNSOP] HTTPS and SVBC key names.

[Dick Franks]

On Tue, 21 Jul 2020 at 00:25, Mark Andrews  wrote:


> > IMHO, tarted up RFC3597 format is easier to read.
>
> Well the presentation form clearly is designed for printable ASCII to be
> rendered as ASCII.
>

Except for the inconvenient fact that Net::DNS also works on OS390 which
speaks EBCDIC.


> Example:
> >
> > use Net::DNS;
> >
> > my $rr = new Net::DNS::RR <<'END';
> > example.net.300 IN  HTTPS   1 target.example.net.
> > mandatory=key0,key1,alpn,no-default-alpn,key99  ; with
> duplications and other sins
> > alpn=h3-29,h3-28,h3-27,h2
> > ...



> Which is a interesting conversion of
> "mandatory=key0,key1,alpn,no-default-alpn,key99”. I would expect the parser
> to reject the record as mandatory contains “key0” in the list.  I would
> also expect the parser to reject the record as there is no “key99” in the
> record.  I would never expect the parser to strip out keys listed in
> mandatory just because they are not present in the rest of the record.
>

Good idea.
I was only raising these exceptions on received packets, but the same tests
are reasonable for freshly created RR.

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

Re: [DNSOP] HTTPS and SVBC key names.

[Dick Franks]

On Thu, 16 Jul 2020 at 21:17, Ben Schwartz  wrote:

>
> Quotes are optional, as with .  Quotes are only required
> if the value contains whitespace.
>

I was trying to establish if the quotes indicated the data type.  Clearly
not.


> The presentation format is optimized for humans and the wire format is
>>> optimized for machines. In particular, when using the named keys it's not
>>> obvious what the numeric ordering is, so keeping them in order when editing
>>> a zone file by hand would be hard.
>>>
>>
  blog.cloudflare.com. 300 IN HTTPS ( 1  .

key1=\005\104\051\045\050\057\005\104\051\045\050\056\005\104\051\045\050\055\002\104\050
 key4=\104\018\026\046\104\018\027\046

key6=\038\006\071\000\000\000\000\000\000\000\000\000\104\018\026\046\038\006\071\000\000\000\000\000\000\000\000\000\104\018\027\046
 )

"optimized" is not the word which springs to this human's mind.
IMHO, tarted up RFC3597 format is easier to read.

Example:

use Net::DNS;

my $rr = new Net::DNS::RR <<'END';
example.net.300 IN  HTTPS   1 target.example.net.
mandatory=key0,key1,alpn,no-default-alpn,key99  ; with duplications
and other sins
alpn=h3-29,h3-28,h3-27,h2
no-default-alpn
port=1234
ipv4hint=192.0.2.1,192.0.2.2
echconfig=base64string
ipv6hint=2001:DB8::1,2001:DB8::2
END

$rr->print;

produces:

example.net.300 IN  HTTPS   ( \# 126 0001
06746172676574076578616d706c6503 6e657400 ; target.example.net.
 0004 00010002
0001 0015 0568332d32390568332d32380568332d 3237026832
0002 
0003 0002 04d2
0004 0008 c201c202
0005 0009 6dab1eeb8b2dae29e0
0006 0020 20010db80001
20010db80002
)

Observations and complaints gratefully received.

--Dick

> ___
>
 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

Re: [DNSOP] HTTPS and SVBC key names.

[Dick Franks]

On Thu, 16 Jul 2020 at 13:31, Ben Schwartz  wrote:


> On Thu, Jul 16, 2020, 4:07 AM Dick Franks  wrote:
>
>>
>> Beefed-up example from 5.3, where we know neither the key name nor how to
>> interpret the value:
>>
>> foosvc.example.net. 3600 IN SVCB\# 9 000100ff350002beef
>>   ; 1 . key65333=...
>>
>
> Should this say "TYPE64" instead of SVCB?  Apart from that, this looks
> right
>

No.  The IANA registry was updated on June 30 and perl Net::DNS::Parameters
is generated from the XML. It will be in the next Net::DNS release.



> Presentation format?
>>
>
> key65333=\190\239
>

If this is a string, should this say?key65333="\190\239"



>
>> Also, why do (key,value) pairs need to be in ascending order on the wire,
>> but can be in any order in the presentation format?
>>
>
> The presentation format is optimized for humans and the wire format is
> optimized for machines. In particular, when using the named keys it's not
> obvious what the numeric ordering is, so keeping them in order when editing
> a zone file by hand would be hard.
>

That does not answer the question.
What is the reason for the keys to be in ascending order?


There is also some inconsistency in the use of quotes.

2.3 has:

  svc4.example.net.  7200  IN SVCB 3 svc4.example.net. (
   alpn="bar" port="8004" echconfig="..." )

2.5.2 has:

  svc2.example.net. 7200  IN HTTPS 1 . port=8002 echconfig="..."

Is the port value an integer or a string, with the quotes being optional?

Is the wire format a character string to be interpreted as an integer
by the client,
or a packed integer in network byte order?


--Dick


___
>>>
>> 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

Re: [DNSOP] HTTPS and SVBC key names.

[Dick Franks]

Beefed-up example from 5.3, where we know neither the key name nor how to
interpret the value:

foosvc.example.net. 3600 IN SVCB\# 9 000100ff350002beef
  ; 1 . key65333=...

Presentation format?

Also, why do (key,value) pairs need to be in ascending order on the wire,
but can be in any order in the presentation format?


Dick Franks



___
> 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

Re: [DNSOP] HTTPS SVCB no service available signal.

[Dick Franks]

On Thu, 9 Jul 2020 at 23:18, Joe Abley  wrote:

> On Jul 9, 2020, at 17:18, Ben Schwartz 
> wrote:
>
> This seems like a reasonable idea to me.  We should be able to incorporate
> this for the next draft revision.
>
>
> I guess I'll mention that when I suggested MNAME=. to indicate that a zone
> did not accept dynamic updates, the proposal was roundly shot down as a
> disgusting idea that would cause junk to be sent to root servers.i
>

The idea is respectable enough.
There is also a precedent to be found in RFC1035 (3.3.7) no less.

--Dick


> ___
> 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

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Dick Franks]

On Fri, 19 Jun 2020 at 18:12, Paul Hoffman  wrote:

> On Jun 19, 2020, at 9:26 AM, Eric Rescorla  wrote:
> > What's your reasoning for why there needs to be community review before
> there is a code point assigned?
>
> Historically, the quality of algorithm descriptions in early drafts has
> been variable. What the author considers sufficient and obvious, another
> might not. Also, review gives folks a chance to say things like "your test
> vectors appear wrong", "having test vectors would be really useful", and so
> on.
>

How does any of that apply?
The algorithm in this case is specified by another standards organisation
and is what it is.
Community review did not find the incorrect test parameters in RFC5832 /
GOST R34.10-2001.

--Dick Franks



> ___
> 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

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Dick Franks]

Strength - equivalent to ECDSA p256, assuming no fundamental weakness in
the curve parameters.
The Net::DNS::SEC implementation of algorithm 12 verification involves an
algebraic transformation of ECC-GOST into a mathematically equivalent ECDSA
verification. Unless I am missing something, the same approach appears to
be feasible for GOST R34.10-2012 (256 bit).

Apart from a brief flowering in Verisign DNSSEC Analyser
<https://dnssec-debugger.verisignlabs.com/d1a12n1.rootcanary.net>,
algorithm 12 achieved almost no traction.
Implementers may have been discouraged by the mistake
<https://www.rfc-editor.org/errata/eid3768> in R34.10-2001 test parameters.

But there is also a timeliness issue here.  A GOST R34.10 revision appears
every 11 years or so, and is deprecated 5 years after adoption of its
successor.  Next revision ETA 2023.

The sunset date specified in GOST R34.10-2012 having already passed,
algorithm 12 should be marked N in the DNSSEC Algorithm Numbers
<http://www.iana.org/assignments/dns-sec-alg-numbers> registry.


Dick Franks



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

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

Re: [DNSOP] On Powerbind

[Dick Franks]

On Fri, 17 Apr 2020 at 10:27, Olaf Kolkman  wrote:

> Looking for this:
> https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml ?
>
I guess we were.

The extraneous bits appear to be remnants of DNSKEY's previous life as a
KEY RR, defined in RFC2535 3.1.2, and presumably now obsolete.

Thanks Olaf.

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

Re: [DNSOP] On Powerbind

[Dick Franks]

Warren,

Comments in line

On Thu, 16 Apr 2020 at 20:31, Warren Kumari  wrote:
>8

> Just checking - the DNSKEY Flags field is 16 bits, and we have so far burned:
> Bit 15 - SEP
> Bit 7 - Zone key
> Bit 8 - Revoked
> Did I miss any (I wasn't able to find a registry for this)?
>
> If not, we still have 13 bits left, and so using one for this seems ok
> to me, especially if recursives doing something with it is optional...
> (I had mistakenly remembered the Flags as being only 8 bits)
> I'm still not convinced that DNSSEC Transparency will come to pass,
> nor that many zones will use this flag, but I'm now much more sanguine
> about giving it a bit...
>

The lack(?) of a registry is indeed regrettable.

However, there seems to be some historical meaning attached to some of
the other flag bits.

If I look back at Net::DNS::SEC 0.17, bequeathed to me by one Olaf
Kolkman, the DS create() method contains the following mysterious
(perl) lines, for which I can offer no coherent explanation:

# The key must not be a NULL key.
if (($keyrr->{"flags"} & hex("0xc000") ) == hex("0xc000") ){
croak "\nCreating a DS record for a NULL key is illegal";
}

# Bit 0 must not be set.
if (($keyrr->{"flags"}) & hex("0x8000")) {
croak "\nCreating a DS record for a key with flag bit 0 set ".
"to 0 is illegal";
}

# Bit 6 must be set to 0 bit 7 must be set to 1
if ( ($keyrr->{"flags"} & hex("0x300")) != hex("0x100")){
croak "\nCreating a DS record for a key with flags 6 and 7 not set ".
"0  and 1 respectively is illegal";
}

which would seem to indicate that some of the other bits were thought
to have some meaning circa 2013.

Perhaps Olaf can shed some light on this topic.


Dick Franks


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

Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones

[Dick Franks]

Response in line

On Mon, 9 Mar 2020 at 07:20, Mark Andrews  wrote:

>8

> > [1.2 para 1]
> >
> >   ...  The procedures for digest calculation and DNSSEC
> >   signing are similar (i.e., both require the same ordering of RRs) and
> >   can be done in parallel.
> >
> > There is no requirement for the RR collating sequence be the same as
> > DNSSEC, otherwise it would be impossible for there to be more than one
> > scheme.
>
> I see no proof for this claim.

Self evident:  If a "Scheme" defines its own collating sequence, then
it is certainly
possible to define another Scheme with a different collating sequence.
The collating sequence therefore can not be constrained to be the same
as DNSSEC.
Also, the eventual goal is to incorporate some as yet unspecified
incremental scheme,
which is a whole new can of worms and unlikely to fit the DNSSEC model.

> > [3.1 para 1]
> >
> >   In preparation for calculating the zone digest, any existing ZONEMD
> > +  and covering RRSIG
> >   records at the zone apex are first deleted.
> >
> > [3.1 para 1]
> >
> >   Prior to calculation of the digest, and prior to signing with DNSSEC,
> >   a placeholder ZONEMD record is added to the zone apex.
> >
> > reword as follows:
> >
> >   Prior to calculation of the digest, and prior to signing with DNSSEC,
> >   exactly one placeholder ZONEMD record is added to the zone apex.
> >
> > [3.1 para 5]
> >
> > reword as follows:
> >
> >   If multiple digests are to be published in the zone, e.g., during an
> >   algorithm rollover, each digest calculation is performed independently
> >   using the placeholder for the corresponding Scheme and Hash Algorithm.
>
> para 5 is about filling out the RRset to have a ZONEMD placeholder record
> for each  pair.

Indeed, that is what para 5 says.

What I am calling into question is the necessity to bind each digest
to *all* of its siblings,
given that DNSSEC will be used to sign and protect the complete ZONEMD RRset.

Binding each digest to its own placeholder should be sufficient, and
also removes the
apparent conflict with [3.1 para 2]:
   Prior to calculation of the digest, ... a [singular] placeholder
ZONEMD record is added ...

With this simplification, verification can be achieved using a single
ZONEMD, instead of
needing the entire RRset.

Michael StJohns pointed out (Feb 25) that a verifier that does not
recognise a particular
ZONEMD Scheme and/or Hash Algorithm may be unable to create the
required placeholders,
and therefore unable to perform a verification using any
(Scheme,Algorithm) at all.

> > [3.2]
> >
> > s/signature(s)/signature/
> >
> > There can never be more than one.
>
> Actually there can be multiple RRSIG for ZONEMD so plural is correct.

There is only ONE RRset at the apex, therefore only ONE covering RRSIG
which needs to be regenerated.

> > [3.3] and [3.3.1]
> >
> >This specification adopts DNSSEC's canonical on-the-wire RR format
> >(without name compression) as specified in [RFC4034].
> >
> >   RR(i) = owner | type | class | TTL | RDATA length | RDATA
> >
> >   where "|" denotes concatenation.
> >
> > The record collating sequence is scheme specific.
> >
> > [3.4 bullet 3]
> >
> >   o  Only one instance of duplicate RRs with equal owner, class, type
> >  and RDATA SHALL be included ([RFC4034] Section 6.3).
> >
> > This seems to detract from the idea of a general purpose comparison
> > advertised in 1.3.5. If unexpected duplicate RRs were to be present in
> > the original zone, the downstream copy should be expected to match,
> > warts and all.
>
> Do you really want to update every AXFR implementation on the planet?

Emphatically not;  but neither does massaging the digest to gloss over an
erroneous duplication at the source seem like a sensible idea.

Moreover, the independence of any particular transport mechanism is one
of the merits of this proposal.

> > [3.5.1 para 5]
> >
> > Needs to be incorporated into 3.3.
> >
> > [3.6]
> >
> > reword:
> >
> >   Once a zone digest has been calculated, the published ZONEMD record
> >   is finalised by inserting the digest into the placeholder ZONEMD.
> >   Repeat for each digest if multiple digests are to be published.
> >
> >   If the zone is signed with DNSSEC, the RRSIG record covering
> >   the ZONEMD RRSet MUST then be added or updated.
> >
_

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

Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones

[Dick Franks]

draft-ietf-dnsop-dns-zone-digest-04 is still a work in progress, with a
number of internal contradictions to be resolved.


[1.2 para 1]

   ...  The procedures for digest calculation and DNSSEC
   signing are similar (i.e., both require the same ordering of RRs) and
   can be done in parallel.

There is no requirement for the RR collating sequence be the same as
DNSSEC, otherwise it would be impossible for there to be more than one
scheme.

[3.1 para 1]

   In preparation for calculating the zone digest, any existing ZONEMD
+  and covering RRSIG
   records at the zone apex are first deleted.

[3.1 para 1]

   Prior to calculation of the digest, and prior to signing with DNSSEC,
   a placeholder ZONEMD record is added to the zone apex.

reword as follows:

   Prior to calculation of the digest, and prior to signing with DNSSEC,
   exactly one placeholder ZONEMD record is added to the zone apex.

[3.1 para 5]

reword as follows:

   If multiple digests are to be published in the zone, e.g., during an
   algorithm rollover, each digest calculation is performed independently
   using the placeholder for the corresponding Scheme and Hash Algorithm.

[3.2]

s/signature(s)/signature/

There can never be more than one.

[3.3] and [3.3.1]

This specification adopts DNSSEC's canonical on-the-wire RR format
(without name compression) as specified in [RFC4034].

   RR(i) = owner | type | class | TTL | RDATA length | RDATA

   where "|" denotes concatenation.

The record collating sequence is scheme specific.

[3.4 bullet 3]

   o  Only one instance of duplicate RRs with equal owner, class, type
  and RDATA SHALL be included ([RFC4034] Section 6.3).

This seems to detract from the idea of a general purpose comparison
advertised in 1.3.5. If unexpected duplicate RRs were to be present in
the original zone, the downstream copy should be expected to match,
warts and all.

[3.5.1 para 5]

Needs to be incorporated into 3.3.

[3.6]

reword:

   Once a zone digest has been calculated, the published ZONEMD record
   is finalised by inserting the digest into the placeholder ZONEMD.
   Repeat for each digest if multiple digests are to be published.

   If the zone is signed with DNSSEC, the RRSIG record covering
   the ZONEMD RRSet MUST then be added or updated.


Dick Franks


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

Re: [DNSOP] Unknown DNS RDATA type presentation syntax vs. e.g. TXT records?

[Dick Franks]

On Mon, 10 Feb 2020 at 16:19, Tony Finch  wrote:
>8

> When I was working out how a SHA-1 attack could work with TXT records,
> (https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html)
> one of the problems was that the collision blocks in the best attack so
> far are 588 bytes, which is too big to fit into a single TXT string. So
> there will be length bytes inside the collision blocks which can't easily
> be controlled by the attacker. The solution is to append 255 zero bytes
> which is enough to fill the tail end of any string specified by the last
> length byte in the collision blocks, and any excess zero bytes get treated
> as a sequence of empty strings.

The troublesome length bytes can be avoided by (ab)using a generic URI
RR instead:

64kilobeef. TYPE256 \# 8 deadbeefdeadbeef

which allows arbitrary content (3 < length < ~64k).
Note that the URI target text occupies the remaining RDATA after the
weight field.

--
Dick

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

Re: [DNSOP] Fwd: [Editorial Errata Reported] RFC1035 (5915)

[Dick Franks]

On Mon, 23 Dec 2019 at 22:01, Ray Bellis  wrote:
>
> On 20/12/2019 15:08, Bob Harold wrote:
>
> > But if we are updating it, could we consider a better word than
> > "forward" ?  Actually "backward" would be correct, although I prefer
> > "from the back to the front" as used elsewhere.
>
> It's not possible to traverse the RRs in a raw DNS packet "backwards".
>  You have to start at the beginning and remember the offset of each RR
> found.
>

Is there an implicit assumption here that all RRs beyond the UDP limit
are to be discarded without requiring inspection of their internal
content?

If so, then I have a problem with the current EDE draft which appears
to involve preferentially discarding the EDE option from the OPT RDATA
(as distinct from the entire OPT RR).

draft-ietf-dnsop-extended-error-13 says:

3.  Extended DNS Error Processing
When the response grows beyond the requestor's UDP payload size
   [RFC6891], servers SHOULD truncate messages by dropping EDE options
   before dropping other data from packets.  Implementations SHOULD set
   the truncation bit when dropping EDE options.


--
RWF

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

Re: [DNSOP] Deprecating the status opcode

[Dick Franks]

IMHO, not worth the effort

Dick Franks



On Sun, 19 May 2019 at 18:31, tjw ietf  wrote:
>
> Can we like this draft *and* a RFC cleanup of 1034/1035?
>
> Though watching tcpm do this for 793 has been disheartening
>
> From my high tech gadget
>
> > On May 16, 2019, at 11:46, Michael J. Sheldon  wrote:
> >
> >> On 5/16/19 3:23 AM, Petr Špaček wrote:
> >> Notice: This email is from an external sender.
> >>
> >>
> >>
> >>> On 15. 05. 19 19:57, Bob Harold wrote:
> >>>
> >>> On Wed, May 15, 2019 at 1:00 PM John Levine  >>> <mailto:jo...@taugh.com>> wrote:
> >>>
> >>>In article <064ba295-f3dd-46e4-86a9-e03cf68eb...@sinodun.com
> >>><mailto:064ba295-f3dd-46e4-86a9-e03cf68eb...@sinodun.com>> you write:
> >>>> -=-=-=-=-=-
> >>>>
> >>>> Hi,
> >>>>
> >>>> In the spirit of deprecating things I have submitted a draft to
> >>>deprecate the status opcode.
> >>>
> >>>RFC 1034 says it's "To be defined" so this seems a little premature.
> >>>
> >>>Other than that, go for it.
> >>>
> >>>
> >>> Does this increase or decrease the 'camel' page count?
> >>
> >> Personally I think it is not worth the effort, it will just add one more
> >> RFC to read and does not help the protocol maintenance.
> >>
> >> I would say that it is better to have one "cleanup" RFC instead of
> >> one-off doc with one useful paragraph in it. With one bigger document we
> >> could say to newcommers "this is list of things you can ignore when you
> >> encounter them in pile of DNS RFCs".
> >>
> >
> > In a perfect world, we'd have occasional complete rewrites like what
> > happened with RFCs 821, 2821, 5321 and RFCs 822, 2822, 5322
> >
> >
> >
> > --
> > Michael Sheldon
> > Dev-DNS Services
> > GoDaddy.com
> > ___
> > 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

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

Re: [DNSOP] Call for Adoption: draft-wessels-dns-zone-digest

[Dick Franks]

Assuming that the draft is adopted, I am willing to work on it and
contribute new text.


Dick




On Sun, 10 Mar 2019 at 14:31, Tim Wicinski  wrote:

>
> The chairs feel the document has been updated to address
> several issues raised from the last meeting, including
> some implementations.
>
> If there is pushback during this call for adoption, we can
> take the topic up in Prague.
>
> This starts a Call for Adoption for draft-wessels-dns-zone-digest
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 24 March 2019
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
> ___
> 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

Re: [DNSOP] RFC 2845bis and HMAC-MD5

[Dick Franks]

On Thu, 14 Mar 2019 at 15:09, Tony Finch  wrote:

> Martin Hoffmann  wrote:
> >
> > As such, I would like to propose to move HMAC-MD5 to optional and only
> > retain SHA-1 and SHA-256 as mandatory.
>
> That seems sensible. There should at the very least be a reference to
> RFC6151, Updated Security Considerations for the MD5 Message-Digest and
> the HMAC-MD5 Algorithms.


Is there any continuing justification for the special treatment of SHA-1
enshrined
in the footnote to Table 1.

Section 8 make abundantly clear that algorithm selection and applicable
truncation
is a matter of policy and agreement between client and server.  Taken
together with
the detailed requirements in section 6.5.2.1, and the statement that a
reply SHOULD
be sent with a MAC at least as long as that in the corresponding request,
removes
the need for specific numerical length constraints to be stated in this
document.

IMHO the SHOULD here should become MUST, promoting this to a full
requirement.

The special cases identified in 6.5.1 and 6.5.2 are obviously not subject
to the
general policy.

Security conscious users will define their policy having regard to
performance and
size versus strength trade-offs and weaknesses of particular algorithms
about which
there is no shortage of published material.

 Requirement Name
   --- 
   Mandatory   HMAC-MD5.SIG-ALG.REG.INT
   Optionalgss-tsig
   Mandatory   hmac-sha1
   Optionalhmac-sha224
   Mandatory   hmac-sha256
   Optionalhmac-sha384
   Optionalhmac-sha512

  Table 1

   SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.



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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Dick Franks]

On Fri, 8 Mar 2019 at 03:58, Paul Wouters  wrote:

8<

You are suggesting to introduce an option code point to convey blobs in
> DNS. So different parties can send and receive blobs. You think or hope
> that these parties will interpret this blob the same. But you have no
> guarantee this is true.
>

groundhog day


> If you have a specific use case, get a code point for that specific use
> case. Than you know for sure what the blob means and that it will be
> interpreted by all parties in the same standard RFC way.
>

There are exactly two parties to a bi-lateral agreement.


> If your use case is too private/secret or non-standard, then use a
> code point from the "Reserved for Local/Experimental Use" range.


My inclination too, but the argument cannot be made by ignoring the
clearly stated requirement for agreement between participating parties.


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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Dick Franks]

On Tue, 5 Mar 2019 at 09:27, Ray Bellis  wrote:

8<

Stretching the analogy to BGP communities slightly (the authors had
> already discussed this internally when working on the draft, and Wes has
> made that comparison too):
>
> Folks *could* have decided to use some unassigned BGP Path attribute
> value to carry similar information, but each implementor would have had
> their own special version of it.   Making it _standardised_ is what
> allows support to be ubiquitous (and interoperable).
>

But that is not the case here.
Even if the mechanism were to become standardised and ubiquitous, each
instance would be interoperable only between two specific consenting
parties.
IMHO this falls into the "local use" category.

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Dick Franks]

On Tue, 5 Mar 2019 at 08:13, Ray Bellis  wrote:

>
>
> On 04/03/2019 23:03, Wes Hardaker wrote:
>
> > Hmmm..  very interesting idea, but I'm having a hard time seeing how
> > this will be used in the real world in a scalable and interoperable
> > way.
>
> The use cases on the open internet are probably less interesting than
> those were client and server have a more tightly coupled relationship.
>

+1


> I suggest that I add a sentence or two about applicability, constraining
> it to those where the client has tight coupling (be that topologically
> or contractually) to a particular set of servers.
>

The present wording already provides the necessary constraint; being
exclusively between the [exactly two] parties to the agreement.

What is there to not understand about the term "bi-lateral agreement".

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Dick Franks]

On Tue, 5 Mar 2019 at 00:45, Mark Andrews  wrote:

8<

Presumably you won’t get back a server tag and you can log that.
>

Not always.

The spec does not require the server to return a server tag in response to
a client tag.
However, a server tag may only be returned in response to a request
containing a client tag.

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Dick Franks]

On Mon, 4 Mar 2019 at 23:43, Wes Hardaker  wrote:

> Dick Franks  writes:
>
> > As the man said, "[semantics are] determined by bi-lateral agreement".
> > If the counter-party decides to do something different, it has
> repudiated the
> > agreement.
>
> Yes, and that's where I see a problem: when the software doesn't know
> the agreement has been severed.
>

Non-performance by one party to the agreement will inevitably cause
something to fail,
which will be directly observable by the [singular] counter-party.

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Dick Franks]

On Mon, 4 Mar 2019 at 23:03, Wes Hardaker  wrote:

> Ray Bellis  writes:
>
> > This new draft describes a way for clients and servers to exchange a
> > limited amount of information where the semantics of that information
> > are completely unspecified, and therefore determined by bi-lateral
> > agreement between the client and server operators.
>

8<

What happens when the upstream software changes?  Or the upstream server
> is taken over by a new company that deploys entirely new semantics?  How
> is that change communicated to all the clients?  What if the new bits
> mean something entirely different, potentially the exact opposite?  How
> are conflicts like this handled?
>

The conflict never arises.
As the man said, "[semantics are] determined by bi-lateral agreement".
If the counter-party decides to do something different, it has repudiated
the agreement.

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

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Dick Franks]

On Thu, 21 Feb 2019 at 12:25, Tony Finch  wrote:

> Mark Andrews  wrote:
> > > On 21 Feb 2019, at 6:30 am, Tony Finch  wrote:
> > >
> > > Does it need to be per-record? Why not GC the whole RRset?
> >
> > Because there are scenarios where you do want to GC as single
> > record from the RRset. AD has them with SRV.  Each server adds
> > its own SRV record to the RRset.
>
> Oh I see, that makes sense. Things like this need explaining in the
> document.
>
> Why not simplify the RDATA format so there is just one item per record,
> instead of containing a list of lists? Aren't the individual items going
> to be added/removed independently of each other?
>

Good idea.

A more radical approach would be to have just one hash per item per record.
This has the attraction of allowing a truncated hash to be used, without
the need for length fields.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

[Dick Franks]

On Wed, 20 Feb 2019 at 11:27, Petr Špaček  wrote:
8<

> Yet another code propodsl:
> * answer with stale data
>
>The resolver was unable to resolve answer within its time limits and
>decided to answer with stale data instead of answering with an error.
>This is typically caused by problems on authoritative side, possibly
>as result of an DoS attack. Retrying is likely to cause load and not
>yield a fresh answer, RETRY=0.
>
> Here is a problem that this code point is applicable to NOERROR as well
> as NXDOMAIN answers so I'm not sure how to categorize it. This
> reinforces my unanswered question why the draft proposes to copy RCODE
> into EDE.
>

This seems to be a good argument in favour of a one-dimensional error table..

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

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Dick Franks]

On Wed, 20 Feb 2019 at 12:36, Tony Finch  wrote:

> Dick Franks  wrote:
> >
> > Unsigned 32 bit RRSIG time is good for travel until 7th February 2106.
>
> No, it lasts indefinitely. It covers +/- 68 years relative to current
> POSIX time using serial number arithmetic.
>

The value is  ( t - Jan1970 ) mod 2**32,  for any integer t,   which is
certainly
not relative to current time, always positive, and I agree lasts
indefinitely.
The point I was trying to make was that the wrapping occurs in 2106,
not 2038 as some have claimed.
RFC1982 serial number arithmetic is mandated for comparison of these values,
not for defining the values themselves.


[RFC4034] 3.1.5.  Signature Expiration and Inception Fields

   The Signature Expiration and Inception fields specify a validity
   period for the signature.  The RRSIG record MUST NOT be used for
   authentication prior to the inception date and MUST NOT be used for
   authentication after the expiration date.

   The Signature Expiration and Inception field values specify a date
   and time in the form of a 32-bit unsigned number of seconds elapsed
   since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
   byte order.  The longest interval that can be expressed by this
   format without wrapping is approximately 136 years.  An RRSIG RR can
   have an Expiration field value that is numerically smaller than the
   Inception field value if the expiration field value is near the
   32-bit wrap-around point or if the signature is long lived.  Because
   of this, all comparisons involving these fields MUST use "Serial
   number arithmetic", as defined in [RFC1982].  As a direct
   consequence, the values contained in these fields cannot refer to
   dates more than 68 years in either the past or the future.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Dick Franks]

On Tue, 19 Feb 2019 at 21:27, Tim Wattenberg  wrote:

> 8<

> RRSIG, SIG, TKEY (32 bits with serial number arithmetic relative to now)
> >
> > TSIG (48 bits)
>
> thanks for bringing up this point again. I was aware of the way RRSIG
> presents time but thanks for pointing us to TSIG – I hadn’t considered this
> earlier.
>

TSIG is an aberration. Using a timescale of 8.9 million years to specify a
window of a few minutes around the current time was a monumental blunder.



> Given these possible representations, is there a preference over one of
> the two?
>

Unsigned 32 bit RRSIG time is good for travel until 7th February 2106.
The fact that 2100 will not be a leap year is likely to be a bigger issue
than wrap-around.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Implementations of extended error?

[Dick Franks]

There is not yet a proper IANA allocated option code for this.

Might I suggest that all interested parties settle on 65015 from the
local/experimental block until the real thing arrives.


Dick Franks




On Fri, 1 Feb 2019 at 17:33, Wes Hardaker  wrote:

>
> Folks,
>
> We (some definite of we, possibly including you) are curious who is
> planning (or has already) implemented the Extended Error EDNS0 extension
> [1]?
> As DNSOP is preferring RFCs that have been implemented already, it would
> be good to know what plans exist or have been completed.
>
> [1]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/
>
> --
> Wes Hardaker
> USC/ISI
>
> ___
> 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

Re: [DNSOP] TSIG - add presentation format for humans.

[Dick Franks]

On Wed, 21 Nov 2018 at 21:31, Mark Andrews  wrote:

>
> --
>

Net::DNS has offered this information for many years in the form of
comments,
which avoids a disaster if inadvertently ingested by a parser.

$packet->print;

;; HEADER SECTION
;;id = 51343
;;qr = 0aa = 0tc = 0rd = 0opcode = QUERY
;;ra = 0z  = 0ad = 0cd = 0rcode  = NOERROR
;;qdcount = 1ancount = 0nscount = 0arcount = 1
;;do = 0

;; QUESTION SECTION (1 record)
;; query.example.INA

;; ANSWER SECTION (0 records)

;; AUTHORITY SECTION (0 records)

;; ADDITIONAL SECTION (1 record)
; hmac-sha1.example.TSIG
;algorithm:HMAC-SHA1
;time signed:1542837913fudge:300
;signature:364892b4af8d131a647157838c541d2606d30be4
;original id:51343
;NOERROR


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-algorithm-update-03.txt

[Dick Franks]

On Tue, 23 Oct 2018 at 19:34, Tim Wicinski  wrote:

The WGLC has completed and we were waiting on the authors on addressing all
> comments and updating their document.
> The chairs feel this is ready to proceed.
>

Just spotted a fumble with document references in section 3.1 which will
need to be fixed before this is put to bed.

[3.1, para 6] reads:

   ECC-GOST (GOST R 34.11-94) has been superseded by GOST R 34.11-2012
   in [RFC6986 ].  The GOST R
34.11-2012 hasn't been standardized for use
   in DNSSEC.

should read:

   ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012
   in [RFC7091 ].  The GOST R
34.10-2012 hasn't been standardized for use
   in DNSSEC.


I apologise for not having noticed this earlier.


-- Dick



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

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-terminology-bis-11

[Dick Franks]

Some of this lack of precision is spread about by much-loved DNS tools.


 ; <<>> DiG 9.11.4-RedHat-9.11.4-4.fc28 <<>> @b.root-servers.net . -t NS
 ; (2 servers found)
 ;; global options: +cmd
 ;; Got
answer:
<<<
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37483
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
 ;; WARNING: recursion requested but not available

 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ;; QUESTION SECTION:
 ;.INNS

 ;; ANSWER SECTION:
 .518400INNSj.root-servers.net.
 .518400INNSh.root-servers.net.
 ...


And before anyone complains, similar infractions in perl Net::DNS
documentation will be fixed in next release.




Dick

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

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

[Dick Franks]

On 12 July 2018 at 02:58, Dave Crocker  wrote:

> On 7/6/2018 8:22 AM, Stephane Bortzmeyer wrote:
>
>> Editorial: I would prefer all occurrences of "right-most" to be
>> replaced by "most general", to emphasize that it is not the position
>> which matters, it is the closeness to the root.
>>
>> Editorial: 'that is they are the "top" of a DNS branch, under a
>> "parent" domain name.' I assume that "top" is used instead of "apex"
>> because the sentence does not always refer to the top of a zone?
>>
>
>
> So, this turned into a niggling 'thing' for me and produced a collection
> of small changes.
>
> The basic model now is to introduce the issue early in the document and
> dispatch it once, and then use a single term for the rest of the document,
> without all the distractingly redundant clarifications.
>
> So there's now text in attrleaf that explains about hierarchy, top,
> highest, and the original presentation convention of right, but noting that
> other presentations are possible.
>

IMO unnecessary.
This will inevitably either overlap or conflict with the draft RFC7719-bis
DNS terminology document.
Better to use already battle-hardened terminology throughout and add
RFC7719-bis citation.



> It then declares the term 'global' as referring to the node name of
> interest and only uses that term in the rest of the document.


"global" does not tick the right box for me.
Perhaps the underscore-prefixed label (sequence? / tree?) needs to be
described as subordinate to (or rooted at?) a "principal name".


  (Well, there are a couple of places where 'highest' was needed as
> clarification.)
>

Stephane: "more/most general"
otherwise: "closer/closest to the root"



>
> The -fix document doesn't stand alone, so it merely continues the
> convention and does not re-explain it.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

[Dick Franks]

On 10 July 2018 at 15:32, Dave Crocker  wrote:

> On 7/9/2018 2:35 PM, Dick Franks wrote:

  >8
>
>>
>>   If a public specification calls for the use of an
>> underscore-prefixed domain name,
>> the underscored name closest to the root MUST be entered into this
>> registry.
>>
>>
> Thanks.  I've added some tweakage to your text:
>
>  If a public specification calls for use of an _underscore-prefixed
>domain node name, the 'global' underscored name -- the name that is
>closest to the DNS root -- MUST be entered into this registry.
>Historically, this is the right-most name that is begins with an
>underscore.
>

You just seem to have reintroduced yet more confusing and redundant
verbiage.

The whole point of my suggested text was to remove the extraneous
directional adjectives
like "right-most", "highest-level", "top-most", "global", etc., which we
have already established
are not as concise or unambiguous as we might have wished.

Also,  "domain name" is the recognised and recommended usage per RFC7719
and the latest
DNS Terminology draft.

A reference to RFC7719 or its successor would be sufficient for readers
unfamiliar with DNS
terminology, if indeed there are any.

As for _underscore-prefixed,  there are enough examples in the document for
even the most
intellectually challenged reader to grasp what underscore-prefixed domain
names look like.
Idiosyncratic usage reflects badly on the document production standards of
the organisation.



> > (Editorial:  The word underscore does not itself need to be
> > underscore-prefixed)
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

[Dick Franks]

On 9 July 2018 at 19:48, Dave Crocker  wrote:
>8

> Does this cause anyone intolerable heart-burn?  If it does, please at
> least explain but preferably offer something better.
>

I do not suffer from intolerable heart-burn but happy to offer:

 If a public specification calls for the use of an underscore-prefixed
domain name,
the underscored name closest to the root MUST be entered into this registry.

(Editorial:  The word underscore does not itself need to be
underscore_prefixed)

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

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

[Dick Franks]

On 3 July 2018 at 16:40, Joe Abley  wrote:

> On 3 Jul 2018, at 09:11, Matthew Pounsett  wrote:
>
> > This is not a complete review of the latest revision.. I'm hoping to get
> to that in a day or two.   But I've got a question about whether something
> should be added to the document..
> >
> > A question came up in conversation recently about the use of the verb
> "to publish" in reference to managing DNS data.  It quickly became clear
> that there may be a common overloading of terms, where the same word means
> different things to different people.  I wasn't sure this fell into the
> scope of the terminology document, but I just checked and it does use
> "publish" in reference to DNS data, so perhaps we should come up with a
> definition for that.
> >
> > To me, publishing DNS data has always meant the generation of the zone
> and the data it contains, as distinct from distributing the zone (to name
> servers, possibly though zone transfer) and serving the zone (making it
> available to be queried on a name server).  To the person I was speaking
> to, "publishing" meant putting that data on Internet-facing name servers
> that would answer queries about it.
>
> To me, DNS data is published when it is made available to actors who wish
> to consume it. That means serving the data (i.e. having servers with the
> data available to answer queries). I have never heard "publish" used to
> mean zone generation. A zone, once generated, is not published until it is
> available for access by others.
>

agree, the word carries the usual dictionary meaning:

 publish  v.t. to make public; to divulge; to announce; to proclaim; to set
forth to the public;
   to put forth and offer for sale orig. any article, now books,
newspapers, etc.;
   to put into circulation.

zone generation without the "setting forth" does not appear to qualify.


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

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

[Dick Franks]

On 2 July 2018 at 00:03, Paul Hoffman  wrote

>8

> Well, RFC 1035 *does* say that it is in ASCII, whether we like that or not.



Perhaps we need to remind ourselves what RFC1035 actually *does* say.

ASCII is mentioned in three places only:

2.3.3 para 1, initially about case-insensitive character string
comparisons, but then wanders off-topic:

  However, future additions beyond current usage may need to use the full
binary octet
  capabilities in names, so attempts to store domain names in 7-bit ASCII
  or use of special bytes to terminate labels, etc., should be avoided.

3.1 para 3, supposedly dealing with preferred name syntax, also has another
crack at case-insensitive comparisons:

  Name servers and resolvers must compare labels in a case-insensitive
manner (i.e., A=a), assuming ASCII
  with zero parity.  Non-alphabetic codes must match exactly.

6.1.2 para 3, in a section dealing with nameserver internal data
structures, yet again gets fixated on character case issues:

  One way to solve the case problem is to store the labels for each node
  in two pieces: a standardized-case representation of the label where all
  ASCII characters are in a single case, together with a bit mask that
  denotes which characters are actually of a different case.


3.1 para 1, dealing with domain names in DNS messages, which being an
external interface, one might expect character encoding to be specified,
does not mention ASCII at all.


Furthermore, in the whole of section 5, which specifies the format of
master files, there is no mention of the character encoding of the files
themselves.

There is only one other occurrence of "encoding" remotely relevant to the
present discussion.

5.1 last para, dealing with special characters and escape sequences:

  Because these files are text files several special encodings are
  necessary to allow arbitrary data to be loaded.

There is nothing in the subsequent \DDD description to indicate that the
decimal number represents an ASCII code point, which it clearly must if
labels are ASCII encoded.


The other occurrences of "encoding" are in section 8, and deal with mailbox
addresses and related matters of no interest here.


The proposition that RFC1035 mandates ASCII "presentation format" is
demonstrably false.


>8

> ... An application could choose to encode the presentation format using a
> different encoding, but that's outside the scope of the protocol.


Application programs do not "choose the encoding"; that "choice" is
inflicted upon them by the I/O system provided by the platform on which
they run.  If the platform uses EBCDIC, then "presentation format" is
EBCDIC encoded, constrained (in this instance) to use the same printable
character repertoire as on an ASCII platform.



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

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

[Dick Franks]

The document appears to be in good shape.

However, I have some difficulty with the wording of these two paragraphs in
section 2.

  The basic wire format for names in the global DNS is a list of
  labels ordered by decreasing distance from the root, with the root
  label last.  Each label is preceded by a length octet.  [RFC1035]
  also defines a compression scheme that modifies this format.

  The presentation format for names in the global DNS is a list of
  labels ordered by decreasing distance from the root, encoded as
  ASCII, with a "." character between each label.  In presentation
  format, a fully-qualified domain name includes the root label and
  the associated separator dot.  For example, in presentation
  format, a fully-qualified domain name with two non-root labels is
  always shown as "example.tld." instead of "example.tld".
  [RFC1035] defines a method for showing octets that do not display
  in ASCII.

The character encoding of "presentation format" depends on the context in
which it is used. The protocol mandates ASCII encoding of labels on the
wire.
It cannot say anything about the internal character encoding conventions of
application programs or related master files, which can, in the general
case,
be different.

Consider the following perl fragment:

use Net::DNS 1.11;

my $resolver = new Net::DNS::Resolver();

my ($rr) = $resolver->query( 'www.example.com.', 'A' )->answer;

$rr->print;
print unpack( 'H*', $rr->string ), "\n";

executed in an ASCII-based environment:

  www.example.com.600INA93.184.216.34

772e6578616d706c652e636f6d2e0936303009494e09410939332e3138342e3231362e3334

in an OS390 EBCDIC environment:

  www.example.com.600INA93.184.216.34

a6a6a64b85a781949793854b8396944b05f6f0f005c9d505c105f9f34bf1f8f44bf2f1f64bf3f4

(output converted to ASCII to preserve your sanity)


Suggested replacement text:

  The basic wire format for names in the global DNS is a list of
  labels ordered by decreasing distance from the root, with the root
  label last.  Each label is ASCII encoded and preceded by a single
length octet.  [RFC1035]
  also defines a compression scheme that modifies this format.

  The presentation format for names in the global DNS is a list of
  labels ordered by decreasing distance from the root, represented by
  printable characters from the ASCII repertoire, irrespective of the
local
  character encoding used to represent them.
  The component labels are separated by a single "." character.
  In presentation format, a fully-qualified domain name includes the
root label and
  the associated separator dot.  For example, in presentation
  format, a fully-qualified domain name with two non-root labels is
  always shown as "example.tld." instead of "example.tld".
  [RFC1035] defines a numerical representation that may be used to
display
  octets for which there is no corresponding ASCII printable character.





Dick Franks



On 22 June 2018 at 21:01, Suzanne Woolf  wrote:

> Colleagues,
>
> This begins the working group last call for 
> draft-ietf-dnsop-terminology-bis-10,
> "DNS Terminology”. The document has gotten significant feedback and the
> editors have worked hard to document current terminology usage, both among
> practitioners and for broader audiences; we’d like to advance it.
>
> We’re seeking consensus to advance it to the IESG with an intended status
> of Best Current Practice. Note that it’s intended to obsolete RFC 7719 (
> the earlier “DNS Terminology” document).
>
> If you support it, please say so. If you don’t, please say why.
>
> The current version is at: https://datatracker.ietf.org/
> doc/draft-ietf-dnsop-terminology-bis/
>
> Last Call will run for two weeks, closing on Friday July 6. This will
> allow for discussion of any major outstanding issues at IETF 102.
>
>
> thanks,
> Suzanne, Tim, & Benno
> ___
> 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

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Dick Franks]

On 26 March 2018 at 22:36, Paul Vixie  wrote:


> i've had my symbolics 3640 online quite a bit in the last 30 years, and it
> still makes WKS queries, and i have used WKS responses to control it. the
> software still works as well as it was designed to do, but the vendor is
> long out of business. however, read on.
>

It still works because the end-points understand WKS.  There is no need for
the other nameservers en route to parse the rdata beyond knowing how long
it is.

Ondřej already decided to remove WKS from further consideration.

The focus of this draft is on MB, MG, etc. not the general case of RR
retirement.


please see down-thread where deprecation turns out to be both undesirable
> for the reasons i've given, and additive to developmental complexity since
> there would be _more_ DNS RFC's to read, and suboptimal compared to
> declaring a core subset of DNS technology as "mandatory to implement" and
> simply leaving WKS (and its hypothetical friends) out of that core subset..
>

I fail to see how this changes the number of RFCs to be read.

Nobody has yet defined a core subset; all we have is a camel-load of DNS
technology most of which appears to be "mandatory to implement",
and a mountain of RFCs which are very unlikely to be 100% consistent with
each other.

Expelling one or more items from the "mandatory" set necessarily involves
writing an RFC to add to this mountain, and sometimes obsoleting an old one..

The result is a smaller set of "mandatory to implement" DNS technology.

Repeat this process until nobody can make a good case for further
expulsions;  what remains is the core subset.

Right now, neither you, nor anyone else, can have more than the foggiest
idea what that eventual core subset will look like.

But one thing is certain, if we continue bickering about crap like WKS and
MB, we will make no progress at all.


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

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Dick Franks]

On 26 March 2018 at 16:42, Paul Vixie  wrote:

>
>
> Ondřej Surý wrote:
>
>> No, I am claiming that no current Internet standard is using those
>> records and they were already marked as EXPERIMENTAL or OBSOLETE 30
>> years ago.
>>
>
> the original specification of these RR types is still in effect,
> regardless of whether any other specification currently specifies whether
> to use them.
>
> i don't entirely disagree that the Internet System definition ought to be
> a window, adding new things and deleting old things as it marches down the
> years.
>
> but if you want to deprecate something that somebody somewhere may still
> be using, then it's because the definition for it is still in effect --
> thus neither experimental nor obsolete as you begin.
>
> the process for doing so is more than reaching consensus on this working
> group. figure out a schedule that includes outreach.



This hypothetical somebody somewhere has already had 30 years warning that
these RR's will disappear or be replaced by something better.

Deprecation signals end of life, end of support, end of story.

To speak of outreach in this particular case is a nonsense; your
hypothetical friend has been ignoring the real world for 30 years, and
nothing drops into his mailbox these days.




> --
> P Vixie
>
> ___
> 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

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Dick Franks]

On 26 March 2018 at 14:39, Tony Finch  wrote:

> Evan Hunt  wrote:
> >
> > These RR types have text representations and wire format representations,
> > which from a complexity standpoint seem quite harmless to implement.
> There
> > are the old annoying rules about name compression and sorting, which do
> add
> > some complexity, but are already implemented in all the existing
> codebases.
>
> There's the particularly special case of WKS which has weird collision
> logic - RFC 2136 section 3.4.2.2. It's extra weird that this was specified
> in 1997 when WKS was deprecated in 1989 - RFC 1101 and RFC 1123.
>

Getting rid of extraneous weird logic is the primary objective.


> I fear that this will make it hard to delete WKS code because that may
> introduce interop bugs if a new server bindly allows colliding WKS records
> that an old server objects to.
>

There are no compressible domain names in WKS.  RFC3597 unknown type
representation
does not change the meaning or otherwise damage the rdata.

Intermediate nameservers unaware of WKS, pass it along as as an unknown
type.

The end-points, if there still are any, are free to continue using WKS by
mutual agreement.



>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h
> punycode
> Irish Sea: South 4, increasing 5 to 7, then veering west later. Slight or
> moderate. Rain at times. Good, occasionally poor.
>
> ___
> 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

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Dick Franks]

On 23 March 2018 at 12:11, Ondřej Surý  wrote:

>
> this is a first attempt to start reducing the load on DNS Implementors and
> actually remove the stuff from DNS that’s not used and not needed anymore.
>


I have no quarrel with the overall effect of this proposal, but the
justifications are necessarily different for each category identified in
RFC1035.

  3.3.4. MD RDATA format (Obsolete)
  3.3.5. MF RDATA format (Obsolete)

These were already obsolete when RFC1035 was published and arguably should
never have appeared at all.
If these have not already been deprecated somewhere else, there is no
plausible argument against doing so now.


  3.3.3. MB RDATA format (EXPERIMENTAL)
  3.3.6. MG RDATA format (EXPERIMENTAL)
  3.3.7. MINFO RDATA format (EXPERIMENTAL)
  3.3.8. MR RDATA format (EXPERIMENTAL)

After 30 years, it seem clear that the "experiment" produced little or
nothing of lasting value.  Plenty of word have been wasted in the past
about open-ended experiments and unpublished results.  Deprecating these
RRTYPES would put a formal end to the "experiment".  Any counter-argument
needs to be justified by evidence of continuing use in the global internet,
and made by the parties directly affected.  The "someone might be using it
somewhere ..." argument is far from convincing.


  3.4.2. WKS RDATA format

WKS is IPv4-specific, so the choice is ether to wait until IPv4 itself
becomes deprecated, or to dispose of it now in the same manner as MB, MG
etc.


  3.2.3. QTYPE values

The intended meaning of MAILA is uncertain, but it is already declared by
RFC1035 to be obsolete.

MAILB is a specific request for MB, MG, and MR records.

Both should also be deprecated by this document.



--DIck

___
> 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

Re: [DNSOP] Terminology question: split DNS

[Dick Franks]

On 19 March 2018 at 21:30, Steve Crocker  wrote:

> I haven't been following the current thread but I have encountered this
> topic before and I have thought about the implications for DNSSEC.
>
> The terminology of "split DNS" -- and equivalently "split horizon DNS" --
> is, in my opinion, a bit limited.  It's not too hard to imagine further
> carve outs.  For me, the general case is at every point in the network,
> there is an external world and an internal world.  Let's say I am in charge
> of the systems that support a department within a division of a very large
> company.  I could imagine a department DNS that resolves names within the
> department but forwards other queries to the division DNS resolvers.
>

The simple distinction between "internal" and "external" does not begin to
describe the situation on the ground in the multi-national company that
used to employ me.

The only real "external" is the global internet.

Obviously, the local network, at subsidiary company, or in some cases
departmental level, is unambiguously "internal"

The operating subsidiaries were connected to a (corporate) national
network, and thence the international and global networks.

The DNS naming regime represented all these levels, including specifically,
a "view" of a subsidiary's (locally) maintained namespace visible from
other parts of the organisation.

The key ingredient that need to be captured in the description, is that
these are multiple "views" of a single database.  The view is a corporate
policy animal, and usually changes at a much lower rate than routine DNS
database maintenance.  This is a different proposition from selective
forwarding.


  They resolve names within the division and forward other queries to the
> company's resolvers.  The company's resolvers handle queries for names
> defined by the company and forward other queries to the outside.
>

To make this manageable, the corporate nameservers also need to delegate
parts of the namespace to the operating subsidiaries.

The concept of "horizon" seems (at least to me) to imply some limit beyond
which there is no visibility.

IMHO, the neutral concept of "view" describes the situation well enough to
be useful.


If we're going to tackle this problem, let's do it cleanly and completely.
>
> Steve
>
>
> On Mon, Mar 19, 2018 at 5:14 PM, Paul Wouters  wrote:
>
>> On Mon, 19 Mar 2018, John Heidemann wrote:
>>
>> +1 on "split-horizon dns" as the term, over "split dns" and some other
>>> neologism, on the basis of running code and existing documentation and
>>> existing wide use.
>>>
>>
>> I and google disagree:
>>
>> "split dns":  72900 hits
>> "split horizon dns": 5640 hits
>>
>>
>> If the document is about explaining terminology, it must explain "split
>> dns" and can say another term for it is "split horizon dns", but not the
>> other way around.
>>
>> I personally don't hear (or use) "split horizon dns"
>>
>> Paul
>>
>>
>> ___
>> 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
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

[Dick Franks]

On 29 November 2017 at 12:17, Andrew Sullivan 
wrote:

> On Wed, Nov 29, 2017 at 01:14:13PM +1100, Mark Andrews wrote:
> > When the CNAME refers to a name that is out of zone and the target zone
> is below
> > a zone that the server serves you will have CNAME (DNAME) + referral.
> >
> > 4.3.2 loops.
>
> This part I got.
>
> >   pass 1 -> 3a  (adds CNAME, AA is set as it matches the question
> section, QNAME is updated).
>
> This is the CNAME response, yes, ok.
>
> >   pass 2 -> 3b  (we have a partial match with a bottom of zone cut
> which adds the referral).
> >
>
> Right, and the authoritative server can't proceed, but the referral is
> necessary.  Good, this is helpful, thanks.  This also means, of
> course, that in such a response the answer section isn't empty.  Is
> this why you call it a "partial referral"?
>

And said referral could be to an arbitrary node in the DNS tree,  i.e.
possibly "upward"?

Or am I missing something?




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

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

[Dick Franks]

On 27 June 2017 at 18:10, Jan Včelák  wrote:

>8

There is plenty other alternative ways to express DS DELETE request.
> But I would prefer accepting this simple erratum rather than
> researching all the other options (which we should have done when
> revising the drafts of this document).
>

There is no point in moaning that things could/should have been done better.

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.


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

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

[Dick Franks]

On 26 June 2017 at 15:30, Matthijs Mekking <matth...@pletterpet.nl> 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?


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

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

[Dick Franks]

On 26 June 2017 at 09:39, Matthijs Mekking  wrote:

I raised the specific issue because the to be RFC 8078 was going to change
> the CDS and CDNSKEY RDATA format from a fixed length RDATA to a variable
> length: In case of the DELETE operation, the Digest in presentation format
> was omitted.
>

CDS and CDNSKEY are both variable length. There is no length component in
the RDATA itself. The length of the digest (or key) is calculated (RDLENGTH
- 4) so whether there is one byte or none at all makes not a scrap of
difference. So that explanation can be dismissed immediately.


While I agree with Paul in that thread that we should use all zeros for the
> DELETE operation, I believe it was an oversight that the proper encodings
> (hexadecimal, base64) should be used.
>

Not just an oversight. Now it is an oversight baked into an IESG approved
standards track document.

So an implementer has little choice but to make CDS/CDNSKEY work in
accordance with the standard as written until IESG approves something else.

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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On 26 June 2017 at 10:59, Jan Včelák  wrote:

>8

>
> The implementers should be careful and avoid the trouble. In this
> sense, I think parent zone should accept both zero-length and one-byte
> long digests/keys as a request to remove the DS.
>

Exactly!  The _only_ way to recognise DELETE CDS/CDNSKEY is the zero
algorithm field. RFC8078 says that.  All the rest is mere decoration.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On 25 June 2017 at 20:54, Paul Hoffman <paul.hoff...@vpnc.org> wrote:

> On 24 Jun 2017, at 6:25, Dick Franks wrote:
>
> > In each case,
> >
> >   CDS 0 0 0 0
> >
> >   CDNSKEY 0 3 0 0
> >
> > the final "0" is a conventional token representing a zero-length key
> field.
>
> Dick, can you give examples of that conventional token use?
>

This example is as good as any.

conventional:   established by custom or agreement

token:   a mark, sign or distinctive feature.

[Chambers 21st Century Dictionary]


The token (final zero) is not in this case a self-defining term, but is
given meaning, or in this case lack of meaning, by the formal agreement
(RFC8078) that a zero algorithm field will completely define a DELETE
CDS/CDNSKEY RR.


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

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

[Dick Franks]

 On 24 June 2017 at 16:45, Ondřej Caletka  wrote:

>8

The result that made it to the RFC is that there should be indeed one
> byte with value of 00 in the Digest/Public key field instead of no data
> at all.


That does not appear to be the position at all.

RFC8078 mandates a specific presentation format notation for the entire
RDATA string whenever algorithm is zero, and irrespective of actual values
in other fields.

The RFC is conspicuously silent about the equivalent wire-format
representation.


This avoids the need of defining new format and updating all the
> deployed software. It's not only about parsers of the wire format but
> also about zone file parsers, that would need an update as the single
> zero is not conformant with currently defined presentation format of
> CDS/CDNSKEY RRs.
>

It is clear from the text of draft-ietf-dnsop-maintain-ds-04 that the
notion of mandated presentation format notation was already present.
Moreover, that version also carried the warning:

This is a change in format from strict interpretation of
[RFC7344] and may cause problems with some deployed software.

Your primary argument was therefore a non-starter even before the
appearance of the unparseable single zero.


I believe changing RRdata format just for this one purpose would add an
> unnecessary complexity.
>
> That train has already left the station.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

 Comments in line below

On 23 June 2017 at 12:37, Ólafur Guðmundsson  wrote:

> The errata is correct.
>


I beg to disagree.

In each case,

  CDS 0 0 0 0

  CDNSKEY 0 3 0 0

the final "0" is a conventional token representing a zero-length key field.
In neither case is it an attempt to specify a single octet key value.

A zone file parser is expected to recognise the zero algorithm field and
hence abstain from attempting to parse the non-existent key.

The fact that the placeholder is unparseable should be regarded not as an
error but a useful feature designed to root out under-performing zone file
parsers.

However, all of this confusion could have been avoided if RFC8078 had also
specified the corresponding RDATA wire format in each case.

Although this erratum should be rejected as it stands, it clearly does
identify an issue with RFC8078 which needs to be rectified at the earliest
opportunity.


--Dick



On Jun 23, 2017 11:54, "RFC Errata System" 
> wrote:
>
>> The following errata report has been submitted for RFC8078,
>> "Managing DS Records from the Parent via CDS/CDNSKEY".
>>
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5049
>>
>> --
>> Type: Technical
>> Reported by: Ondřej Caletka 
>>
>> Section: 4
>>
>> Original Text
>> -
>>The contents of the CDS or CDNSKEY RRset MUST contain one RR and only
>>contain the exact fields as shown below.
>>
>>   CDS 0 0 0 0
>>
>>   CDNSKEY 0 3 0 0
>>
>>The keying material payload is represented by a single 0.  This
>>record is signed in the same way as regular CDS/CDNSKEY RRsets are
>>signed.
>>
>>Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the
>>DNSKEY algorithm is what signals the DELETE operation, but for
>>clarity, the "0 0 0 0" notation is mandated -- this is not a
>>definition of DS digest algorithm 0.  The same argument applies to
>>"CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by
>>[RFC4034], Section 2.1.2.
>>
>>
>> Corrected Text
>> --
>>The contents of the CDS or CDNSKEY RRset MUST contain one RR and only
>>contain the exact fields as shown below.
>>
>>   CDS 0 0 0 00
>>
>>   CDNSKEY 0 3 0 AA==
>>
>>The keying material payload is represented by a single octet with
>>the value 00. This record is signed in the same way as regular
>>CDS/CDNSKEY RRsets are signed.
>>
>>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.
>>
>> Notes
>> -
>> RFC 7344 defines both CDS and CDNSKEY record wire and presentation format
>> to be identical to DS and DNSKEY wire and presentation format defined in
>> RFC 4034.
>>
>> In case of CDNSKEY record, RFC 4034 section 2.2 requires that:
>> > The Public Key field MUST be represented as a Base64 encoding of the
>> Public Key.
>>
>> As Base64 encoding encodes 6 bits into one character, one character alone
>> can never be a valid Base64 sequence. The proper encoding of one-byte long
>> sequence with binary value of 00 is AA==.
>>
>> In case of CDS record, RFC 4034 section 5.3 requires that:
>> > The Digest MUST be represented as a sequence of case-insensitive
>> hexadecimal digits
>>
>> Although the value of a single 0 fulfils this requirement per se, it's
>> not properly parsable by many implementations since it is expected to be
>> even number of hex digits to align with octet boundaries in the wire
>> format. So proper form of CDS record should contain two zeroes in place of
>> the digest.
>>
>> 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
>> can log in to change the status and edit the report, if necessary.
>>
>> --
>> RFC8078 (draft-ietf-dnsop-maintain-ds-06)
>> --
>> Title   : Managing DS Records from the Parent via CDS/CDNSKEY
>> Publication Date: March 2017
>> Author(s)   : O. Gudmundsson, P. Wouters
>> Category: PROPOSED STANDARD
>> Source  : Domain Name System Operations
>> Area: Operations and Management
>> Stream  : IETF
>> Verifying Party : IESG
>>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

Re: [DNSOP] search for reference

[Dick Franks]

If you generate keys using the dnssec-keygen that comes with BIND, then
ISC's arbitrary numbers are exposed as follows:

HMAC-MD5157a.k.a.  HMAC-MD5.SIG-ALG.REG.INT
HMAC-SHA1   161
HMAC-SHA224   162
HMAC-SHA256   163
HMAC-SHA384   164
HMAC-SHA512   165


Dick Franks



On 30 December 2016 at 11:20, A. Schulze <s...@andreasschulze.de> wrote:

>
> Mukund Sivaraman:
>
> TSIG uses DNS names for encoding the algorithm type.
>>
> I didn't expected that...
>
>
> Thanks!
>
>
>
> ___
> 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

Re: [DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt

[Dick Franks]

My mistake. Apologies.

I also had draft-wouters-sury-dnsop-algorithm-update-02
on screen. That has the registry table with same TBDs.
Starting at 04:30 dulls the brain.


Dick Franks



On 15 November 2016 at 17:05, Ondřej Surý <ondrej.s...@nic.cz> wrote:

> The IANA Considerations Sections says:
>
> This document updates the IANA registry "Domain Name System Security
> (DNSSEC) Algorithm Numbers".
>
> And I believe that's the correct language according to
> https://tools.ietf.org/html/rfc5226#section-5.1
>
> Cheers,
> Ondrej
>
> --
>  Ondřej Surý -- Technical Fellow
>  
>  CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC
>  Milesovska 5, 130 00 Praha 3, Czech Republic
>  mailto:ondrej.s...@nic.czhttps://nic.cz/
>  --------
>
> - Original Message -
> > From: "Dick Franks" <rwfra...@acm.org>
> > To: "Ondřej Surý" <ondrej.s...@nic.cz>
> > Cc: "dnsop" <dnsop@ietf.org>
> > Sent: Tuesday, 15 November, 2016 17:51:56
> > Subject: Re: [DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-
> eddsa-02.txt
>
> > Ondrej
> >
> > The document calls up two TBD code points for the EDDSA algorithms, but
> the
> > IANA Considerations section places no action on IANA to assign these and
> > add them to the registry.
> >
> > Other than that, seems ok.
> >
> >
> > Dick Franks
> > 
> >
> >
> > On 14 November 2016 at 23:22, Ondřej Surý <ondrej.s...@nic.cz> wrote:
> >
> >> Dear all,
> >>
> >> a new version of EDDSA for DNSSEC has been posted
> >> that resolves most if not all comments received
> >> during WGLC in curdle.  This is one last chance
> >> to review the document, so don't miss it! :)
> >>
> >> Cheers,
> >> --
> >>  Ondřej Surý -- Technical Fellow
> >>  
> >>  CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC
> >>  Milesovska 5, 130 00 Praha 3, Czech Republic
> >>  mailto:ondrej.s...@nic.czhttps://nic.cz/
> >>  
> >>
> >> - Forwarded Message -
> >> From: internet-dra...@ietf.org
> >> To: i-d-annou...@ietf.org
> >> Cc: "curdle" <cur...@ietf.org>
> >> Sent: Tuesday, 15 November, 2016 00:10:15
> >> Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >> This draft is a work item of the CURves, Deprecating and a Little more
> >> Encryption of the IETF.
> >>
> >> Title   : EdDSA for DNSSEC
> >> Authors : Ondrej Sury
> >>   Robert Edmonds
> >> Filename: draft-ietf-curdle-dnskey-eddsa-02.txt
> >> Pages   : 8
> >> Date: 2016-11-14
> >>
> >> Abstract:
> >>This document describes how to specify EdDSA keys and signatures in
> >>DNS Security (DNSSEC).  It uses the Edwards-curve Digital Security
> >>Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/
> >>
> >> There's also a htmlized version available at:
> >> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-02
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-dnskey-eddsa-02
> >>
> >>
> >> 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/
> >>
> >> ___
> >> Curdle mailing list
> >> cur...@ietf.org
> >> https://www.ietf.org/mailman/listinfo/curdle
> >>
> >> ___
> >> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt

[Dick Franks]

Ondrej

The document calls up two TBD code points for the EDDSA algorithms, but the
IANA Considerations section places no action on IANA to assign these and
add them to the registry.

Other than that, seems ok.


Dick Franks



On 14 November 2016 at 23:22, Ondřej Surý <ondrej.s...@nic.cz> wrote:

> Dear all,
>
> a new version of EDDSA for DNSSEC has been posted
> that resolves most if not all comments received
> during WGLC in curdle.  This is one last chance
> to review the document, so don't miss it! :)
>
> Cheers,
> --
>  Ondřej Surý -- Technical Fellow
>  
>  CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC
>  Milesovska 5, 130 00 Praha 3, Czech Republic
>  mailto:ondrej.s...@nic.czhttps://nic.cz/
>  
>
> - Forwarded Message -
> From: internet-dra...@ietf.org
> To: i-d-annou...@ietf.org
> Cc: "curdle" <cur...@ietf.org>
> Sent: Tuesday, 15 November, 2016 00:10:15
> Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the CURves, Deprecating and a Little more
> Encryption of the IETF.
>
> Title   : EdDSA for DNSSEC
> Authors : Ondrej Sury
>   Robert Edmonds
> Filename: draft-ietf-curdle-dnskey-eddsa-02.txt
> Pages   : 8
> Date: 2016-11-14
>
> Abstract:
>This document describes how to specify EdDSA keys and signatures in
>DNS Security (DNSSEC).  It uses the Edwards-curve Digital Security
>Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-dnskey-eddsa-02
>
>
> 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/
>
> ___
> Curdle mailing list
> cur...@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>
> ___
> 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

Re: [DNSOP] Erratra rejection

[Dick Franks]

On 11 March 2016 at 17:47, Robert Edmonds <edmo...@mycre.ws> wrote:

> Dick Franks wrote:
> > There is no need to resort to doctrinal arguments about MUST/SHOULD, or
> > imagine that the RFC6844 tail can wag the RFC1035 dog.
> >
> > Mark A's objection really points a fundamental contradiction in RFC6844
> > itself.
>
> Hi, Dick:
>
> Are you implying that 6844 violates 1035 in some way?


6844 5.1.1 defines the tag field in a way which forbids the (arbitrary)
characters which MAY (but SHOULD NOT) be present according to the text in
5.1.

This conflicts with the 1035 notion that master files contain text
representation of RRs.


I understand the
> reasoning in the erratum rejection:
>
> [...]
>
> The author believes SHOULD is correct here. The protocol on the wire
> will work just fine if someone breaks this advice.
>
> Yes, it might well break some zone file parsers. But those aren't on
> the wire and that type of incompatibility is exactly what I would
> expect from violating a SHOULD.
>
> [...]
>
> to be asserting that a valid wire format RR can have no valid canonical
> presentation format.


But CAA _does_ have a canonical presentation format, defined at 5.1.1.


The closest requirement I can find in 1035 is this:
>
> 5. MASTER FILES
>
> Master files are text files that contain RRs in text form.  Since the
> contents of a zone can be expressed in the form of a list of RRs a
> master file is most often used to define a zone, though it can be used
> to list a cache's contents.
>

So are you really suggesting flipping between canonical 6844 format and
3597 \# format merely because the tag field happens to contain some
non-alphanumeric character or upper case letter?


> RFC6844 offers no justification for case folding, so
> > specifying exact matching would make the whole issue go away.
>
> I would hazard a guess that the "Matching of tag values is case
> insensitive" sentence is a requirement on applications that consume the
> RR, and not to DNS protocol comparisons like RRset data equality or
> DNSSEC canonical form. (Note the sentence "Applications that interpret
> CAA records..." a few lines up.)
>

An unnecessary complication in my view, but maybe that is off-topic here.


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

Re: [DNSOP] Erratra rejection

[Dick Franks]

There is no need to resort to doctrinal arguments about MUST/SHOULD, or
imagine that the RFC6844 tail can wag the RFC1035 dog.

Mark A's objection really points a fundamental contradiction in RFC6844
itself.

RFC6844:

5.1.1.  Canonical Presentation Format

   The canonical presentation format of the CAA record is:
[snip]

   Tag:  Is a non-zero sequence of US-ASCII letters and numbers in lower
  case.

[I assume "non-zero" really means "non-empty"]


is incompatible with the text in 5.1:

   Tag:  The property identifier, a sequence of US-ASCII characters.

  Tag values MAY contain US-ASCII characters 'a' through 'z', 'A'
  through 'Z', and the numbers 0 through 9.  Tag values SHOULD NOT
  contain any other characters.  Matching of tag values is case
  insensitive.

  Tag values submitted for registration by IANA MUST NOT contain any
  characters other than the (lowercase) US-ASCII characters 'a'
  through 'z' and the numbers 0 through 9.


which not only appears to imply the existence of two distinct species of
tag identifiers, but has the bizarre consequence that not all tag
identifiers are exactly representable using the canonical format prescribed
by section 5.1.1

The same form of words, or at least compatible words, should be used in
both places.  RFC6844 offers no justification for case folding, so
specifying exact matching would make the whole issue go away.


Dick Franks



On 10 March 2016 at 20:34, Mark Andrews <ma...@isc.org> wrote:

>
> I believe the erratra below was rejected incorrectly.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Setting the AD bit in the query changes whether you get the AD bit in the response?

[Dick Franks]

On 7 February 2016 at 00:36, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
[snip]

> I can't find anywhere in 403[3:5] that says that the AD bit in the request
> means anything. Did I miss that? Or is it specified in a different RFC?
>
> RFC6840

5.7.  Setting the AD Bit on Queries

   The semantics of the Authentic Data (AD) bit in the query were
   previously undefined.  Section 4.6 of [RFC4035] instructed resolvers
   to always clear the AD bit when composing queries.

   This document defines setting the AD bit in a query as a signal
   indicating that the requester understands and is interested in the
   value of the AD bit in the response.  This allows a requester to
   indicate that it understands the AD bit without also requesting
   DNSSEC data via the DO bit.
5.8.  Setting the AD Bit on Replies

   Section 3.2.3 of [RFC4035] describes under which conditions a
   validating resolver should set or clear the AD bit in a response.  In
   order to interoperate with legacy stub resolvers and middleboxes that
   neither understand nor ignore the AD bit, validating resolvers SHOULD
   only set the AD bit when a response both meets the conditions listed
   in Section 3.2.3 of [RFC4035], and the request contained either a set
   DO bit or a set AD bit.


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

Re: [DNSOP] Setting the AD bit in the query changes whether you get the AD bit in the response?

[Dick Franks]

On 7 February 2016 at 00:36, Paul Hoffman <paul.hoff...@vpnc.org> wrote:

> Greetings again. While doing some testing, I came across something that is
> both consistent across implementations but that I do not find in RFC 4033,
> 4034, or 4035. If a query for a properly-signed zone is sent to
> BIND-as-recursor, Unbound, or Google DNS, and the AD bit in the request is
> set to 1, the answer returned has the AD bit set to 1. However, if the
> query has the AD bit set to 0, the response always has the AD bit set to 0,
> even though the requested zone is properly signed.
>
> This happens regardless of whether or not there is an EDNS0 extension with
> the DO bit set to 1.
>
> I can't find anywhere in 403[3:5] that says that the AD bit in the request
> means anything. Did I miss that? Or is it specified in a different RFC?
>
> RFC6840

5.7.  Setting the AD Bit on Queries

   The semantics of the Authentic Data (AD) bit in the query were
   previously undefined.  Section 4.6 of [RFC4035] instructed resolvers
   to always clear the AD bit when composing queries.

   This document defines setting the AD bit in a query as a signal
   indicating that the requester understands and is interested in the
   value of the AD bit in the response.  This allows a requester to
   indicate that it understands the AD bit without also requesting
   DNSSEC data via the DO bit.
5.8.  Setting the AD Bit on Replies

   Section 3.2.3 of [RFC4035] describes under which conditions a
   validating resolver should set or clear the AD bit in a response.  In
   order to interoperate with legacy stub resolvers and middleboxes that
   neither understand nor ignore the AD bit, validating resolvers SHOULD
   only set the AD bit when a response both meets the conditions listed
   in Section 3.2.3 of [RFC4035], and the request contained either a set
   DO bit or a set AD bit.


--

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

Re: [DNSOP] Order of DNS records...

[Dick Franks]

Attempt to repeat your result using

 #!/usr/bin/perl -w
 #
 use Net::DNS 1.01;

 my $resolver = new Net::DNS::Resolver( nameserver => 'ns02.one.com.',
dnssec => 1 );
 $resolver->send(qw( masters-consultants.fr SOA ))->print;
 #

returned RRSIG first for 44% of my statistically dubious sample.


Dick Franks



On 11 January 2016 at 21:20, Stephane Bortzmeyer <bortzme...@nic.fr> wrote:

> Interesting: it sends the signature before the SOA (and it breaks at
> least one DNS program - one of mine, shame):
>
> % dig @ns02.one.com. SOA masters-consultants.fr.
>
> ; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @ns02.one.com. SOA
> masters-consultants.fr.
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51995
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1680
> ;; QUESTION SECTION:
> ;masters-consultants.fr.IN SOA
>
> ;; ANSWER SECTION:
> masters-consultants.fr. 14400 IN RRSIG SOA 8 2 14400 (
> 2016012100 2015123100 58536
> masters-consultants.fr.
>
> FOZbAQLnjdq9GPIvAJWUi5LURWMBubbFAMj6q/GVn2mu
>
> jdU8IjNL+9+pxY/hZCEFd2Fpubkslvl161q6eYXR3Po0
>
> xbI54ZDVvGOvUG/7zhHhwZKTYfoksjQdGjrwfyvdg8F0
>
> JcMV8v0jd8433Vm+d7VkSeomfbMXOlImKIUutQ1KqlBR
> rP0tiuhzXWNZmb8jL4nPg46kc/sqmObbQW2Ujg== )
> masters-consultants.fr. 14400 IN SOA ns01.one.com. hostmaster.one.com. (
> 2016010811 ; serial
> 14400  ; refresh (4 hours)
> 3600   ; retry (1 hour)
> 1209600; expire (2 weeks)
> 900; minimum (15 minutes)
> )
>
> ;; Query time: 154 msec
> ;; SERVER: 2001:67c:28cc::138#53(2001:67c:28cc::138)
> ;; WHEN: Mon Jan 11 22:19:03 CET 2016
> ;; MSG SIZE  rcvd: 324
>
> ___
> 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

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

[Dick Franks]

Dick Franks



On 1 October 2015 at 11:12, Shane Kerr <sh...@time-travellers.org> wrote:

>
> In the case where people just want to reduce the damage of ANY queries
> in reflection attacks, I quite like the PowerDNS option of forcing ANY
> queries to TCP via truncation. I'm not sure if this has been documented
> in any RFC, but if not then perhaps it bears mentioning too?
>

That rests on two assumptions:

1)  that damage limitation from reflection attacks is the primary concern
here, which appears no longer to be the case.

2) that there is some plausible reason for doing ANY queries, in which case
it would be interesting to know what that might be.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?

[Dick Franks]

Next release of Net::DNS::SEC will support  ECDSA and ECC-GOST


Dick Franks



On 19 January 2015 at 15:17, Warren Kumari war...@kumari.net wrote:



 On Monday, January 19, 2015, Francis Dupont francis.dup...@fdupont.fr
 wrote:

  In your previous mail you wrote:

   Currently a number of validators don't do ECC, because of the openssl
   library from the distribution they are using doesn't include support.
   This makes ECC an unsupported algorithm, and so it fails open (See
   RFC4035, Section 5.2, around If the validator does not support any of
   the algorithms...). Geoff also has a good blog post
   (http://labs.apnic.net/blabs/?p=544) and presentations at various
 places
   (e.g: https://ripe69.ripe.net/presentations/135-18-2014-11-01-ecc.pptx
 ).

 = This very unfortunate fact is IMHO the major (and perhaps only) issue
 to solve before deploying ECDSA (and solve the RSA/SHA-1 vs RSA/SHA-2
 question).



 Unfortunately not the only - we also need the registrars to accept ECDSA.
 But yes, this is annoying- rolling the DNSSEC root key to ECDSA would be
 very cool, as we could then fit 2 signatures well within the IPv6 MTU.

 Oh, as was pointed out earlier, Google Public DNS does ECDSA.

 W



   I suggest that folk whose ssl libraries don't support ECC should
   figure out why (see http://tools.ietf.org/html/rfc6090 and also
   Geoff's blog post for some background) and then recompile with
   support[0].

 = I can't say more.

 Thanks

 francis.dup...@fdupont.fr



 --
 I don't think the execution is relevant when it was obviously a bad idea
 in the first place.
 This is like putting rabid weasels in your pants, and later expressing
 regret at having chosen those particular rabid weasels and that pair of
 pants.
---maf

 ___
 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

Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?

[Dick Franks]

Next release of Net::DNS::SEC will support  ECDSA and ECC-GOST


Dick Franks



On 19 January 2015 at 15:17, Warren Kumari war...@kumari.net wrote:



 On Monday, January 19, 2015, Francis Dupont francis.dup...@fdupont.fr
 wrote:

  In your previous mail you wrote:

   Currently a number of validators don't do ECC, because of the openssl
   library from the distribution they are using doesn't include support.
   This makes ECC an unsupported algorithm, and so it fails open (See
   RFC4035, Section 5.2, around If the validator does not support any of
   the algorithms...). Geoff also has a good blog post
   (http://labs.apnic.net/blabs/?p=544) and presentations at various
 places
   (e.g: https://ripe69.ripe.net/presentations/135-18-2014-11-01-ecc.pptx
 ).

 = This very unfortunate fact is IMHO the major (and perhaps only) issue
 to solve before deploying ECDSA (and solve the RSA/SHA-1 vs RSA/SHA-2
 question).



 Unfortunately not the only - we also need the registrars to accept ECDSA.
 But yes, this is annoying- rolling the DNSSEC root key to ECDSA would be
 very cool, as we could then fit 2 signatures well within the IPv6 MTU.

 Oh, as was pointed out earlier, Google Public DNS does ECDSA.

 W



   I suggest that folk whose ssl libraries don't support ECC should
   figure out why (see http://tools.ietf.org/html/rfc6090 and also
   Geoff's blog post for some background) and then recompile with
   support[0].

 = I can't say more.

 Thanks

 francis.dup...@fdupont.fr



 --
 I don't think the execution is relevant when it was obviously a bad idea
 in the first place.
 This is like putting rabid weasels in your pants, and later expressing
 regret at having chosen those particular rabid weasels and that pair of
 pants.
---maf

 ___
 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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Dick Franks]

On 22 September 2014 12:27, Tony Finch d...@dotat.at wrote:

 Dick Franks rwfra...@acm.org wrote:
  On 22 September 2014 11:03, Tony Finch d...@dotat.at wrote:
  
   (1) Master-only. The master observes an ANAME record at the apex of a
 zone
   it loads and uses it to periodically refresh the relevant records in
 the
   zone (as if you had a cron job running dig | magic | nsupdate).
  
   Disadvantage: potentially lots of XFR traffic if the TTLs are low.
 
  Why would TTL be relevant here?
 
  Is the master not acting as a partial slave for the target RRs?
  In which case, the timing should depend on the SOA refresh period.

 Yes, you could do it that way. But a lot of people want changes to take
 effect quickly.

 So whenever TTL times out, master does validated lookup of each ANAME
target, resigns, updates zone, notifies own slaves, services XFRs.

Someone beyond your direct control sets a short TTL (0 or 1) in ANAME
target RRs and your master is in deep, deep [trouble] !!

Thinking about it, (target side) SOA refresh is not much better.



 And I forgot to cover the effects that client-subnet might have ...

  I do not know either


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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Dick Franks]

On 21 September 2014 19:14, bert hubert bert.hub...@netherlabs.nl wrote:

 On Sun, Sep 21, 2014 at 08:13:46AM -0700, Paul Hoffman wrote:

   PS: the above is currently not yet supported for DNSSEC domains!
 
  Can you say (much) more about that aside? Does it mean that the server


 An interesting opening is that we'd be signing potentially unsigned data
 this way. Potentially, we should check for the AD bit. But first let's see
 how this idea fits.

 Must validate the response. Otherwise bad actor can just toss in a bogus
AD bit!
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

[Dick Franks]

Mark,

Surely, something stronger than a reminder is appropriate.

For a mission-critical requirement, this needs to be an explicit and
unambiguous request:

This document directs IANA to create insecure delegations
 for the listed zones.


Dick




On 14 August 2014 01:16, Mark Andrews ma...@isc.org wrote:


 Can we please move on this.

 The reverse address are not yet insecurely delegated as
 would be required for RFC 6598 compliance.  This is starting
 to cause operational problems for ISP's that validate DNS
 responses as they can't deploy local IN-ADDR.ARPA zones
 until that insecure delegation is done.

 Also should I add a reminder to the IANA Considerations that
 the insecure delegation needs to be performed?

 e.g.

 IANA is reminded that a insecure delegation for these zones
 is required for compliance with RFC 6598 to break the DNSSEC
 chain of trust.

 Mark
 --
 Mark Andrews, ISC
 1 Seymour St., Dundas Valley, NSW 2117, Australia
 PHONE:  +61 2 9871 4742 INTERNET: ma...@isc.org

 ___
 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

Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B)

[Dick Franks]

On 11 April 2012 14:48, Matthijs Mekking matth...@nlnetlabs.nl wrote:



 On 04/05/2012 12:48 AM, Alfred � wrote:
 
  |  o  Signature validity period The time interval during which a
  | signature is valid.  It starts at the (absolute) time specified in
  | the signature inception field of the RRSIG RR and ends at the
  | (absolute) time specified in the expiration field of the RRSIG RR.

 I don't see why this should be changed. Do you prefer interval over
 period? Do you want the clarify that the times are absolute? This is a
 non-issue in my opinion.


 The word 'period' means the (constant) interval between events in a
sequence; for example, the orbital period of a satellite.

The time elapsed between aperiodic events occurring at times t1 and t2 is
best described as an interval of duration (t2-t1).

Absolute time was deprecated in 1905.

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