On Mon, 25 Aug 2008, Roque Gagliano wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Terry, > > I wanted to ask you about this line: > - ------------------ > 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.) > > 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 > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
