Subject: [mile] AD review of draft-ietf-mile-rfc6046-bis

From: Sean Turner <[email-masked]>
Date: Wed, 07 Dec 2011 17:11:24 -0500

Here is my review of draft-ietf-mile-rfc6046-bis.

1) s1.1/s4: s1 contains the following:

   o The required version of TLS is upgraded to 1.1.

But, I don't see any text that says TLS 1.1 is the MUST.  There's this 
statement in s4:

   Although TLS
   implementations typically support the older SSL protocol, a RID peer
   MUST NOT request, offer, or use any version of SSL, or any version of
   TLS prior to 1.1 [RFC4346], due to known security vulnerabilities in
   prior versions of the protocol; see Appendix E of [RFC5246] for more.

To me that reads like the required TLS version is at least 1.1 but could 
be 1.2.  So maybe the summarized change is:

   o  The minimum required version of TLS is upgraded to 1.1.

Note that this requirement is going to require changes to most TLS 
implementations, but I bet you knew that.

2) s3 contains the following:

  When a RID message must be sent,
  the sending RID system connects to the receiving RID system and sends
  the message, optionally receiving a message in reply.

Maybe swap must for is (must usually makes people wonder if it's 
supposed to be 2119ed and if it's not lets use another word if we can):

  When a RID message is sent,
  the sending RID system connects to the receiving RID system and sends
  the message, optionally receiving a message in reply.

3) s3: Need a pointer to s10 for the port assignment (see later comment).

  Consistent with BCP 56, RID systems listen for TCP
  connections on port 4590 (see Section 10.3).

4) s3: must or MUST?

  When a RID
  System's address changes, contact point information within the
  consortium must be updated out of band.

5) s10: Please instruct IANA to update the registry reference to point 
to this document.  I'd rather have it point to this document than RFC 
6046 because you're obsoleting it.

6) s12.1: Please refer to the mile version of 6045bis as opposed to the 
individual version.

7) s6/s7.2: Is RFC6125 really informative?  I think we want people to 
follow the rules defined therein - don't we?

8) I'm not so sure about listing which bits are informative/normative, 
but here's my initial thoughts on the choices:

- Isn't s1.2 normative - if somebody copied this but didn't follow our 
classification then what would we do?

- Isn't s2 also normative because it defines the meanings of 
MUST/SHOULD/etc?  We shouldn't let somebody decide to change the 
meanings of these words.

- Isn't s7.1 normative - it lists the normative references?

What does normative/informative mean in the context of section in an 
draft/RFC?  I understand what it means in the context of a reference, 
but not so much with sections.  Are you saying implementations that 
claim conformance with this standard MUST conform to those sections?  I 
think it makes sense to explain what you mean when you say a section is 
normative/informative. Let's not assume people know what it's supposed 
to mean ;)

spt

---

From: Sean Turner <[email-masked]>
Date: Wed, 07 Dec 2011 17:37:35 -0500

One more:

8) Maybe we should just delete this sentence from the abstract:

  This document updates [RFC6046], and to
  change the intended status to Proposed Standard, and to reference the
  updated RID specification.

I'm concerned we'll end up discussing the fact the abstract says updates 
but the header says obsoletes and when wordsmithing everybody gets a cut 
;)  Also, references in the abstract are a no-no and the IESG tries to 
lighten their load by removing them before drafts get there.  Since this 
draft is obsoleting 6046 and there's a changes section it's probably not 
needed to list the changes in the abstract.  Or swap updates to obsoletes.

spt

On 12/7/11 5:11 PM, Sean Turner wrote:
> MUST/SHOULD/etc? We shouldn't let somebody decide to change the meanings
> of these words.
>
> draft/RFC? I understand what it means in the context of a reference, but
> not so much with sections. Are you saying implementations that claim
> conformance with this standard MUST conform to those sections? I think
> it makes sense to explain what you mean when you say a section is
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Dec 2011 14:42:17 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
> Sent: Wednesday, December 07, 2011 2:11 PM
> To: [email-masked]
> Subject: [mile] AD review of draft-ietf-mile-rfc6046-bis
> 

In this particular draft, the only non-boilerplate stuff that's not normative is the Introduction.  I would hope nobody would expect normative language in there.  Thus, I would strike Section 1.2 altogether.

Also, I would merge the Security Considerations into Section 3, but that's because I'm of the camp that Security Considerations should be pedagogical, but not normative.  I don't know what others think or what the current IESG might want to see.

In general, I actually don't like this declarative normative/informative practice in documents.  We did it in DKIM, blatantly labeling some things as "INFORMATIVE NOTE" and "INFORMATIVE ADVICE", and I find it awkward to read.  Some people do like it though.  Presumably the intent is to advise the reader that if somehow this document gets published where the normative stuff and the informative stuff are in conflict, the normative stuff always wins.

My preference is to split such sections into the ones that contain the normative bits, and those that contain discussion, with the latter containing no 2119 language whatsoever.  Something like:

	Section x.y.  Protocol Definition

	[blah SHOULD blah MUST blah]

	Section x.y+1.  Discussion

	[blah blah explain the protocol blah, no 2119 stuff here]

Section 3 might benefit from such a treatment.

-MSK

---

From: SM <[email-masked]>
Date: Wed, 07 Dec 2011 14:57:51 -0800

At 14:37 07-12-2011, Sean Turner wrote:
>says obsoletes and when wordsmithing everybody gets a cut ;)  Also, 
>references in the

I am waiting for the outcome on the following when the document is published:

   "More information on best practices in peer identity verification is
    available in [RFC6125]."

Regards,
-sm

---

From: <[email-masked]>
Date: Thu, 8 Dec 2011 09:57:00 -0500

Thank you for the comments, Sean.  

I'll stick to #8 and answer Murray's questions on the same topic in my next message.  The rest look like they are for Brian, as editor.  The reasons behind my request to add this section is in the response to Murray's questions.

Agreed, this should be normative.  We should define what we mean as normative or informative sections here as well in response to your point below.  How about the following (please edit as you/others see fit):

A section defined as normative MUST be followed to claim conformance with this standard.  The terms from [RFC2119] used within these sections MUST be interpreted according to their definitions, as referenced in Section 2, to claim conformance.  The definitions allow flexibility when the terms SHOULD, MAY, RECOMMENDED, and OPTIONAL are present to ensure interoperability between implementations.  The sections declared as informative provide helpful background information and considerations for implementations.

Yes, agreed.

Yes, agreed.

Good point, hopefully the above proposed text helps to address these concerns.

Thank you!
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Wednesday, December 07, 2011 5:11 PM
To: [email-masked]
Subject: [mile] AD review of draft-ietf-mile-rfc6046-bis

   Although TLS

4) s3: must or MUST?

  When a RID

spt

---

From: <[email-masked]>
Date: Thu, 8 Dec 2011 10:04:52 -0500

Murray,

Thank you very much for your comments.  I'll provide more of the background for my request to the list to put in the section explicitly stating whether or not sections are normative or informative.

In my initial message to the list on this topic, I stated this is what was done in RFC6045, per recommendation from the Security AD at the time.  This advice turned out to be helpful later on, as this work (both RFC6045-bis and RFC6046-bis) is being adopted by the ITU-T.  The ITU-T is adding this document into their Cybersecurity Information Exchange (CYBEX) suite of techniques and protocols (Study Group 17/Question 4).  In August, a proposal was made to format the ITU-T documents, where they directly refer to the IETF RFCs.  In the proposal, the ITU-T document is essentially an outline that lists the section headers of the IETF document.  Within the outline, there is just a statement whether or not each section of the IETF document is considered normative or informative.  The interpretation at the ITU meeting (for how the drafts look now) matches our thinking - if there are RFC2119 terms and points essential for implementation, it is normative.  

Having this reviewed by the WG and IETF is good to ensure the IETF agrees and can format the document as appropriate for the IETF.  The ITU may, at some point, want to create a 'profile' of the referenced RFCs.  They may want to change some SHOULDs to MUST or set other requirements that are still interoperable with the RFC implementations.  The stricter we can be on guidance, we may have more of a chance at maintaining compatibility between implementations.  The rapporteur of the study group question is assisting, as are others to help prevent interoperability concerns.  The published version of this RFC-to-be will be referenced in an ITU-T recommendation.

I like your recommendations to split normative text out of the Security Considerations section.  Developers may view that as an informative section because of the title and it could help avoid any ambiguity (even though the RFC2119 terms should say it all).  If the IETF decides to cut out the section that states what is normative or informative, having clear delineations in where there is either normative or informative text in each section will be very helpful.  It would be good for the ITU-T reference of this document so there is no confusion in how to interpret the sections.

Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, December 07, 2011 5:42 PM
To: [email-masked]
Subject: Re: [mile] AD review of draft-ietf-mile-rfc6046-bis

-MSK

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 09 Dec 2011 03:28:29 +0800

Hi Kathleen,

Good description of the construct with the ITU-T.  It should
be noted that the model has significant utility on a scale beyond
just ITU-T.  Other bodies like 3GPP are also producing derivative
versions of RFCs that get driven into the global mobile
communications infrastructure.  Their "normatives" are especially
important because their specs are tightly versioned and the
capabilities get mandated by all the operators and vendors into
the global mobile communications infrastructure.

--tony

On 12/8/2011 11:04 PM, [email-masked] wrote:
> other requirements that are still interoperable with the RFC implementations.  The stricter we can be on guidance, we may have more of a chance at maintaining compatibility between implementations.  The rapporteur of the study group question is assisting, as are others to help prevent interoperability concerns.  The published version of this RFC-to-be will be referenced in an ITU-T recommendation.

---

From: Sean Turner <[email-masked]>
Date: Thu, 08 Dec 2011 15:42:02 -0500

trimming this down to the proposed text (hoping others will jump in here 
too)

> A section defined as normative MUST be followed to claim conformance with this standard.  The terms from [RFC2119] used within these sections MUST be interpreted according to their definitions, as…

I like the 1st and last sentences.  The middle two I think might be read 
as rephrasing/re-characterizing what's already in 2119.  And, 
SHOULD/RECOMMENDED is really MUST unless you can come up with a really 
good reason not to do it that way - it's really only MAY/OPTIONAL that 
allows implementations to do what they want.  In the olden days when 
they did interop reports they tested the MUSTs and the SHOULDs to test 
for interop.  The only other point I want to get across is that the 
definitions of the conformance terms is normative, but I wonder if I'm 
the only one worried about that.  Maybe ? :

   A section defined as normative MUST be followed to claim
   conformance with this standard.  This includes the section that
   defines the conformance words.  The sections declared as
   informative provide helpful background information
   and considerations for implementations.

spt

---

From: SM <[email-masked]>
Date: Thu, 08 Dec 2011 13:05:49 -0800

Hi Sean,
At 12:42 08-12-2011, Sean Turner wrote:
>I like the 1st and last sentences.  The middle two I think might be 
>read as rephrasing/re-characterizing what's already in 2119.  And, 
>SHOULD/RECOMMENDED is really MUST unless you can come up with a 
>really good reason not to do it that way - it's really only 
>MAY/OPTIONAL that allows implementations to do what they want.  In 
>the olden days when they did interop reports they tested the MUSTs 
>and the SHOULDs to test for interop.  The only other point I want to 
>get across is that the definitions of the conformance terms is 
>normative, but I wonder if I'm the only one worried about that.  Maybe ? :
>

As you mentioned above, requirement levels are about 
interoperability.  There isn't any claim of conformance or 
conformance words in a Standard-Track document.

I'll nit on this on the Last Call if there is such text about 
conformance.  For background information, see the thread about 
2119bis at http://www.ietf.org/mail-archive/web/ietf/current/msg68878.html

Regards,
-sm

---

From: Brian Trammell <[email-masked]>
Date: Thu, 8 Dec 2011 22:40:28 +0100

Hi, Sean, Kathleen, all,

Jumping in here on this issue specifically; will address other comments in a separate message.

I also think we should avoid restating what's in 2119.

Another was to approach this would be to clarify in the text (what I have always assumed to be) the rules about what is normative and what is informative in an IETF Standards Track draft:

All sections which use the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"  as defined in [RFC2119] are declared as normative unless specifically noted otherwise. All normative sections MUST be followed by implementations of this standard. Sections which are not declared as normative are informative; these provide helpful background information and considerations for implementations. Specifically, the normative sections in this document are Section 2 and Section 3. 

In RFC6046, I would replace the current Section 2. Terminology with the above paragraph, and rename the section 2. Terminology and Normative Sections. Thoughts?

(The text above also assumes a move of the normative text from the Security Considerations section into Section 3; see a forthcoming message on this).

Best regards,

Brian (as author of 6046bis)

On Dec 8, 2011, at 9:42 PM, Sean Turner wrote:

> trimming this down to the proposed text (hoping others will jump in here too)
> 
> I like the 1st and last sentences.  The middle two I think might be read as rephrasing/re-characterizing what's already in 2119.  And, SHOULD/RECOMMENDED is really MUST unless you can come up with a really good reason not to do it that way - it's really only MAY/OPTIONAL that allows implementations to do what they want.  In the olden days when they did interop reports they tested the MUSTs and the SHOULDs to test for interop.  The only other point I want to get across is that the definitions of the conformance terms is normative, but I wonder if I'm the only one worried about that.  Maybe ? :
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Dec 2011 14:57:23 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Thursday, December 08, 2011 1:06 PM
> To: Sean Turner
> Cc: [email-masked]
> As you mentioned above, requirement levels are about interoperability.
> There isn't any claim of conformance or conformance words in a
> Standard-Track document.

I think the RFC2119 already language makes it explicit: You are compliant with a specification if you adhere to 100% of the normative statements in it.

That said, I don't think there's anything wrong with including conformance requirements in a document, perhaps an appendix, especially if it's like a checklist of the normative stuff elsewhere in the document that an implementer could easily consult.  Sort of like a test plan.  The risk, though, is that the rest of the document has to match exactly the contents of that checklist.

(But this is becoming a topic larger than MILE, so I'll stop now.)

---

From: Brian Trammell <[email-masked]>
Date: Fri, 9 Dec 2011 00:00:52 +0100

Hi, Sean, all,

I've made most of these changes to an eventual -04 revision of the document; details or questions on particular points inline, below.

Cheers,

Brian

On Dec 7, 2011, at 11:11 PM, Sean Turner wrote:

> But, I don't see any text that says TLS 1.1 is the MUST.  There's this statement in s4:
> 
>  Although TLS
> To me that reads like the required TLS version is at least 1.1 but could be 1.2.  So maybe the summarized change is:
> 
> Note that this requirement is going to require changes to most TLS implementations, but I bet you knew that.

This is the rationale behind 1.1; it's (much) more widely available, and should minimize migration effort. Indeed, we hope that implementations based upon a widely available TLS library would have been using 1.1 anyway.

> 7) s6/s7.2: Is RFC6125 really informative?  I think we want people to follow the rules defined therein - don't we?

I wasn't really sure the best way to handle this reference (I think SM's comment, earlier, addressed this point too). It seemed like a little much to _require_ SRV records (this gets into deployment-time considerations), but none of the application design points in section 3 of 6125 really seem to apply to RID. Given that, the intention was to state the requirement then point to 6125 for guidelines (informative) on implementing it.

Probably the right thing to do, instead, is to specify DNS-ID (as in 6125 seciton 1.8 "identifier type"), with CN-ID as a fallback and SRV-ID for deployments which use SRV records, using normative language in 6046-bis itself, and referring back to 6125 -- in that case, I think 6125 really _would_ be informative.

> 8) I'm not so sure about listing which bits are informative/normative, but here's my initial thoughts on the choices:

(See the other thread on this)...

Also, I've gone ahead and cut the "updates" language out of the abstract.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 9 Dec 2011 00:13:08 +0100

(I forgot to explicitly note, but hope it was obvious, that the previous message was sent as author of 6046-bis)

---

From: Brian Trammell <[email-masked]>
Date: Fri, 9 Dec 2011 00:15:29 +0100

Hi, Murray,

Thanks for the comments; replies inline...

> Also, I would merge the Security Considerations into Section 3, but that's because I'm of the camp that Security Considerations should be pedagogical, but not normative.  I don't know what others t…

Given the structure of 6046-bis, this makes sense; as it read, the "protocol specification" was essentially written as "protocol without security", which wasn't really the intent. I've merged these back in in my working copy of the next revision.

> In general, I actually don't like this declarative normative/informative practice in documents.  We did it in DKIM, blatantly labeling some things as "INFORMATIVE NOTE" and "INFORMATIVE ADVICE", an…

(I've already addressed this a bit in my earlier message on the subject, but...)

Indeed, this is also the limit of my personal experience with such language in drafts: where one part of a draft is essentially a restatement of the other (say, an XML schema and some text explaining its contents), stating which wins in case of ambiguity (whether real or imagined). It allows an _interoperable_ protocol even in the presence of imperfect language in the draft. 

Here, though, the intent is different -- "meta-interoperability" of the specification with other standards processes. In that case, as long as the note doesn't _change_ the meaning of the normative bits of the document, and is phrased in such a way as to minimize confusion (as we seem to be converging on), I think it's worth adding.

> 	[blah blah explain the protocol blah, no 2119 stuff here]

I like the approach, if only because it makes it clear that the presence of 2119-phrased specifications is what makes something normative, which I think is the de facto way sections of drafts are assumed to be normative or informative, anyway. However...

> Section 3 might benefit from such a treatment.

I've had a quick look, and don't really see what of section 3 could be pulled out into its own section, without damaging the readability of the specification. There's really not so much content in Section 3 that it deserves subsectioning, IMO.

Cheers,

Brian (as author of 6046-bis)

---

From: "Martin, Robert A." <[email-masked]>
Date: Thu, 8 Dec 2011 20:48:02 -0500

Hi everyone,

Not being as familiar with IETF's practices as most of you I'll leave 
that aspect of making sure we keep within the "IETF rails" on these 
documents for you to decide, however I do believe that we need to make 
it painfully easy for others to know what parts/portions of these 
documents they need to follow, leverage, or apply.

Given the leveraging of IETF RFCs by other groups, we need to do our 
best to make sure all of those groups correctly and completely invoke 
the right parts of the RFCs in their own work or we are going to end up 
with divergent and possibly conflicted implementations and that is not 
the goal or desire of anyone.

Some standards bodies have explicit compliance points defined in their 
specifications to help clarify for implementers the sub-sets of the work 
that need to work together and are necessary as "units" of capabilities 
so that implementers "know" what they are expected to provide.

Bob's 2cents

On 12/8/11 5:57 PM, Murray S. Kucherawy wrote:
> .

---

From: Sean Turner <[email-masked]>
Date: Fri, 09 Dec 2011 11:41:29 -0500

> This is the rationale behind 1.1; it's (much) more widely available, and should minimize migration effort. Indeed, we hope that implementations based upon a widely available TLS library would have…

Compared to 1.2, 1.1 is way more implemented.  But, if you want to pick 
1.1 then I think you need to be explicit.  That is you need a statement 
like the following: TLS 1.1 MUST be supported.

> Probably the right thing to do, instead, is to specify DNS-ID (as in 6125 seciton 1.8 "identifier type"), with CN-ID as a fallback and SRV-ID for deployments which use SRV records, using normative…

okay I think that makes sense

---

From: <[email-masked]>
Date: Fri, 9 Dec 2011 14:02:01 -0500

Hi Sean,

The TLS 1.1 requirement resulted from my WGLC comment:

	... given how recently RID was originally specified (2010), would it
	be reasonable to require TLS 1.1 (2006) or a more recent version?  Requiring at least
	TLS 1.1 removes the vulnerability caused by use of an implicit IV for CBC-mode ciphers
	in prior versions of TLS and SSL.

I would hope that implementations are picking up "a widely available TLS library" that has TLS 1.1 support - a "MUST" requirement to implement TLS 1.1 does seem reasonable, IMHO.

Thanks,
--David

> Sent: Friday, December 09, 2011 11:41 AM
> To: Brian Trammell
> Cc: [email-masked]
> > This is the rationale behind 1.1; it's (much) more widely available, and should minimize migration
> effort. Indeed, we hope that implementations based upon a widely available TLS library would have been
> using 1.1 anyway.
> 
> > I wasn't really sure the best way to handle this reference (I think SM's comment, earlier, addressed
> this point too). It seemed like a little much to _require_ SRV records (this gets into deployment-time
> considerations), but none of the application design points in section 3 of 6125 really seem to apply
> to RID. Given that, the intention was to state the requirement then point to 6125 for guidelines
> (informative) on implementing it.
> >
> > Probably the right thing to do, instead, is to specify DNS-ID (as in 6125 seciton 1.8 "identifier
> type"), with CN-ID as a fallback and SRV-ID for deployments which use SRV records, using normative
> language in 6046-bis itself, and referring back to 6125 -- in that case, I think 6125 really _would_
> be informative.
>

---

From: Sean Turner <[email-masked]>
Date: Sun, 11 Dec 2011 13:27:39 -0500

On 12/8/11 4:05 PM, SM wrote:
> conformance. For background information, see the thread about 2119bis at
> http://www.ietf.org/mail-archive/web/ietf/current/msg68878.html

Yep that was a slip up.  It ought to be about interop.

spt

---

From: Sean Turner <[email-masked]>
Date: Sun, 11 Dec 2011 13:36:45 -0500

> In RFC6046, I would replace the current Section 2. Terminology with the above paragraph, and rename the section 2. Terminology and Normative Sections. Thoughts?

I don't think you can replace the text that's in 1.2 with this text.  I 
think this could added and it might work.  Need to add "NOT RECOMMENDED" 
after "RECOMMENDED" in the paragraph that's there and the one you're 
proposing.

I think that whatever section this appears in needs to be normative, the 
IANA considerations section needs to be normative, and the normative 
references need to be normative ;)

I think you'll need to work a normative reference to 6045-bis somewhere 
in to one of the other sections that you're calling normative.  I guess 
you should double check that any normative reference is in a section 
that is also normative.

spt

---

From: Sean Turner <[email-masked]>
Date: Sun, 11 Dec 2011 14:23:22 -0500

David,

Hi.  I'm thinking that maybe we should require 1.2 not 1.1.  Before I 
became an AD I tried to knock over SSL 3.0, TLS 1.0, and TLS 1.1.  The 
argument for only knocking off SSL 3.0 was that there were so few 
servers actually implementing TLS 1.1 or 1.2.  At one point there were 
only two 1.2 server and I think they were both test servers.  Now, the 
tests conducted by Opera with their TLS prober show that there are many 
more TLS 1.2 servers.  Assuming an implementation of 6046 isn't a 
generic web server, why can't we go all the way to 1.2?

spt

---

From: <[email-masked]>
Date: Sun, 11 Dec 2011 14:40:20 -0500

Thanks Sean & David,

My .02 - I think 1.2 sounds reasonable.

Thank you,
Kathleen  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Sunday, December 11, 2011 2:23 PM
To: Black, David
Cc: [email-masked]
Subject: Re: [mile] AD review of draft-ietf-mile-rfc6046-bis

David,

spt

---

From: Brian Trammell <[email-masked]>
Date: Sun, 11 Dec 2011 21:24:17 +0100

Hi, Sean, David,

On the one hand, purely from a security and correctness-of-protocol standpoint, I agree. 

On the other hand, I'd hesitate to mandate not-yet-ubiquitously-implemented security technologies, as this may hinder deployment. This has been an issue in IPFIX, which mandated DTLS over SCTP as the default method for confidentiality and integrity in 2008, and which has never (to my knowledge) been interop'd -- AFAIK everyone who needs to run IPFIX on the open Internet uses TLS1.1 over TCP, which has the advantage that it's _really easy_ to get running. Granted, DTLS over SCTP was (and still is) way less widely supported than TLS1.2 is, but my experiences there would lead me to reformulate the question as follows:

Do the advantages of knowing you _never_ have to deal with TLS1.1 outweigh the difficulty of implementing 6046 over TLS1.2 right now?

I don't have an _answer_ to the question. It may be yes. I think it's worth asking though.

Best regards,

Brian (author hat)

On Dec 11, 2011, at 8:23 PM, Sean Turner wrote:

> David,
> 
> Hi.  I'm thinking that maybe we should require 1.2 not 1.1.  Before I became an AD I tried to knock over SSL 3.0, TLS 1.0, and TLS 1.1.  The argument for only knocking off SSL 3.0 was that there were so few servers actually implementing TLS 1.1 or 1.2.  At one point there were only two 1.2 server and I think they were both test servers.  Now, the tests conducted by Opera with their TLS prober show that there are many more TLS 1.2 servers.  Assuming an implementation of 6046 isn't a generic web server, why can't we go all the way to 1.2?
> 
> spt
>

---

From: <[email-masked]>
Date: Sun, 11 Dec 2011 17:35:38 -0500

Brian and Sean,

I wanted to get to at least TLS 1.1 as the minimum version for its improved security.  TLS 1.2 as the minimum version is fine with me, as long as it doesn't cause serious implementation problems - I'll defer to Kathleen on that, as she's more familiar with RID implementation efforts.

Thanks,
--David

> From: Brian Trammell [mailto:[email-masked]]
> Sent: Sunday, December 11, 2011 3:24 PM
> To: Sean Turner
> Cc: Black, David; [email-masked]
> On the other hand, I'd hesitate to mandate not-yet-ubiquitously-implemented security technologies, as
> this may hinder deployment. This has been an issue in IPFIX, which mandated DTLS over SCTP as the
> default method for confidentiality and integrity in 2008, and which has never (to my knowledge) been
> interop'd -- AFAIK everyone who needs to run IPFIX on the open Internet uses TLS1.1 over TCP, which
> has the advantage that it's _really easy_ to get running. Granted, DTLS over SCTP was (and still is)
> way less widely supported than TLS1.2 is, but my experiences there would lead me to reformulate the
> question as follows:
> 
> > Hi.  I'm thinking that maybe we should require 1.2 not 1.1.  Before I became an AD I tried to knock
> over SSL 3.0, TLS 1.0, and TLS 1.1.  The argument for only knocking off SSL 3.0 was that there were so
> few servers actually implementing TLS 1.1 or 1.2.  At one point there were only two 1.2 server and I
> think they were both test servers.  Now, the tests conducted by Opera with their TLS prober show that
> there are many more TLS 1.2 servers.  Assuming an implementation of 6046 isn't a generic web server,
> why can't we go all the way to 1.2?
> >
> > spt
> >
> >> I would hope that implementations are picking up "a widely available TLS library" that has TLS 1.1
> support - a "MUST" requirement to implement TLS 1.1 does seem reasonable, IMHO.
> >>
> >> Thanks,
> >> --David
> >>
> >>>> I've made most of these changes to an eventual -04 revision of the document; details or questions
> on
> >>> particular points inline, below.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Brian
> >>>>
> >>>>> Note that this requirement is going to require changes to most TLS implementations, but I bet
> you
> >>> knew that.
> >>>>

---

From: Sean Turner <[email-masked]>
Date: Sun, 11 Dec 2011 17:37:15 -0500

I'm curious to see what others think about this issue.

spt

---

From: <[email-masked]>
Date: Mon, 12 Dec 2011 09:20:28 -0500

Hello,

I thought the following might help to get opinions on whether or not to require TLS 1.2 support.

Are there any opinions from a development standpoint if it is reasonable to require TLS 1.2?  Is the support in toolkits (included below) adequate enough to require TLS 1.2 for the additional security gains?

SSL/TLS Toolkits:
The following has a comparison chart of TLS/SSL implementations (see second chart, most are listed as yes for TLS 1.2 support).
http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations

Open SSL does not have official support yet (the latest official version is 1.0.0e), but it is there is some support starting from release version 1.0.1-stable from the 'snapshot' section of their webpage.  From the OpenSSL changelog, it appears additional support was added between 1.0.1 and 1.1.0:
http://www.openssl.org/news/changelog.html

RID Implementations:
In terms of RID implementations, there is one available on the Internet.  I am not sure what version of IODEF/RID they are compatible with as there is no date on the one from Japan.  Changes would be required to match the new versions, RFC6045-bis and RFC6046-bis at a minimum.  If someone on the list is familiar with this development of IODEF/RID, could you let us know if it is believed to be compliant with RFC6045 and RFC6046 or later?

Japan Implementation of IODEF and RID:
http://www.ipa.go.jp/security/fy16/development/IODEF/api/index.html

I am aware of 3-4 different project where IODEF/RID is being implemented.  As far as I am aware, they are early enough that if TLS 1.2 is accessible, it could be used.
  
Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, December 11, 2011 5:36 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mile] AD review of draft-ietf-mile-rfc6046-bis

Brian and Sean,

Thanks,
--David

---

From: Brian Trammell <[email-masked]>
Date: Mon, 12 Dec 2011 16:15:52 +0100

Hi, Sean, all,

Would the following suggested text address the concerns about pointing out normative vs. informative sections, while avoiding language about conformance?

All sections which use the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" as defined in [RFC2119] are declared as normative, unless specifically noted otherwise. All normative sections MUST be followed by implementations of this standard. Sections which are not declared as normative are informative; these provide helpful background information and considerations for implementations. Specifically, the normative sections in this document are Section 2 and Section 3. 

Thanks, best regards,

Brian (author hat)

---

From: <[email-masked]>
Date: Mon, 12 Dec 2011 10:20:20 -0500

Hi Sean,

Here are some more details and thoughts ...

The improved security from TLS 1.0 to TLS 1.1 included removing "the vulnerability caused by use of an implicit IV for CBC-mode ciphers in prior versions of TLS and SSL."  That was a visible security improvement - in contrast, a quick scan of the TLS 1.2 change summary in RFC 5246 didn't turn up any security improvements that rise to that level, although there are a lot of functionality additions and design improvements.

One possible reason to go to TLS 1.2 is that TLS 1.1 is still using an MD5/SHA-1 hash pair internally for its PRF and handshake digital signatures.  That's a fixed algorithm pair, as there's no crypto agility for either of those functions in TLS 1.1, whereas TLS 1.2 is crypto-agile in both areas. Needless to say, those two hash functions don't have long lives ahead of them ;-).  OTOH, the PRF is not a concern, as both MD5 and SHA-1 are fine bit-mixers, and the handshake signatures shouldn't be a current concern because for a collision to cause problems there, the same collision has to collide for *both* MD5 and SHA-1 (not impossible, but definitely more difficult than colliding for just one of the hashes)

On balance, I'd be inclined to leave movement away from SHA-1 (currently has the stronger collision resistance of the two secure hashes) to other contexts/forums, but it could be encouraged here.  Hence, I'd be happy with:

	- MUST NOT use TLS 1.0 or any version of SSL
	- MUST implement TLS 1.1
	- SHOULD implement TLS 1.2
	- SHOULD prefer TLS 1.2 to TLS 1.1 when there is a choice

Thanks,
--David

> I wanted to get to at least TLS 1.1 as the minimum version for its improved security.  TLS 1.2 as the
> minimum version is fine with me, as long as it doesn't cause serious implementation problems - I'll
> defer to Kathleen on that, as she's more familiar with RID implementation efforts.
> 
> Thanks,
> --David
> 
> > >>> effort. Indeed, we hope that implementations based upon a widely available TLS library would
> have
> > been
> > >>> using 1.1 anyway.
> > >>>
> > >>> this point too). It seemed like a little much to _require_ SRV records (this gets into
> deployment-
> > time

---

From: SM <[email-masked]>
Date: Mon, 12 Dec 2011 11:30:10 -0800

Hi Brain,
At 07:15 12-12-2011, Brian Trammell wrote:
>Would the following suggested text address the concerns about 
>pointing out normative vs. informative sections, while avoiding 
>language about conformance?
>
>All sections which use the key words "MUST", "MUST NOT", "REQUIRED", 
>"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
>and "OPTIONAL" as defined in [RFC2119] are declared as normative, 
>unless specifically noted otherwise. All normative sections MUST be 
>followed by implementations of this standard. Sections which are not 
>declared as normative are informative; these provide helpful 
>background information and considerations for implementations. 
>Specifically, the normative sections in this document are Section 2 
>and Section 3.

Julian Reschke commented on the normative vs informative sections ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03936.html ).

I consider my comment as addressed.  Please read the comments below 
as editorial.

It's unusual to see wording similar you proposed above in 
RFCs.  Basically, if you want to see something implemented in a 
specific way, use a "MUST".  Fro example:

   "Consistent with BCP 56, RID systems listen for TCP connections
    on port 4590."

doesn't say that all RID systems will listen on tcp/4590.

  "Every RID system participating in a consortium MUST listen for
   HTTP/TLS connections on the assigned port."

In the above sentence, there is a requirement that every RID system 
must listen on tcp/4590.

RFC 2119 defines what are absolute requirements.  The following is 
not an absolete requirement:

  "For security purposes, RID systems SHOULD NOT return 3xx Redirection
   response codes"

However, your "normative sections MUST be followed by 
implementations" could be read as a "MUST NOT return 3xx Redirection".

Kathleen provided some background information about this document ( 
http://www.ietf.org/mail-archive/web/mile/current/msg00268.html 
).   Based on that, I'll suggest the following text in the Terminology section:

   Section 1 provides helpful background information.  RID systems
   participating in a consortium are required to fully implement
   Section 3 and Section 4 to prevent interoperability concerns.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Dec 2011 11:50:54 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, December 08, 2011 7:05 AM
> To: Murray S. Kucherawy; [email-masked]
> Subject: RE: [mile] AD review of draft-ietf-mile-rfc6046-bis
> 

Hi Kathleen,

> In my initial message to the list on this topic, I stated this is what
> was done in RFC6045, per recommendation from the Security AD at the
> time.  This advice turned out to be helpful later on, as this work
> (both RFC6045-bis and RFC6046-bis) is being adopted by the ITU-T.  The
> ITU-T is adding this document into their Cybersecurity Information
> Exchange (CYBEX) suite of techniques and protocols (Study Group
> 17/Question 4).  In August, a proposal was made to format the ITU-T
> documents, where they directly refer to the IETF RFCs.  In the
> proposal, the ITU-T document is essentially an outline that lists the
> section headers of the IETF document.  Within the outline, there is
> just a statement whether or not each section of the IETF document is
> considered normative or informative.  The interpretation at the ITU
> meeting (for how the drafts look now) matches our thinking - if there
> are RFC2119 terms and points essential for implementation, it is
> normative.

I find myself cringing a bit at the idea that we need to start adding this to our documents just because it makes life easier for other standards organizations, especially when it feels seriously redundant to me.  I suspect it feels redundant because perhaps ITU-T documents don't have RFC2119 or anything like it, so they have to make explicit statements like that.  Rather, they should do something like an Applicability Statement, which allows them to reference our RFCs but make normative adjustments as they see fit into their own contexts.

Naturally, I think our way is better.  :-)

Thanks for the background.  I guess I'd better get used to seeing this.

-MSK

---

From: <[email-masked]>
Date: Mon, 12 Dec 2011 15:04:22 -0500

Hi Murray,

We would like our interpretation to set the standard for the ITU-T when they list each section as normative/informative.  This is really so that we have a better chance of winding up with interoperable implementations (the IETF agreed as to what is normative/informative - the ITU goes through this evaluation as well).  As an FYI, the ITU does have an equivalent of RFC2119.  They use similar terms, but in documents prefer using shall instead of MUST and have some slight differences.  In the cases of the MILE documents, we have agreement to use the IETF terms since they are referencing the full document and not using the text from the RFCs in the body of the ITU recommendation.

Ideally, we will come up with something that works in each of our documents through this discussion.  I appreciate your help!

Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Monday, December 12, 2011 2:51 PM
To: [email-masked]
Subject: Re: [mile] AD review of draft-ietf-mile-rfc6046-bis

Hi Kathleen,

-MSK

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Dec 2011 09:05:05 -0500

On 12/12/11 2:30 PM, SM wrote:
>> Would the following suggested text address the concerns about pointing
>> out normative vs. informative sections, while avoiding language about
>> conformance?
>>
> I consider my comment as addressed. Please read the comments below as
> editorial.
>
> It's unusual to see wording similar you proposed above in RFCs.
> Basically, if you want to see something implemented in a specific way,
> use a "MUST". Fro example:
>
> In the above sentence, there is a requirement that every RID system must
> listen on tcp/4590.
>
> RFC 2119 defines what are absolute requirements. The following is not an
> absolete requirement:
>
> However, your "normative sections MUST be followed by implementations"
> could be read as a "MUST NOT return 3xx Redirection".
>
> http://www.ietf.org/mail-archive/web/mile/current/msg00268.html ). Based
> on that, I'll suggest the following text in the Terminology section:
>

I think I like this better.  Maybe we should make required/REQUIRED. 
Using this means we don't have to make the terminology and references 
sections "normative" in this bit and we really only talk about interop.

spt