Subject: RE: [Isms] Rough Consensus Declaration: ISMS Architecture is EK

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 5 May 2005 09:26:23 -0400

hi

I think most people recognize that the most likely alternative to accepting
the selected architecture is for the working group to continue to thrash
until it eventually gets shut down. Most people don't want that and from
what I have seen so far on the mailing list are generally interested in
making progress on our selected path.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sam Hartman
Sent: Thursday, May 05, 2005 8:07 AM
To: Eliot Lear
Cc: [email-masked]
Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Sam, You think *any* decision is a good decision.  I think
    Eliot> that's only reasonable if and only if the implementors have
    Eliot> bought into that and the decisions are roughly technically
    Eliot> equivalent.  You need consensus on this point.  Otherwise
    Eliot> you end up precisely with the IMPP mess because people walk
    Eliot> away from the table.

No, I actually think I agree with your statement 100%.  If the working group
has bought into the idea that making a decision (no matter what it is) is
sufficiently important then it is reasonable to make a decision even given a
very rough consensus.  If the working group has not bought into the idea
that a decision is sufficiently important then we do not have consensus.

I have tried not to state an opinion (or really to form one to the extent
that I can avoid doing so) on whether the working group has bought into the
idea that a decision of any kind is sufficiently important.  Judging that
consensus is the job of the chairs and unless required to do so it would be
inappropriate for me to second guess the chairs.

--Sam

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "McDonald, Ira" <[email-masked]>
Date: Sat, 7 May 2005 11:35:20 -0700

Hi,

Keith is apparently distorting the EK picture in order to push back on the
rough concensus decision of the ISMS WG chairs.

Just like plain UDP, DTLS does _not_ do packet reordering for application
data. 
DLTS only ensures ordering during the session startup handshake.  DTLS does
ensure 
the data integrity of each application data packet.  The SNMP application
layer
mechanism for detecting misordered packets would still be necessary.

But, by design, DTLS _does_ share the same security mechanisms with TLS.  

It's worth noting that one of the co-editors of DTLS (Eric Rescorla) is also
one 
of the co-editors of RFC2246bis (TLS/1.1) now being developed by the TLS WG
and
is also one of the co-chairs of the TLS WG.

The TLS WG is now developing TLS with native SRP authentication (which
solves
the problem of assymetric client/server authentication across different
protocol
layers recently mentioned on this mailing list).  Using SRP-6 (see the
draft)
this is accomplished _without_ modifying the order of the normal TLS
handshake.
The most recent TLS with SRP draft is <draft-ietf-tls-srp-09.txt> (March
2005).

A new SNMP security model for SNMP over TLS over TCP could also easily
support 
SNMP over DTLS over UDP.

The ISMS WG has frittered away eight months coming to a fragile architecture
concensus.  It's unreasonable to expect that the ISMS WG will define and
move onto the IETF standards track any new SNMP security model any faster 
than the fairly mature DTLS and TLS with SRP definitions can be completed.

Cheers,
- Ira  

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Keith McCloghrie
> Sent: Friday, May 06, 2005 8:57 PM
> To: [email-masked]
> Apparently, the people who voted for (including the maybe's and the
> not-against's) EK, believe that they voted not only for encapsulating
> the keying but also for encapsulating SNMP messages.  Assuming this is
> true, then it seems to me that if one is forced to pay the 
> price of TLS
> in order to have secure SNMP, then I no longer see any benefit in
> running SNMP over UDP.  There are both advantages and disadvantages of
> running SNMP over TCP; the advantages include larger messages and flow
> control.  For the disadvantages, all but one of them are inherent in
> encapsulating SNMP messages in TLS; the remaining one is the 
> minor issue
> that both SNMP and TCP have reliability mechanisms, i.e., SNMP engines
> should avoid having SNMP's retransmission timers fire before TCP's
> retransmission timers (see page 2 of RFC 3430).  That one remaining
> disadvantage is negligible compared to larger messages and 
> flow-control.
> Therefore, to define SNMP-over-DTLS-over-UDP is silly; the only
> sensible way of using TLS is to define SNMP-over-TLS-over-TCP.
> 
> So, I believe the WG's choice of EK discards the perceived wisdom 
> of the last 15+ years that UDP was the preferred transport mapping.
> Nevertheless, given that the WG has decided to do this, I think it
> should be made explicit by:
> 
>   - putting RFC 3430 on the standards track,
>   - starting an update to remove the word "preferred" from RFC 3417,
>   - not wasting any time on defining a SNMP-over-DTLS-over-UDP,
> 
> Keith.
> 
> PS. As a further observation, I will note that this has occurred in a
> Security Area Working Group.  How sad this all is.
>

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Sat, 7 May 2005 12:11:41 -0700

I think you misunderstood Keith.  He didn't try to push back on
the consensus in his last message.  In fact, he did acknowledge
the advantages of TLS over TCP.  It was DTLS over UDP that he 
found problems with, and he made some good points about that.

Anyway, we may have many disagreements here, but let's not take
them personally :)  We all are here for a common goal, so let's
work this out in a positive way.

Khanh 

> From: McDonald, Ira
> Keith is apparently distorting the EK picture in order to 
> push back on the rough concensus decision of the ISMS WG chairs.
> 
> Just like plain UDP, DTLS does _not_ do packet reordering for 
> application data. 
> DLTS only ensures ordering during the session startup 
> handshake.  DTLS does ensure the data integrity of each 
> application data packet.  The SNMP application layer 
> It's worth noting that one of the co-editors of DTLS (Eric 
> Rescorla) is also one of the co-editors of RFC2246bis 
> (TLS/1.1) now being developed by the TLS WG and is also one 
> of the co-chairs of the TLS WG.
> 
> The TLS WG is now developing TLS with native SRP 
> authentication (which solves the problem of assymetric 
> client/server authentication across different protocol layers 
> recently mentioned on this mailing list).  Using SRP-6 (see the
> draft)
> this is accomplished _without_ modifying the order of the 
> normal TLS handshake.
> The most recent TLS with SRP draft is 
> <draft-ietf-tls-srp-09.txt> (March 2005).
> 
> A new SNMP security model for SNMP over TLS over TCP could 
> also easily support SNMP over DTLS over UDP.
> 
> The ISMS WG has frittered away eight months coming to a 
> fragile architecture concensus.  It's unreasonable to expect 
> that the ISMS WG will define and move onto the IETF standards 
> track any new SNMP security model any faster than the fairly 
> mature DTLS and TLS with SRP definitions can be completed.
> 
> Cheers,
> - Ira  
> 
> Ira McDonald (Musician / Software Architect) Blue Roof Music 
> / High North Inc PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> > Subject: Re: [Isms] Rough Consensus Declaration: ISMS 
> Architecture is 
> > EK
> > 
> > 
> > true, then it seems to me that if one is forced to pay the price of 
> > TLS in order to have secure SNMP, then I no longer see any 
> benefit in 
> > encapsulating SNMP messages in TLS; the remaining one is the minor 
> > issue that both SNMP and TCP have reliability mechanisms, 
> i.e., SNMP 
> > engines should avoid having SNMP's retransmission timers 
> fire before 
> > TCP's retransmission timers (see page 2 of RFC 3430).  That one 
> > remaining disadvantage is negligible compared to larger 
> messages and 
> > flow-control.
> > So, I believe the WG's choice of EK discards the perceived 
> wisdom of 
> > the last 15+ years that UDP was the preferred transport mapping.