Subject: Re: [sidr] removing TLS from the provisioning protocol

From: Geoff Huston <[email-masked]>
Date: Fri, 8 Oct 2010 23:03:19 +1100

sure!

If I scrub the HTTPS constructs from the draft what I'm left with are "naked" CMS objects (and they look a lot like rpki-signed objects, but they are not signed by keys certified by rpki certificates so I guess that technically they are NOT spki-signed-objects).

My question is: What is the end-to-end substrate for these objects? Or should I just scrub HTTPS and leave the rest undefined?

guidance please.

thanks,

  Geoff (no clothing specified)

On 15/09/2010, at 4:45 AM, Christopher Morrow wrote:

> SIDR-WG Folks,
> Hey, pulling up a note from the grave, this seems to have gotten no
> dissent so, could the authors (and implementors) go scrub the stink of
> tls off?
> 
> -Chris
> (wg-chair-scarf on)
> 
> On Mon, Aug 30, 2010 at 11:25 AM, Warren Kumari <[email-masked]> wrote:
>> 
>> On Aug 25, 2010, at 4:18 AM, Sandra Murphy wrote:
>> 
>>> We had a discussion in April on the list regarding removing TLS from the
>>> provisioning protocol.  Rob Austein presented his views on the issue at the
>>> sidr meeting at the IETF78 in Maastricht.
>>> 
>>> I am calling for wg consensus on the question.  Should the authors of
>>> draft-ietf-sidr-rescerts-provisioning-06 revise that draft to remove TLS
>>> from the protocol?
>> 
>> Yes, yes they should...
>> 
>> W
>> 
>>> 
>>> Please respond to the list by 8 Sept, so the authors can represent wg
>>> consensus in the draft.
>>> 
>>> --Sandy
>>> 
>>> _______________________________________________
>>> sidr mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sidr
>> 
>> --
>> No man is an island, But if you take a bunch of dead guys and tie them
>> together, they make a pretty good raft.
>>                --Anon.
>> 
>> 
>> _______________________________________________
>> sidr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sidr
>> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: Rob Austein <[email-masked]>
Date: Fri, 08 Oct 2010 08:32:37 -0400

At Fri, 8 Oct 2010 23:03:19 +1100, Geoff Huston wrote:
> 
> If I scrub the HTTPS constructs from the draft what I'm left with
> are "naked" CMS objects

I would have thought we'd be left with CMS objects wrapped in HTTP,
replacing CMS objects wrapped in HTTPS.  Strictly speaking, what we're
doing here is removing the TLS encapsulation of HTTP.

> (and they look a lot like rpki-signed objects, but they are not
> signed by keys certified by rpki certificates so I guess that
> technically they are NOT spki-signed-objects).

Different CMS eContentType OIDs too:

1.2.840.113549.1.9.16.1.24   id-ct-routeOriginAttestation 
1.2.840.113549.1.9.16.1.26   id-ct-rpkiManifest 
1.2.840.113549.1.9.16.1.28   id-ct-xml

---

From: Geoff Huston <[email-masked]>
Date: Sat, 9 Oct 2010 00:16:22 +1100

> doing here is removing the TLS encapsulation of HTTP.

ok - I can do that

> 1.2.840.113549.1.9.16.1.28   id-ct-xml 

that too!

I assume that in addition to the CMS requirement that:

"The signing-time attribute MUST be present"

there is an additional requirement that reads (approximately)

"Each party MUST ensure that the signing-time attribute value is strictly greater than the signing-time attribute value of the previous message sent to the same recipient. Messages received with a signing-time value less than that of the most recently received and accepted message from the same sender MUST be rejected."

I'm also pretty sure that this text is inadequate in various corner cases, and of there are suggestions on how to improve this skeletal text to allow he CMS signing-time attribute as a reasonable form of replay attack protection would be appreciated.

thanks

  Geoff

---

From: Rob Austein <[email-masked]>
Date: Fri, 08 Oct 2010 09:35:32 -0400

> "The signing-time attribute MUST be present"

Yes.

> "Each party MUST ensure that the signing-time attribute value is
> strictly greater than the signing-time attribute value of the
> previous message sent to the same recipient. Messages received with
> a signing-time value less than that of the most recently received
> and accepted message from the same sender MUST be rejected."

Close.  I think the proposal was that the signing time attribute must
be greater than or equal to the signing-time attribute of previous
messages sent by the same originator to the same recipient.

"Greater than or equal to" vs "strictly greater than" is important,
and is a tradeoff.  The advantage is that it removes the problem of
unintended rate limiting to one message per second (don't really know
if that's a real issue, but in theory it might be).  Disadvantage is
that it leaves one open to replay of the latest message, but with the
protocol as currently written, I haven't been able to think of
anything evil an attacker could do by replaying the most recent
message, and it's easy for the sender to add one-second delays (if
neede) to the middle of a command stream that really should not be
inverted.  So greater-than-or-equal-to seems right to me.

There probably should also to be a note somewhere stating that there
must be -some- way (even if only manually typing SQL commands, that's
an implementation detail) for an operator to reset this value, to
handle the case where a sender accidently signs with a time far in the
future (read: "wait two years and call me in the morning" is not the
preferred answer from the help desk in such cases).