Re: [regext] FW: Proposal to remove RDAP from the Thick Whois CL&D Policy (was Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration)

[John R Levine]

<

I'm looking at the new TLD registry agreement.  Could 
you point out the part where it says they can't do that?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Google open source Nomulus registry software

[John R Levine]

Google's blog today says that they've put their Nomulus registry software 
on Github.  It runs in their App Engine environment and is mostly written 
in Java


blog: https://opensource.googleblog.com/

source code: https://github.com/google/nomulus

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [regext] RDAP lookup queries for reserved or unassignable domains

[John R Levine]

There are lots of reasons an RDAP server might not have info about a
domain, e.g., you ask it about a TLD it doesn't handle, and there's no
reason to assume that an RDAP server would know anything about an
unknown domain's availability.


I would think anybody doing reselling would have the availability
servers explicitly addressed and would not use redirects to find an
authoritative server, no matter the underlying protocol.


I was thinking that you're the RDAP server for .FOO and someone who's 
screwed up his bootstrap asks about BLAH.BAR, with whom you have no 
connection.  Or you're a reseller for a thin registry and someone asks you 
about a domain at another reseller, about which you have no info. 
(Perhaps it was transferred and the client thinks it can speed things up 
by cacheing old redirects forever.)  So either way you return a 404 code.


I suppose we could pick another code for "it's not assigned but if you pay 
me money it could be" but I really don't think it's a good idea to read 
anything beyond "I don't know" into a normal 404 response.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [regext] first reason not to do EPP and DNAME records?

[John R Levine]

Already replied but see



This answer just confirms my main point.  Whether to put DNAMEs in the 
root is primarily a policy question.  Even if you thought it was a good 
idea (which I still don't, see next message) there is no point to 
inventing an EPP extension unless and until there is a policy that lets 
them use it.


If merely having the EPP feature was all it took, we'd have sunrise and 
redemption periods in the root.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [regext] EPP and DNAME records, second reason not to do it

[John R Levine]

On Mon, 15 Jan 2018, Stephane Bortzmeyer wrote:

Since you can get the effect of a DNAME in the root zone by putting
a DNAME at the apex of a TLD as Taiwan has done,


No, the goal here is to have no NS delegation (for reasons explained
in RFC 7535). So, this cannot work.


I don't understand this objection.  If there's a reason this wouldn't 
work, I'd appreciate knowing what it is:


in the root (add DNSSEC to taste):

...
evil. NS ns1.evilsrv.wtf.
evil. NS ns2.evilsrv.wtf.
ns1.evilsrv.wtf. glue ...
ns2.evilsrv.wtf. glue ...
...

in the evilsrv.wtf servers

evil. SOA whatever
evil. NS ns1.evilsrv.arpa.
evil. NS ns2.evilsrv.arpa.
evil. DNAME empty.as112.arpa.

There'd be an initial spike of traffic to the evilsrv.wtf servers but 
assuming the DNAME does what you anticipate, that should tail off pretty 
fast as caches start synthesizing the answers.


This has the advantage that it involves no new technology and lets us skip 
directly down the hall to the policy discussion.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [regext] first reason not to do EPP and DNAME records?

[John R Levine]

On Mon, 15 Jan 2018, Ulrich Wisser wrote:

I might be mistaken, but I believe that IANA sends root updates to Verisign
via EPP.
In that light, we would need an EPP extension before IANA can adopt a
policy to allow DNAME in the root.


I don't understand why you think it would have to be in that order.  It 
seems to me that even if DNAMEs in the root are a good idea (which they 
aren't, but whatever) we can't invent an appropriate EPP extension until 
we understand what it needs to do.


A lot of the discussion around this has been related to 2LD DNAMEs, also a 
bad idea, and for which I've seen no demand.


R's,
John





Matthew Pounsett  schrieb am Mo., 15. Jan. 2018 um
20:10 Uhr:


On 15 January 2018 at 13:09, John R Levine  wrote:


Already replied but see

<https://mailarchive.ietf.org/arch/msg/dnsop/lGdwGFO58iJ_dYYM9UR87Er9F5c






This answer just confirms my main point.  Whether to put DNAMEs in the
root is primarily a policy question.  Even if you thought it was a good
idea (which I still don't, see next message) there is no point to inventing
an EPP extension unless and until there is a policy that lets them use it.

If merely having the EPP feature was all it took, we'd have sunrise and
redemption periods in the root.

Perhaps I missed this upthread somewhere, but before we start talking

about EPP extensions for managing the root, shouldn't we talk about using
EPP to manage the root?  Last I heard (May 2017, Spain) there was work
underway for a custom API for TLD->IANA changes that does not involve EPP.
I imagine shifting gears to replace that with an EPP interface would be a
significant undertaking by this time.



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







Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [regext] EPP and DNAME records, second reason not to do it

[John R Levine]

in the root (add DNSSEC to taste):
...
evil. NS ns1.evilsrv.wtf.
evil. NS ns2.evilsrv.wtf.


Does not work for the use case of draft-bortzmeyer-dname-root since
you cannot delegate new names to the old AS 112 (see RFC 7535 for the
rationale).


Hi, Stephane.  Not to belabor the obvious, but this does not delegate new 
names to the old AS112, it delegates them to real servers which use a 
DNAME to AS112, and it will work fine, so there is no need to put DNAMEs 
in the root zone.  I have read RFC7535, and I have also read RFCs 6672 amd 
1035 and written a few small DNS servers so I am reasonably sure that I 
understand how delegation and DNAMEs work.


To make it easier to understand, imagine that instead of 
ns[12].evilsrv.wtf I said [abc].iana-servers.net.


Once again, in the root (add DNSSEC to taste):

...
evil. NS a.iana-servers.net.
evil. NS b.iana-servers.net.
evil. NS c.iana-servers.net.
...

New tiny zone on [abc].iana-servers.net:

evil. SOA whatever
evil. NS a.iana-servers.net.
evil. NS b.iana-servers.net.
evil. NS c.iana-servers.net.
evil. DNAME empty.as112.arpa.



Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [regext] EPP and DNAME records, how to do it

[John R Levine]

OK, I see your point. Documented in an appendix in
draft-bortzmeyer-dname-root-05.txt as a possible alternative.


Thanks.

Now my question is that since we have a workable approach that does not 
require a new EPP extension, and since (in my opinion at least) DNAMEs as 
2LDs are an actively bad idea, what need is there for this extension?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

[John R Levine]

The 2119 words MUST and MAY are used to signify requirements; although 
that does imply interoperability as well.  This statement is associated 
with making the verification code functional, since the verification 
code represents a signed and typed verification pointer, it must point 
to something.


I don't understand why.  The code is a signed token.  Imagine the registry 
goes back to the signer asks about token 123-foo666 and the answer is 
"We're the Ministry, we signed it, of course it's valid.  The details are 
secret."


While that would not be my favorite way to work, and I can easily imagine 
other scenarios with auditing and transparency business requirements, why 
wouldn't that interoperate?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

[John R Levine]

On Wed, 2 Jan 2019, Adam Roach wrote:

 I don't understand why.  The code is a signed token.  Imagine the registry
 goes back to the signer asks about token 123-foo666 and the answer is
 "We're the Ministry, we signed it, of course it's valid.  The details are
 secret."

 While that would not be my favorite way to work, and I can easily imagine
 other scenarios with auditing and transparency business requirements, why
 wouldn't that interoperate?


If we're concerned merely with interoperation, the same is true of most -- 
if not all -- normative keywords used in "Security Considerations" sections. 
Your position might (or might not) be correct, but the logic of "2119 
language is only used for interoperabilty reasons" simply isn't true.


I think there's a difference -- in security sections the goal is usually 
to prevent leakage or spoofing or something else that would allow a 
malicious party to interoperate with a victim.  One part of good interop 
is not to interoperate with attackers.  But that's not what's going on 
here.  The signature shows that the token is valid, and unless I'm missing 
something, whatever you might learn from the thing the token represents is 
outside the scope of EPP.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

[John R Levine]

On Wed, 2 Jan 2019, Gould, James wrote:

To remove any concerns related to the inclusion of VSP policy in 
draft-ietf-regext-verificationcode, the sentence " The VSP MUST store the proof of 
verification and the generated verification code; and MAY store the verified data." 
can be removed.  If there are no objections to the removal of this sentence, it will be 
removed in the next version of the draft.


That's OK with me.  I'm not totally opposed to it but without some hint 
about what an interoperating system would do with the object the token 
points to, I think it's confusing.  As you can see, it confused me.




—

JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 1/2/19, 3:56 PM, "regext on behalf of John R Levine"  wrote:

   On Wed, 2 Jan 2019, Adam Roach wrote:
   >>  I don't understand why.  The code is a signed token.  Imagine the 
registry
   >>  goes back to the signer asks about token 123-foo666 and the answer is
   >>  "We're the Ministry, we signed it, of course it's valid.  The details are
   >>  secret."
   >>
   >>  While that would not be my favorite way to work, and I can easily imagine
   >>  other scenarios with auditing and transparency business requirements, why
   >>  wouldn't that interoperate?
   >
   > If we're concerned merely with interoperation, the same is true of most --
   > if not all -- normative keywords used in "Security Considerations" 
sections.
   > Your position might (or might not) be correct, but the logic of "2119
   > language is only used for interoperabilty reasons" simply isn't true.

   I think there's a difference -- in security sections the goal is usually
   to prevent leakage or spoofing or something else that would allow a
   malicious party to interoperate with a victim.  One part of good interop
   is not to interoperate with attackers.  But that's not what's going on
   here.  The signature shows that the token is valid, and unless I'm missing
   something, whatever you might learn from the thing the token represents is
   outside the scope of EPP.

   Regards,
   John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
   Please consider the environment before reading this e-mail. https://jl.ly




Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

[John R Levine]

If a registrant is living in the EU, or a EU citizen, they would be covered by 
GDPR protections, so its impact is quite significant. As you know, ICANN and 
the industry is seeking to find one compliance model. I do not see why we would 
deviate from that.


I pretty sure nothing has changed since Wednesday, so I guess we're 
done.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

[John R Levine]

The final decision on this is planned to be made in April:

https://community.icann.org/pages/viewpage.action?pageId=88574682&preview=/88574682/102142026/EPDP_summary_timeline_20190116.pdf


Not that it's relevant here, but I am a member of the ICANN SSAC 
subcommittee that supports the SSAC reps on the EPDP group, and I talk to 
them about its progress or lack thereof several times a week.  I think 
it's fair to assume that I know at least as much about what it's doing as 
anyone else here.  I was also a member of the IAOC when we figured out 
what the IETF needed to do to be GDPR compliant (not much.)


But once again, the IETF is not ICANN, working groups are not GDPR data 
controllers, nor are we GDPR data processors.  This entire argument is a 
waste of everyone's time.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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