Sandy,
- ------------------
4.1.1
e. Confirm that all of the objects listed in the downloaded manifest
have been retrieved.
- ------------------

What if I have a partial download of the URIs from the manifest? What
if the successfully downloaded object files match the stored hashes?

There's a "not" missing in here somewhere, I think.   (Successful
download and match of hashes seem like entirely good things.)

let me clarified what was trying to say. The question is about the word "all", what if you only succeed on download some of the objects in the manifest.

Regards,
Roque






I personally believe that the manifest itself has to be only entirely
download but partial downloads of object should be permitted.

If you mean a partial download of some individual object, the signature of that object could not verify if the object was only partially downloaded.

If you mean a partial download of the list of objects mentioned in the manifest, the manifest is designed particularly to detect when objects that should be in the repository are missing, so a partial download should not be permitted.

Unless I've misunderstood you.

--Sandy


Regards,

Roque



On Aug 24, 2008, at 10:36 PM, Terry Manderson wrote:



.. and in the bad form of following-up to my own post.


On 29/07/2008, at 11:10 PM, Terry Manderson wrote:

The ubiquity of HTTP provides a strong platform for both server and
client development. I'm not sure it would expose an attack surface
by adding http. It may be that specifying just https may eliminate
additional vectors. Do you have any in mind?

I had the opportunity on the weekend to catch up with an old colleague who now spends her time dealing with banking sector network security.
After the usual banter about the selection of red wine we 'talked
shop'.

She was quite immovable in her view that regardless of the validation
constructs of RPKI, the end to end fetching and publishing MUST be
over a path that covers confidentiality, integrity, and availability.

So in her eyes the important things are:
- That when you establish a discussion with endpoint you are (to the
best of current technology) certain it really is the endpoint.
- That you are talking (unmolested) to the endpoint you think you are
for the entirety of the session.
        - That what is retrieved by the client is audit-able at both the
server and the client.
        - That retrievals are predictable, and perfectly repeatable.
- That the client _never_ permits a downgrade, or unsecured retrieval
of information
        - That Trust anchor management for both the client ssl and the PRKI
is considered in such a way that it minimises the fact there is no
such thing as trusted computing (her words).

I asked for situations that she could identify (ie problems) and after
the expected Kaminsky DNS issue discussion, I was showed the secret
decoder ring and she suggested that I wasn't being paranoid enough
given we are dealing with and constructing operational systems which
affect the control plane.

I'm not sure how this might reflect in the ARRRM draft yet, but I
thought it worthwhile to share.

Cheers,
Terry
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiyw5wACgkQnk+WSgHpbO7jNgCg1dHvT3z3QcYbecGKxIEw/ZpE
Nu0An2hhqQd35VT9GOXYYq3K8H1H3IZ3
=SzHP
-----END PGP SIGNATURE-----
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr


Attachment: PGP.sig
Description: This is a digitally signed message part

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

Reply via email to