Subject: [sidr] agenda items request

From: Sandra Murphy <[email-masked]>
Date: Tue, 6 Jul 2010 06:45:17 -0400 (Eastern Daylight Time)

The draft agendas are due Wednesday July 14 (a week from tomorrow).

Anyone who has a topic or draft to discuss, please send a message to the 
list or to both chairs.

--Sandy

---

From: Rob Austein <[email-masked]>
Date: Tue, 06 Jul 2010 10:02:25 -0400

> Anyone who has a topic or draft to discuss, please send a message to the 

I would like to see if we can achieve WG consensus to remove TLS from
the provisioning protocol, per list discussion back in April.

Given that the list is the WG, in theory this should not require face
time, but as the proposal seems to have stalled, perhaps the face to
face meeting can serve as a forcing function.

---

From: Rob Austein <[email-masked]>
Date: Tue, 06 Jul 2010 10:29:31 -0400

> Anyone who has a topic or draft to discuss, please send a message to the 

I would also like to see some discussion of the simplified trust
anchor proposal.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 06 Jul 2010 16:55:21 +0200

> I would also like to see some discussion of the simplified trust

I agree that this needs discussing.

For the WG reference we have just upgraded our beta test implementation
at the RIPE NCC to the current TA draft. It may be interesting to look
at a live example of the current draft (save bugs that we may have
overlooked, comments welcome).

This implementation is not cast in stone. We were aware of the
discussion, but at that time the implementation was almost finished and
we needed _something_ defined in a public draft now.

URIs:
ETA: rsync://certrepo.ripe.net/eta/CN=ETA,O=RIPE%20NCC,C=NL.cer
RTA: rsync://certrepo.ripe.net/rta/CN=RTA,O=RIPE%20NCC,C=NL.cer

Regards,
Tim Bruijnzeels

Senior Software Engineer
RIPE NCC

---

From: Geoff Huston <[email-masked]>
Date: Wed, 7 Jul 2010 10:35:09 +1000

> face meeting can serve as a forcing function.

As I recall TLS was used as a convenient mechanism to prevent forms of replay attacks.

What protection is provided against replay attacks in the absence of TLS?

Geoff (neither for nor against, just worried that we are dropping protection for the sake of implementation simplicity)

---

From: Geoff Huston <[email-masked]>
Date: Wed, 7 Jul 2010 10:40:40 +1000

> I would also like to see some discussion of the simplified trust

What appears to me missing in this second model, aside from the comments provided earlier by Steve Kent, is the singalling to relying parties as to the suggested refresh interval for the RTA. IN the ETA/RTA model the CRLDP provides a time interval that can be used by RPs to configure their next refresh of the local RTA. In this model what is the suggested refresh interval? Does one explicitly use short validity times on the RTA (this would be strange/ possibly bad) or does one leave it to the RP to just guess (again this seems strange/ possibly bad).

  Geoff

---

From: Geoff Huston <[email-masked]>
Date: Wed, 7 Jul 2010 11:51:41 +1000

> What appears to me missing in this second model, aside from the comments provided earlier by Steve Kent, is the singalling to relying parties as to the suggested refresh interval for the RTA. IN th…

sorry - thats the CRL itself, not the CRLDP

  Geoff

---

From: Rob Austein <[email-masked]>
Date: Tue, 06 Jul 2010 22:59:53 -0400

> As I recall TLS was used as a convenient mechanism to prevent forms

That was indeed the theory back in the day.  In practice, the way we
ended up using TLS does not provide any replay protection worth
mentioning, as discussed on this list back in late April.

> What protection is provided against replay attacks in the absence of

Again, discussed on this list in late April.  In brief: at the moment
we have no replay protection, adding it would not be hard, and
removing TLS wouldn't make it any harder.

---

From: Rob Austein <[email-masked]>
Date: Tue, 06 Jul 2010 23:07:40 -0400

At Wed, 7 Jul 2010 10:40:40 +1000, Geoff Huston wrote:
> What appears to me missing in this second model, aside from the
> comments provided earlier by Steve Kent, is the singalling to
> relying parties as to the suggested refresh interval for the RTA. IN
> the ETA/RTA model the CRLDP provides a time interval that can be
> used by RPs to configure their next refresh of the local RTA. In
> this model what is the suggested refresh interval? Does one
> explicitly use short validity times on the RTA (this would be
> strange/ possibly bad) or does one leave it to the RP to just guess
> (again this seems strange/ possibly bad).

The simplified mechanism has no need for an explicit refresh interval.
The self-signed RPKI certificate (corresponding to the RTA in the
ETA/RTA model) is just another object to be retrieved using rsync, so
one using rsync to retrieve it on validation if it has changed, same
as any other object.  No special handling needed.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 7 Jul 2010 19:33:01 +1000

> removing TLS wouldn't make it any harder.

Discussed in November and April as far as I can see:

Steve Kent: 3 November 2009
"My recollection differs somewhat. I think what Russ and I suggested was using TLS to enable session-level protection, which includes two-way authentication at the time of session creation (as an input to access control for the server), session integrity (i.e., dropped or re-ordered packets are detectable), and session authentication (i.e., all packets belonging to the same session are verified as such). Anti-replay at the session level and within a session are two facets of this protection suite."

Steve Kent: 4 November 2009
"I understand your comment that HTTP per se has no real session flavor. Not surprising since it was designed to support stateless query/response exchanges.  That was changed as cookies were added to enable better support of state, without changing the base protocol in a fundamental way. I am not enough of an HTTP guy to know what are appropriate ways to get the session flavor that we want, taking advantage of the TLS/HTTPS combination. I'm tempted to suggest use of IPsec, but I'm biased :-)."

Russ Housley: 28 April 2010
"This seems quite reasonable to me." ["This" is referring to dropping of TLS]

hmmm - I'm not sure that there was any clarity of resolution so far in terms of the traffic on the mailing list. I also have not seen any alternate approach to replay protection on the WG mailing list other than your assertion that "adding it would not be hard". It would help me (and maybe other WG folk) to understand the degree of difficultly here if we were to move on from such assertions and looked at specific mechanisms that would provide such replay protection.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 7 Jul 2010 20:41:23 +1000

> as any other object.  No special handling needed.

And key roll over of the RTA?

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Jul 2010 19:45:58 +0900

> hmmm - I'm not sure that there was any clarity of resolution so far in
> terms of the traffic on the mailing list.

hmmm.  then maybe we should discuss it in maastricht, which, i believe
was the original subject.

randy

---

From: Rob Austein <[email-masked]>
Date: Wed, 07 Jul 2010 09:25:35 -0400

At Wed, 7 Jul 2010 19:33:01 +1000, Geoff Huston wrote:
> 
> I also have not seen any alternate approach to replay protection on
> the WG mailing list other than your assertion that "adding it would
> not be hard".

http://www.ietf.org/mail-archive/web/sidr/current/msg01538.html

---

From: Rob Austein <[email-masked]>
Date: Wed, 07 Jul 2010 09:31:08 -0400

> And key roll over of the RTA?

Question does not translate exactly because of differences in the
mechanisms.  The equivalent operation would be rolling the key of the
certificate described in the last sentence of section 4 of Sam's
draft.  From the relying party's point of view, this is just another
RPKI certificate, no special handling required.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Jul 2010 12:28:20 -0400

>as any other object.  No special handling needed.

Rob,

rsync is not an ideal way to know when a new cert needs to retrieved, since
we don't assume that either the repository or the channel used to 
access it are integrity secure.

If I understand Geoff's comment, I might have phrased it differently.  For both
the compound TA and simplified TA models, the self-signed certs that 
used as TAs for 3779 validation contain a validity interval which is 
the primary way to determine when to acquire a new cert. However, in 
the compound TA model there is a CRL, and that provides an 
independent way to tell an RP when to check to see if the TA may have 
been replaced, without having to re-issue that cert if there is no 
change. I think you can achieve the same effect by mandating a second 
tier CA as the effective TA, which will be covered by a CRL issued by 
the top tier TA. (I believe my analysis urged adoption of this 2-tier 
CA model to make the two schemes comparable. Geoff's observation 
provides another motivation for doign so.)

Steve

---

From: Geoff Huston <[email-masked]>
Date: Thu, 8 Jul 2010 07:58:26 +1000

> http://www.ietf.org/mail-archive/web/sidr/current/msg01538.html

thanks

---

From: Geoff Huston <[email-masked]>
Date: Thu, 8 Jul 2010 08:18:44 +1000

> http://www.ietf.org/mail-archive/web/sidr/current/msg01538.html

The ensuring short exchange was inconclusive as far as I can tell. The four options that were considered at the time raised by yourself and Rob Kisteleki were:

a) treat the sender's time in the CMS as a monotonically increasing sequence and insist that every message from a sender uses a higher value than the previous message.

my understanding of this is:
pros - already in the CMS
cons - if the time at a second level granularity is used, then the request rate is limited

b) use an explicit sender's message id, and treat this as a strict (+1) counter where a jump in the counter value is also detected

my understanding of this is:
pros - can also detect requests that have not made it
cons - change to the XML spec

c) use a) with a nanosecond granularity 

my understanding of this is:
pros - addresses the maximum request erate problem
cons - rfc4049 and RFC5652 both specify time in seconds, so its not possible to directly use the CMS signing time fields here

d) use a) but allow the sender to have a time equal to or higher than the time of the previous request

my understanding of this is:
pros - already in the CMS
cons - rapid fire replay and reordering is possible. Is reordering of messages (request and revoke) a concern here?

My personal opinion is that d) would be adequate as long as the potential for MITM reordering was considered to be relatively  harmless. Is this the case?

Geoff

---

From: Rob Austein <[email-masked]>
Date: Wed, 07 Jul 2010 19:23:32 -0400

At Thu, 8 Jul 2010 08:18:44 +1000, Geoff Huston wrote:
> cons - rapid fire replay and reordering is possible. Is reordering
>        of messages (request and revoke) a concern here?
> 
> My personal opinion is that d) would be adequate as long as the
> potential for MITM reordering was considered to be relatively
> harmless. Is this the case?

That's my take as well.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 09 Jul 2010 11:45:21 +0200

>> harmless. Is this the case?

We have not yet implemented up-down. But as far as I can tell from
following the mailing list discussion and just looking at the draft I am
in favour of dropping TLS and this option d seems okay to me as well.

It's probably good to have an item on this in Maastricht to make sure
there is consensus as Rob suggested in his first mail in this thread.

Cheers,
Tim

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

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 09 Jul 2010 11:54:45 +0200

> Anyone who has a topic or draft to discuss, please send a message to the

Do people see value in discussing the key roll-over algorithm in
Maastricht? Or is the mailing list discussion enough for now? I am happy
to present something on how we are currently dealing with this if this
will help the discussion.

For my part I would like to avoid that we would have to re-work our
implementation significantly in the future.. So I would like to know two
things:
 -- Is there a need for a draft on key roll-overs?
     --> there may be more than one way to do this..

 -- Is our implementation okay given the current drafts?
     --> may be not so relevant to the wg, but good to know for me ;)

Cheers,
Tim