Re: Example of stupid inconsistencies between registries

On 5 mar 2012, at 14:21, Gould, James wrote:

> I believe that a
> mix of "thin" and "fat" would make things more complex since the
> registrars would need to support both instead of one interface for the
> registries that do support the "fat" model.

Today that is obviously what we have as the registries do support either DS or KEY (and not both).

> Think about handling
> transfers between registrars where the gaining registrar supports only the
> "thin" model and the losing registrar supports both "thin" and "fat".

Yup, that creates problems for the registrant as well.

>  The registries that I work
> on support the "thin" model with the ds data interface.

...and the registries I work with so far (which include .SE) support the DS interface.

But I stumbled upon one that only support KEY interface.

   Patrik

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Example of stupid inconsistencies between registries

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Example of stupid inconsistencies between registries

On 5 mar 2012, at 14:54, Peter Koch wrote:

> The provisioning protocol should implement policy, not dictate it.
> Otherwise you'd really end up with incompatible extensions.

Absolutely!

There is always a balance between freedom in protocol specifications and interoperability...

   Patrik

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Example of stupid inconsistencies between registries

On 5 mar 2012, at 16:05, Andrew Sullivan wrote:

> Your complaint seems to be that a registrant has to provide different
> data for different names.  I fail completely to see why that is a
> problem.  (To put this slightly differently, you seem to be arguing
> that a registrant shouldn't need to understand that example.com and
> example.org are different domains.  This seems a little bit at odds
> with your views on the many things people call "variants".)

No, I am just talking about how to design for example a web interface and instructions to the one that is to
paste data into it. You have a number of fields, and different fields are mandatory depending on what TLD it is.

Same with for example an API. If you run a DNS hosting, would it not be easier if you can pass the same
information to all registrars, and not have to do different depending on which one it is?

I am just talking about how much more difficult it is for everyone but the registry if it asks for something
else than the DS, and in many cases it can also fetch the Key from the auth server if it want to validate the
DS... Part from some cases where one want DS pre-published in the parent zone when the parent simply must
trust whatever the registrar send anyway as it can not validate the data passed to it. As nothing is in the
child zone that the data can be validated against.

   Patrik

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Example of stupid inconsistencies between registries

On Mar 5, 2012, at 9:11 AM, Andrew Sullivan wrote:

> On Mon, Mar 05, 2012 at 09:48:04AM -0500, MICHAEL YOUNG wrote:
>> Ok I see this argument but on the other hand I have to ask how much
>> responsibility does the registry want to take on? 
> 
> The registry took on the responsibility for authoritative data in its
> zone by virtue of accepting the delegation from its parent (usually
> the root).  You might as well argue that the registry doesn't really
> have to keep its apex records well-maintained.

Yes - when working on this RFC, we were torn between two different realities: (1) that there were already
many registries that either (1a) want to take the "registrar is responsible for the data they send to the
registry" model, or (1b) are already working fine with accepting DS data, and don't want to change; vs.  (2)
The DS record is a completely different dragon, and (2a) the registry should generate any data for which it
is authoritative, or (2b) the registry wants to make sure that it has some control over which algorithms
are in use (i.e. registry X does not want to see GOST, or registry Y wants to make sure they only see GOST).

Consensus was that both arguments (1) and (2) were valid, so the RFC was worded to allow either.

> 
>> verify the DS data.  However, lets face it, I can publish whatever I
>> want to the registry and then later on mess my zone up because I
>> mis-manage something.
> 
> That's just irrelevant.  The issue here is data that is authoritative
> _only_ in the parent-side zone.

Right - see (1a) above.

-Howard

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Example of stupid inconsistencies between registries

On 8 mar 2012, at 07:35, Jay Daley wrote:

> On 8/03/2012, at 7:02 PM, Patrik Fältström wrote:
> 
>>> To explain what I mean, here's a simple idea - could the protocol have been designed to better minimise
pain for registrars while maintaining the choice for registries?
>> 
>> I think this is a case that creates a problem for the _registrant_.
> 
> How?

Because compared to other discussions we have, this implies the registrant (or, more correctly, the DNS
hosting provider) have to do completely different actions depending on the policy of the TLD.

>> So the DS should be enough. Everything else is bonus. Or am I completely confused before enough coffee
here in the morning?
> 
> You are assuming a particular sequence of provisioning (i.e. that there are published DNSKEY records
when the DS is received).  Many registries make no assumptions and so don't expect to contact delegated
nameservers during the provisioning process.

Correct, just like many registries already today require delegations to be made before registration can
be done. I.e. some registries do not allow registration without delegation.

My point is that without delegation, sending KEY does not make any sense. It is when delegating the dnssec
data is needed and because of that the KEY can be fetched at time of delegation.

   Patrik

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Example of stupid inconsistencies between registries

On Thu, Mar 08, 2012 at 09:16:04AM +0100, Peter Koch wrote:
...
> In your scenario any DNSKEY that would end up in the registry db
> would have to be present at the apex at the time of registration,
> which prohibits pre-publication of a DS RR for a DNSKEY not yet
> present at the apex DNSKEY RRSet.

Which basically proofs that the DNSKEY interface is not suitable for
pre-publications too. Remember the purpose of this is to not
pre-expose the public-key, so why show it to your registry.

So plain DS, without DNSKEY fetch and check, is the only suitable
interface for this corner case scenario.

...
> -Peter

Fred
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Example of stupid inconsistencies between registries

On 8 mar 2012, at 09:16, Peter Koch wrote:

>> A registry that want to be "thick" can still receive the DS, then fetch the DNSKEY from DNS which they
validate against the DS. If they want create a new DS they can do so with whatever digest algorithm they want
and not even publish the DS that the client passes to them.
> 
> i'm not sure what exactly you mean by thick (or "fat", as others have said)
> vs. thin here since in the realm of registries these terms are already occupied.

Well, I use it because other people started using it  I think people have used "thick" or "fat" for
registries that want to have the DNSKEY for all the DS they have, and "thin" if they just have the DS.

> I think the validation is related to, but otherwise independent of the type
> of object passed.
> In your scenario any DNSKEY that would end up in the registry db would have
> to be present at the apex at the time of registration,

No, not at the time of registration. At the time the DS is to appear in the zone (after validation that the
DNSKEY and DS matches each other). Just like NS records, they can be added much later than time of
registration. The validation is similar to the validation some registries do for lame delegation (at
time of addition of NS to the parent zone).

It has nothing to do with registration per se, although some registries require delegation at time of registration.

> which prohibits
> pre-publication of a DS RR for a DNSKEY not yet present at the apex DNSKEY RRSet.

This is correct.

If the registry want to hold the DNSKEY and they only get the DS and the DNSKEY is not in the apex DNSKEY RRSet, then...

A lot of "if" there 

I see such policies be policies that a registry can implement anyway with the DS interface. For example, I
sort of can understand that a registry only want to accept some digest types. That can be done by only
accepting some digest types when DS is passed to them. In the case of pre-publication of DS, the registry
can say that "if you use the DS interface, the DNSKEY must be present in the DNSKEY apex RRSet at time of
passing the DS via epp". I think both of those solutions would be better than refusing to support the DS interface.

That said, I do not understand registries that do not accept DS interface and "just" pass that to their zone
and sign it. It seems to much much easier than the for me more complicated DNSKEY interface.

> I don't understand how the DNSKEY would be worse for the registrant than the DS given that
> the DNSKEY is what they already have in their hands.

Correct, we could as well have always passed the DNSKEY to the registry. The problem is not even that some
registries ask for DS, some for DNSKEY, but that some refuse to accept DS (in my case). It could, as you say,
also have been that some refuse to accept DNSKEY.

To repeat, I have encountered a number of registries accepting DS (they might accept DNSKEY as well) and now
suddenly one that only accept DNSKEY and not DS.

I felt that was a situation complicated enough for the registrar (me) and the registrant (our customers)
that I wanted to discuss the situation on this list.

Which I thank you all for the ability to do. It has been a good conversation.

   Patrik

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Example of stupid inconsistencies between registries

I'm not sure why as a DNS operator I would want to either send a ZSK (signed
by my KSK) or receive a ZSK signed by a KSK I don't control through the
domain registry.

I tend to think this should stay between the two DNS operators, as the keys
are being managed in the delegate zone, all the TLD zone should care about
is that whoever controls the domain has submitted what they consider to be a
valid DS.  As Patrik said, if the registry wants to be generous, it can
validate the DS  against the key by looking it up in the subordinate zone -
but that should be at the decision (option) of the registry.

DNSSEC is only one of numerous out of (registry) band activities that happen
around a transfer.

Personally, if I was processing a DNS operator transfer for a signed zone,
and I was the losing DNS operator, I would prefer the requesting DNS
operator to provide a ZSK that they generated and I would incoporate that
into my key rollover.

I don't think the registry's responsibilities should try and overreach, for
example, what if I am switching registrars but not DNS operators?  I could
run a transfer with no related DNS/DNSSEC changes.  What if I change DNS
operators but stay with the same registrar? Again, other than switching up
DS records through my registrar, the registry doesn't need to be involved
any further.

I think the registry's role should stay constrained to what it's
responsibilities are at it's level of the hierachary.  Now I suppose we
argue about what those responsibilities really should be, but I think it
starts and ends with what they can control.    

Best Regards,

Michael Young
M:+1-647-289-1220

-----Original Message-----
From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On Behalf
Of Antoin Verschuren
Sent: March-08-12 3:36 AM
To: provreg <at> ietf.org
Subject: Re: [provreg] Example of stupid inconsistencies between registries

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08-03-12 07:02, Patrik Fältström wrote:

> I think this is a case that creates a problem for the _registrant_. If it
was only a registry/registrar battle (as in most cases we discuss on this
list  ) I would not have spent so much time on this.
> 

Patrick,

I think you are correct that multiple options are confusing for the users.
In fact that is why we chose for DNSKEY in stead of DS, let me explain.

In the beginning of DNSSEC, where procedures were not well worked out yet,
registries chose for DS because that's what they minimally need to enter
into the parent zone for a new DNSSEC delegation to work, and it's shorter
and perhaps easier to copy-paste.

However we encountered problems with other procedures when dealing with
DNSSEC, like the transfer issue. Please read
http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-03

To deal with the dns-operator change, users need to relay ZSK's, which is a
KEY and not a DS. The losing operator needs the KEY from the gaining
operator.

So when we chose to use DS or DNSKEY, one of the rationales was that users
need to send DS with no transfer, but need to send a KEY (ZSK) as well when
there is a transfer. Let's just use KEYs all the time, it's less confusing.

When the draft describing the transfer issue is done, I expect a new
standard EPP extension that contains the "DNSKEY to be relayed" to the
losing DNS operator, that contains a KEY (Any volunteers to take that up in
this group ?). I also expect by that time that registries will see that it
makes no sense to ask for a KEY one time, and a DS another time.
The only reason to still support DS is then legacy support.

- --
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:antoin.verschuren <at> sidn.nl  xmpp:antoin <at> jabber.sidn.nl
http://www.sidn.nl/ -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJPWG9sAAoJEDqHrM883AgnRa4H/jc79//8AiFTV0q/UYUUsFkw
a4U/pevfcbs8TLU0QzdCDie0nuPO7Eeg/aF5FXY3uFknTgS+nWDAkatAXKBNFNQZ
vzdICrxLY905wO9sOmV9nuAPTEvy4ae42tt4TRwid8/5Q6BOnhgglPt/oYc1qb5d
Ga+V6YUDEYRYEVLdEPPOdXfAzwEPFbtvObKvF6cKayiNr+a4szxSH7YAaLSkkwdy
u0Vc19h9Ztpi06Ohm4ZfzMyxEEqS7ec1qEG3H5bDZt2UFi2C9f60f1KoUtWU3EXa
QYiP+oT3ThgwpT9qOrwZRjlIhp88JsG4AhOEg3D4fpqhgPmyuMbaQ6IvsxgEz20=
=ktvM
-----END PGP SIGNATURE-----
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Example of stupid inconsistencies between registries

On 08-03-12 11:52, Mark Elkins wrote:

> Once signed, a simple trigger should be enough though? The Registry can
> ask via DNSSEC for any new DNSKEY records as then the DNS transaction is
> signed (as in the AD bit is set)... OK - It'll still be a DS Record
> trigger.

We have discussed such a principle some time ago, but it is/will be
rejected by the politics of ICANN registrars.
In our technical vision, EPP only needs to be used for bootstrapping the
original delegation and chain of trust. After that, all technical stuff
can be done over (secure) DNS, and EPP is only needed for administrative
data.
ICANN registrars disagree. According to their contract, ALL changes to
the delegation may only be done by submission by the registrar over EPP
to the registry, so that they are aware and can intercept technical
changes. Even if that means the delegation is technically incorrect. NS
changes can also be done over DNS if that is a secure channel, but
registrars want to be able to block technical changes when f.e. a bill
has not been paid. The motivation they use is that provisioning the
registry data then comes from 2 channels, DNS and EPP, and the
discussion may arise which one is authoritative.

--

-- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:antoin.verschuren <at> sidn.nl  xmpp:antoin <at> jabber.sidn.nl
http://www.sidn.nl/

Re: Example of stupid inconsistencies between registries

This has been a very interesting thread.  The key is what the provisioning
interface should be for the DNSSEC information.  I don't believe that the
Registrar should provide a hint to the Registry to go retrieve information
from DNS.  EPP is the secure provisioning protocol that should be used for
passing information that makes it into the resolution services provided by
the Registry.  In RFC 5910 the two interfaces define what objects in the
Registry are managed by the Registrars.  The DS Data Interface has the
Registrar manage the DS Data that is directly placed into the parent zone
by the Registry.  The Key Data Interface has the Registrar manage the Key
Data and the Registry generates the DS Data to place in the parent zone.
RFC 5910 supports passing both DS Data and the associated Key Data for
validation purposes by the Registry, but that still is considered the DS
Data Interface.  Back when we started working on the update to RFC 4310
that eventually became RFC 5910, the concept of supporting a Key Data
Interface was discussed with no concerns expressed at the time or as RFC
5910 went through the standards process.  The only real discussion was
around supporting a mix of the DS Data Interface and the Key Data
Interface which resulted in having the server support one or the other and
only a mix during a transition period.  Support for both models in RFC
5910 is no different than support for multiple models for hosts (host
objects or host attributes) or contacts (thin or thick) in RFC 5731, where
the protocol does not dictate the model but supports the different models.
 If the registries are going to support the different models, as in this
case, the only alternative would be the creation of a one or more custom
extensions for the less popular model, which as I posted previously
wouldn't benefit anyone.

--

JG

 
James Gould
Principal Software Engineer
jgould <at> verisign.com

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 3/8/12 5:52 AM, "Mark Elkins" <mje <at> posix.co.za> wrote:

>On Thu, 2012-03-08 at 07:02 +0100, Patrik Fältström wrote:
>
>> A registry that want to be "thick" can still receive the DS, then fetch
>> the DNSKEY from DNS which they validate against the DS. If they want
>> create a new DS they can do so with whatever digest algorithm they want
>> and not even publish the DS that the client passes to them.
>> 
>> So the DS should be enough. Everything else is bonus. Or am I
>> completely confused before enough coffee here in the morning?
>
>I'd agree with you. A DS record over EPP (I'd thus assume a SSL/TLS type
>of secured link) gives the Registry enough validatable information to
>fetch DNSKEY records via unsigned DNS and then validate them.
>
>Personally - just sending a trigger to the Registry to come fetch my
>DNSKEY from me would statistically be enough.  The Registry has my
>Nameservers - they can ask each NS in turn for my DNSKEY - if all
>Nameservers agree - its most probably correct... OK - so I'll send a
>valid DS record as a trigger.
>
>Once signed, a simple trigger should be enough though? The Registry can
>ask via DNSSEC for any new DNSKEY records as then the DNS transaction is
>signed (as in the AD bit is set)... OK - It'll still be a DS Record
>trigger.
>
>This is probably of insignificance to anyone running a properly
>configured Registry<-->Registrar systems but for anyone doing EPP type
>updates via a web portal, the less one has to type - the better.
>-- 
>  .  .     ___. .__      Posix Systems - (South) Africa
> /| /|       / /__       mje <at> posix.co.za  -  Mark J Elkins, Cisco CCIE
>/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496
>
>_______________________________________________
>provreg mailing list
>provreg <at> ietf.org
>https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg