Subject: [Sidr] comments on draft-ietf-sidr-res-certs-02

From: Joe Abley <[email-masked]>
Date: Thu, 5 Oct 2006 11:33:07 -0400

I have read draft-ietf-sidr-res-certs-02, and have some comments.

I have decidedly little experience of the guts of X.509 certificates,  
but some practical experience of routing systems and resource  
assignment. The following comments (and the absence of comments on X. 
509 minutiae) should be read in that context.

I have assumed that the intended audience for this draft includes  
organisations which assign resources to others (the IANA, RIRs, NIRs,  
LIRs) and those which might have a reason to validate a certificate  
for a particular resource (RPSL repositories, transit providers being  
asked to announce new customer prefixes). Both these groups'  
perspectives seem to be well-covered in this document.

There are no examples provided in the document of how these  
certificates might be used, once generated. I realise that's a much  
wider topic of which a description of the certificates themselves is  
a small component; however, some examples might be useful in the  
event that this document is ever read in isolation.

Section 3 contains fields described using phrases such as "positive  
integer" without including information about the field width -- in  
other words, there's no comment on the maximum value that might be  
stored. Perhaps this is implicit in the design of X.509, but since I  
couldn't find any mention of it in RFC 3280 either, I thought I'd  
make the observation here.

In section 3.7 the draft alludes to possible reasons for a resource  
certificate's "valid to" field to extend beyond that in the superior  
certificate. It's not clear to me why this should be the case. I  
don't have strong opinions about this, but it seems possible that an  
example would lend some clarity.

In section 3.8 the draft uses normative language to specify key  
sizes. Should it not instead specify *minimum* key sizes, or is it an  
explicit goal to specify an absolute size? (Would it be bad, for  
example, if I chose to use a 4096 bit key instead of the 2048 bit key  
I SHOULD use?)

Section 3.9.1 has a typo, maybe ("cA" vs. "CA")?

Section 3.9.2 is missing a space between the "of" and the "[RFC3280]"  
at the end of the last paragraph.

In section 3.9.5, why is an rsync URI preferred over any other kind  
of URI? There's no normative language surrounding the stated  
preference. Is a preference lacking normative teeth worth mentioning?  
If so, might it be an idea to indicate that other URIs MAY be used  
instead?

In section 3.9.6 and 3.9.7 the rsync URI is specified again, this  
time as a MUST with a note that other URIs MAY be used. While I'm  
still interested in why the rsync URI is a MUST, the language and the  
associated MAY make these sections clearer than 3.9.5.

In general, the draft seems to systematically misspell words like  
"authorise" and "recognise", in defiance of the authors' Commonwealth  
origins. Also I'm fairly sure "unexpired" is not a word; "non- 
expired" seems better. :-)

Joe

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

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 05 Oct 2006 17:51:45 +0200

Sandy and others,

I read the draft and it looks fine, though I immediately admit that
I didn't look at every tiny detail.

The draft is being used by the teams working on prototype implementation
of this, at APNIC and RIPE NCC (and others).  The engineer working
on this here, said the draft is fine but there are some details to
be worked out.  This is being discussed on the list that the APNIC and
RIPE NCC folks use to discuss their work, rather than the IETF SIDR
list.  A number of things brought up there, actually made it into
the -02 version of the draft.

(I agree that the discussion should take place on the IETF list but
don't ask me how to get it there.)

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

1160438400 + 381600 = 1160820000.

---

From: Robert Loomans <[email-masked]>
Date: Fri, 06 Oct 2006 20:01:04 +1000

Thanks, Joe, for the feedback.

I am one of the APNIC staff working on this, and a co-author of the
draft.

> event that this document is ever read in isolation.

Good call. Such examples mostly live in Geoff's slidepacks at the moment...

> make the observation here.

Serial numbers are discussed in section 4.1.2.2 of RFC 3280:

"Certificate users MUST be able to handle serialNumber values up to 20
octets.  Conformant CAs MUST NOT use serialNumber values longer than 20
octets."

> example would lend some clarity.

An example of this in situations where there are contractual or
membership period differences between your upstream and and downstream.

As an APNIC member your APNIC-issued certificates would have validity
related to their typically annual membership, but you might have
relationships with your customers that are expected to last longer. You
can issue certificates to your customer reflecting that longer
relationship, and you don't have to re-issue when your APNIC
certificates are re-issued.

Another example (that just came to mind) is that within a company, you
might delegate resources to different sections. Obviously you expect
those relationships to last indefinitely, and you can reflect that in
the validity period.

> example, if I chose to use a 4096 bit key instead of the 2048 bit key

I believe there are concerns about the overhead of using unnecessarily
larger keys....

> Section 3.9.1 has a typo, maybe ("cA" vs. "CA")?

No... the ASN.1 definition of BasicConstraints in RFC 3280 calls the
field cA:

   BasicConstraints ::= SEQUENCE {
        cA                      BOOLEAN DEFAULT FALSE,
        pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

>  associated MAY make these sections clearer than 3.9.5.

There are two issues here:

1) We want *all* certificates, CRLs, etc to be available and accessible
by only having to implement one protocol. Alternative protocols are
fine, but one protocol is mandatory. This will aid in interoperability.

2) We want a protocol with properties that include fetching complete
trees of objects/files, and, if you already have an old tree, just the
changes. We could implement this in any transport, but RSYNC does this
for free.

>  origins.

Ummm.... not my call :)

> Also I'm fairly sure "unexpired" is not a word; "non-expired" seems
> better. :-)

Pedant! :-P

Cheers,
    Rob

-- 
Robert Loomans                                 Email:  [email-masked]
Programmer/Analyst, APNIC                      Phone:    +61 7 3858 3100
http://www.apnic.net                             Fax:    +61 7 3858 3199
_______________________________________________
Sidr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sidr

---

From: Joe Abley <[email-masked]>
Date: Fri, 6 Oct 2006 08:02:17 -0400

> I believe there are concerns about the overhead of using unnecessarily

I'd like to understand that concern a little better.

It seems to me (as a crypto non-expert) that the three principle  
degrees of freedom available when you generate a key are the  
algorithm, the key length, and the the validity period.

For applications in which the key is exercised very regularly, the  
usual (general) advice I have heard is to use a larger key, or to  
reduce the validity period.

This kind of advice regarding specific key lengths and lifetimes  
seems to change over time -- the key sizes get longer and the  
validity periods get shorter -- presumably as a result of ongoing  
research and improved capabilities of the machinery which can be used  
to break keys.

By specifying absolute values for the algorithm and the key size,  
this document leaves us only with the validity period, and changing  
that in many cases is going to involve talking to a customer to  
reissue a certificate. Talking to customers is expensive.

For sensitive applications, it also seems possible that in the future  
the requirement to use a 2048-bit key length might imply the need for  
such keys to expire more frequently than is practical to manage.

I'm quite prepared to believe there are reasons to fix the key size  
in the specification, but I think that decision needs some  
justification.

Joe

---

From: Róbert Kisteleki <[email-masked]>
Date: Sat, 07 Oct 2006 17:45:53 +0200

> I'd like to understand that concern a little better.

I had the same concern a while ago - namely that 2048 should be a minimum. 
At that time Stephen Kent pointed out that on the longer term he would 
prefer to move to EC-DSA instead of RSA with larger key sizes.

Regards,
Robert

---

From: Cat Okita <[email-masked]>
Date: Sun, 8 Oct 2006 15:21:43 -0400 (EDT)

> don't ask me how to get it there.)

Is there a way to peruse their archives, so we've got some idea of the
discussions that have been taking place?

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."

---

From: Cat Okita <[email-masked]>
Date: Sun, 8 Oct 2006 15:46:33 -0400 (EDT)

On Fri, 6 Oct 2006, Joe Abley wrote:
> This kind of advice regarding specific key lengths and lifetimes seems to 
> change over time -- the key sizes get longer and the validity periods get 
> shorter -- presumably as a result of ongoing research and improved 
> capabilities of the machinery which can be used to break keys.
>
> By specifying absolute values for the algorithm and the key size, this 
> document leaves us only with the validity period, and changing that in many 
> cases is going to involve talking to a customer to reissue a certificate. 
> Talking to customers is expensive.

I would strongly suggest that if absolutely necessary, the key size and 
algorithm not not be fixed, but that a basic compatibility requirement
should be set.  All of the PXIX working group documents that I've checked 
through avoid the pitfall of specifying an absolute algorithm/key size - 
and I strongly suspect that there are far more cryptographers there than here.

3.3.  Signature Algorithm

    This field describes the algorithm used to compute the signature on
    this certificate.  This profile specifies SHA-256 with RSA
    (sha256WithRSAEncryption), and, accordingly, the value for this field
    MUST be the OID value 1.2.840.113549.1.1.11 [RFC4055].

Looking in RFC4055, we find that there are already questions about
SHA-256, given the recent advances in attacking SHA-1:

 	[Page 21/22] If a greater level of security is desired, then a
 	secure one-way hash function with a longer hash value is needed.
 	SHA-256, SHA-384, and SHA-512 are reasonable choices [SHA2],
 	although their security needs to be reconfirmed in light of the
 	SHA-1 results.

I'd suggest that we refer to a minimum standard (probably as set in one
of the related documents such as RFC4055), and follow the same, standard
means of specifying any 'upwards' improvements in algorithm/key length.

cheers!

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Oct 2006 10:47:01 -0400

At 3:46 PM -0400 10/8/06, Cat Okita wrote:
>>research and improved capabilities of the machinery which can be 
>>used to break keys.
>>
>I would strongly suggest that if absolutely necessary, the key size 
>and algorithm not not be fixed, but that a basic compatibility 
>requirement
>should be set.  All of the PXIX working group documents that I've 
>checked through avoid the pitfall of specifying an absolute 
>algorithm/key size - and I strongly suspect that there are far more 
>cryptographers there than here.

As co-chair of PKIX I can explain why we don't put algorithms or key 
sizes into those standards, but why they are relevant here.

PKIX standards focus on formats and processing algorithms for certs 
and CRLs in all Internet contexts. Thus we don't make ANY algorithms, 
much less key sizes, standard.  Different application need not use 
the same certs and thus can use different algorithms for cert 
signing/verification without imposing any interoperability issues. 
Also, some applications are uses in closed communities and thus 
different sets of users can employ different algorithms for their 
certs without interoperability concerns.

What PKIX does allow is publication of standards on HOW to represent 
info about a given algorithm in a cert. So, for example, we say how 
to represent RSA, DH, DSA, and EC DSA algorithms and associated 
parameters.  We also cite appropriate hash algorithms and the OIDs 
that represent the use of one of these hash algorithms with a 
signature algorithm.

In the SIDR context, we are discussing a single application, and for 
use in the public Internet, it helps immensely if the same algorithm 
is used everywhere.  However, it is fair to say that we could avoid 
algorithm references in a SIDR cert profile, which could be used in 
closed Internets as well as the public Internet, and just put the 
algorithm and key size info into a CP for the public Internet 
instance of SIDR.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Oct 2006 10:29:08 -0400

Joe,

4096-bit RSA is computationally intensive, which is why I didn't 
suggest that we set minimum key sizes. There is a tendency for some 
folks to pick bigger keys w/o regard to the need for such.  We see 
this often in the IPsec environment, where when AES was adopted, many 
folks were convinced that 256-bit AES keys were appropriate, when 
128-bit keys would be just fine.

In the case of a PKI, one should take into account the impact on the 
relying parties who will have to check signatures generated with very 
large keys, as well as the local impact on an individual CA that uses 
a very large key for signing.

As Robert  noted, in the long run we can transition to EC DSA when we 
feel to need for bigger (equivalent) key sizes.  That's what folks 
are doing in general, as an alternative to very big RSA keys.

Steve

---

From: Joe Abley <[email-masked]>
Date: Mon, 9 Oct 2006 10:02:52 -0500

Hi Stephen,

Thanks for the clues.

On 9-Oct-2006, at 09:29, Stephen Kent wrote:

> As Robert  noted, in the long run we can transition to EC DSA when  
> we feel to need for bigger (equivalent) key sizes.  That's what  
> folks are doing in general, as an alternative to very big RSA keys.

Re-reading the document, I think I might have mis-read the text in  
the first place. Section 3.8 says:

    This field specifies the subject's public key and the algorithm with
    which the key is used.  The public key algorithm MUST be RSA, and,
    accordingly, the OID for the algorithm is 1.2.840.113549.1.1.1.  A
    minimum key size of 1024 bits is mandated in this profile.  In the
    context of certifying resources it is recommended that certificates
    that are intended to be used as root certificates, and their
    immediate subordinates SHOULD use a key size of 2048 bits.
    Subordinates of these subordinate certificates, in the context of
    continued level of high trust, SHOULD use a key size of 2048 bits.

    In the application of this profile to certification of public number
    resources, it would be consistent with this recommendation that the
    Regional Internet Registries used a key size of 2048 bits, and that
    their immediate subordinate certificate authorities also use a key
    size of 2048 bits.  All other subordinate certificates MAY use a key
    size of 1024 bits.

So, in fact, for general use it is a minimum that is recommended  
(1024 bits), not an absolute, and where an absolute number is quoted  
it's for RIRs and LIRs, and even then a SHOULD rather than a MUST.

Your comments above though (and Rob's comments earlier) make me  
wonder about the hard requirement that the algorithm MUST be RSA,  
though. Seems to me that a future transition to a different algorithm  
would require a new document to be issued which updates this one.  
Perhaps that's a feature.

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 9 Oct 2006 16:43:35 +0200

> means of specifying any 'upwards' improvements in algorithm/key  

The current work on certificates assumes that these are kept outside  
the actual routing system, but proposals such as S-BGP carry  
certificates and signatures in BGP. This will increase the amount of  
data that must be communicated from one BGP speaker to another, and,  
more importantly, the amount of data a BGP router must keep in memory  
manifold. As such, it would be very helpful to keep all of this as  
small as possible, and use better algorithms with shorter keys rather  
than weaker algorithms with longer keys.

It would also be useful to consider how much protection is  
sufficient. Obviously the security should be reasonably strong, but  
we may be overshooting the mark if we go for the absolutely strongest  
crypto we have available.

It might be useful approach to carry medium-strength certificates and  
signatures inside the routing system and have cryptographically  
stronger certificates and signatures available out-of-band.

In any event, I would rather give operators the choice of algorithm/ 
key length strength rather than mandate a certain minimum.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Oct 2006 11:58:33 -0400

>...

We have lots of time to revise this text, but I'd suggest that we 
establish target sizes for RIRs, LIRs, and ISPs, and that we try to 
establish a max key size as well, for the reasons I cited. However, 
we can put this into a CP, instead of the cert profile, if we want to 
maintain flexibility.

>though. Seems to me that a future transition to a different 
>algorithm would require a new document to be issued which updates 
>this one. Perhaps that's a feature.

Switching to a different algorithm will be a big deal. Changing the 
documentation will be the easiest part of such a transition :-).

---

From: Geoff Huston <[email-masked]>
Date: Sat, 14 Oct 2006 23:32:27 +1000

>discussions that have been taking place?

Have a look at the headers of the sidr mail:

List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sidr>,
         <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sidr>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sidr>,
         <mailto:[email-masked]?subject=subscribe>

thanks,

    Geoff

---

From: Joe Abley <[email-masked]>
Date: Sat, 14 Oct 2006 14:38:30 -0400

> Have a look at the headers of the sidr mail:

Cat was talking about the discussions between RIPE and APNIC that  
Henk mentioned had happened on some other list, I think, not those  
that have happened here.

Joe

---

From: Cat Okita <[email-masked]>
Date: Mon, 16 Oct 2006 11:04:13 -0400 (EDT)

> Have a look at the headers of the sidr mail:

I think you missed the details, Geoff - I was asking about the RIPE and 
APNIC list discussions (which are not available), not how to find 
archives for this list.

cheers!

---

From: Geoff Huston <[email-masked]>
Date: Tue, 17 Oct 2006 05:16:36 +1000

At 01:04 AM 17/10/2006, Cat Okita wrote:
>I think you missed the details, Geoff - I was asking about the RIPE 
>and APNIC list discussions (which are not available), not how to 
>find archives for this list.

My apologies for the misunderstanding.

The design group working on certification trials do not have a public 
archive of their work. Public progress reports of certification trial 
activity can be found in the archives of recent APNIC, RIPE and ARIN meetings.

kind regards,

    Geoff

---

From: Terry Manderson <[email-masked]>
Date: Mon, 30 Oct 2006 16:00:13 +1000

Apologies for awakening an old thread, I was on holidays.

There is something that I am stuck on, and since I am in the same 
physical location as two of the authors, I have been able to beat on 
their door for a discussion. Apologies for not raising it directly on 
the SIDR list.

The following is a transposition of a discussion that which fairly 
accurately describes my concerns relating to Joe's comment and Rob's 
reply.

I am concerned with the current draft's reliance on RSYNC as a base 
line (read required) protocol for transport of the certificate 
information and the CRL.

I'm not that concerned with the specific protocol, ie RSYNC vs 
HTTP/HTTPS vs something else. I am predominately concerned with an 
aspect of "lock-in" that will bind operators to running that mandated 
service/protocol even _IF_ the protocol selected is found to be wanting 
in areas of scale, security, and integrity.

My initial feel for this document suggested two options.

1) change the wording of MUST to SHOULD in stating the protocol.

or

2) Have the URI protocol defined in another draft that could be more 
easily changed in IETF process that modifying a RFC that would become 
certificate profile/policy.

Cheers
Terry

--
Terry Manderson                         email:      [email-masked]
Network Operations Manager, APNIC       sip:    [email-masked]
http://www.apnic.net                    phone:      +61 7 3858 3100

---

From: Joe Abley <[email-masked]>
Date: Mon, 30 Oct 2006 08:48:28 -0500

On 30-Oct-2006, at 01:00, Terry Manderson wrote:

> accurately describes my concerns relating to Joe's comment and  
> Rob's reply.
>

I think I had two concerns about the the way that rsync was specified:

1. Why specify (with MUSTs and SHOULDs) a particular protocol at all?

2. Given the need for a base protocol, why choose rsync?

Point 1 was answered, I think, and I agree that having a uniforum  
protocol which is required to be supported has advantages for  
implementors (who might otherwise be obliged to code support for many  
exotic URI schemes on platforms with limited capabilities) and avoids  
the situation where particular policies cannot be retrieved by some  
clients because they happen to lack support for a particular protocol.

Point 2 still bothers me slightly, since it seems to me that the  
rsync protocol is not documented in a sufficiently stable form for it  
to be used as a base protocol for work such as this. Unless I'm  
mistaken, the rsync protocol/algorithm are products of a single  
talented individual and are documented in ad-hoc web pages. This  
seems to present risks (e.g. of future IPR claims, or modifications  
to the protocol which break interop with other rsync implementations).

It seems to me that the answer to question 1 lends itself to the  
choice of a protocol which is widely implemented, for which  
interoperability has been well-demonstrated, and whose specification  
is stable. Given these goals, HTTP seems like a better choice than  
rsync.

Perhaps this is a non-issue, but it seems to me that it ought to be  
discussed.

Joe

---

From: Róbert Kisteleki <[email-masked]>
Date: Mon, 30 Oct 2006 15:42:51 +0100

> 2. Given the need for a base protocol, why choose rsync?

[...]

> Point 2 still bothers me slightly, since it seems to me that the rsync 
> protocol is not documented in a sufficiently stable form for it to be 
> used as a base protocol for work such as this. Unless I'm mistaken, the 
> rsync protocol/algorithm are products of a single talented individual 
> and are documented in ad-hoc web pages. This seems to present risks 
> (e.g. of future IPR claims, or modifications to the protocol which break 
> interop with other rsync implementations).

These might be real concerns, I don't know.

> It seems to me that the answer to question 1 lends itself to the choice 
> of a protocol which is widely implemented, for which interoperability 
> has been well-demonstrated, and whose specification is stable. Given 
> these goals, HTTP seems like a better choice than rsync.

If you look at the expected use cases (especially parties synchronising 
between repositories), you end up with a number of requirements against the 
protocol that is going to be used in the distribution of these certificates:
1. It should be able to handle access to individual files (e.g. download 
issuer certificate or CRL).
2. It should be able to handle access to a large set files (download all 
objects from one or more repositories), out of which only relatively few are 
new (because you don't want to transfer data you already have)
3. The previous need to be supported throughout multiple directories, which 
are potentially nested
4. It should have some method for marking/deleting the objects that no 
longer exist on the "server".
5. It should work bidirectionally, i.e. should support sync between "A" and 
"B", not only update "B" from the repository "A".

rsync does all that, pretty effectively. Number (1) is easy with HTTP, but 
starting from (2) you need to have some common listing format, a directory 
traversal (probably with multiple requests), etc. Yes, it could be done, but 
if you specify everything for all that functionality, you pretty much invent 
"rsync over HTTP" :-)

> Perhaps this is a non-issue, but it seems to me that it ought to be 

I'm not saying rsync is the only solution here, but from the usage point of 
view it is a very good tool.

Regards,
Robert

---

From: Joe Abley <[email-masked]>
Date: Mon, 30 Oct 2006 09:49:07 -0500

On 30-Oct-2006, at 09:42, Róbert Kisteleki wrote:

>> Perhaps this is a non-issue, but it seems to me that it ought to  
>> be discussed.
>
> I'm not saying rsync is the only solution here, but from the usage  
> point of view it is a very good tool.

No argument from me on that. If Tridge sold t-shirts, I'd buy one.

Joe

---

From: Robert Loomans <[email-masked]>
Date: Tue, 31 Oct 2006 08:41:04 +1000

> Yes, it could be done, but if you specify everything for all that
> functionality, you pretty much invent "rsync over HTTP" :-)

"Rsync over HTTP" has already been (partially?) done:
http://zsync.moria.org.uk/

The only wrinkle is that there'd have to be an index file or similar,
because zsync is aimed at single files.... The advantages of zsync over
rsync include that the diffs are pre-calculated once per file change as
opposed to every transfer, and the actual server is simply a HTTP 1.1
compliant web server. The diffs can calculated off-line and uploaded to
the server or servers.

Debian has implemented a similar scheme for it's package files.

On a related note, one of the requirements that Tridge had in mind when
designing rsync was maximising throughput even in the presence of high
end-to-end latencies and lots of small files. He did this by minimising
the "chattiness" of the protocol and thus the effect of round-trip
times. I think that is another property of rsync that would be useful to
retain.

Rob