Subject: [Isms] multiple security levels in the dtls transport model

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jan 2010 09:09:38 +0100

Hi,

it seems that we are getting really close to being done with the DTLS
document. There is, however, one open issue remaining concerning the
support for multiple security levels in the (D)TLS transport model.

The document current spells out how you check security levels in every
direction to make sure that the requested security level matches the
transport, etc. Just search for "tmRequestedSecurityLevel" or
"security level" to find the sections where this discussion takes
place.

David Harrington raised a last-call comments that this adds unneeded
complexity and he wants to always assume authPriv for all D(TLS)
transports (which was done in SSH). Tom has agreed with David> and
he would prefer to only support authPriv.

As it stands, the document leaves the details how a requested security
level is mapped to (D)TLS open for implementations:

       [...] It is also implementation-dependent and possibly
       policy-dependent how tmRequestedSecurityLevel will be used to
       influence the security capabilities provided by the (D)TLS
       session.  However this is done, the security capabilities
       provided by (D)TLS MUST be at least as high as the level of
       security indicated by the tmRequestedSecurityLevel parameter.

The WG needs to come to a conclusion whether the support for multiple
security levels should remain in the document or taken out. To better
understand the issue, I would like those who like to have this feature
to provide use cases how noAuthNoPriv maps to a DTLS transport or how
authNoPriv maps to a DTLS transport and what the requirements are that
are driving the need for such a feature.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 11 Jan 2010 09:18:59 -0800

>>>>> On Mon, 11 Jan 2010 09:09:38 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> [...] It is also implementation-dependent and possibly
JS> policy-dependent how tmRequestedSecurityLevel will be used to
JS> influence the security capabilities provided by the (D)TLS
JS> session.  However this is done, the security capabilities
JS> provided by (D)TLS MUST be at least as high as the level of
JS> security indicated by the tmRequestedSecurityLevel parameter.

One other important point to consider about this is that by dictating
directly that every TLS connection is authPriv even when the security in
TLS has been turned off via a NULL algorithm selection (eg), you
actually prevent any implementation from implementing this feature.  IE,
it becomes impossible for an implementation to follow the spec and to
have a product-differentiation feature that would map authNoPriv to a
particular TLS algorithm set, etc.

JS> The WG needs to come to a conclusion whether the support for multiple
JS> security levels should remain in the document or taken out. To better
JS> understand the issue, I would like those who like to have this feature
JS> to provide use cases how noAuthNoPriv maps to a DTLS transport or how
JS> authNoPriv maps to a DTLS transport and what the requirements are that
JS> are driving the need for such a feature.

The intent of that text is to allow for the following combinations:

   |                | noAuthNoPriv | authNoPriv | authPriv  |
   | Authentication | NULL         | something* | something |
   | Encryption     | NULL         | NULL       | something |

But to explicitly disallow:

   |                | noAuthNoPriv | authNoPriv | authPriv |
   | Authentication |              | NULL       | NULL     |
   | Encryption     |              |            | NULL     |

It allows for an implementation to select algorithms based on what
traffic needs to go over the connection, just as SNMPv3 has always
allowed in USM.  I've heard of people specifically wanting authNoPriv
support because they didn't want the encryption overhead (especially on
small devices).

It's absolutely true to say that it's not our job to define what is and
what isn't acceptable levels of authentication or encryption.  Some may
consider DES sufficient for allowing the priv bit to be turned on and
usable.  Others may not.  Certainly I don't think anyone thinks the NULL
encryption algorithm is an ok choice for protecting traffic marked with
the priv bit.

Note that the document already allows an implementation to ignore this
whole issue since it says:

   Implementations MAY choose to force (D)TLS to only allow
   cipher_suites that provide both authentication and privacy to
   guarantee this assertion.

IE, an implementation is free to use the "no complexity" route already
and assume every tunnel can handle authPriv or lower.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jan 2010 20:25:24 +0100

> particular TLS algorithm set, etc.

Yes, but this is what the WG decided to do with SSH. So why is (D)TLS 
different?

> support because they didn't want the encryption overhead (especially on

Can you give me an example for something you consider an authNoPriv
setting for (D)TLS? I understand the SNMP side of things, not so much
the (D)TLS side of creating something that maps authNoPriv.

> and assume every tunnel can handle authPriv or lower.

I am trying to understand why we decided to not go into crypto
algorithm details for the SSH TM and why we should do different for
the D(TLS) TM.

/js

---

From: Robert Story <[email-masked]>
Date: Mon, 11 Jan 2010 18:50:12 -0500

On Mon, 11 Jan 2010 20:25:24 +0100 Juergen wrote:
JS> Yes, but this is what the WG decided to do with SSH. So why is (D)TLS 
JS> different?

I'm sure there was some debate on the issue then. Maybe someone who
took part in that debate could summarize the issue?

I haven't had the time to participate in IETF work recently, so I
missed the opportunity to participate in the SSH decision, but I'll
throw in my 2 bits on the issue now. 

- RFC 3411 says "it is explicitly allowed to send messages which do not
  require authentication or privacy." I think there should be a very good
  reason for a security model to limit applications/users further.

- customers with secure and/or private networks don't want the overhead
  of encryption on simple traffic monitoring packets. This is most
  likely why noAuthNoPriv was created in the first place.

JS> Can you give me an example for something you consider an authNoPriv
JS> setting for (D)TLS? I understand the SNMP side of things, not so much
JS> the (D)TLS side of creating something that maps authNoPriv.

I took a quick peek at 5246, and was disappointed to find that they
define a 'noAuthNoPriv' suite, TLS_NULL_WITH_NULL_NULL, but prohibit
negotiating it (it is only used at start of session, before real suite
is negotiated).  So noAuthNoPriv is out.

That leaves authNoPriv as the next best choice.  The cipher suites
section (A.5) of 5246 defines 3 suites without encryption: TLS_RSA_WITH_NULL_MD5, TLS_RSA_WITH_NULL_SHA and TLS_RSA_WITH_NULL_SHA256.

JS> > Note that the document already allows an implementation to ignore this
JS> > whole issue since it says:
JS> > 
JS> >    Implementations MAY choose to force (D)TLS to only allow
JS> >    cipher_suites that provide both authentication and privacy to
JS> >    guarantee this assertion.

I think this offers a good compromise.

-- 
Robert Story
Senior Software Engineer
SPARTA (dba Cobham Analytic Soloutions)

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 11 Jan 2010 16:32:49 -0800

>>>>> On Mon, 11 Jan 2010 18:50:12 -0500, Robert Story <[email-masked]> said:

RS> I took a quick peek at 5246, and was disappointed to find that they
RS> define a 'noAuthNoPriv' suite, TLS_NULL_WITH_NULL_NULL, but prohibit
RS> negotiating it (it is only used at start of session, before real suite
RS> is negotiated).  So noAuthNoPriv is out.

I actually agree with everyone else here that there is no real benefit
to providing noAuthNoPriv support for DTLS; we really only care about
protecting traffic in either the authNoPriv states or the authPriv
states.

RS> That leaves authNoPriv as the next best choice.  The cipher suites
RS> section (A.5) of 5246 defines 3 suites without encryption:
RS> TLS_RSA_WITH_NULL_MD5, TLS_RSA_WITH_NULL_SHA and
RS> TLS_RSA_WITH_NULL_SHA256.

That's very useful information, so thanks for looking it up (I was
planning on looking up the exact suite names since I couldn't remember
them but hadn't yet).

RS> I think this offers a good compromise.

If an implementation wanted to choose not to support any of the
algorithms you mention above they wouldn't even have to have if()
statements for checking the snmpv3 bits.  I agree.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Jan 2010 08:52:31 +0100

> took part in that debate could summarize the issue?

As far as I recall, the decision was to resist the temptation to peek
inside the internals of the security protocol, that is the negotiation
of the crypto algorithms. So it was more an architectural and layering
decision. People commonly associate authentication and encryption with
SSH (even though SSH has NULL algorithms). The same might be true for
(D)TLS.
 
>   reason for a security model to limit applications/users further.

The SNMP application can send noAuthNoPriv messages but the transport
ships them via an authPriv "tunnel". The WG concluded that providing a
higher level of security on the wire than what was requested by the
SNMP application is acceptable.

>   likely why noAuthNoPriv was created in the first place.

Note that the performance equation looks slightly different with
(D)TLS and SSH. The big performance hit is session key generation - so
the first thing you have to worry about is to avoid unnecessary
session key generation. But yes, encryption has some price.

> section (A.5) of 5246 defines 3 suites without encryption:
> TLS_RSA_WITH_NULL_MD5, TLS_RSA_WITH_NULL_SHA and
> TLS_RSA_WITH_NULL_SHA256.

Thanks, this is what I was looking for.

> I think this offers a good compromise.

There was a concern raised during WG last call that the support for
different security levels adds complexity to the EoP. The WG needs to
come to a conclusion whether this additional complexity is well
justified or not.

I understand that at least two WG members with some implementation
background like to have the flexibility to map authNoPriv to an
appropriate (D)TLS cipher suite. I guess it is now up to those who are
concerned about the complexity to make a point why the price is too
high to support this feature by pointing to concrete parts of the ID.
Please do so as soon as possible so that we can get this issue
resolved in a timely manner.

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 12 Jan 2010 09:08:03 -0500

With SSHTM, we worked very hard to keep the transport model from
knowing about the underlying ciphersuites. We had massive discussions
about this topic, and it was extremely difficult editing the SSHTM
docs without getting into mentioning the specific authentication or
encryption mechanisms in use in the lower layer. But WG consensus was
clear - the SNMP engine should NOT have visibility into the algorithms
or cipher suites being used at the lower layers. The operator was
responsible for configuring the lower layer to provide security. And
since SNMP had no insight into which suites were being used, SNMP
could not determine whether the operator's configuration did or did
not provide auth and priv. The transport model had to trust that the
operator had configured things correctly. period.

Now this whole discussion of supporting mutliple security levels goes
directly against that WG consensus to not reveal the underlying
mechanisms or ciphersuites. 

If we are going to support multiple securityLevels, then I think the
standard should identify the mandatory-to-implement ciphersuites to
support each securityLevel, so we have interoperability. And that
begins to open a whole can of worms ...

Now we need to start thinking about how to configure the SNMP to
decide which traps to send over which securitylevel, and which OIDs
have sensitive information and which are not sensitive, and yada yada
yada ... Added complexity with no real benefit because people will not
do this level of data access control.

If we do not get into discussing specific ciphersuites and algorithms,
then we can treat all SNMP communications over TLS as being one
securityLevel. The operator can configure all SNMP/(D)TLS to work
using one assumed securityLevel. Honestly it doesn't matter much which
securitylevel is supported, although we should make strong security
(authpriv)  mandatory-to-implement, as per BCP 61. If the operator
wants to deploy a TLS configuration that only provides authNoPriv,
then that is a deployment decision. If the operator wants to deploy
their TLS environment to provide one level of security from node A to
node B, and have a different level of security between nodes A and C,
then they can do so by configuring the TLS-layer negotiations to use
specific suites (in an implementation-dependent manner). This type of
deployment decision might be made for small devices, but also in
environments where encryption is not permitted (by company policy or
by law). The real point is that SNMP shouldn't need to know about
multiple securityLevels - design TLSTM to assume one securityLevel per
address pair, and let the operator choose how to deploy the underlying
security - they are the people who best understand the demands of
their TLS environment.

Moving that knowledge into SNMP adds unnecessary complexity to VACM
configuration, and to TARGET-MIB configuration, and so on. We do not
need this complexity in SNMP, because we are "outsourcing" security
configuration to the underlying TLS layer.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, January 12, 2010 2:53 AM
> To: Robert Story
> Cc: [email-masked]
> Subject: Re: [Isms] multiple security levels in the dtls 
> transport model
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Jan 2010 16:35:45 +0100

> configuration to the underlying TLS layer.

But to be fair, the complexity in VACM etc. already exists and is part
of the SNMPv3 standards. I can't judge how much authNoPriv or even
mixtures of authNoPriv and authPriv are used in practice and it is
likely that nobody really has any reliable hard data.

The question for me really is whether one can expect APIs to expose
the details of ciphersuites (and thus the security level) to the
applications using a secure transport. Some well known SSH
implementations did not start their life as embeddable libraries,
while this was a common approach for TLS implementations. So we have
notable differences at least in open source implementations of SSH and
TLS. (There are meanwhile decent SSH C libraries that might expose
proper APIs but they came along just in recent years.)

Anyway, to resolve this issue, it might help us to understand what the
complexity saving is if we do not support multiple security levels in
the (D)TLS document. VACM does not matter here - we need to talk about
the complexity of the (D)TLS transport since this is the document we
have to complete.

/js (speaking as technical contributor)

---

From: Robert Story <[email-masked]>
Date: Tue, 12 Jan 2010 11:06:59 -0500

On Tue, 12 Jan 2010 08:52:31 +0100 Juergen wrote:
JS> The SNMP application can send noAuthNoPriv messages but the transport
JS> ships them via an authPriv "tunnel". The WG concluded that providing a
JS> higher level of security on the wire than what was requested by the
JS> SNMP application is acceptable.

I'll agree that the inverse in unacceptable. But I think that the user
should be able to configure whether or not an authNoPriv session can be
created and used for authNoPriv messages.

JS> Note that the performance equation looks slightly different with
JS> (D)TLS and SSH. The big performance hit is session key generation - so
JS> the first thing you have to worry about is to avoid unnecessary
JS> session key generation. But yes, encryption has some price.

I could only find one paper [1] that compared SSL/TLS performance with
and without encryption. That paper found an almost 4-fold performance
gain when disabling encryption. That's a significant gain, and one that
I'd like to be able to take advantage of.

JS> There was a concern raised during WG last call that the support for
JS> different security levels adds complexity to the EoP. The WG needs to
JS> come to a conclusion whether this additional complexity is well
JS> justified or not.

I argue that the intent of the original SNMPv3 specs was to provide
authNoPriv, and the WG needs to justify restricting this option.

As far as complexity goes, I think that most implementations are
already going to have to maintain a list of acceptable cipher_suites
for an authPriv session (if nothing else, to exclude the NULL encryption
options). All that's needed is another list of acceptable cipher_suites
for an authNoPriv session.

[1]  http://user.informatik.uni-goettingen.de/~fu/ptls/santoshb.ps

---

From: Robert Story <[email-masked]>
Date: Tue, 12 Jan 2010 11:07:07 -0500

On Tue, 12 Jan 2010 09:08:03 -0500 David wrote:
DH> The operator was
DH> responsible for configuring the lower layer to provide security. And
DH> since SNMP had no insight into which suites were being used, SNMP
DH> could not determine whether the operator's configuration did or did
DH> not provide auth and priv. The transport model had to trust that the
DH> operator had configured things correctly. period.
DH> 
DH> Now this whole discussion of supporting mutliple security levels goes
DH> directly against that WG consensus to not reveal the underlying
DH> mechanisms or ciphersuites. 

In what way? We aren't currently saying anything about what
ciphersuites are acceptable for an authPriv connection. We don't need
to get into the underlying ciphersuites, all we need to say is that an
authPriv session MUST NOT use a ciphersuite that does not offer both
authentication and encryption. For authNoPriv, we just need to say that
an authNoPriv session MUST NOT use a ciphersuite that does not offer
authentication. Note that this does not prohibit using encryption,
should the user desire to configure it that way.

I'd also like to point out that section 8 of 5591 says:

   This Security Model SHOULD always be used with Transport Models that
   provide adequate security, but "adequate security" is a configuration
   and/or run-time decision of the operator or management application.

DH> If we are going to support multiple securityLevels, then I think the
DH> standard should identify the mandatory-to-implement ciphersuites to
DH> support each securityLevel, so we have interoperability. And that
DH> begins to open a whole can of worms ...

I disagree. TLS already specifies a mandatory to implement ciphersuite
(TLS_RSA_WITH_AES_128_CBC_SHA), so I think all we need to say is that
an implementation MUST always offer that suite as an option. That would
guarantee interoperability at the cost of possibly having authNoPriv
sessions encrypted. I can live with that.

DH> Now we need to start thinking about how to configure the SNMP to
DH> decide which traps to send over which securitylevel, and which OIDs
DH> have sensitive information and which are not sensitive, and yada yada
DH> yada ... Added complexity with no real benefit because people will not
DH> do this level of data access control.

The same holds true for SNMP with USM. there is no difference here.

DH> If we do not get into discussing specific ciphersuites and algorithms,
DH> then we can treat all SNMP communications over TLS as being one
DH> securityLevel. The operator can configure all SNMP/(D)TLS to work
DH> using one assumed securityLevel. Honestly it doesn't matter much which
DH> securitylevel is supported, although we should make strong security
DH> (authpriv)  mandatory-to-implement,

I agree that authPriv should be mandatory-to-implement. I don't agree
that it should be mandatory to use for all sessions.

DH> If the operator wants to deploy a TLS configuration that only
DH> provides authNoPriv, then that is a deployment decision.

I don't agree with that. As I said earlier, I think we should require
that implementations not allow non-encrypted ciphersuites for authPriv
sessions.

DH> If the operator wants to deploy
DH> their TLS environment to provide one level of security from node A to
DH> node B, and have a different level of security between nodes A and C,
DH> then they can do so by configuring the TLS-layer negotiations to use
DH> specific suites (in an implementation-dependent manner).

agreed.

DH> The real point is that SNMP shouldn't need to know about
DH> multiple securityLevels

SNMPv3 specifies multiple securityLevel, so I don't see how you can
make that statement.

DH> design TLSTM to assume one securityLevel per
DH> address pair, and let the operator choose how to deploy the underlying
DH> security - they are the people who best understand the demands of
DH> their TLS environment.

I agree that they best understand their environment. I disagree that
single level of security per address pair will provide them with the
flexibility that they want.

---

From: Robert Story <[email-masked]>
Date: Tue, 12 Jan 2010 11:18:37 -0500

On Tue, 12 Jan 2010 16:35:45 +0100 Juergen wrote:
JS> The question for me really is whether one can expect APIs to expose
JS> the details of ciphersuites (and thus the security level) to the
JS> applications using a secure transport.

Isn't that putting the cart before the horse? We shouldn't be designing
to existing APIs. We should be designing what we want, and the APIs
should follow.

Having said that:

— Function: int gnutls_priority_set (gnutls_session_t session,
                                      gnutls_priority_t priority)
    session: is a gnutls_session_t structure.
    priority: is a gnutls_priority_t structure.

    Sets the priorities to use on the ciphers, key exchange methods,
    macs and compression methods. 

- int SSL_set_cipher_list(SSL *ssl, const char *str);

   DESCRIPTION
   SSL_CTX_set_cipher_list() sets the list of available ciphers for ctx
    using the control string str.

So, yes, APIs exist that allow the application to specify ciphersuites.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Jan 2010 17:43:21 +0100

> to existing APIs. We should be designing what we want, and the APIs

Yes, but then designing something that can't be implemented easily is
also not a good recipe for success. Perhaps we even have to revise the
SSH TM decision once there is more implementation experience and we
know that authNoPriv can be reasonably supported with SSH libraries
and there is a demand for this.

In the case of (D)TLS, the libraries allowing authNoPriv support are
available and some WG members seem to have demand for this feature.

/js

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Jan 2010 14:55:35 -0500

> mechanisms or ciphersuites.

Oh, I think we could reasonably come to a consensus that the right thing 
for (D)TLS is different from the right thing for SSH.  But I don't think we 
should; the same principles are at work, and should result in the same 
answer -- the TM has no business peeking below the abstraction layer, and 
that means not knowing or caring what ciphersuites have what properties. 
Thus, we should simply treat all (D)TLS sessions as AuthPriv and mandate 
that TLS be configured so as to insure this is the case.

> support each securityLevel, so we have interoperability.

Yes, though I think we could reasonably defer that question to TLS itself, 
which already has mandatory-to-implement ciphersuites, and further say (as 
we already have) that it is OK for a secure transport to provide better 
security than the application asked for.

> do this level of data access control.

_That_ is not in any way unique to our work; it would apply just as well to 
USM.  I propose that we treat such questions as out of scope, at least for 
now, and possibly indefinitely.

So, my position is that there is little benefit to supporting multiple 
securityLevels in TLSTM.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Jan 2010 15:05:27 -0500

> to existing APIs. We should be designing what we want, and the APIs

True, to an extent.  However, what we _should_ be talking about is not 
API's, but the abstraction that TLS intends to export to the layer above. 
If we need something that is part of the abstraction, but nothing 
implements it, then we can decide whether it is worthwhile to require 
people to implement more of TLS in order to use TLSTM.  But if what we want 
is _not_ part of the abstraction, then we should not be using it, 
regardless of whether it happens to be exposed anyway by some APIs.

I argue that ciphersuite selection, and the question of what ciphersuites 
are available and what properties they have, is below the abstraction.  To 
decide whether a particular TLS session is suitable for a given security 
level, TLSTM would not only need to know what ciphersuite is in use; it 
would have to have some means of deciding whether that ciphersuite is 
suitable for a specified secuirty level.  When trying to establish a new 
session known to be suitable for a given securityLevel, the situation is 
even worse.  That kind of knowledge badly violates the abstraction, and is 
impractical to boot.

I keep using the word "abstraction", but not just because it sounds cool. 
Abstractions and the modularity they imply are _essential_ to keeping 
security analysis of our protocols manageable.

-- Jeff

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 12 Jan 2010 12:29:46 -0800

Hi -

> From: "Jeffrey Hutzelman" <[email-masked]>
> To: "Robert Story" <[email-masked]>; "Juergen Schoenwaelder" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Tuesday, January 12, 2010 12:05 PM
> Subject: Re: [Isms] multiple security levels in the dtls transport model
...
> suitable for a specified secuirty level.

No.  The "level of security" is a service user / service provider interface
abstraction .  It does *not* require that the service user (SNMP) know
what ciphersuites are available.  It merely requires the service provider
(TLS implementation) be able to honor a request to carry information
at a given level of security (or better) using whatever ciphersuites it
chooses, and, in the case of incoming information, to be able to inform
the service user what level of security had been given to the arriving
information.  This sort of requirement is not peculiar to SNMP.

> When trying to establish a new 

On the contrary, the need to be able specify whether information needs no
particular protection, requires authentication, or requires confidentiality
is a requirement that would be imposed by almost any application I can
think of that would need the services of a security protocol.  This does
not entail requiring the service interface to expose details of ciphersuite
selection.

> security analysis of our protocols manageable.

And an essential part of the abstract service interface provided by a
security layer is an abstract (e.g. at the granuality of "AuthNoPriv" rather
than "SHA/HMAC") characterization of the service provided.

Randy

---

From: Robert Story <[email-masked]>
Date: Tue, 12 Jan 2010 15:51:46 -0500

On Tue, 12 Jan 2010 14:55:35 -0500 Jeffrey wrote:
JH> [...] the TM has no business peeking below the abstraction layer, and 
JH> that means not knowing or caring what ciphersuites have what properties. 

agreed

JH> Thus, we should simply treat all (D)TLS sessions as AuthPriv

but I don't see how that follows.

JH>  and mandate that TLS be configured so as to insure this is the case.

As David said, we have to trust that an app/implementation actually
follows this mandate. If we can trust them to do this for authPriv, I
don't see why we can't also trust them to do it for authNoPriv.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 12 Jan 2010 12:57:09 -0800

[this is somewhat responding to multiple threads...  It's somewhat more
coherent together and I won't repost under each thread though.]

>>>>> On Tue, 12 Jan 2010 15:05:27 -0500, Jeffrey Hutzelman <[email-masked]> said:

JH> I argue that ciphersuite selection, and the question of what
JH> ciphersuites are available and what properties they have, is below the
JH> abstraction.

I agree.  In particular, I don't think we should define what is and what
is not an appropriate level of privacy protection or appropriate level
of authentication.  What we can say, and what the document does say, is
that you must use at least *a* form of authentication to pass traffic
with the Auth bit set.  And you must use *a* form of privacy to pass
traffic with the Priv bit set.  IE, you MUST NOT use NULL.  That's all
it says in terms of how you protect the traffic being sent by the
application.  It does not say that "1DES sucks and you shouldn't use it",
because that's best left to local policy choices.  We state that local
policy/configuration decisions may affect which algorithms are selected
or are acceptable.

This does *not* introduce any new failure cases that aren't already
present in TLS negotiations today.  It's *already* possible that a
SNMP/DTLS server may reject a client because they couldn't agree on
algorithms.  It's *already* possible that an SSH establishment would
fail for the same reasons.

The real question is, in my mind, should we allow a product to offer two
forms of protection of different levels (authNoPriv and authPriv).  We
allow this for SNMPv3 because we thought it was important.  I fail to
buy the argument "use USM if you want authNoPriv at different
cryptography".  The whole reason we're using TLS instead of USM is
because people don't want to use USM.  No where have people said "we
don't need authNoPriv".  In fact, I know of a lot of users that are
using it (maybe because they're clueless, I don't know, but I do know
they're using it).

I fail to see the purpose of putting in wording that actually
*restricts* an application from offering different levels of service
(authNoPriv and authPriv) to mean different things.  We *already* have
text that lets an implementation bail out and *not* offer tunnels
without both authentication and encryption.

IE, the current text says:

1) if you don't want the bit-checking complexity in your code, only
   offer TLS algorithms with at least minimal auth/priv protection
   mechanisms.

2) if you want to offer different levels of service you can.

As far as checking on the client side we already know it's possible for
most TLS suites out there (and I agree; it wasn't for SSH at the time
5592 was written).  Go to firefox, open a https session to your local
bank and click on the lock icon.  It'll tell you exactly what method of
protection you're being protected with.  This *is* exposed to TLS
clients today.

I think the current document strikes a perfect balance: it allows
implementations to be picky and protective if they want, and it allows
implementations not to.  We're not diving into "this security method is
better than that one".

I don't think we're violating layering either.  SNMPv3/USM has strong
knowledge of crypto algorithms.  TSM doesn't, and nothing in the current
document says it needs to.  The TLSTM layer must be able to at least
impose minimal (non-NULL) selections, which we know existing TLS layers
allow for (in fact, OpenSSL's selection APIs are much more complex than
we need).

Is it different than the SSH solution?  Yes.  Should it have to be the
same?  No!  I realize that "we already discussed that for another
protocol" is one argument you could make.  But we could have also made
the argument that "we already have a secure protocol and don't need
another one" is an approach we could have used to say "we don't need
DTLS", but the WG decided to adopt the TLS work.  It's also an approach
we could have used to throw out SSHTM too, but again we decided that we
needed something else.

What's the harm in keeping multiple security levels in the document?

1) People have said "complexity"; for them: don't implement it and only 
   offer secure transports.  Problem solved.

2) Layer violations: I've explained again that I don't buy that argument
   based on how existing TLS applications work.  Again, only offer
   secure transports and the problem solved.  You don't have to expose
   the connection details beyond the TLSTM.

At least we're getting good discussion out of this topic :-)  Is that a
good thing or a bad thing?