Re: [secdir] [Isms] secdir reviewofdraft-ietf-isms-transport-security-model-12

["tom.petch" <[e-mail]>]

----- Original Message -----
From: "Barry Leiba" <[e-mail]>
To: "tom.petch" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Friday, May 08, 2009 8:05 PM

(Top post only...)
I get what you're saying, Tom, but I'm not sure where it's going.  Are
you saying that the text should be changed to allow *less*
flexibility?  That may be right, but then what text do you suggest
instead?

Barry

I would like the idea of 'in conjunction with' to hint at the co-dependence of
xSM and xTM eg

"However, the Transport Security Model
does not by itself provide security mechanisms such as authentication and
encryption, so it MUST always be used in conjunction with a Transport Model that
together with it provides appropriate security"

Tom Petch

Barry

>> > That is a deployment decision made by an administrator who has an
>> > understanding of what is appropriate to the system in question.
>> >
>> > What is the correct non-RFC2119 phrase in which to couch our
>> > deployment advice?
>>
>> Well, this would make me happy; would it work for you (and others)?:
>>
>> OLD:
>> by the RFC 3411 architecture. However, the Transport Security Model
>> does not provide security mechanisms such as authentication and
>> encryption itself, so it SHOULD always be used with a Transport Model
>> that provides appropriate security. Which threats are addressed and
>> how they are mitigated depends on the Transport Model.
>>
>> NEW:
>> by the RFC 3411 architecture. However, the Transport Security Model
>> does not provide security mechanisms such as authentication and
>> encryption itself, so it MUST always be used with a Transport Model
>> that provides appropriate security. What is "appropriate" for a particular
>> deployment is an administrative decision. Which threats are addressed
>> and how they are mitigated depends on the Transport Model.
>
> I have reservations about this, about the optimism that it may generate in
> readers.
>
> The idea of Models in SNMP is to be able to mix and match. In practice, this
> has not worked - USM with sshTM will not function, regardless of whether it is
> secure or not. Do not underestimate the labour it has taken to get TSM working
> with sshTM.
>
> If we have got TSM right, then it will work with eg TLSTM or DTLSTM, an idea
> that is being mooted now. But it may not. In a similar vein, I am mindful that
> ssh just hit problems with AES-GCM, that the architecture of ssh does not
allow
> for this new cryptography or that the discussions leading to TLS 1.2 of how to
> introduce (or not) algorithm agility, just as SNMP has problems (and has given
> up) trying to use USM with sshTM.
>
> Thus TLS has session cache and resumption. Will that work with TSM? I do not
> know - and as it has taken the last two years to come up with an agreed form
of
> words that allows just TSM to work with just sshTM, so I am not going
> to try and work out the ramifications of TLSTM just yet:-( We may find we got
> TSM wrong and that it needs changing.
>
> Or we may have another secure Transport Model that turns out to be insecure
with
> TSM and needs an xSM to make it secure. The proposed amendment seems to me
> rather optimistic.
>
> Tom Petch