.. 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
