Subject: [sidr] A draft seeking guidance.

From: Terry Manderson <[email-masked]>
Date: Thu, 9 Oct 2014 00:21:54 +0000

Hi All,

As you are probably aware ICANN has been following the SIDR work fairly
closely, based in the IAB guidance that a single authoritative trust
anchor should exist - what we term as the Global Trust Anchor (GTA).

In the process of looking at the implementation of this, the GTA, and the
technical concerns relating to stability and resiliency, a few questions
have bubbled to the surface over the past year. Instead of sitting on our
hands and not communicating to the WG we thought it best to raise what we
are thinking and seek a discussion. Thus we would very much like the WG
guidance and advice on these questions.

We have created a draft to raise these discussion points.

http://tools.ietf.org/html/draft-vegoda-manderson-sidr-key-management-00

Are there simple answers? and if so, what are they? Have we
mis-charatcerised some concerns? How? Are our concerns unfounded? and why?
Are there more concerns that people see and which we haven't covered here?

Cheers
Terry and Leo

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Thu, 9 Oct 2014 14:58:22 +0000

Hi Terry,

Thanks for this effort.

Overall I think there are good points that you raise.

However, I am struggling with the relevance from a CA perspective of Section 7 (Communication from validators to objects signers regarding validation status). Validation is a local process done from RPs. There are many reasons why validation may fail and many of them good reasons. Are you expecting a massive Big Brother system of all validator reporting results back to IANA? 

BTW, I know RIPE has this option but I take it as something they want to keep tracking during the boot-up process. In general I would assume that every CA (like any other entity with a  product) is  interesting in testing its products (signed objects) before making them public. Moreover, current key-rollover/algorithm rollover mechanism assume an overlap period where OLD and NEW products overlap in time to prevent any problem.

All in all, what I would recommend you is to verify that the current key-rollover/algorithm roll-over documents are adequate for IANA considering that IANA will test its signed objects adequately.

Roque

On 09 Oct 2014, at 02:21, Terry Manderson <[email-masked]> wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Leo Vegoda <[email-masked]>
Date: Mon, 13 Oct 2014 00:32:32 +0000

Hi Roque,

Roque Gagliano (rogaglia) wrote:

[...]

> However, I am struggling with the relevance from a CA perspective of 
> Section 7 (Communication from validators to objects signers regarding 
> validation status). Validation is a local process done from RPs. There 
> are many reasons why validation may fail and many of them good 
> reasons. Are you expecting a massive Big Brother system of all validator 
> reporting results back to IANA? 

No, we weren't envisaging that there would be a central repository of all
validation failure reports. I want to reiterate that we are seeking advice
on whether it is important for certificate owners and object signers to know
if validation fails because of something they have done.

I was thinking that letting the resource owner know that its certificate or
ROA failed validation and why could be helpful to the resource owner and
help minimize routing failures based on validation failures. 

Regards,

Leo

---

From: George Michaelson <[email-masked]>
Date: Mon, 13 Oct 2014 11:10:51 +1000

I think these are good questions to have raised and discussed in the public
forum.

-George

---

From: Sandra Murphy <[email-masked]>
Date: Sun, 12 Oct 2014 21:45:05 -0400

> if validation fails because of something they have done.

Have you looked at the RPSTIR work?  

http://sourceforge.net/projects/rpstir/

There's a large set of compliance tests in there.  Is that what you were looking for?

--Sandy

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 13 Oct 2014 21:57:30 +0000

Hi Leo,

> help minimize routing failures based on validation failures. 

If I want to be contacted, I can issue a Ghostbuster RR: https://tools.ietf.org/html/rfc6493

Maybe that is the requested advise?

Roque

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 13 Oct 2014 22:23:58 +0000

Terry,

I have two other comments on this draft.

4.1.  Algorithm based on jurisdiction

(Roque) My (basic) understanding of the GHOST problem when tackled by the DNSSEC people is that it end up been a no-problem. A lot of discussions, lot of waisted time, support for GHOST was added to standards but finally, .RU got signed using RSA just like the rest of the world. Do we have a summary of the DNSSEC experience that we could use as reference? 

4.2.  Algorithm vulnerability

(Roque)  We have a procedure in RFC6916. Have you evaluate it? is there a problem that needs to be fix?
>From your text I cannot figure out if what you are looking for is an emergency algorithm rollover. This was discussed and agreed that algorithm roll-over will be a long process and no emergency procedure is practically feasible.

5.  Key Length

(Roque)  I would go for a shorter lifetime until 2030 and keep 2048bits. The technology is ramping up and migrating to a longer key length at this time would not be advisable IMHO.

6.1.  Protocol support for key rollover events not requiring a change in cryptographic algorithm

(Roque) I believe you are talking about two things:
	- Rollover communication from parent CA to subordinate CA using top-down protocol (hosted environment is trivial):
		IMHO, out-of-band seams to be the right approach. I do not believe CAs will automate the roll-over request to its parent, so the use of an in band mechanism will basically triggers a manual action (probably an email) which is the same communication method used by out-of-band.
	
	- TAL rollover.
		You do not mentioned explicitly but I guess that when you refer to “communicated to validators” you are referring to the TAL file.
		There is no magic on how to distribute a new TAL, just like your DNSSEC keys or a new root cert for your browser. What you normally want is to have an independent trust anchor that signs that sets the authenticity of the content. In this case you need to make sure that it is hosted in a TLS secured site via a trusted certificate authority.
		Carlos Martinez had an idea about creating a signed object signed by the old TA CA that points to the new TAL file. Seams like a good idea at first view.

Regards,
Roque