Subject: [sidr] GOST & SIDR

From: Danny McPherson <[email-masked]>
Date: Mon, 6 Apr 2009 10:06:23 -0600

Given the DNS SEC discussions taking place regarding
GOST, are there adjustments that need to be made here
to accommodate this requirement as well?

-danny

---

From: Dmitry Burkov <[email-masked]>
Date: Mon, 06 Apr 2009 20:57:34 +0400

> to accommodate this requirement as well?
Danny,
I think so - as before I thought that it is necessary to correct current 
sidr drafts to accept multiple algorithms.
It seems reasonable simply from point of view that we will need to 
change algorithms as they will be unacceptable (broken).

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

---

From: Geoff Huston <[email-masked]>
Date: Tue, 7 Apr 2009 06:35:14 +1000

Danny,

Perhaps it would be appropriate in the first instance to assist  WG  
members to get into context here by providing one or two URLs that  
point to these "DNS SEC discussions taking place regarding GOST" that  
you are referring to here.

    Geoff Huston
    [WG Co-Chair hat ON]

---

From: Danny McPherson <[email-masked]>
Date: Mon, 6 Apr 2009 16:47:57 -0600

On Apr 6, 2009, at 2:35 PM, Geoff Huston wrote:

> point to these "DNS SEC discussions taking place regarding GOST"  
> that you are referring to here.

I picked up on this on the (non-IETF) DNSSEC-deployment
list (Subject "DNSSEC in Russia"), first message of thread
included below and archive available here:

<http://mail.shinkuro.com:8100/Lists/dnssec-deployment-archive/>

However, prior to that Dmitry Burkov mentioned it to me both
at the SIDR meeting - as well as at a DNS-related meeting prior
to that.

I saw a subsequent pointer here as well:

<http://blog.internetgovernance.org/blog/_archives/ 
2009/4/6/4142793.html>

I'm hoping folks well versed in this will assert some
clue - hence my query to the list.

-danny

Begin forwarded message:

> From: Suzanne Woolf <[email-masked]>
> Date: April 1, 2009 8:18:22 AM MDT
> To: "DNSSEC deployment" <[email-masked]>
> Cc: [email-masked]
> Subject: [dnssec-deployment] DNSSEC in Russia
>
>
> Colleagues,
>
> Steve Crocker and I just got off the phone from remotely participating
> in a session at RANS, the Russian security conference going on today,
> about DNSSEC.
>
> We were asked to offer a general overview, including special attention
> to cryptographic issues because Russia is interested in DNSSEC for .ru
> but has some legal and operational constraints that make common crypto
> (RSA) difficult to deploy. Veni Markovski (ICANN) was the frontman,
> presenting the slides, then Steve and I did some Q&A.
>
> I believe the session was very constructive. We were able to answer
> some questions about DNSSEC, particularly with multiple crypto
> algorithms, and promote open source and open standards as enhancing
> trust in situations like Russia's.
>
> I look forward to seeing .ru signed.
>
> Slidepack will be posted at ISC soonly, with thanks to the ISC staff
> who worked on it, especially Brian Reid.
>
>
> Suzanne
>
> #############################################################
> This message is sent to you because you are subscribed to
>  the mailing list <[email-masked]>.
> To unsubscribe, E-mail to: <[email-masked]>
> A public archive is available here: <http://mail.shinkuro.com:8100/Lists/dnssec-deployment/ 
> >
> and older material is at
> <http://mail.shinkuro.com:8100/Lists/dnssec-deployment-archive/>

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 16 Apr 2009 12:06:06 -0400 (EDT)

> I think so - as before I thought that it is necessary to correct 
> current sidr drafts to accept multiple algorithms.

To me, the meaningful question is "can we handle algorithm agility"? 
By that, I mean "can we, for reasons not yet specified but including 
discovery of weaknesses in some algorithms, cleaning introduce new 
algorithms"?

Section 3.3 of sidr-res-certs uses a 2119 MUST when saying the 
Signature Algorithm field MUST be one of X, Y, or Z.  By its language, 
that suggests that we can't handle algorithm agility.  But I suspect 
we really can handle it.

Is there any strong justification for a MUST?  Can we instead use a 
MUST only to describe validator support and use a RECOMMENED or SHOULD 
when talking about certficate generation?

And is there any reason why algorithm agility won't just work?

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 16 Apr 2009 16:41:11 -0400 (EDT)

On Thu, 16 Apr 2009, Samuel Weiler wrote:

> To me, the meaningful question is "can we handle algorithm agility"? By that, 
> I mean "can we, for reasons not yet specified but including discovery of 
> weaknesses in some algorithms, cleaning introduce new algorithms"?

Make that "cleanly introduce new algorithms".  I'm not have good luck 
with the typing today.

-- Sam

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Apr 2009 07:56:29 +0900

> And is there any reason why algorithm agility won't just work?

how do you capability negotiate with a cert?  i understand how to do it
with a protocol peer, but not a static object.

not that i think your desire is bad, i just don't see how to get there
from here.  

i suppose with enough complexity, ...  but this is one of those time i
think there is a version number in the protocol.

randy

---

From: Sean Turner <[email-masked]>
Date: Thu, 16 Apr 2009 20:30:31 -0400

> think there is a version number in the protocol.

I'm not saying you should do this but there's a way to indicate the 
other algorithms supported by the certificate holder using the S/MIME 
Capabilities certificate extension: http://www.ietf.org/rfc/rfc4262.txt. 
  It's not negotiation per se but it might help.

spt

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 20 Apr 2009 17:41:18 -0400 (Eastern Daylight Time)

> with a protocol peer, but not a static object.

I agree that it doesn't seem to be possible to negotiate, as there's only 
a one way communication between the two parties - signers sign, relying 
parties validate.  But I don't see that negotiating on algorithm support 
is necessary.

Can more than one algorithm be used in signing?  My very uninformed 
reading of 3280 says that the algorihm of the subject public key 
need not be the same as the issuer's signature algorithm.  Those of 
informed opinions should say otherwise.

Can more than one algorithm be used in validating?  Same uninformed 
opinion says that some islands could validate using one algorithm, other 
islands could validate using another.

Of course, if one island can use *only* one algorithm, and the other 
island can use *only* another algorithm, then neither island can validate 
all RPKI certs.  That's not good from the issuer's point of view, as the 
issuer would like its routes to be validatable everywhere.  So if there 
are multiple algorithms for whatever reason (from politics to new crypto 
breakthroughs), issuers might want to produce multiple certs, one per 
algorithm, for each certified resource.

(Could do that the other way around, also - the validators must support 
all algorithms, the issuers get to use a subset.  However, if some 
validators support *some* and some issuers support *some* - it would be 
hard to know or predict which parts of the Internet could validate each 
other's routes.)

In times of partial deployment of a new algorithm, any member of the 
side (issuer or validator) that is supposed to support all available 
algorithms but who does not yet support the new algorithm will be cutting 
themselves off from any portion of the net that uses only the new 
algorithm.  Or at least there will be more validation answers of 
"indeterminate".  Which sounds to me a lot like the situation we're 
considering now of partial deployment.

Certainly having just one algorithm, period, makes this a lot more 
predictable. That, surely, was the reason for mandating a single signature 
algorithm.  But it also makes agility, whether from politics or crypto 
changes, impossible.

> not that i think your desire is bad, i just don't see how to get there

As someone has already pointed out, the security directorate has been 
pretty insistent on having security agility everywhere, and for good 
reasons.  We need to consider if we can make a case that those good 
reasons do not apply, or that the cost is much too high.

(And getting there from here would require changing only the MUST for 
RSA...)

> think there is a version number in the protocol.

There is no protocol here, and the version number in the certs is fixed at 
"2" to represent "X.509 Version 3 certificates".  I don't think that's 
going to change any time soon.  :-)

--Sandy

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 20 Apr 2009 17:55:50 -0400 (EDT)

> with a protocol peer, but not a static object.

I'm not suggesting negotiation.

I'm asking "will RPKI partcipants who want to use algorithms different 
from the norm and/or their parents be able to do so without any bad 
effects"?  Using strange algorithms may well mean that most relying 
parties can't verify the certificates, but that's to be expected.

> think there is a version number in the protocol.

So long as "version number" isn't a synonym for "flag day", there's 
nothing wrong with having one.  But we already have algorithm 
identifiers in the certs.  Are those enough?

-- Sam

---

From: Randy Bush <[email-masked]>
Date: Mon, 20 Apr 2009 18:13:13 -0400

> effects"?

no

> Using strange algorithms may well mean that most relying parties can't
> verify the certificates, but that's to be expected.

i hope you do not think this is acceptable or useful.

randy

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 20 Apr 2009 18:41:08 -0400 (EDT)

On Mon, 20 Apr 2009, Randy Bush wrote:

>> I'm asking "will RPKI partcipants who want to use algorithms 
>> different from the norm and/or their parents be able to do so 
>> without any bad effects"?
>
> no
>
>> Using strange algorithms may well mean that most relying parties 
>> can't verify the certificates, but that's to be expected.
>

Strangely enough, I do think it's useful, or at least not harmful, but 
I'm interested in hearing your perspective.

Here's my perspective, informed in part by Dmitry's comments both here 
and on DNS-related lists:

There may (or will) be communities that WILL NOT sign with (=issue 
certificates signed by) algorithm X (=RSA).  They might happily sign 
with algorithm Y (=GOST).  Some parts of the world (=that same 
community plus some) will be able to verify Y certificates and will 
gain utility from them, perhaps by authenticating route originations 
from within that community.  To the parts of the world that can't 
verify algorithm Y certificates, hopefully it will be as though such 
certs were never issued which, if you assume incremental deployment, 
isn't so very bad.

So I do assume a world of partial deployment, and I assume that having 
no certificates issued won't cut you off from the rest of the net. 
And I assume that having only algorithm Y certificates is no worse 
than having none at all.

Where do you think I've gone astray?

-- Sam

---

From: Randy Bush <[email-masked]>
Date: Mon, 20 Apr 2009 18:45:18 -0400

> with algorithm Y (=GOST).

and there will be communities which run x.25 or decnet.  not a problem
to me.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 20 Apr 2009 19:17:54 -0400 (Eastern Daylight Time)

> and there will be communities which run x.25 or decnet.  not a problem

Except that if a significant portion of the world uses an algorithm your 
validator code can't handle, then you can't validate routes to that part 
of the world.

Which means you could be sending your packets to some destinations down 
some dark alley.

I would think that the validation of routes is not only of benefit in 
packets reaching you, but in you being more confident that your packets 
are going where they are meant to go.

(All of this "you" and "your" is only personification - I could say "one's 
packets", but that's just a bit too precious.)

Are you really advocating a system that could not support a change of 
algorithm?  A new algorithm means a new RPKI-v2?  (How is that different 
from an RPKI with a new OID in the alg field?)

--Sandy

---

From: Randy Bush <[email-masked]>
Date: Mon, 20 Apr 2009 20:29:51 -0400

> Except that if a significant portion of the world uses an algorithm
> your validator code can't handle, then you can't validate routes to
> that part of the world.

like if drc decides to change in a panic because dean anderson said he
broke X?

> packets reaching you, but in you being more confident that your
> packets are going where they are meant to go.

hard to disagreee with that.  though, to be pedantic, we are securing,
or attempting to secure, the control plane, not the data plane.

> algorithm?  A new algorithm means a new RPKI-v2?

i really do not think it's gonna be reasonable to add a new algorithm
without serious operational planning and roll-out.  if this stuff
deploys successful, N years from now, there will likely be a significant
part of the net that just won't except non-validatable routing data.
and we can't just let chunks of the net go unroutable.

i also worry that non-trivial chunks of the net may not manage their
certification data well, just as they do not manage bogon filters well
today.

basically, i think we need a few years of experience to get a feeling
for what kinds of change we can tolerate and what kinds we need.

> (How is that different from an RPKI with a new OID in the alg field?)

probably not much.  excuse the jet lag wipeout.  at least i managed to
get some food.

but if there is negligible difference, then why/what exactly does sam
want to change? :)

randy

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 21 Apr 2009 13:16:25 -0400 (Eastern Daylight Time)

> but if there is negligible difference, then why/what exactly does sam

The word "MUST" in the section about use of RSA as the signature 
algorithm.

To something like, maybe, "mandatory to implement"?  I'm guessing.

--Sandy

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Apr 2009 13:19:21 -0400

> To something like, maybe, "mandatory to implement"?  I'm guessing.

that addresses the reader.  but how does this help when the writer
uses an 'optional' one?

randy

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 21 Apr 2009 14:16:38 -0400 (Eastern Daylight Time)

> that addresses the reader.  but how does this help when the writer

The writer has also implemented the "mandatory to implement" algorithm, 
and produces a cert with that algorithm as well.

Parallel certs.  (Whole set of things to worry about there as well.)

--Sandy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Apr 2009 14:40:00 -0400

Given the constraints of the certificates (a given certificate can only 
use a single algorithm) it seems to follow that the necessary mechanism 
to allow for migration of algorithms is that we must allow for multiple 
certificates for the same block, with different algorithms.
This does of course produce the potential for myriad subtl inconsistency 
problems.

But the alternative of pretending that we know now the final algorithm 
that we will ever want to use seems very wrong.

Yours,
Joel

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Apr 2009 14:51:56 -0400

> and produces a cert with that algorithm as well.
                                          ^^^^^^^
> Parallel certs.

gag me with a spoon

randy

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 Apr 2009 15:24:57 -0400

>and produces a cert with that algorithm as well.

Such a thing may be necessary to transition from one algorithm to 
another.  Well, let's get this stuff deployed, and then in a decade 
or more when the currently specified algorithm is showing some 
tarnish, we can consider algorithm transition schemes.

Russ

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 21 Apr 2009 16:57:53 -0400 (EDT)

>> that addresses the reader.  but how does this help when the writer

It doesn't.

> The writer has also implemented the "mandatory to implement" algorithm, and 
> produces a cert with that algorithm as well.

Maybe, maybe not.  The constraint presently at hand says "no, we won't 
produce certs using both algorithms".  "Mandatory to implement" does 
not imply "mandatory to sign with".  The document DOES say "MUST..." 
now, and I've previously asked what the justification for that MUST 
is.

> Parallel certs.  (Whole set of things to worry about there as well.)

Indeed.  Hence my questions about "do we know how algorithm agility 
will work"?

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 21 Apr 2009 16:59:08 -0400 (EDT)

>> and produces a cert with that algorithm as well.

AFAIK, that's pretty typical if you're aiming for real "agility".  Do 
you know of another way?

> but if there is negligible difference, then why/what exactly does 
> sam want to change? :)

Quoting from April 16th: "Is there any strong justification for a 
MUST?  Can we instead use a MUST only to describe validator support 
and use a RECOMMENED or SHOULD when talking about certficate 
generation?"  So I'm proposing that we don't require cert generation 
with any particulay set of algorithms, just that the code understand a 
certain set.

Does that clarify?

-- Sam

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Apr 2009 17:08:52 -0400

Maybe I am just crazy, but this seems to cause us to miss the two goals 
I thought we had:
1) Aiming at an end state where every router (possibly with some outside 
help) can verify the origin of every prefix advertisement.
2) the security-mandated ability to change algorithms over time.

If we are not aiming at the first, I am missing the point of the work.
If we do not try to deal with the second, aren't we inviting trouble?

Yours,
Joel

Samuel Weiler wrote:
> Quoting from April 16th: "Is there any strong justification for a MUST?  
> Can we instead use a MUST only to describe validator support and use a 
> RECOMMENED or SHOULD when talking about certficate generation?"  So I'm 
> proposing that we don't require cert generation with any particulay set 
> of algorithms, just that the code understand a certain set.
> 
> Does that clarify?
> 
> -- Sam
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Apr 2009 17:55:23 -0400

> AFAIK, that's pretty typical if you're aiming for real "agility".  Do 

nope, though i am not well versed in this end of the swamp.  but there
is a non-trivial difference between having two equivalent blobs and two
equivalent/parallel pieces of hierarchy, as in pki.  the latter goes
places that give me the shudders.

> with any particulay set of algorithms, just that the code understand a

yes.  but i am not sure why it should make me more comfortable.

randy