[DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

[Tim Wicinski]

Hi

We've been talking with the authors of Extended Error and now that
they've gotten around to updating the document, and the chairs
feel it is ready for Working Group Last Call.

We're going to kick this WGLC off this week and run it through IETF103.
This will give folks time during the meeting to bring up any issues
they may have there.


This starts a Working Group Last Call for draft-ietf-dnsop-extended-error

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/


The Current Intended Status of this document is: Standards Track

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication,
please speak out with your reasons.

This starts a two+ week Working Group Last Call process,
and ends on at the end of IETF 103: 9 November 2018

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

[DNSOP] Reserved field in draft-wessels-dns-zone-digest-04.txt

[Paul Hoffman]

Section 5 says:

   FOR DISCUSSION: The authors are willing to remove the Reserved field
   from this specification if the working group would prefer it.  It
   would mean, however, that a future version of this protocol designed
   to efficiently support large, dynamic zones would most likely require
   a new RR type.

Please strongly consider removing the Reserved field so that designing an way 
to do a message digest over a dynamic zone can be done independently.

Quite frankly, if the Reserved field isn't there and it's clear that this is 
for complete zones, I see no reason why this should even be considered 
experimental. The mic line at the presentation at the recent DNS-OARC seems to 
agree with wanting this for real, as soon as possible.

--Paul Hoffman

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

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

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : Algorithm Implementation Requirements and Usage 
Guidance for DNSSEC
Authors : Paul Wouters
  Ondrej Sury
Filename: draft-ietf-dnsop-algorithm-update-04.txt
Pages   : 11
Date: 2018-10-23

Abstract:
   The DNSSEC protocol makes use of various cryptographic algorithms in
   order to provide authentication of DNS data and proof of non-
   existence.  To ensure interoperability between DNS resolvers and DNS
   authoritative servers, it is necessary to specify a set of algorithm
   implementation requirements and usage guidelines to ensure that there
   is at least one algorithm that all implementations support.  This
   document defines the current algorithm implementation requirements
   and usage guidance for DNSSEC.  This document obsoletes [RFC6944].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-04
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-algorithm-update-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-algorithm-update-04


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

[Tim Wicinski]

Versions are cheap. spin a new one while I work on the shepherd write up

On Tue, Oct 23, 2018 at 11:04 PM Ondřej Surý  wrote:

> Dick, good catch!
>
> Tim, do you want me to publish -04 addressing this or would it be better
> to fix this in RFC Editor queue.
>
> The diff is simple:
>
>
> https://github.com/oerdnj/draft-ietf-dnsop-algorithm-update/commit/7164f8a6ee4b210f5d83684156cb2905769f7fb4#diff-e9d2d55442440292530838192590a871
>
> O.
> --
> Ondřej Surý
> ond...@isc.org
>
> > On 23 Oct 2018, at 22:37, Dick Franks  wrote:
> >
> > 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] I-D Action: draft-ietf-dnsop-algorithm-update-03.txt

[Ondřej Surý]

Dick, good catch!

Tim, do you want me to publish -04 addressing this or would it be better to fix 
this in RFC Editor queue.

The diff is simple:

https://github.com/oerdnj/draft-ietf-dnsop-algorithm-update/commit/7164f8a6ee4b210f5d83684156cb2905769f7fb4#diff-e9d2d55442440292530838192590a871

O.
--
Ondřej Surý
ond...@isc.org

> On 23 Oct 2018, at 22:37, Dick Franks  wrote:
> 
> 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] 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

[DNSOP] I-D Action: draft-ietf-dnsop-session-signal-18.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : DNS Stateful Operations
Authors : Ray Bellis
  Stuart Cheshire
  John Dickinson
  Sara Dickinson
  Ted Lemon
  Tom Pusateri
Filename: draft-ietf-dnsop-session-signal-18.txt
Pages   : 66
Date: 2018-10-23

Abstract:
   This document defines a new DNS OPCODE for DNS Stateful Operations
   (DSO).  DSO messages communicate operations within persistent
   stateful sessions, using type-length-value (TLV) syntax.  Three TLVs
   are defined that manage session timeouts, termination, and encryption
   padding, and a framework is defined for extensions to enable new
   stateful operations.  This document updates RFC 1035 by adding a new
   DNS header opcode which has different message semantics, and a new
   result code.  This document updates RFC 7766 by redefining a session,
   providing new guidance on connection re-use, and providing a new
   mechanism for handling session idle timeouts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-18
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-session-signal-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-18


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-17.txt

[Ted Lemon]

On Oct 23, 2018, at 4:10 PM, Bob Harold  wrote:
> Page 6
> "Early Data"
> The last phrase:
> "a TCP SYN message that does not use TLS
>   encapsulation but contains is not permitted."
>  Seems to be missing something, like "but contains early data is not 
> permitted."
> Was there in the previous version, but accidentally deleted?


Sigh.   Thanks, Bob.   :]

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-17.txt

[Bob Harold]

On Tue, Oct 23, 2018 at 3:49 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the
> IETF.
>
> Title   : DNS Stateful Operations
> Authors : Ray Bellis
>   Stuart Cheshire
>   John Dickinson
>   Sara Dickinson
>   Ted Lemon
>   Tom Pusateri
> Filename: draft-ietf-dnsop-session-signal-17.txt
> Pages   : 66
> Date: 2018-10-23
>
> Abstract:
>This document defines a new DNS OPCODE for DNS Stateful Operations
>(DSO).  DSO messages communicate operations within persistent
>stateful sessions, using type-length-value (TLV) syntax.  Three TLVs
>are defined that manage session timeouts, termination, and encryption
>padding, and a framework is defined for extensions to enable new
>stateful operations.  This document updates RFC 1035 by adding a new
>DNS header opcode which has different message semantics, and a new
>result code.  This document updates RFC 7766 by redefining a session,
>providing new guidance on connection re-use, and providing a new
>mechanism for handling session idle timeouts.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-17
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-session-signal-17
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-17


Page 6
"Early Data"
The last phrase:
"a TCP SYN message that does not use TLS
  encapsulation but contains is not permitted."
 Seems to be missing something, like "but contains early data is not
permitted."
Was there in the previous version, but accidentally deleted?

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

Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Ted Lemon]

On Mon, Oct 15, 2018 at 10:02 AM Mirja Kuehlewind (IETF) <
i...@kuehlewind.net> wrote:

> sorry for the delay, however, as you performed a couple of changes it took
> me a while to re-review. I believe I’m unfortunately not fully ready to
> release my discuss at this point, but close..
>

No worries—it's a busy time.


> Regarding my first discuss point (delayed ACKs aso.) I think the text
> improved and  I would like to seem my minor wording question (comment 2)
> below addressed before I finally release the discuss here. However, I still
> think the extensive discussion as provided in section 9.5 now, does not
> necessarily belong in this document. Therefore I would rather would have
> preferred to move this text in a real appendix, or removed it completely
> and maybe document in an own informational RFC (in tcpm).
>
> Regarding my second discuss point (keep-alives), the text seems still not
> quite right yet, or I’m really confused. Please also see also further below
> (comment 3).
>
> Anyway here are my comments on the edited/new text in the order they
> appear in the draft:
>
> 1) I think the following text in section 3 is not fully correct:
>
> "Fast Open message: A TCP SYN packet that begins a DSO connection and
>contains early data ([RFC8446] section 2.3).  Fast Open is only
>permitted when using TLS encapsulation: a TCP SYN message that does
>not use TLS encapsulation but contains early data is not permitted.“
> If TLS 0-RTT is used this data will not be carried in the TCP SYN, it will
> „just“ be send at the same time as the TLS handshake is performed (but
> after the TCP handshake). Only if TCP Fast Open (TFO) (see RFC7413) is
> used, data can also be sent in the TCP SYN. I guess you mainly need to fix
> the reference here, or maybe name both mechanisms separately.
>

If you look at the table on p. 18 of RFC8447, it shows early data being
sent in the first packet.  What am I missing here?


> 2) In section 5.5.1:
>"With a DSO request message, the TCP implementation waits for the
>application-layer client software to generate the corresponding DSO
>response message, which enables the TCP implementation to send a
>single combined IP packet containing the TCP acknowledgement, the TCP
>window update, and the application-generated DSO response message.
>This is more efficient than sending three separate IP packets.“
>
> The phrasing here is a bit confusing, to me at least. It sounds a bit like
> there is a special TCP for DSO… maybe the following is a bit better:
>"With a DSO request message, TCP delayed acknowledge timer will usually
>make the implementation wait for the
>application-layer client software to generate the corresponding DSO
>response message before it sends out an TCP acknowledgment
>This will generate a
>single combined IP packet containing the TCP acknowledgement, the TCP
>window update, and the application-generated DSO response message and
>is more efficient than sending three separate IP packets.“
>
> (Note that the deplayed ack timer can be configured to a very small value
> as well, and as such it depends on the processing time and the value of the
> timer if a TCP implementation will wait or not.)
>

I think using the passive voice here makes the text harder to follow, but I
see what you are saying.   How about this:

With a bidirectional exchange over TCP, as for example with a DSO request
message, the operating system TCP implementation waits for the
application-layer client software to generate the corresponding DSO
response message.   It can then send a
single combined packet containing the TCP acknowledgement, the
TCP window update, and the application-generated DSO response message.
This is more efficient than sending three separate packets, as would occur
if
the TCP packet containing the DSO request were acknowledged immediately.

3) Section 6.5.2
> "For example, a (hypothetical and unrealistic)
>keepalive interval value of 100 ms would result in a continuous
>stream of ten messages per second or more, in both directions, to
>keep the DSO Session alive.  And, in this extreme example, a single
>packet loss and retransmission over a long path could introduce a
>momentary pause in the stream of messages of over 200 ms, long enough
>to cause the server to overzealously abort the connection.“
> I think this example is still not correct (and the changes might made have
> it worse: how can there be more then 10 messages?)


> So the point here is that there is a dependency on the RTT. Only if the
> RTT is smaller than 200ms this can happen, otherwise the connection is
> closed anyway after two keep-alives. However, if the RTT is much smaller
> than 100ms and e.g. TLP is used, it would still work even if one packet is
> lost.
>

Remember that keepalives are not synchronous.   That is, if we send a
keepalive, we don't wait for the response.   So it's perfectly possible for
there to be se

[DNSOP] I-D Action: draft-ietf-dnsop-session-signal-17.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : DNS Stateful Operations
Authors : Ray Bellis
  Stuart Cheshire
  John Dickinson
  Sara Dickinson
  Ted Lemon
  Tom Pusateri
Filename: draft-ietf-dnsop-session-signal-17.txt
Pages   : 66
Date: 2018-10-23

Abstract:
   This document defines a new DNS OPCODE for DNS Stateful Operations
   (DSO).  DSO messages communicate operations within persistent
   stateful sessions, using type-length-value (TLV) syntax.  Three TLVs
   are defined that manage session timeouts, termination, and encryption
   padding, and a framework is defined for extensions to enable new
   stateful operations.  This document updates RFC 1035 by adding a new
   DNS header opcode which has different message semantics, and a new
   result code.  This document updates RFC 7766 by redefining a session,
   providing new guidance on connection re-use, and providing a new
   mechanism for handling session idle timeouts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-17
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-session-signal-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-17


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

[Tim Wicinski]

Thanks Ondrej

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.

Tim

On Tue, Oct 23, 2018 at 7:55 PM Ondřej Surý  wrote:

> Dear colleagues,
>
> thank you for the valuable feedback during the WGLC.  I have improved the
> document
> based on your comments and I think it’s good to go gold.
>
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
>
> > On 23 Oct 2018, at 19:53, internet-dra...@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Domain Name System Operations WG of the
> IETF.
> >
> >Title   : Algorithm Implementation Requirements and Usage
> Guidance for DNSSEC
> >Authors : Paul Wouters
> >  Ondrej Sury
> >   Filename: draft-ietf-dnsop-algorithm-update-03.txt
> >   Pages   : 11
> >   Date: 2018-10-23
> >
> > Abstract:
> >   The DNSSEC protocol makes use of various cryptographic algorithms in
> >   order to provide authentication of DNS data and proof of non-
> >   existence.  To ensure interoperability between DNS resolvers and DNS
> >   authoritative servers, it is necessary to specify a set of algorithm
> >   implementation requirements and usage guidelines to ensure that there
> >   is at least one algorithm that all implementations support.  This
> >   document defines the current algorithm implementation requirements
> >   and usage guidance for DNSSEC.  This document obsoletes [RFC6944].
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-03
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-algorithm-update-03
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-algorithm-update-03
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
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

[Ondřej Surý]

Dear colleagues,

thank you for the valuable feedback during the WGLC.  I have improved the 
document
based on your comments and I think it’s good to go gold.

Ondrej
--
Ondřej Surý
ond...@isc.org

> On 23 Oct 2018, at 19:53, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>Title   : Algorithm Implementation Requirements and Usage 
> Guidance for DNSSEC
>Authors : Paul Wouters
>  Ondrej Sury
>   Filename: draft-ietf-dnsop-algorithm-update-03.txt
>   Pages   : 11
>   Date: 2018-10-23
> 
> Abstract:
>   The DNSSEC protocol makes use of various cryptographic algorithms in
>   order to provide authentication of DNS data and proof of non-
>   existence.  To ensure interoperability between DNS resolvers and DNS
>   authoritative servers, it is necessary to specify a set of algorithm
>   implementation requirements and usage guidelines to ensure that there
>   is at least one algorithm that all implementations support.  This
>   document defines the current algorithm implementation requirements
>   and usage guidance for DNSSEC.  This document obsoletes [RFC6944].
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-03
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-algorithm-update-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-algorithm-update-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

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

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : Algorithm Implementation Requirements and Usage 
Guidance for DNSSEC
Authors : Paul Wouters
  Ondrej Sury
Filename: draft-ietf-dnsop-algorithm-update-03.txt
Pages   : 11
Date: 2018-10-23

Abstract:
   The DNSSEC protocol makes use of various cryptographic algorithms in
   order to provide authentication of DNS data and proof of non-
   existence.  To ensure interoperability between DNS resolvers and DNS
   authoritative servers, it is necessary to specify a set of algorithm
   implementation requirements and usage guidelines to ensure that there
   is at least one algorithm that all implementations support.  This
   document defines the current algorithm implementation requirements
   and usage guidance for DNSSEC.  This document obsoletes [RFC6944].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-03
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-algorithm-update-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-algorithm-update-03


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

[Ondřej Surý]

> On 21 Oct 2018, at 17:40, fujiw...@jprs.co.jp wrote:
> 
>> From: Vladimír Čunát 
>> On 10/17/18 11:18 PM, fujiw...@jprs.co.jp wrote:
>>> 4. In my opinion, Ed25519 is best algorithm some yars later.
>>>   If the document describes both current RECOMMENDATIONS and
>>>   RECOMMENDATIONS some years later, we can plan.
>> 
>> 
>> I agree, but the last paragraph of 3.1 seems to express that already:
> 
> Yes.
> 
> # I'm afraid that some TLD/Root operators may not support ED25519
> # because it is RECOMMENDED (not MUST).

The I-D already says:

>It is expected that deprecation of an algorithm will be performed
>gradually.  This provides time for various implementations to update
>their implemented algorithms while remaining interoperable.  Unless
>there are strong security reasons, an algorithm is expected to be
>downgraded from MUST to NOT RECOMMENDED or MAY, instead of to MUST
>NOT.  Similarly, an algorithm that has not been mentioned as
>mandatory-to-implement is expected to be introduced with a
>RECOMMENDED instead of a MUST.

and the last paragraph of 3.1 explicitly says:

>   It is
>   expected that ED25519 will become the future RECOMMENDED
>   default algorithm once there's enough support for this
>   algorithm in the deployed DNSSEC validators.

I don’t think more handholding would be appropriate of IETF RFC.

Thanks for all the comments,
--
Ondřej Surý
ond...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

Fujiwara-san,

I don’t exactly understand why such table would be better than existing text 
that say:

> 3.2.  DNSKEY Algorithm Recommendation
> 
>Operation recommendation for new and existing deployments.
> 
>Due to industry-wide trend to move to elliptic curve cryptography,
>the ECDSAP256SHA256 is RECOMMENDED for use by new DNSSEC deployments,
>and users of RSA based algorithms SHOULD upgrade to ECDSAP256SHA256.


I believe this is clear enough.

As for the second column, I am strongly opposed to saying what would the 
recommendation
be in ‘2 years’.  We have no idea about the deployment of Ed25519 resolvers[*], 
neither about
RSA.

But this is a type of document that needs to be regularly refreshed when 
needed, so we can
issue another update in 2-5 years...

Ondrej

* - I also suspect that saying “usable” is too optimistic given that support 
for Ed25519 requires
new OpenSSL 1.1.0 and the general glacier-speed deployments of new software.
--
Ondřej Surý
ond...@isc.org

> On 15 Oct 2018, at 17:04, fujiw...@jprs.co.jp wrote:
> 
> WGLC comment to draft-ietf-dnsop-algorithm-update-02
> 
> Section 3.2 is "recommendations for operators".
> 
> There is texts that discuss ECDSAP256SHA256 only in section 3.2.
> However, RSASHA256 is still usable.
> Please add text about other algorithms.
> if there is a table similar to section 3.1, it will help operators.
> 
> For example,
> choice of| choice of
> sigining algorithm (now) | sigining algorithm (2 years Later)
>  
>  RSASHA1*MUST NOT| MUST NOT
>  RSASHA256   usable  | usable/consider change to EC*/Ed*
>  ECDSAP256*  usable  | usable
>  Ed25519 MAY | usable
> 
> 
> Regards,
> 
> --
> Kazunori Fujiwara, JPRS 
> 
> ___
> 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-kskroll-sentinel-17.txt

[Warren Kumari]

Thank you. I've updated in the editors copy.

W

On Mon, Oct 22, 2018 at 7:02 PM Bob Harold  wrote:

>
> On Sun, Oct 21, 2018 at 3:24 PM  wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Domain Name System Operations WG of the
>> IETF.
>>
>> Title   : A Root Key Trust Anchor Sentinel for DNSSEC
>> Authors : Geoff Huston
>>   Joao Silva Damas
>>   Warren Kumari
>> Filename: draft-ietf-dnsop-kskroll-sentinel-17.txt
>> Pages   : 23
>> Date: 2018-10-21
>>
>> Abstract:
>>The DNS Security Extensions (DNSSEC) were developed to provide origin
>>authentication and integrity protection for DNS data by using digital
>>signatures.  These digital signatures can be verified by building a
>>chain of trust starting from a trust anchor and proceeding down to a
>>particular node in the DNS.  This document specifies a mechanism that
>>will allow an end user and third parties to determine the trusted key
>>state for the root key of the resolvers that handle that user's DNS
>>queries.  Note that this method is only applicable for determining
>>which keys are in the trust store for the root key.
>>
>>[ This document is being collaborated on in Github at:
>>https://github.com/APNIC-Labs/draft-kskroll-sentinel.  The most
>>recent version of the document, open issues, etc should all be
>>available here.  The authors (gratefully) accept pull requests.  RFC
>>Editor, please remove text in square brackets before publication. ]
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-17
>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-17
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-kskroll-sentinel-17
>
>
>  2
> .
> Sentinel Mechanism in Resolvers
>
> As one example, underscore
>  prefixed names were rejected because some browsers and operating
>systems would not fetch them because they domain names but not valid
>hostnames (see [RFC7719] for these definitions).
>
> s/ they domain names / they are domain names /
>
> --
>
> Bob Harold
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


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