Subject: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

From: Sandra Murphy <[email-masked]>
Date: Thu, 20 Oct 2011 10:50:09 -0400 (Eastern Daylight Time)

The authors have requested a WG LC for draft "Algorithm Agility Procedure 
for RPKI."

The document and the draft version history are available at
http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-03

The last call will end Thu, 3 Nov 2011 (AOE).

As usual, please address all comments to the WG mailing list, and
please be clear in your comments to this last call if you are
supporting the document's submission to the IESG or if you are
opposed. If you are opposed, please indicate why.

--Sandy, speaking as wg chair with appropriate ceremonial garb donned
          (and covered with ashes for having neglected this)

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 28 Oct 2011 10:00:47 -0400

> opposed. If you are opposed, please indicate why.

I have read this and support it (as a regular joe/jane/dog/cat) thanks!
-chris
(regular-chris, not co-chair-chris)

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

---

From: "Murphy, Sandra" <[email-masked]>
Date: Sun, 30 Oct 2011 01:10:28 +0000

This is a reminder that the last call is in progress and is ending soon.

I have encouraged people to comment on this in the past.  I think it is an important feature of what we are building and deserves some careful attention.  It would not be good to be faced in the future with the need to change the algorithms and discover we had missed something.

There is still time to read and comment.  Please do.

--Sandy, speaking as wg chair

________________________________________
From: [email-masked] [[email-masked]] on behalf of Sandra Murphy [[email-masked]]
Sent: Thursday, October 20, 2011 10:50 AM
To: [email-masked]
Subject: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

---

From: Arturo Servin <[email-masked]>
Date: Sun, 30 Oct 2011 17:45:33 -0200

I have read and support.

/as

On 20 Oct 2011, at 12:50, Sandra Murphy wrote:

> The authors have requested a WG LC for draft "Algorithm Agility Procedure for RPKI."
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Oct 2011 13:34:24 -0700

I have read this document and think it should be published as a standards-track RFC. It is fairly complex, but I could not find places to reduce the complexity without removing scenarios that seem reasonably likely to pop-up in real-world transitions.

--Paul Hoffman

---

From: Danny McPherson <[email-masked]>
Date: Sun, 30 Oct 2011 20:59:37 -0400

> The last call will end Thu, 3 Nov 2011 (AOE).

---------------------------------------
Substantial;

---
In S 4.6  (Phase 3) you state that all signed product sets are available
using both algorithms and all RPs MUST be able to validate using either 
suite.  Further, you state that an object that validates using either 
Algorithm Suite A or Algorithm Suite B MUST be considered valid, 
but in the subsequent sentence it is "RECOMMENDED" that RPs utilize
only Suite B for validation [throughout Phase 3].  

Is the recommendation you're making that if product sets are available 
via both Algorithm Suite A and Algorithm Suite B then the Suite A product
sets SHOULD NOT be validated by RPs in order to minimize processing 
overhead and the probability of cryptographic vulnerabilities resulting
in downgrade attacks? 

Or SHOULD NOT be validated by RPs unless Algorithm Suite B validation 
failure occurs, then fallback to the Algorithm Suite A product set  
should be considered?  Or something else?  S.6 guidelines provide "As 
a general rule, the validation of signed objects using different 
algorithm suites are independent and the RP MUST NOT keep any 
relationship between the different hierarchies", which seems to be 
in conflict with the recommendation above unless some implementation 
optimization or minimization of vulnerability to downgrade attacks 
is being contemplated?

---
Whatever the recommended behavior, how would it also change in Phase 4
(Twilight), where a RP MAY continue to validate signed product sets
using Suite C (old)?  If there's a failure in validation of the 
current algorithm then should it use the "old" objects?  You seem to 
suggest in S.6 that this is fine, but not in S.4.7?

I think some more explicit guidelines about what to do and what not 
to do would be useful in both Phase 3 and Phase 4 behavior that aligns
with S.6 and clarifies the above issues would be of benefit.

---
Also, in S.6 it's not clear to me what you mean by "instance of a 
product" and "instances of such products", did you mean "signed 
product sets" or something else?  If the former, which I think you 
did, then it would be really useful if this "MUST contain the same
resources" was provided much earlier in the document. 

"A failure to validate one instance of a product, under either 
 algorithm Suite MUST NOT cause the RP to reject the other instance 
 of the product. Because both instances of such products MUST contain 
 the same resources, relying on either instance will yield the same
 outcome."

Whereas in Phase 4 both may not even exist, correct?  

---
And given the above, if they "MUST contain the same resource", yet 
S.7 says revocations are handled independently (even though during 
phase 2 and phase 3 the "two certificate hierarchies are designed to 
carry identical information" -- what does this mean?), how do you \
accomplish all of this in practice?

---
Perhaps it should be that if two hierarchies exist they should be 
identical - however, this diverges from the guidance that algorithm
suites must be independent and the RPs MUST NOT keep any relationship
between the different hierarchies.  This applies to "fallback" 
implementation behaviors as well, I guess...

Also, general guidance that as long as "old" or Algorithm Suite C 
data is considered in parallel to or IF "current" algorithm fails, 
the cryptographic vulnerabilities that triggered the rollover in the 
first place may well result in downgrade attacks.

---------------------------------------
Minor nits:

---
S 3 Terminology 

-
s/conventions use din examples/conventions used in examples/

-
Two occurrences of this ("CA Y" & "CA Z"):

s/used in examples this document/used in examples in this document/

---
S 4.2 Process Overview

-
s/prohibit a CA issuing/prohibit a CA from issuing/

---
S 4.7 Phase 4

s/figure describe a possible/figure describes a possible/

---
S 5

s/implementing a different resource classes/implementing different resource classes/

---
S 11

s/set will not longer be valid/set will no longer be valid/

---

From: Terry Manderson <[email-masked]>
Date: Sun, 30 Oct 2011 19:18:46 -0700

Some comments.

Section 4.3. Phase 0

I'm still struggling to see the necessity to put in the operational dates
for a Alg shift in [I-D.ietf-sidr-rpki-algs]. I concur that the future Alg
suite and to be EOL's suite should be identified once suitable candidates
have been selected in rpki-algs. But the dates in which the ALGs come into
effect[1], and are twiglighted/EOL'd seems like a operational CA/RP concern,
in a hierarchical manner, and would probably end up in the CA's CPS. As such
I question the viability, and validity, of fixing dates in the IETF.

[1] I would think that as soon at the document is updated and published they
are able to be used.

Phase 3

This section confuses me, the draft says that the RF MUST be able to do both
algorithms, but its recommended to only use Suite B.

The first sentence seems superfluous to me. Why not just:
" Phase 3 starts at the RP Ready Algorithm B Date.  During this phase,
   all signed product sets are available using both algorithm suites.
   It is RECOMMENDED that RPs utilize only
   Suite B for validation throughout this phase, in preparation for
   Phase 4. RPs MAY use Suite A if operationally necessary" ? (ie similar
wording as used in the Phase 4 Suite A/C observation.)

If that first sentence part " RPs MUST be able to .." is a necessity, it
makes me start thinking about a matrix decision process of using Suite A
(and|or) Suite B - which isn't described here.

or perhaps not even mention the RP's responsibility to Suite A in Phase 3??
...

Phase 4.

The ordering of the sentences could be shuffled I think.

The important statement is that the "CAs MUST neither issue nor publish
signed products using Algorithm Suite C" ... therefore any erroneous
issuance of suite C products MUST be considered invalid.
 
Section 5.

I think some discussion of the dates, and for communicating twilight and EOL
dates between the parent and the child should be here. I don't quite hold
the belief that it's a unidirectional downward assertion from parent to
child. In may well be in PKI - there there is a raft of operational
interaction  that surrounds that.

Section 6.

Can you spell out what you technically mean by "keep any relationship
between " in para 1?

Section 7.

Can you expand the recommendation in keeping the parallel certificate
hierarchies in sync by also identifying the Alg A/Alg C mix? (phase 4)

Twilight doesn't necessarily mean "dead wood is o.k".. since products MAY
still be constructed.

.. If these concerns can be addressed, then I think the document is ready to
move on.

Cheers
Terry

---

From: Stephen Kent <[email-masked]>
Date: Mon, 31 Oct 2011 06:57:00 -0400

>I question the viability, and validity, of fixing dates in the IETF.

We have included dates for alg start an EOL because they affect all 
RPs, and we want to make life predictable for RPs. Also, because the 
WG agreed that alg transition will be top-down (to avoid geometric 
growth in the repository system), it is necessary to set alg 
transition dates, for the benefit of
CAs as well.

>[1] I would think that as soon at the document is updated and published they

The top tier CAs have to be ready to issue certs under the new alg before
any lower tier CAs can do so, so we need a set date, agreed upon, in 
the future,
to start the transition.

>or perhaps not even mention the RP's responsibility to Suite A in Phase 3??

We want to encourage RPs to verify their ability to use the new Suite, but
we also realize that, during transition, there may be problems. So, 
we RECOMMEND use of Suite B, but require that if either Suite works, 
the RP MUST accept the data as valid. That provides a fall back 
position in case a CA doesn't get it right.

>issuance of suite C products MUST be considered invalid.

we can revisit this text to try to make it clearer, if others agree with
your observation.

>interaction  that surrounds that.

The dates for alg transition are published and accessible to 
everyone, so there is no need for pairwise communication of the 
dates. Because the alg transition affects ALL RPs, not just the 
children of a given CA, it is important to mandate the transitions on 
a global basis.

>Can you spell out what you technically mean by "keep any relationship

We will revise this sentence. The text is intended to note that the 
data extracted from the repository, signed under each alg, are 
treated separately. Thus one gets a compete, valid chain of data via 
Suite A or Suite B, but not a mix of data under A and B. The next 
paragraph explains this.

>hierarchies in sync by also identifying the Alg A/Alg C mix? (phase 4)

In phase 4, Suite C products MAY be present, which means that they 
also may be absent. So, we cannot say that the hierarchies are 
parallel any more.

>Twilight doesn't necessarily mean "dead wood is o.k".. since products MAY

Not sure what you mean by the above sentence.

Steve

---

From: Terry Manderson <[email-masked]>
Date: Mon, 31 Oct 2011 05:31:44 -0700

> transition dates, for the benefit of

I understand why you want to, but don't come to the same conclusion as to
the mechanism.

Is that really the IETF's job?

Is there prior art in the IETF where this has been done in such a date
specific manner?

> any lower tier CAs can do so, so we need a set date, agreed upon, in

Call me a dirty rotten cynic but I just don't see this operational aspect of
one or more running RPKI hierarchies as part of the IETF. Although you can
prove me wrong, and I'll concede to an already enacted example where dates
were set for some artifact.

> position in case a CA doesn't get it right.

In which case some clarification to the text could go a long way. I suspect
in the effort to simplify a complex process the text became too brief.

> children of a given CA, it is important to mandate the transitions on

I'm still not with you on this - I understand that it makes life easy to say
"the IETF said 12/12/2018 is D-Day, get with it" .. ... buuuutt I see that
as a step beyond what the IETF should do.

Noting the "fun" had with 6to4.

> Suite A or Suite B, but not a mix of data under A and B. The next

right, there is a discontinuous leap there that I didn't get. Clarification
would be appreciated.

> also may be absent. So, we cannot say that the hierarchies are

So perhaps suggest to the RP/Child CA that in the situation where a
revocation is issued for Suite A, _if_ there are products with matching
information for the Suite A revocation, a Suite C revocation should also be
issued.

> Not sure what you mean by the above sentence.

I think the above clarifies my meaning.

Cheers
Terry