Subject: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 18 May 2016 08:51:09 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-sidr-rpsl-sig-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'd like to check one thing - this may be needed for strict
compliance with RPKI thing but it seems kinda weird to also
impose that here, but anyway...

Is 3.2 step 1 needed?  That seems like useless complexity
here.  If it is needed, how does the verifier check that
it's really a single-use? I don't see the point TBH.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- If you keep the potential for http(s) URIs then I think
more text is needed in the security considerations but
it looks like you're taking that out for now so I guess
that's ok. 

- 2.1, I don't see why it's useful to allow variation in the
fields of the signature attribute e.g. why "MAY" the version
not be 1st?

- 2.1, "t=" and "x=" any limits on precision here?
(Non-)support for fractional seconds can be a source for
non-interop if not. The "All times MUST be converted to" is
also actually a little ambiguous as you don't say to do that
before signing;-)

- 2.1, "a=" did you want a lowercase "must" there?

- Are steps 2 and 3 in 3.1 order-sensitive? I think you
might sometimes need to do 2 after 3, or re-do 2 maybe or
else leading whitspace could be an issue. Maybe say that
sometimes you need to do step 2 >1 time?  

- 3.1, oops, an ambiguity - in "The following steps MUST be
applied in order..." does "in order" mean "in the order
below" or "so as to"? I assume the latter.

- 3.1: In general I think you'd be better if you pointed at
specific bits of text in all the RFCs mentioned in 3.1 -
it's maybe easy to get wrong otherwise, esp. if we don't yet
have >1 implementation. 

- 3.1, step 6: names are all ASCII right? just checking

- 3.2, step 1 - given 3.3 step 2, you're missing a step to
"publish the cert" at the c= location as well.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 18 May 2016 12:06:29 -0400

Hiya Stephen,

> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/

This text was driven by the statement in RFC 6487 (Section 3) that says:

   The private key associated with an EE certificate is used to sign a
   single RPKI signed object, i.e., the EE certificate is used to
   validate only one object.

Step 1 in 3.2 is there so that this approach follows the above directive
on the use of the RPKI infrastructure/certificates.

Regards,
Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 May 2016 17:09:49 +0100

Hiya,

> on the use of the RPKI infrastructure/certificates.

Well... sure. But what is the benefit here? IIRC that was
something related to making more fine-grained revocation
possible or something which doesn't seem that useful here
since a verifier will likely already have processed stuff
already or am I mixed up?

If there's no benefit, it seems like that adds a bunch of
CA code just for fun (or "compliance" maybe;-)

Ta,
S.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 18 May 2016 12:20:05 -0400

Hiya Stephen,

> Well... sure. But what is the benefit here? IIRC that was

I *think* the benefit is supposed to be compliance with the RPKI approach...

> already or am I mixed up?

I don't think you are mixed up, but I will let others in SIDR chime in...

> CA code just for fun (or "compliance" maybe;-)

I could very easily see dropping step 1 from 3.2 and simply augmenting
the intro sentence with something about certs/keys generated per 3487.

Regards,
Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 May 2016 17:32:06 +0100

goto bottom:-)

> I don't think you are mixed up, but I will let others in SIDR chime in...

Yeah, be good if someone could justify doing that. Maybe
there's a good reason, though I'm not seeing it.

> the intro sentence with something about certs/keys generated per 3487.

My guess is that that'd lead signing implementers to not
generate new and possibly useless certs. I guess I'd be ok
with that but it seems a bit unfair of us to be sorta kinda
not telling 'em that they ought have the code for that. (The
verifier doesn't know/care in this case afaics, though of
course that means that the once-only aspect is also a bit
"pretendy" too I suppose.)

Anyway, yeah, maybe having someone more up to speed on
sidr than I say why this makes sense here is the best next
step so that we don't muck up or take the pretendy route?

Cheers,
S.

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 18 May 2016 17:12:28 -0400

comments inline.  speaking as a regular ol’ wg member

On May 18, 2016, at 12:20 PM, Brian Haberman <[email-masked]> wrote:

> I don't think you are mixed up, but I will let others in SIDR chime in…

There was at one point in the history of resource certificates the idea that EE certs could be used multiple times.  (EE certs even had their own manifests!)

The signed object definition encapsulated the EE cert used to verify the signature.  That revocation of the signed object could be accomplished by revoking the EE cert.  Which meant that the EE cert should be used just to sign that one object, as Stephen says. (otherwise chaos ensues)

As the only defined use of EE certs at the time of the publication of 6487 was the use to verify signed objects, the text about EE certs was reduced to just that necessary to support the single-use.

This is different.  The validity of the rpsl object is not tied to the validity of the EE cert.  The comments from the wg were that this draft should talk about the syntax of the new attribute, not the authorization/semantics.  So revocation of the EE cert in this case would/might not have the effect of revoking the rpsl object.  I personally don’t think it likely that it ever will, but that’s IMHO only.

So it is a moot question as to whether the single-use is a part of “the RPKI approach” for this rpsl-sig use.

>> CA code just for fun (or "compliance" maybe;-)

curious: how would this single-use requirement add anything to the CA code?  If the requirement is in 6487, the CA code would already have the checks.  I ask only because I might be missing something.

> the intro sentence with something about certs/keys generated per 3487.

I think you mean 6487?

You have already suggested removing the SIA requirement from 6487 for the EE certs rpsl-sig uses, so these EE certs are already a different sort of EE cert. Other special  requirements as necessary.

—Sandy, speaking as a regular ol’ wg member

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 May 2016 22:23:38 +0100

Hi Sandy,

On 18/05/16 22:12, Sandra Murphy wrote:
>>>>> Stephen Farrell has entered the following ballot position
>>>>> for draft-ietf-sidr-rpsl-sig-11: Discuss
>>>>> 
>>>>> When responding, please keep the subject line intact and
>>>>> reply to all email addresses included in the To and CC lines.
>>>>> (Feel free to cut this introductory paragraph, however.)
>>>>> 
>>>>> 
>>>>> Please refer to
>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for
>>>>> more information about IESG DISCUSS and COMMENT positions.
>>>>> 
>>>>> 
>>>>> here.  If it is needed, how does the verifier check that it's
>>>>> really a single-use? I don't see the point TBH.
>>>>> 
>>>> 
>>>> The private key associated with an EE certificate is used to
>>>> sign a single RPKI signed object, i.e., the EE certificate is
>>>> used to validate only one object.
>>>> 
>>>> Step 1 in 3.2 is there so that this approach follows the above
>>>> directive on the use of the RPKI infrastructure/certificates.
>>> 
>>> something related to making more fine-grained revocation possible
>>> or something which doesn't seem that useful here since a verifier
>>> will likely already have processed stuff already or am I mixed
>>> up?
>> 
> There was at one point in the history of resource certificates the
> idea that EE certs could be used multiple times.  (EE certs even had
> their own manifests!)
> 
> The signed object definition encapsulated the EE cert used to verify
> the signature.  That revocation of the signed object could be
> accomplished by revoking the EE cert.  Which meant that the EE cert
> should be used just to sign that one object, as Stephen says.
> (otherwise chaos ensues)
> 
> As the only defined use of EE certs at the time of the publication of
> 6487 was the use to verify signed objects, the text about EE certs
> was reduced to just that necessary to support the single-use.
> 
> This is different.  The validity of the rpsl object is not tied to
> the validity of the EE cert.  The comments from the wg were that this
> draft should talk about the syntax of the new attribute, not the
> authorization/semantics.  So revocation of the EE cert in this case
> would/might not have the effect of revoking the rpsl object.  I
> personally don’t think it likely that it ever will, but that’s IMHO
> only.
> 
> So it is a moot question as to whether the single-use is a part of
> “the RPKI approach” for this rpsl-sig use.

But that means that there is no reason to include the requirement
here then or am I missing something? Deleting that "step" in the
signing process would seem like a good idea so. (Assuming that
current implementers, if any, are fine with that.)

> 
>> 
>>> 
>>> If there's no benefit, it seems like that adds a bunch of CA code
>>> just for fun (or "compliance" maybe;-)
> 
> curious: how would this single-use requirement add anything to the CA
> code?  If the requirement is in 6487, the CA code would already have
> the checks.  I ask only because I might be missing something.

What I was trying to say was that requiring signers of this to
include all the CA code is the problem/oddity, esp if there's no
real benefit.

So the single-use thing doesn't add to the CA code, it adds a
need for the CA code in the wrong place.

And I guess if the spec says "once only" then I can well imagine
some poor verifier implementer keeping some kind of cache and
checking it'd not seen a signature before or something like that.
And that'd also be kinda pointless code too I think.

>> 
>> I could very easily see dropping step 1 from 3.2 and simply
>> augmenting the intro sentence with something about certs/keys
>> generated per 3487.
> 
> I think you mean 6487?
> 
> You have already suggested removing the SIA requirement from 6487 for
> the EE certs rpsl-sig uses, so these EE certs are already a different
> sort of EE cert. Other special  requirements as necessary.

Great - so no need to do the single-use thing here then? But I
may not be grokking all the consequences of the above so please
do correct me if I'm wrong.

Cheers,
S.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 19 May 2016 08:11:50 -0400

Hiya Stephen,

> current implementers, if any, are fine with that.)

As one implementer, I have no problem dropping this step. There is
nothing in my RPSL code that enforces this (it is a function of the RPKI
EE cert usage).

> And that'd also be kinda pointless code too I think.

I certainly don't do any type of checking at the verification step.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 19 May 2016 08:18:16 -0400

One further point... Dropping step 1 in section 3.2 is one part of this
change. I think that the fourth bullet in section 5 can be dropped as
well.  Thoughts?

Regards,
Brian