Subject: [Isms] Review of draft-ietf-isms-dtls-tm-01.txt

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 6 Dec 2009 23:18:53 -0800

I've had a chance to take a look at draft-ietf-isms-dtls-tm-01.  In
general I think the document is clear and well done.  I have a few
comments below, I haven't gotten all the way through the MIB definition
or the appendices yet.  

1) Section 2.1.  

I find it hard to reconcile a SHOULD for authentication of both client
and server. Why not a MUST?.  The next bullet seems to be a MUST for
client authentication.  Without server authentication there can be
serious problems such as man-in-the-middle.  I'm concerned that it is
not required here.  

2) Section 3.1.3

The document is slightly ambiguous as to the (D)TLS to transport
mapping.  DTLS can be run over UDP, TCP and SCTP and TLS can be run over
TCP or SCTP.  I think the document should be more clear that DTLS is
used for SCTP and UDP and TLS is used for TCP.  This is clear in the
IANA considerations, but it would be better if it were spelled out
earlier in the document.  

3) Section 3.3 and 4.1.1

These sections describe the mechanisms to map client certificates to
security names and provisioning mechanism for this.  After reading these
sections I was left wondering about the server side.  Section 5, does
cover most of this in detail, but it seems some mention of this is
appropriate earlier on in the document.  

4) Section 5.3, 2b

It seems that referencing I-D.saintandre-tls-server-id-check should be
enough, why do you need the last sentence about Common Name and
subjectAltNAme?

5) Section 5.3 last paragraph

TLS does define a Server Name Indication extension for identifying the
server you connect to
(http://www.ietf.org/id/draft-ietf-tls-rfc4366-bis-06.txt).  Right now
the only type of name defined is host name, which may not be very useful
for this case.  New name types could be developed if it would solve a
real problem.  

6) Section 9.1

TLS also supports extensions to communicate OCSP in the case the client
does not have access to an OCSP server.  I'm not sure if OCSP would be
operationally useful for SNMP.  

7) Section 10

Do you really need low number ports?  Unless we really need them it
might be best to just ask for reserved ports.  

Cheers,

Joe

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 08 Dec 2009 16:25:16 -0800

>>>>> On Sun, 6 Dec 2009 23:18:53 -0800, "Joseph Salowey (jsalowey)" <[email-masked]> said:

JS> I've had a chance to take a look at draft-ietf-isms-dtls-tm-01.  In
JS> general I think the document is clear and well done.  I have a few
JS> comments below, I haven't gotten all the way through the MIB definition
JS> or the appendices yet.  

Thanks for the comments and suggestions.  My responses are prefixed
below with "WH:" if you want to search for them.  The status of each
item is as follows:

  DONE:     Suggestion was acted on
  WONTDO:   Nothing was done; refer to the WH: response for reasons why
  DISCUSS:  There is an outstanding question back to you

* DONE Section 2.1. 

  + Yep.  As discussed in responses to others: the text actually
    came from others and I changed one SHOULD to a MUST but
    missed the other.  The new document now has MUSTs for
    supporting authentication on both sides. 
  
* DONE Section 3.1.3 

  + I added a sentence to the introduction and abstract in order
    to make sure this is well spelled out.  If you have other
    places you think it needs to be clearly stated, please
    suggest text.  Note that the section you referenced above
    was already cleaned up lately so I believe it's already
    somewhat better.
  
  + Second, in looking for places to add a new sentence I
    noticed another typo that no one had caught yet; so thanks
    for that too!
  
* DONE Section 3.3 and 4.1.1 

  + This section has gotten a lot of attention due to comments
    from other people as well.  If you wish to re-read it to
    make sure they address your issues that would be great!
  
* DONE Section 5.3, 2b 

  + That text has also changed and should be significantly better
    and more clear based on results from the last WG discussions.
  
* DONE Section 5.3 last paragraph 
  
  TLS does define a Server Name Indication extension for identifying the
  server you connect to
  ([http://www.ietf.org/id/draft-ietf-tls-rfc4366-bis-06.txt]).  Right now
  the only type of name defined is host name, which may not be very useful
  for this case.  New name types could be developed if it would solve a
  real problem.  
  
  + I did add a reference to 4366 (Pasi mentioned it as well).
  + I found it interesting to note that 5246 is marked as
    obsoleting 4366 even though not everything in 4366 is in
    5246 (and in fact 5246 *references* 4366).  I suspect a bug
    in the RFC status DB.
  
* WONTDO Section 9.1 

  + I doubt it fits wonderfully into the expected usage model.
    But if you have text you'd like to add, please propose it!
    Generally we've tried to make SNMP available offline as
    much, although the recent move into radius-based
    authentication is possibly changing that attitude.
  
* DONE Section 10 

  + Nope.  In fact, I mentioned this to you in the airport too and said
    we'd likely be changing it.  And I did!

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "tom.petch" <[email-masked]>
Date: Wed, 30 Dec 2009 11:43:58 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
Sent: Wednesday, December 09, 2009 1:25 AM

> JS> or the appendices yet.

<snip>

>     5246 (and in fact 5246 *references* 4366).  I suspect a bug

I think it wrong to reference 4366.  The definition of extensions is now in
RFC5246 while the details of extensions per se - eg SNI - is the updated
4366-bis that Joe refers to so that is the reference we should use.

Also, I think that s8.2 is now contradicting this section so 8.2 needs
updating with a reference to use of SNI  to fix this problem.

As Joe says, HostName seems inappropriate while SNI is an excellent
fit for our problem.  (The trouble with TLS and its documents is that
they are frequently written as if HTTP was the only application protocol
in the world:-).  I think we should ask for a new case in 4366-bis to cover
user/principal names.

And, while I am at it, I think the reference to RFC4347 is wrong; should be
draft-ietf-tls-rfc4347-bis
to go with RFC5246.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Wed, 30 Dec 2009 10:31:53 -0500

Personally, I recommend against having a reference to the bis
document. We are in WGLC and don't want publication held up because of
a reference to bis.

I suggest the wording allow for the changes that are being
incorporated into bis, preferably without referencing bis or the
discussing any of the details from bis.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of tom.petch
> Sent: Wednesday, December 30, 2009 5:44 AM
> To: Wes Hardaker; Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: Re: [Isms] SNI was IsmsReview of 
> draft-ietf-isms-dtls-tm-01.txt
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Dec 2009 08:07:45 -0800

>>>>> On Wed, 30 Dec 2009 10:31:53 -0500, "David Harrington" <[email-masked]> said:

DH> Personally, I recommend against having a reference to the bis
DH> document. We are in WGLC and don't want publication held up because of
DH> a reference to bis.

I agree; I was trying not to specify which versions of the TLS based
protocols we are requiring because I don't think there are any features
of the newer ones that we need.  There is no reason that future versions
of TLS and DTLS couldn't be used as well assuming they didn't introduce
a technical conflict with our document, which is unlikely.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Dec 2009 08:14:55 -0800

>>>>> On Wed, 30 Dec 2009 11:43:58 +0100, "tom.petch" <[email-masked]> said:

tp> Also, I think that s8.2 is now contradicting this section so 8.2 needs
tp> updating with a reference to use of SNI  to fix this problem.

You're right about that; I've now updated 8.2 so it should match the
text from 5.3 and they should now be consistent (with SNI being strongly
recommended).  Thanks for pointing that out.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Dec 2009 08:36:14 -0800

>>>>> On Wed, 30 Dec 2009 08:07:45 -0800, Wes Hardaker <[email-masked]> said:

WH> I agree; I was trying not to specify which versions of the TLS based
WH> protocols we are requiring because I don't think there are any features
WH> of the newer ones that we need.  There is no reason that future versions
WH> of TLS and DTLS couldn't be used as well assuming they didn't introduce
WH> a technical conflict with our document, which is unlikely.

Whoops.  Having re-read everything I realized I was confused about which
of the two issues David was talking about.  I responded about the DTLS
reference but the discussion was surrounding the fact that RFC4366 is
the only RFC that documents the server name extension until a new one
gets published.  Because of that, we'd either have to keep referencing
the older one (which doesn't cause any technical problems that I'm aware
of) or reference the ID and hope it completes soon.  Pasi may have a
better idea about how the other document is progressing, but unless it's
almost identically timed I don't think it buys us much to reference the ID.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

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

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
Sent: Wednesday, December 30, 2009 5:36 PM
Subject: Re: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt

> almost identically timed I don't think it buys us much to reference the ID.

Um

My point was rather that RFC4366 is obsoleted by RFC5246 because the
description of the extension technique has been removed from the TLS
extension document and made part of the base document, ie extensions
are base TLS as of TLS 1.2 (a key feature of current TLS list discussions).

4366-bis will only contain details of specific extensions.

SNI does appear in both RFC4366 and 4366-bis so from that
point of view, either will do, so it is a choice of being allowed to depend
on an obsoleted document versus having to wait for an I-D to
progress - I think the latter far preferable, the former a short
term expedient.  The latter gives us the chance to request
another case for SNI, the current hostname insisting on a fully
qualified DNS name which isn't really right for a securityName.

My personal view is that, currently, the TLS WG is rather
preoccupied with fixing the hole in renegotiation and I expect
it will be some months before 4366bis gets the attention it deserves.

Tom Petch

---

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

> it will be some months before 4366bis gets the attention it deserves.

If we can avoid to get delayed by months, we should try to do so. Lets
keep in mind that Propose Standard is just the beginning of the life
of a document on the standards track.

/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: Thu, 31 Dec 2009 08:02:04 -0500

My experience tells me that getting a document through the IESG
approval process can take a year, more likely 6 months. If the bis
status changes we can always change the reference later. But I don't
get the sense that the bis will beat our document through the system,
so I would prefer to point to the stable document unless, as Juergen
points out, there is a real technical  distinction.

dbh

> From: tom.petch [mailto:[email-masked]] 
> Sent: Thursday, December 31, 2009 3:32 AM
> To: Wes Hardaker
> Cc: David Harrington; 'Joseph Salowey (jsalowey)'; 
> [email-masked]; Pasi Eronen
> > >>>>> On Wed, 30 Dec 2009 08:07:45 -0800, Wes Hardaker 
> <[email-masked]>
> said:
> >