On 31/05/2017 08:47, Eric Rescorla wrote:
> On Tue, May 30, 2017 at 1:37 PM, Brian E Carpenter <
> [email protected]> wrote:
>
>> On 31/05/2017 05:02, Michael Richardson wrote:
>>>
>>> Eric Rescorla <[email protected]> wrote:
>>> > It's the job of this group of specifications to provide a complete
>>> > security story, so it must either be here or it must be in some
>> other
>>> > document which is normatively referenced from here and which
>> therefore
>>> > one can read to determine if this document achieves the appropriate
>>> > security objectives. Just generally pointing in the direction of
>> TLS is
>>> > not sufficient. You could, of course, say that TLS is not to be
>> used at
>>> > all and you rely entirely on ACP, but the current text doesn't do
>> that
>>> > either.
>>>
>>> The use case for TLS is inter-domain (while the ACP is intra-domain).
>>> I.e. between two ISPs. Such a GRASP instance would be isolated from
>> other
>>> ANIMA GRASP instances, would perhaps not be hop-by-hop. Or might be.
>>>
>>> As that use case is not well understood at all, and I think can (and
>> SHOULD)
>>> be addressed later on, I have argued for simply not mentioning it
>> because we
>>> don't have a story about certificates or identities or validation, etc.
>> (I
>>> suspect that many initial uses will use pinned self-signed certificates,
>>> manually configured).
>>>
>>> Brian has argued to continue to include the reference so that we remember
>>> that use over a secured ACP is not the only use, and that we shouldn't
>> write
>>> some complex interaction that involves many UDP/TCP port combinations
>> that
>>> would be hard to support over TLS.
>>>
>>> Use of GRASP at an Internet Exchange (IX) might be different again,
>> perhaps
>>> using COSE to sign GRASP multicast messages.
>>>
>>> Can anyone suggest a way to keep TLS in mind while not actually saying
>> we know
>>> how to use it?
>>
>> That's the crux of it. We intentionally did not want to bind GRASP
>> irrevocably to the ACP, so that it can be used, for example, to implement
>> dynamic resource management between two ISPs that have a specific trust
>> model between themselves. But clearly that's future work. How can we
>> express that?
>>
>
> The usual way is to define things for ACP and then say that future specs may
> define other protection mechanisms.
OK, so no spec is better than an incomplete spec. That's easy enough.
It also, IMHO, means deleting the "SONN" subsection, 3.5.2.3.
Toerless: you invented that, but as I understand it BRSKI does
not need it since the registrar-proxy interaction will take place
over the ACP.
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
