Re: [DNSOP] [v6ops] Fwd: New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

[Davey Song]

Hi Jinmei,

Thanks for your comments. I once had same questions in my mind when this
draft is conceived. I reply inline.

Some quick observations:
>
> - I don't see why the intended status is Standards Track.  It seems to
>   be a document about an operational practice rather than a new
>   protocol feature.
>

I agree with your observation here if the draft intends to share
information and practice. It now goes with Standards Track because the
authors would like to provide a new HE feature(or a framework) on network
side as a peering funtion of client-side HE. I would like to see more
feadback on this issues.

- In general, I wouldn't be excited about placing such complicated
>   functionality in the network rather than end hosts.  Sometimes it
>   may be justified as a least evil option, but the current description
>   of the draft didn't fully convince me
>

Before I put down this draft, I talked with some CPs (content/app
providers) and ISPs, they have motivations and requirement on this.  One
example is Tencent, they are planning to deploy a complicated measurement
network to info their Apps (with a SDK ) which address family they should
try first (their apps use dns over http).  I'm told that Tencent think HE
implemented on each client is too complicated (they have comlicated apps)
and resource consuming. ISP's motivation is easy to understood, they always
try to improve their network connenctivity on both IPv4 and IPv6. I have no
more comment on your saying of evil option：） Any technology can be used as
evil purpose I think.

- I suspect the discussion on breaking DNSSEC is way too hand-waving.
>   In my general understanding it's generally not accepted at dnsop to
>   justify breaking DNSSEC just by saying "it's okay as validation at
>   end hosts is not typical".  Especially if it really intends to be
>   published as Standards Track I suspect some more detailed discussion
>   with a stronger justification will be needed.
>

Sorry, I admit current txt on breaking DNSSEC is weak. Now it is put
into Security
Considerations as well as the issues on incoherency. I think one way to
avoid it as suggested in  Security Considerations is to artificially delay
the  answers, other than omitting the  record and its RRSIG

Best regards,
Davey
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [v6ops] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

[Fred Baker]

> On Sep 24, 2018, at 11:14 AM, 神明達哉  wrote:
> 
> At Fri, 21 Sep 2018 14:31:50 +0800,
> Davey Song  wrote:
> 
> > I just submited a new draft intending to provide better connectivity from
> > network side function . Comments are welcome.
> 
> Some quick observations:
> 
> - I don't see why the intended status is Standards Track.  It seems to
>   be a document about an operational practice rather than a new
>   protocol feature.

I think we would have a charter problem as well. V6ops, per charter, can 
produce BCPs and informational documents.

> - In general, I wouldn't be excited about placing such complicated
>   functionality in the network rather than end hosts.  Sometimes it
>   may be justified as a least evil option, but the current description
>   of the draft didn't fully convince me
> 
> - I suspect the discussion on breaking DNSSEC is way too hand-waving.
>   In my general understanding it's generally not accepted at dnsop to
>   justify breaking DNSSEC just by saying "it's okay as validation at
>   end hosts is not typical".  Especially if it really intends to be
>   published as Standards Track I suspect some more detailed discussion
>   with a stronger justification will be needed.
> 
> --
> JINMEI, Tatuya
> ___
> v6ops mailing list
> v6...@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
 Sun Tzu



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [v6ops] Fwd: New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

[神明達哉]

At Fri, 21 Sep 2018 14:31:50 +0800,
Davey Song  wrote:

> I just submited a new draft intending to provide better connectivity from
> network side function . Comments are welcome.

Some quick observations:

- I don't see why the intended status is Standards Track.  It seems to
  be a document about an operational practice rather than a new
  protocol feature.

- In general, I wouldn't be excited about placing such complicated
  functionality in the network rather than end hosts.  Sometimes it
  may be justified as a least evil option, but the current description
  of the draft didn't fully convince me

- I suspect the discussion on breaking DNSSEC is way too hand-waving.
  In my general understanding it's generally not accepted at dnsop to
  justify breaking DNSSEC just by saying "it's okay as validation at
  end hosts is not typical".  Especially if it really intends to be
  published as Standards Track I suspect some more detailed discussion
  with a stronger justification will be needed.

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

[DNSOP] DNSSEC validation

[Djibril ROBLE]

Hi, 

 

I am an administrator of DNS resolvers to Djibouti Telecom.

I updated the root key to our DNS resolvers servers. Is there a way to tell if 
DNSSEC is using the last trusted anchor ( Update on the Root KSK Rollover 
Project) ?
 
# dig @127.0.0.1 dnssec-failed.org a +dnssec



 

Link:  https://www.icann.org/dns-resolvers-checking-current-trust-anchors 

 

Thank you for your answer. 

 

Coordialement 

Djibril ROBLE 

 

De : dns-operations [mailto:dns-operations-boun...@dns-oarc.net] De la part de 
Warren Kumari
Envoyé : vendredi 7 septembre 2018 21:38
À : Steve Crocker
Cc : dnsop; dns-operations
Objet : Re: [dns-operations] [DNSOP] DNSSEC threshold signatures idea

 

 

 

On Thu, Sep 6, 2018 at 2:15 PM Steve Crocker  wrote:

I've been thinking about a version of this problem for several years.  Attached 
are a short paper and presentation on the topic of a tamperproof root zone 
update system.  The ideas are also applicable to other levels in the DNS tree.

 

In parallel, there is work on open source hardware crypto that can easily be 
extended to include this functionality.

 

 

Yup. Two of my concerns are:

 

1: the HSM has to have a bunch more complexity / content awareness than is 
usual - most HSMs simply take a blob and sign it / store keys. This will 
require the HSM to have much more understanding of the content, and understand 
who the "owner" of each RR is, NSEC / NSEC3 , etc. This logic all needs to live 
inside the security envelope, not in the system driving it. Any "interesting" 
new resource record types will require updating of the secure logic. This will 
be largely a one-off bit of code, and will require careful code review of the 
initial, and any new code (and based upon the amount of review of 
https://github.com/iana-org/dnssec-keytools I'm not sure the community has the 
time / desire). Any scewup by the HSM makes 1: that TLD or 2: the entire zone 
unavailable. 

 

2: Based upon things like https://ianix.com/pub/dnssec-outages.html, it is 
clear that even TLD operators sometimes manage to shoot themselves in the foot. 
Yes, the majority of these are expirations, but it is clear that people will 
mess this up. The root KSK is well protected, with people being really careful, 
but even that has some risk - multiply that by the number of TLDs (or opted in 
TLDs) and the risks multiply. This means that you really really need a fast, 
reliable way to regain access in the event of an Oops... and now you have what 
looks awfully like a backdoor. 

 

There are some important governance and process details alluded to but not 
fleshed out in the paper..  Happy to discuss with anyone interested.

 

Thank you, happy to discuss further, but the above concerns are why I think (at 
least at the beginning) why something similar to Certificate Transparency but 
for the root zone is much safer - yes, it provides deterrence through 
transparency instead of inviolate crypro protection - but this same reason 
prevents a minor mistake turning into a major outage.

 

This is a summary of a document from back in ~2015 (before the PTI transition, 
and so the terminology / focus is historic):



*Sunlight is the best disinfectant.*

 

Currently, the entity that generates the root zone has full control over the 
contents. While this is not a new issue or concern, it is being brought to the 
public eye because of the IANA transition. To ensure that that entity doesn’t 
abuse the power/privilege, or make incorrect or unauthorized changes, we 
propose the following.

 

Transparency and accountability are both fundamental to the safe and successful 
management of IANA, regardless of under whose management IANA sits. To that 
end, we propose a publicly verifiable, published audit trail for any and all 
changes to the root zone. No invisible/unaudited changes will be able to be 
made to the root zone by any party. The entity generating the root zone has 
full control over what ends up in the file; in order to ensure that there are 
no abuses of this power, any and all changes to the root zone would require a 
full audit trail.

 

To implement this technically, each TLD operator will cryptographically sign 
and publicly publish any requested updates to their entries in the root zone. 
No changes will be made to the root zone without accompanying signatures. The 
entity generating the root zone will validate all signatures before making the 
changes. Because all of this will be public, auditors will be able to see from 
whom the request originated, how it was validated, and when it was implemented. 
This is a general case/solution; emergency backup procedures will also be in 
place as needed (i.e., if a country loses its signing key).

 

So, if the ‘example’ TLD wanted to update its nameservers, it would generate a 
change request (format to be discussed later) and digitally sign the request. 
It would then publicly publish this change request. The IANA Functions 

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04

[Dave Crocker]

Hi.  Thanks for the detailed comments.

Some responses...

On 9/24/2018 3:00 AM, Francesca Palombini wrote:

The use of underscored node names is specific to each RRTYPE that is
being scoped.

As an non-expert in the area, I would have appreciate a ref to a document
introducing RRTYPE.


The term is basic to DNS, with RFC 1035 cited in the first sentence of 
the Introduction:


 "Original uses of an underscore character as a domain node name
  [RFC1035] prefix, which creates a space for constrained
  interpretation of resource records, were specified without the
  benefit of an [IANA-reg] registry."

Once such a citation has been included, is a document expected to repeat 
the citation for every term used from it?  The implication is that 
someone reading this sort of document is not expected to have basic DNS 
familiarity?


However this did cause me to look for the first use of "RRTYPE" and I 
discovered that RFC 1035 has "RR TYPE" but not "RRTYPE". I'm not sure 
where first use without the space started.




This section provides a generic approach for changes to existing
specifications that define straightforward use of underscored node
names, when scoping the use of a "TXT" RRset.

Same for "TXT" RRset.


Same response.




An effort has been made to locate existing drafts that
do this, register the global underscored names, and list them in this
document.

Since the effort has been done, I would have appreciated the full list here.


This is the 'fix' document, not the registry definition document.  The 
latter is cited in the first paragraph of this document's Introduction:


  "A registry has been now defined, and that document
   discusses the background for underscored domain name use
   [Attrleaf]."

That's where the list is provided.



An
effort has been made to locate existing drafts that do this, register
the global underscored names, and list them in this document.

Same as previous comment.


Same response.



An effort has been made to locate
existing drafts that do this and register the associated 'protocol'
names.

Same as previous.


Same response.



3.1. and 3.2. is the formatting of the updated sections (after "And is to be
updated to the new text:") wanted? Why not use the same format as in 3.3., with
OLD and NEW?


OK.




+  Those registered by IANA in the "Service Name and Transport
 Protocol Port Number Registry [RFC6335]"

Move the end quote after Registry.


ok.  Good catch.



+  Those listed in "Enumservice Registrations [RFC6117].

Missing end quote after Registrations.


ditto.



" Signaling Trust Anchor Knowledge in DNS Security Extensions

Remove the space after the quote.


ok.



  John Levine, Bob Harold, Joel Jaeggli, Ondej Sury and Paul

In Acknowledgements, one name is not encoded correctly.


I believe this as a bug in the xml2rfc generator used by the tools site, 
for text format, since the correct text is produced by an xml to html 
generator.






From running the idnits tool (https://tools.ietf.org/tools/idnits/), several

comments, warnings and one error were raised, which I snipped and pasted below
as a summary:


What's most interesting here is that the document passed IDNits during 
submission!  (Apparently nits only works on txt documents and I only 
submitted an xml version; I'd guess the submission process does not 
general a txt version on the fly, for nits to inspect...)




   -- The draft header indicates that this document updates RFC, but the
   abstract doesn't seem to mention this, which it should. (see
   https://www.ietf.org/id-info/checklist) --> I see that the abstract generally
   mentions "the existing specifications that use underscore naming", but I
   think to make this correct, it should explicitely list them as well.


That actually makes no sense to me, since that would be fully redundant 
with the Updates header field that is already provided.




   -- The document seems to lack a disclaimer for pre-RFC5378 work (See the
   Legal Provisions document at https://trustee.ietf.org/license-info for more
   information.)


Another victim of the long lag time.  I've updated the IPR template 
reference.  We'll see whether it's the right one...




   == Unused Reference: several documents are included in the list of
   references, but no explicit reference was found in the text --> if my
   editorial comments are taken, they should fix this one.


This actually poses an interesting challenge.  The references are used 
in the Updates header field, but apparently IDNits does not look there.




   ** Downref: Normative reference to an Informational RFC: RFC 7553


That document is a specification.  This document modifies it.  No matter 
it's standards track status, it is a normative reference to this document.





   -- Obsolete informational reference (is this intentional?): RFC 3921
  (Obsoleted by RFC 6121)


Ack. Not 

[DNSOP] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04

[Francesca Palombini]

Reviewer: Francesca Palombini
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-dnsop-attrleaf-fix-04
Reviewer: Francesca Palombini
Review Date: 2018-09-24
IETF LC End Date: 2018-09-25
IESG Telechat date: Not scheduled for a telechat

Summary:

This draft is basically ready for publication, but has nits that should be
fixed before publication.

Major issues:

N/A

Minor issues:

N/A

Nits/editorial comments:

I give some proposal for clarification here, feel free to take them or leave
them. The idnits tool however produced several output, I would suggest to fix
those before publication.

   The use of underscored node names is specific to each RRTYPE that is
   being scoped.

As an non-expert in the area, I would have appreciate a ref to a document
introducing RRTYPE.

   This section provides a generic approach for changes to existing
   specifications that define straightforward use of underscored node
   names, when scoping the use of a "TXT" RRset.

Same for "TXT" RRset.

   An effort has been made to locate existing drafts that
   do this, register the global underscored names, and list them in this
   document.

Since the effort has been done, I would have appreciated the full list here.

   An
   effort has been made to locate existing drafts that do this, register
   the global underscored names, and list them in this document.

Same as previous comment.

   An effort has been made to locate
   existing drafts that do this and register the associated 'protocol'
   names.

Same as previous.

3.1. and 3.2. is the formatting of the updated sections (after "And is to be
updated to the new text:") wanted? Why not use the same format as in 3.3., with
OLD and NEW?

   +  Those registered by IANA in the "Service Name and Transport
Protocol Port Number Registry [RFC6335]"

Move the end quote after Registry.

   +  Those listed in "Enumservice Registrations [RFC6117].

Missing end quote after Registrations.

   " Signaling Trust Anchor Knowledge in DNS Security Extensions

Remove the space after the quote.

 John Levine, Bob Harold, Joel Jaeggli, Ondej Sury and Paul

In Acknowledgements, one name is not encoded correctly.

>From running the idnits tool (https://tools.ietf.org/tools/idnits/), several
comments, warnings and one error were raised, which I snipped and pasted below
as a summary:

  -- The draft header indicates that this document updates RFC, but the
  abstract doesn't seem to mention this, which it should. (see
  https://www.ietf.org/id-info/checklist) --> I see that the abstract generally
  mentions "the existing specifications that use underscore naming", but I
  think to make this correct, it should explicitely list them as well.

  -- The document seems to lack a disclaimer for pre-RFC5378 work (See the
  Legal Provisions document at https://trustee.ietf.org/license-info for more
  information.)

  == Unused Reference: several documents are included in the list of
  references, but no explicit reference was found in the text --> if my
  editorial comments are taken, they should fix this one.

  ** Downref: Normative reference to an Informational RFC: RFC 7553

  -- Obsolete informational reference (is this intentional?): RFC 3921
 (Obsoleted by RFC 6121)

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