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

[Barry Leiba <[e-mail]>]

(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

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