Subject: [Isms] TLSTM -04 draft being published: wraps up all outstanding edits

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Dec 2009 09:11:17 -0800

I'm in the process right now of publishing a -04 copy of the TLSTM draft
and it contains all my outstanding edits from the comments received
since last call.  Note that although last call has long ago finished
we've received a number of comments after that cut-off, in part because
of Juergen's request for more reviews.  Thanks to everyone who has
submitted comments about the draft as they've been very helpful.  I've
already responded to each person with the actions taken based on the
comments.

I'll leave it up to the working group chairs to decide if there are any
outstanding consensus calls that need to be made that I've missed.

The only outstanding issues that I think are still being discussed on
the list are:

1) The reference to 4366 for the server-name extension.  Consensus
   currently seems that we should leave the reference and not reference
   the unpublished ID yet that updates that section from 4366.  But
   there aren't many opinions yet.

2) The issue of MIB fate-sharing is still being discussed as well about
   whether or not the rows in the target add-on tlstmParamsTable should
   be deleted when a row in the original target table has been deleted.

   There are two independent in functionality but related in
   global-picture that we're discussing.

   I. row creation ordering

      a) The tlstmParamsTable entry may be created in advance of the row
         in the snmpTargetParamsTable.
         [being done now in the MIB DESCRIPTIONs]

      b) The snmpTargetParamsTable entry must pre-exist before the row
         in the tlstmParamsTable can be created.  The downside of this
         is that with the snmpTargetParamsTable row in existence before
         the tlstmParamsTable then the row won't be functional when one
         of the TLSTM domains are in use until the other row is created.
         Or worse, per 5.3 step 1) the connection can still be attempted
         with a different certificate than was expected if another was
         identified through other configuration (eg, a global device
         certificate).

      c) The tlstmParamsTable entry must pre-exist before the row in the
         snmpTargetParamsTable can be created.  This would be adding
         requirements to the existing TARGET-MIB implementations when
         the new MIB is supported, which is generally frowned upon.

  II. row deletion ordering

      a) The row in tlstmParamsTable is automatically deleted when the
         corresponding row in the snmpTargetParamsTable is deleted.
         [being done now in the MIB DESCRIPTIONs]

      b) The rows in the two tables are independent with respect to
         deletion.  Either can be deleted first (and without both in
         place, the connection can't be completed).

      c) One table could require the deletion of a row from the other
         table.  I don't think anyone is vying for this option though.

  The working group seems somewhat split on this subject but I don't
  think we have an accurate account of who wants what at this point.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Dec 2009 06:13:39 +0100

>    there aren't many opinions yet.

Unless there is a very strong technical reason, we should avoid having
a reference to 4366bis. If someone believes there is such a very
strong technical reason, please speak up now.

>          the new MIB is supported, which is generally frowned upon.

I do not think there was a request to change what we have for row
creation ordering, namely I.a).

>   think we have an accurate account of who wants what at this point.

I heard David Harrington, Randy Presuhn, Andrew Donati and myself (as
technical contributor) speaking in favour of II.b) and all three
provided different arguments for choosing II.b):

- David mentioned consistent user experience and consistency across
  SNMP configuration tables in general.

- Randy mentioned the implementation aspects of fate shared tables and
  side effects potentially circumventing access controls rules.

- Andrew mentioned issues with StorageTypes that prevent fate sharing
  from happening.

Unless someone speaks up now with a technical argument in favour of
keeping II.a) and in particular explains how to address the issue
Andrew Donati brought up, I assume we will go with II.b.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Dec 2009 06:21:33 +0100

> outstanding consensus calls that need to be made that I've missed.

According to my record, the following people provided WG last call
reviews:

- Andrew Donati <[email-masked]>
- Pasi Eronen <[email-masked]>
- Juergen Schoenwaelder <[email-masked]>
- Hamid Mukhtar <[email-masked]>
- Alan Luchuk <[email-masked]>
- Joe Salowey <[email-masked]>
- David Harrington <[email-masked]>
- Tom Petch <[email-masked]>

I like to ask these WG members to check that the changes in the -04
document address their concerns. Silence will be read as the changes
are fine. Please check until Wed January 6th the latest.

/js

---

From: "tom.petch" <[email-masked]>
Date: Thu, 31 Dec 2009 09:30:41 +0100

Some editorial suggestions, of grammar, semantics and clarity.

3.1.1 2

"The TLSTM provides for verification of the identity of the (D)TLS
       server through the use of the (D)TLS protocol and the X.509
      certificates.  "
Suggest
"The TLSTM verifies the identity of the (D)TLS
       server through the use of the (D)TLS protocol and X.509
       certificates.  "

3.1.1 5
"However, datagram-based security  protocols are ....  because it"
/it/they/

3.1.2
" and the type and address associated "
suggest  "and the transport type and address associated "
type on its own left me floundering

3.1.3
"Each unique combination of these
   parameters MUST have a locally-chosen unique tlstmSessionID
   associated for active sessions.  "
The last clause seems barely grammatical; suggest removing 'associated
for active sessions'  If you want to limit this to active sessions, suggest
'for each active session'

"TLS and DTLS over SCTP sessions,"
tells me this is TLS over SCTP; suggest
"TLS over TCP and DTLS over SCTP sessions,"

"The tlstmSessionID identifier MUST
   NOT change during the entire duration of the connection "
since it is a sessionID suggest session not connection.

3.2 "(e.g..," an extra period to go with ...

4.4.1 ... a missing period

5.1.1 5 /(D)TLS/DTLS/

5.2 5 4b (eh???? but that is what it says:-(

  /tmStateReferenc/tmStateReference/

5.3 3b
"The (D)TLS client side of the connection MUST verify that
           authenticated identity of the (D)TLS server's presented
           certificate is the expected certificate"
ie 'the authenticated identity is the certificate'
ok grammatically, but for me, not semantically; identities and certificates
come from different universes

5.3 4
this is the one and only appearance of sessionID; well known in the TLS
protocol but not what I think you mean:-)

Tom Petch

----- Original Message ----- 
From: "Wes Hardaker" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 30, 2009 6:11 PM
Subject: [Isms] TLSTM -04 draft being published: wraps up all outstandingedits

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

---

From: "tom.petch" <[email-masked]>
Date: Thu, 31 Dec 2009 09:42:57 +0100

on 4366

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Wes Hardaker" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 31, 2009 6:13 AM
Subject: Re: [Isms] TLSTM -04 draft being published: wraps up all outstanding
edits

> strong technical reason, please speak up now.

4366 requires the HostName to be a fully qualified DNS name
so if we follow that RFC, we would require our securityNames-to-be
to be fully qualified DNS names.  I think that wrong.

We should either ask the TLS WG to add another case more
suitable for our needs, ie in 4366bis or else we do it ourselves,
put in another case as an update to the registry of cases - the rules
for update allow us to do that.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Dec 2009 13:51:05 +0100

> to be fully qualified DNS names.  I think that wrong.

Why?

> for update allow us to do that.

If there is a strong case that can be well argued, I would prefer to
channel this through the TLS WG if it needs to be dealt with at all.

/js

---

From: "tom.petch" <[email-masked]>
Date: Thu, 31 Dec 2009 16:13:48 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" [email-masked]
Sent: Thursday, December 31, 2009 1:51 PM

> > to be fully qualified DNS names.  I think that wrong.

You seem to be suggesting that your principal names are
fully qualified DNS names.  I know of none such so forcing
the SNI to be a fully qualified DNS name, which is my
reading of RFC4366, means yet another mapping table
to be configured by the admin, mapping fully qualified
DNS names into what admins actually assign to users.

I see a need for another case allowing snmpAdminString
format.

Tom Petch