Subject: [Isms] dtls document writeup

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Feb 2010 15:50:48 +0100

Hi,

now that we have cleared up the counters, I believe we are pretty much
done with the (D)TLS transport mapping.  I plan to deliver the
document to our AD by the end of this week.  Attached is my document
writeup in case you want to review it before it goes to Pasi.

/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: "David Harrington" <[email-masked]>
Date: Tue, 2 Feb 2010 10:27:12 -0500

Hi,

Has anybody published an analysis of the differences, especially for
configuration and defaults and certificate processing, between the
TLS/DTLS usage in this document versus that in the syslog/tls and
syslog/dtls documents?

I know the syslog/dtls document was largely based on Wes's early
drafts for snmp/dtls. But both the tlstm and the syslog/dtls documents
have gone through significant editing since then.

The syslog WG has already had syslog/tls approved, and is about to
start WGLC on syslog/dtls, and plans to submit it to the IESG by
March. These documents will likely be going through the approval
process together, at least to a degree. While the syslog and SNMP
architectures are polar opposites, I think it would be helpful to
consider whether the operation and security of these two solutions
will be compatible and/or comparable.

The writeup mentions a review by the security directorate; you might
also ask that the operations directorate review it with an eye toward
consistency in operations between the protocols.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, February 02, 2010 9:51 AM
> To: [email-masked]
> Subject: [Isms] dtls document writeup
> 
> Hi,
>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 02 Feb 2010 11:50:11 -0800

>>>>> On Tue, 2 Feb 2010 15:50:48 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> now that we have cleared up the counters, I believe we are pretty much
JS> done with the (D)TLS transport mapping.  I plan to deliver the
JS> document to our AD by the end of this week.  Attached is my document
JS> writeup in case you want to review it before it goes to Pasi.

Thanks for the writeup Juergen; looks perfect.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 02 Feb 2010 11:52:21 -0800

>>>>> On Tue, 2 Feb 2010 10:27:12 -0500, "David Harrington" <[email-masked]> said:

DH> Has anybody published an analysis of the differences, especially for
DH> configuration and defaults and certificate processing, between the
DH> TLS/DTLS usage in this document versus that in the syslog/tls and
DH> syslog/dtls documents?

I compared them a while back, but I agree they've both received a lot of
work since then.  I'll take a look at the syslog document next week
sometime to look for any gotchas, but I don't think the pieces that are
similar between them have likely diverged much for as you said,
architecturally they're very different.  The one previous thing that the
SNMP document didn't do that the syslog document did was fingerprints,
and we've since added support for that.

I don't think it's worth holding up the submission to the IESG for though.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 3 Feb 2010 08:45:07 -0800

When I did my review I looked at this.  While the two are not exactly
aligned I think they are close enough not to cause problems.  I do think
it is still a good idea to have folks look at it from an operational
point of view.  

Joe

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> David Harrington
> Sent: Tuesday, February 02, 2010 7:27 AM
> To: 'Juergen Schoenwaelder'; [email-masked]
> Subject: Re: [Isms] dtls document writeup
> 
> Hi,
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: "tom.petch" <[email-masked]>
Date: Fri, 5 Feb 2010 09:41:18 +0100

Juergen

I think that the document should also be pointed at the Transport Directorate in
1c).

You mention a review by a TLS expert there, which is something I appreciate.  I
think the description of certificate handling wrong, although not wrong enough
to say any more than I have already said, so if a(nother) TLS expert says fine,
then I will revise my views.  I won't appeal, or raise this again.

But I have also expressed concern over transport, the description of the
differences between TCP and UDP, which, for me, do not exist at the protocol
level, rather at the implementation detail of what code libraries are currently
available.  I have reservations about how much of that should be normative
specification in a RFC, and think that this goes too far.  Again, I have said
this all already and don't plan to say any more but would appreciate a review by
the Transport Directorate.

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, February 02, 2010 3:50 PM
Subject: [Isms] dtls document writeup

> Document: draft-ietf-isms-dtls-tm-08.txt
>
>   (1.a) Who is the Document Shepherd for this document? Has the
>         Document Shepherd personally reviewed this version of the
>         document and, in particular, does he or she believe this
>         version is ready for forwarding to the IESG for publication?
>
> Juergen Schoenwaelder is the document shepherd. I have reviewed the
> document several times including thef latest version and I believe it
> is ready for forwarding it to the IESG for publication.
>
>   (1.b) Has the document had adequate review both from key WG members
>         and from key non-WG members? Does the Document Shepherd have
>         any concerns about the depth or breadth of the reviews that
>         have been performed?
>
> The document has received WG last call reviews from
>
> - 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]>
> - Robert Story <[email-masked]>
>
> and I do not have any concerns regarding the level of review for this
> document.
>
>   (1.c) Does the Document Shepherd have concerns that the document
>         needs more review from a particular or broader perspective,
>         e.g., security, operational complexity, someone familiar with
>         AAA, internationalization or XML?
>
> The document might benefit from a review of the TLS certificate
> handling procedures by some TLS expert; perhaps this can be dealt with
> as part of the security directorate review.
>
>   (1.d) Does the Document Shepherd have any specific concerns or
>         issues with this document that the Responsible Area Director
>         and/or the IESG should be aware of? For example, perhaps he
>         or she is uncomfortable with certain parts of the document, or
>         has concerns whether there really is a need for it. In any
>         event, if the WG has discussed those issues and has indicated
>         that it still wishes to advance the document, detail those
>         concerns here. Has an IPR disclosure related to this document
>         been filed? If so, please include a reference to the
>         disclosure and summarize the WG discussion and conclusion on
>         this issue.
>
> I do not have any specific concerns.
> No IPR disclosure been filed as far as we know.
>
>   (1.e) How solid is the WG consensus behind this document? Does it
>         represent the strong concurrence of a few individuals, with
>         others being silent, or does the WG as a whole understand and
>         agree with it?
>
> The document has WG consensus and the WG wants the document to be
> published as a Proposed Standard.
>
>   (1.f) Has anyone threatened an appeal or otherwise indicated extreme
>         discontent? If so, please summarise the areas of conflict in
>         separate email messages to the Responsible Area Director. (It
>         should be in a separate email because this questionnaire is
>         entered into the ID Tracker.)
>
> No-one has threatened with an appeal or expressed extreme discontent.
>
>   (1.g) Has the Document Shepherd personally verified that the
>         document satisfies all ID nits? (See the Internet-Drafts Checklist
>         and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
>         not enough; this check needs to be thorough. Has the document
>         met all formal review criteria it needs to, such as the MIB
>         Doctor, media type and URI type reviews?
>
> The document has been checked with idnits 2.12.00 and the warnings
> generated are all intentional or bugs in the tool. The document
> contains a MIB module and should go through the MIB doctor review
> processs.
>
>   (1.h) Has the document split its references into normative and
>         informative? Are there normative references to documents that
>         are not ready for advancement or are otherwise in an unclear
>         state? If such normative references exist, what is the
>         strategy for their completion? Are there normative references
>         that are downward references, as described in [RFC3967]? If
>         so, list these downward references to support the Area
>         Director in the Last Call procedure for them [RFC3967].
>
> References are split in Normative and Informative. All normative
> documents have been published.
>
>   (1.i) Has the Document Shepherd verified that the document IANA
>         consideration section exists and is consistent with the body
>         of the document? If the document specifies protocol
>         extensions, are reservations requested in appropriate IANA
>         registries? Are the IANA registries clearly identified? If
>         the document creates a new registry, does it define the
>         proposed initial contents of the registry and an allocation
>         procedure for future registrations? Does it suggest a
>         reasonable name for the new registry? See [RFC5226]. If the
>         document describes an Expert Review process has Shepherd
>         conferred with the Responsible Area Director so that the IESG
>         can appoint the needed Expert during the IESG Evaluation?
>
> The document requests a number of assignment in existing registries.
> It does not create any new registries. I believe the IANA instructions
> are clear.
>
>   (1.j) Has the Document Shepherd verified that sections of the
>         document that are written in a formal language, such as XML
>         code, BNF rules, MIB definitions, etc., validate correctly in
>         an automated checker?
>
> The MIB module has been checked using smilint for syntactic
> correctness.
>
>   (1.k) The IESG approval announcement includes a Document
>         Announcement Write-Up. Please provide such a Document
>         Announcement Write-Up? Recent examples can be found in the
>         "Action" announcements for approved documents. The approval
>         announcement contains the following sections:
>
>      Technical Summary
>      This document describes a Transport Model for the Simple
>         Network Management Protocol (SNMP), that uses either the
>         Transport Layer Security protocol or the Datagram Transport
>         Layer Security (DTLS) protocol.  The TLS and DTLS protocols
>         provide authentication and privacy services for SNMP
>         applications.  This document describes how the TLS Transport
>         Model (TLSTM) implements the needed features of a SNMP
>         Transport Subsystem to make this protection possible in an
>         interoperable way.
>
>      Working Group Summary
>
>         The working group went over several revisions of this document
> and the document and all WG last call comments have been
> resolved. There has been strong WG consensus to publish this
> document as Proposed Standard.
>
>      Document Quality
>         There are two known implementations in progress of the
> (D)TLS Transport Model.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Feb 2010 13:28:22 +0100

On Fri, Feb 05, 2010 at 09:41:18AM +0100, tom.petch wrote:
 
> I think that the document should also be pointed at the Transport
> Directorate in 1c).

[...]
 
> But I have also expressed concern over transport, the description of
> the differences between TCP and UDP, which, for me, do not exist at
> the protocol level, rather at the implementation detail of what code
> libraries are currently available.  I have reservations about how
> much of that should be normative specification in a RFC, and think
> that this goes too far.  Again, I have said this all already and
> don't plan to say any more but would appreciate a review by the
> Transport Directorate.

Please help me by naming the section(s) in the document you think the
Transport Directorate should look at.

/js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 5 Feb 2010 19:25:26 +0100

----- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
Subject: Re: [Isms] dtls document writeup

> Transport Directorate should look at.

Sections 5.1, 5.1.1, 5.1.2

Tom Petch