Subject: [Nea] PT-TLS Ready for IESG Review

From: Stephen Hanna <[email-masked]>
Date: Fri, 11 May 2012 01:06:37 -0400

Stephen,

I'm pleased to say that PT-TLS (draft-ietf-nea-pt-tls-04.txt)
is ready for IESG evaluation. The NEA WG has reached consensus
on this document and now it's ready to go off and begin the
broader review and approval process, eventually to become a
Standards Track RFC.

I will be the Document Shepherd for this document. I have
attached a copy of the Document Shepherd Write-Up for it.
I look forward to working with you and with the document
editors as this document proceeds through the review and
approval process. With the cooperation and assistance of
the IETF community, I'm sure this will be a big success.

Thanks,

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 May 2012 13:08:20 +0100

Hi Steve,

My AD review of this is below. I think question 1
is the main one where I have a concern really, the
others are mostly not-quite-nits or things where I'm
just asking, or where there'd be an easy fix if
a change is needed.

I dunno if this will require a revised I-D or not.
I suspect it will, but will wait for your/the WG's
response before putting it in that state. Please
do argue about that if, having seen this review,
you think this doesn't require another rev.

(And if some of my questions are just dumb, then
do say, I'm quite used to that:-)

Cheers,
S.

Questions:

(1) 3.1.1, This says in one place "the NEA Client is
effectively acting as a TLS server" which I thought was
going to be more strongly deprecated or entirely removed?
While you do recommend (RECOMMEND is good 2119 language
btw) not doing that, it won't work in many cases, so is it
really worth keeping at all? How about just leaving in the
first and last paragraphs of 3.1.1? (Would need some more
edits to fix up, but all of those would simplify the
document overall.)

(2) 3.3, last sentence: this says "an attack" - is this
normative instruction meant to apply only for detected
Asokan attacks, or does it also apply for any other attack
at all, or for some others? For example, what if the TLS
handshake terminates fails for some reason not specifically
stated in this document? What if some new unexpected attack
on NEA is discovered - would this MUST apply to that? I
guess choices are to s/an attack/this attack/ if you just
want this to cover the Asokan attack, or if a more general
statement is desirable then maybe adding something
somewhere else would be right.

(3) 3.4.2: How do I know that the "TLS Setup" phase has
completed and how do I enforce the requirement that TLS
re-negotiation MUST NOT happen after that? The former seems
unclear unless it means "after the Finished exchanges" in
which case maybe say so. The latter seems tricky - will
current TLS implementations allow you to enforce that?

(4) 3.4.1.1: You do validation according to 5280 which is
fine.  But in 5280, revocation checking is optional. Do you
need to check revocation here? If you do, then do you need
to say that the NEA client might need to contact an OCSP
responder, or is some further profiling of how TLS and 5280
are used needed?  (e.g. OCSP stapling?) There are a bunch
of reasonable answers possible and I'm fine with any of 'em
(particularly whatever folks will implement:-) but I
suspect you may need to say a bit more here.

(5) 3.4.2.3 - The last sentence is a bit confusing - what
should happen if a "NEA protocol" may not be able to make
use of full-duplex? (And maybe s/protocol/implementation/?)
What do you do if you're one of those or talking to one of
those?

(6) 3.5: I don't think that enterprise numbers [1] are
restricted to 24 bits - those are OID arcs which are in
theory unlimited length. What happens if one is larger than
24bits? Reserving a number from that registry also probably
needs an IANA action, and who knows that might conflict
with something else.  I know you set this to zero but I'm
guessing vendors will use this as well or its used
elsewhere by NEA so I do wonder. This also affects 3.9.
(Nits on this as well: That might also be better stated as
"Implementations of this specification MUST..." just for
clarity. And it'd be good to put in a link or reference to
the IANA registry somewhere - not everyone knows what that
registry is I guess. Also, referring to 0 as an IETF SMI
Private Entreprise Number might raise a hackle, since
that's reserved in the IANA registry. Having said all that,
if you got this past in other NEA RFCs (didn't check) then
doing the same thing here is probably ok.)

	[1] http://www.iana.org/assignments/enterprise-numbers

(7) 3.5, Message Type. I don't understand what "MUST
interoperate with other parties despite any differences"
means here and suspect that that 2119 MUST isn't doable.

(8) 3.5, 6.2 Any "reserved" values should really be
mentioned in the IANA considerations section so IANA don't
go and give them out, I mean the 0xffff... ones.  "9+" is
also a bit odd in 6.2. You might want to change that to
specify the exact range "available for allocation by DE"
(or whatever is the right term) different from the
"reserved" value(s) there.

(9) 3.6, is it really ok for the "TLS session initiator" to
always be the one who proposes the versions in the version
request message? You still allow the NEA server to be the
TLS session initiator so what'd happen with this then is
confusing - the naughty client could get to pick the
weakest version of PT-TLS that the server supports?  3.7
also seems to contradict this, saying that the "PT-TLS
initiator" sends the version request. Maybe there is some
cleaning up needed here?

(10) 4.1, are you saying here that if any of these trust
relationships do not hold, then PT-TLS ought not be used?
If so, then saying that explicitly would be good. For
example, it could be that with some implementations, e.g.
that use less secure inter-proces communications, a bad
process on a client could invalidate some of these
assumptions, thus (maybe) making PT-TLS unsafe.

(11) section 5: do you mean the NEA client SHOULD (in 2119
terms) provide an indication here? If not, why not? If so,
what's the criteria for not providing that? (Perhaps if
there is no UI?) Same should/SHOULD question for the last
paragraph, i.e. s/should ensure/SHOULD ensure/ and what's
the exception?

(12) section 6: some of the intro text here is not really
for IANA, should it be moved elsewhere? (Mainly the
explanation of PEN handling, which might go up into 3.5
perhaps?)

(13) section 6.1: you're asking IANA to act as a repository
for non-RFC specifications (sort-of), I think that's maybe
an innovation (not sure) that should be checked out with
IANA, or maybe you've done that or know of a precedent?

(14) 6.2 & 6.3 - do you need to tell IANA or the DE that
entries with PEN value 0 need to be IETF stream RFCs,
or standards-track RFCs, or just RFCs or what? If you
want the DE to be able to add PEN=0 entries without
an RFC, I think saying that would be best.

(15) References: can we not make the reference to 4346 (TLS
1.1) informative and craft language to make that work? E.g.
say you SHOULD support TLS1.2 but that in reality a lot of
people still don't and are only doing 4346 as of now? I
think if you do that you can argue that TLS 1.1 is not
a normative reference and that'd be better in future once
most everyone has caught up with TLS1.2.

Nits:

- 1.4: Not sure its right to talk about the future actions
of some other organisation in such a definite manner.
Might be better to say that "the authors understand
that..." or some other weasel words, or even better would
be to refer to something the TCG have published if that's
possible.

- s2, 1st para: maybe s/should use/can use/ just to avoid
rfc 2119 confusion.

- 2.1, why use the "underlying carrier protocol" when only
TCP is covered here?

- 2.4, I'm not clear why this section is (still) needed.
It tries to say, but I don't get it. Did you once want to
control what ciphersuites could be used by TLS as part of
NEA? No problem with it staying though.

- 3.1.2, last sentence, s/must/MUST/? or s/must/needs to
be/?

- 3.4.2, s/normally starts/starts/ how else can it work?
Also not quite correct to say the connection triggers TLS
h/s - the sending/listening processes do that.

- 3.4.2.2: The end of this phase is also a little
ambiguous.  You say we're done when the NEA server has sent
an empty list of sasl mechanisms after all NEA client
authentications are done. But then you also say that the
NEA server can choose to not authenticate the client and
move on. But how would the client know that the PT-TLS
negotiation phase is over in that case? Ah, 3.8.3 clears
this up. Might be worth clarifying that a bit in 3.4.2.2.

- 3.5, Message Id. Since receivers have to handle roll
over, there doesn't seem to be a need for a MUST start at
zero, is there? And maybe you don't even really need the
MUST monotonically increasing either?  (Aside: I generally
prefer if senders can start randomly anyway, just in case
there's some message guessing threat - never any harm to
make that harder IMO.)

- 3.5, message length: your answer here is probably "no,"
which is fine, but I wondered if there's any useful
guidance about over-long messages that could be given? E.g.
could a NEA client try send a (number of) 2^31 byte
payload(s) to DoS the server in the hope that the server
would then fail-open?  (I note that the TLS plaintext max
is 2^14 bytes in one record, dunno if that might be a
factor here or not to be honest.)

- 3.6, seems off for a standards track RFC to distinguish
between production code and something else, maybe that
could be better phrased?

- 3.6, PB-TNC batch: total and utter nit:-) The reference
to section 4 of the PB-TNC spec is rendered with the wrong
URL in the tools.ietf.org version of the draft.
(Interpreted as a link to section 4 of this.) I think if
you added the RFC number for PB-TNC it might help there.

- 3.8, 2nd last para, maybe s/may require/MAY require/ ?

- 3.8.5.4, maybe s/may trigger/MAY trigger/ ?

- section 6, s/requests the IANA/requests that IANA/?

- 6.2, "Once this document becomes an RFC..." probably
ought be deleted. Easier if that's a separate paragraph
with an instruction to the RFC editor as to what to delete,
which is not all of the paragraph in this case I think.

---

From: Paul Sangster <[email-masked]>
Date: Thu, 17 May 2012 14:10:30 -0700

Stephen,

Thanks for all the great feedback, I suspect we would need to do a revision to address everything.  Let me respond to question 1 since its mentioned as the primary concern.  We've discussed the inbound NEA Server initiated assessments a few times and hadn't ever planned to remove it since it's such a useful feature.  Clearly its use comes with some risks that deployers need to account for with countermeasures.  Having that feature in the specification allows implementers and deployers to use that feature in a standards based way and an understanding of the risks.

Personally, I don't view the have every endpoint nail up the TCP connection to the NEA Server for re-assessments as a great solution for everyone (e.g. scaling issues, only usable by AAA server, ...).  Allowing customers particularly those with internal deployments inside the enterprise edge firewalls to have network infrastructure devices beside just the AAA server (e.g. compliance/conformance, patch management or security management tools) to reach out to the desktops and perform assessments when network security policies change or as urgent patches are released is a nice feature to allow.

Endpoint agents could accept only IPsec or TLS protected connections as a countermeasure against many forms of attack on the exposed ports.  Leaving the option in allows the deployer to decide what works best with their deployment (scale, product mix, threat model and goals).

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephen Farrell
> Sent: Thursday, May 17, 2012 5:08 AM
> To: Stephen Hanna
> Cc: [email-masked]
> Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04
> 
> 
> Hi Steve,
> 
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 18 May 2012 09:02:46 +0100

Hi Paul,

On question #1, I'm not sure we're talking about
quite the same issue.

My concern here isn't security related, its about the
complexity of allowing the NEA server to be the
TLS client. That causes the spec to be more complex
in a bunch of places, adds some work to both
implementations and adds complexity to deployments,
in that e.g. the NEA server TLS server cert now has
to also work as a TLS client cert if you want to
use this feature.

So my question is really whether the WG are sure
you want to keep this feature or not. If the answer
is "yes, we want to keep it" that's fine, I'll not
stop things moving ahead (I may have to hold my
nose a bit though;-).

S

---

From: Paul Sangster <[email-masked]>
Date: Fri, 18 May 2012 09:47:11 -0700

Thanks, I agree we were looking at different angles on this issue.  I personally do think it's worth leaving this feature in the protocol specification as it is very useful to provide an alternative to nailing up (potentially) huge numbers of connections to the AAA server and enabling for other network infrastructure devices to perform assessments (as discussed below).

However, I do appreciate that implementers of some products may not wish to address these issues, so I think it makes sense for it to be an optional to implement feature (particularly on the client). 

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Friday, May 18, 2012 1:03 AM
> To: Paul Sangster
> Cc: Stephen Hanna; [email-masked]
> Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04
> 
> 
> Hi Paul,
> 
> > Thanks for all the great feedback, I suspect we would need to do a
> revision to address everything.  Let me respond to question 1 since its
> mentioned as the primary concern.  We've discussed the inbound NEA
> Server initiated assessments a few times and hadn't ever planned to
> remove it since it's such a useful feature.  Clearly its use comes with
> some risks that deployers need to account for with countermeasures.
> Having that feature in the specification allows implementers and
> deployers to use that feature in a standards based way and an
> understanding of the risks.
> >
> > Personally, I don't view the have every endpoint nail up the TCP
> connection to the NEA Server for re-assessments as a great solution for
> everyone (e.g. scaling issues, only usable by AAA server, ...).
> Allowing customers particularly those with internal deployments inside
> the enterprise edge firewalls to have network infrastructure devices
> beside just the AAA server (e.g. compliance/conformance, patch
> management or security management tools) to reach out to the desktops
> and perform assessments when network security policies change or as
> urgent patches are released is a nice feature to allow.
> >
> > Endpoint agents could accept only IPsec or TLS protected connections
> as a countermeasure against many forms of attack on the exposed ports.
> Leaving the option in allows the deployer to decide what works best
> with their deployment (scale, product mix, threat model and goals).
> >
> > Paul
> >

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 22 May 2012 15:25:05 -0400

Stephen Farrell wrote:
> you want to keep this feature or not.

While server-initiated PT-TLS sessions are not my favorite
part of PT-TLS, this feature is clearly required by the use
cases in RFC 5209 (NEA Overview and Requirements). Section
6.2.2 of that spec describes several situations where the
NEA Server may need to initiate a reassessment: periodic,
event-based, and in response to policy updates. One way to
do this is to require each endpoint to always maintain a TLS
connection to a NEA Server. But this is a lot of overhead so
section 6.2.2.2 of RFC 5209 describes an approach where the
NEA Server reaches out to NEA Clients as needed.

This use case was agreed to by the NEA WG and the IETF and the
IESG more than four years ago. Clearly, it represented rough
consensus at the time. Since then, we've spent a good deal of
WG time creating this spec to meet the use case, including
changes just a few months ago to describe in more detail how
certificates should be handled for this case. The WG is well
aware of the ugliness involved.

Therefore, I conclude that we still have rough WG consensus in
favor of keeping server-initiated sessions as an optional
feature. Stephen, please let me know if you want me to run a
formal consensus check to verify this.

And thanks for all your careful review. This is a good issue
to raise. It's the least elegant part of the protocol and should
only be included if there's a driving reason to do so and a
strong WG consensus that we should include it. But I believe
based on what I've seen that we have both the reason and the
consensus.

Thanks,

Steve

> From: Paul Sangster [mailto:[email-masked]]
> Sent: Friday, May 18, 2012 12:47 PM
> To: Stephen Farrell
> Subject: RE: [Nea] AD review of draft-ietf-nea-pt-tls-04
>
> Thanks, I agree we were looking at different angles on this issue.  I
> personally do think it's worth leaving this feature in the protocol
> specification as it is very useful to provide an alternative to nailing
> up (potentially) huge numbers of connections to the AAA server and
> enabling for other network infrastructure devices to perform
> assessments (as discussed below).
>
> However, I do appreciate that implementers of some products may not
> wish to address these issues, so I think it makes sense for it to be an
> optional to implement feature (particularly on the client).
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 May 2012 20:41:54 +0100

That's fine Steve, like I said I wanted to check.

Can you get back to me as to whether any of the other questions warrant a revised I-D?

Cheers,
S

---

From: Paul Sangster <[email-masked]>
Date: Fri, 25 May 2012 19:12:33 -0700

Yes, I think it's worth doing an update before advancing the document to the IESG.  I'll respond to your comments to get the ball rolling.

> Sent: Tuesday, May 22, 2012 12:42 PM
> To: Stephen Hanna
> Cc: Paul Sangster; [email-masked]
> >>>>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >>> Of
> >>>>> Stephen Farrell

---

From: Paul Sangster <[email-masked]>
Date: Fri, 25 May 2012 19:45:09 -0700

> edits to fix up, but all of those would simplify the

[PS:] We already discussed this one

> somewhere else would be right.

[PS:] Agreed, this was about the Asokan attack so will make that more clear.

> current TLS implementations allow you to enforce that?

[PS:] Will clarity its after the Finished messages.  Yes we know of several implementations allowing the renegotiation to be disabled.

> suspect you may need to say a bit more here.

[PS:] Will mention that the NEA Client can optionally do revocation checking.

> What do you do if you're one of those or talking to one of

[PS:] Its referring to the higher level protocols on top of PT that might not support full-duplex (e.g. PB).  So we'll make that more clear.

> 	[1] http://www.iana.org/assignments/enterprise-numbers

[PS:] This approach is what we used in NEA's PA and PB protocols, so we're just staying consistent with that approach in PT-TLS.  So far the IANA has only assigned 16 bits worth of PEN so we should have ALONG time before we will exceed the 24 bits assuming a nearly sequential assignment of numbers.

> means here and suspect that that 2119 MUST isn't doable.

[PS:] Will reword these sentences.  This is about disallowing implementations to not interoperate with NEA complaints implements since they always require a vendor specific attribute to be used to do an assessment.

> "reserved" value(s) there.

[PS:] Agreed will describe the 0xffff... situation in the IANA considerations and make the 9+ into a to be assigned range.

> initiator" sends the version request. Maybe there is some

[PS:] The TLS session initiator offers a range of supported versions and the responder selects one to use.  If an initiator believe a version to be weak it shouldn't offer it in the range.  However if the initiator considers several versions to be acceptable it can offer them.  Right now we only have 1 version but if for some reason 1.0 is badly broken and 1.1 comes out with the fix, then initiators just offer 1.1.

> assumptions, thus (maybe) making PT-TLS unsafe.

[PS:] Will try to make this a little more clear.  Other countermeasures could be used if something in the trust model doesn't hold for an implementation/deployment.

> paragraph, i.e. s/should ensure/SHOULD ensure/ and what's

[PS:] Will change the SHOULDs. 
 
> explanation of PEN handling, which might go up into 3.5

[PS:] It was provided to provide context to the IANA on how the PEN is defining different name spaces since this will be visible in the repository.  The text is also discussed elsewhere in the document where implementers will see it.  This is the same text used in the other NEA RFCs.

> IANA, or maybe you've done that or know of a precedent?

[PS:] The IANA would just reference the permanent and readily available specification in the repository even if it's not an IETF document. I believe this was done in other NEA RFCs.

> an RFC, I think saying that would be best.

[PS:] We are following the RFC 5226 policies of "Specification Required" which says a 
"permanent and readily available" document must be defined.  This doesn't need to be an RFC.  This was thoroughly discussed by the WG in the past and agreed to for previous NEA RFCs.

> most everyone has caught up with TLS1.2.

[PS:] We discussed this a couple times in the working group and this was the suggested approach due to the lack of 1.2 implementations.  We need to have a MUST and it seems premature to have that be 1.2 as it might hold up implementations.  This represents the working group consensus.  Hopefully the downgraded reference isn't a show stopper for the IESG.

[PS:] If you are ok with the above responses, I'd be happy to put out another revision early next week so the document can continue to make progress.

Thanks,
Paul

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 26 May 2012 16:53:46 +0100

> [PS:] We already discussed this one

Ack.

> [PS:] Will clarity its after the Finished messages.  

Great.

> Yes we know of several implementations allowing the renegotiation to be disabled.

Disabled entirely or only after Finished? Doesn't the text
call for the latter. I'm a bit surprised that a TLS
implementation would support that, which do you mean?

> [PS:] Will mention that the NEA Client can optionally do revocation checking.

Ok. That means you gotta allow HTTP out from the
client in most cases though. Not sure what impact that might
have on the overall NEA setup.

> [PS:] Its referring to the higher level protocols on top of PT that might not support full-duplex (e.g. PB).  So we'll make that more clear.

Ok.

> [PS:] This approach is what we used in NEA's PA and PB protocols, so we're just staying consistent with that approach in PT-TLS.  So far the IANA has only assigned 16 bits worth of PEN so we should…

Fair enough. However I don't think there's anything calling
on IANA to allocate these sequentially so an e.g. 32 bit PEN
could be registered anytime. (Say if someone needed to align
numbering with some other space.) Your call as to whether to
say anything about this or not.

> [PS:] Will reword these sentences.  This is about disallowing implementations to not interoperate with NEA complaints implements since they always require a vendor specific attribute to be used to…

And unfortunately I also don't understand your explanation
either;-)

> [PS:] Agreed will describe the 0xffff... situation in the IANA considerations and make the 9+ into a to be assigned range.

Ack.

> [PS:] Will try to make this a little more clear.  Other countermeasures could be used if something in the trust model doesn't hold for an implementation/deployment.

I don't get your response addresses the question sorry.

> [PS:] Will change the SHOULDs. 

Ok. I'll look at the results of whatever change you mean:-)

> [PS:] It was provided to provide context to the IANA on how the PEN is defining different name spaces since this will be visible in the repository.  The text is also discussed elsewhere in the docu…

Ok. You may get other AD comments on this later but
we'll deal with 'em as they come.

> [PS:] The IANA would just reference the permanent and readily available specification in the repository even if it's not an IETF document. I believe this was done in other NEA RFCs.

This is the text I meant:

  "However, in this latter
   case, the vendor MUST supply a copy to the IANA and authorize
   the IANA to archive this copy and make it freely available to
   all if at some point the document becomes no longer freely
   available to all through other channels."

That's more than referencing, isn't it? But yes, its in
RFC 5793 all right, so leave it as is.

> "permanent and readily available" document must be defined.  This doesn't need to be an RFC.  This was thoroughly discussed by the WG in the past and agreed to for previous NEA RFCs.

But earlier (3.5) it said:

      If the PT-TLS Message Type Vendor ID field has the value zero
      (0), then the PT-TLS Message Type field contains an IETF Standard
      PT-TLS Message Type, as listed in the IANA registry.

"IETF standard" != "specification required" so the question stands.
(Could be that previous NEA RFCs contain this ambiguity, if it is
one. That would not mean we shouldn't fix it here.)

> [PS:] We discussed this a couple times in the working group and this was the suggested approach due to the lack of 1.2 implementations.  We need to have a MUST and it seems premature to have that b…

I get the concern but don't think this is quite the right
approach.

OAuth had the same concern and their solution might be on
to copy. [1]

   [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-1.6

> [PS:] If you are ok with the above responses, I'd be happy to put out another revision early next week so the document can continue to make progress.

Almost all will be fine, might need a bit more chatting on
a few. Your call if you wanna iterate those some more via email
or draft revision(s).

S

---

From: Paul Sangster <[email-masked]>
Date: Sun, 27 May 2012 10:01:24 -0700

Responses are in-lined...

> Sent: Saturday, May 26, 2012 8:54 AM
> To: Paul Sangster
> Cc: [email-masked]

[PS:] Yes, in our case its after the Finished messages.   OpenSSL and Java have registerable callbacks that could be used to achieve this.

> have on the overall NEA setup.

[PS:] Agreed, if the client isn't using a local CRL.  In this case, the client is already on the network and is being re-assessed so suspect the client already has HTTL access so this shouldn't be a problem for most deployments.

> > [PS:] Its referring to the higher level protocols on top of PT that
> might not support full-duplex (e.g. PB).  So we'll make that more clear.
>
> Ok.
>
> > [PS:] This approach is what we used in NEA's PA and PB protocols, so
> we're just staying consistent with that approach in PT-TLS.  So far the
> IANA has only assigned 16 bits worth of PEN so we should have ALONG
> time before we will exceed the 24 bits assuming a nearly sequential
> assignment of numbers.
>

[PS:] So are you suggesting we add text to the IANA considerations to highlight that we're counting on them continuing to do a sequential assignment of numbers so as to maximize the time the 24 bits will be sufficient?

> > [PS:] Will reword these sentences.  This is about disallowing
> implementations to not interoperate with NEA complaints implements
> since they always require a vendor specific attribute to be used to do
> an assessment.
>

[PS:] Re-reading I can see why :).  We're trying to avoid the situation where a vendor implements PT-TLS and claims to be compliant with the spec yet won't interoperate with other PT-TLS compliant implementations because they will only function after being given a vendor-specific attribute in the exchange.

> > [PS:] Agreed will describe the 0xffff... situation in the IANA
> considerations and make the 9+ into a to be assigned range.
>
> Ack.
>
> >>
> > [PS:] The TLS session initiator offers a range of supported versions
> and the responder selects one to use.  If an initiator believe a
> version to be weak it shouldn't offer it in the range.  However if the
> initiator considers several versions to be acceptable it can offer them.
> Right now we only have 1 version but if for some reason 1.0 is badly
> broken and 1.1 comes out with the fix, then initiators just offer 1.1.
> >
> >>
> > [PS:] Will try to make this a little more clear.  Other
> countermeasures could be used if something in the trust model doesn't
> hold for an implementation/deployment.
>

[PS:] Yes, I was agreeing with your comment and mentioning that the customer could have other mitigating controls or countermeasures that would still allow PT-TLS to be used.

> Ok. I'll look at the results of whatever change you mean:-)

[PS:] will change the "should" to "SHOULD" as you suggested if the software has a UI.

> > [PS:] It was provided to provide context to the IANA on how the PEN
> is defining different name spaces since this will be visible in the
> repository.  The text is also discussed elsewhere in the document where
> implementers will see it.  This is the same text used in the other NEA
> RFCs.
>

[PS:] Ok.  I don't recall PA or PB receiving IESG comments about this text but that was a few years ago.

> > [PS:] The IANA would just reference the permanent and readily
> available specification in the repository even if it's not an IETF
> document. I believe this was done in other NEA RFCs.
>
> > "permanent and readily available" document must be defined.  This
> doesn't need to be an RFC.  This was thoroughly discussed by the WG in
> the past and agreed to for previous NEA RFCs.
>

[PS:] Good point, maybe that should say "IETF namespace" instead of "IETF standard".

> > [PS:] We discussed this a couple times in the working group and this
> was the suggested approach due to the lack of 1.2 implementations.  We
> need to have a MUST and it seems premature to have that be 1.2 as it
> might hold up implementations.  This represents the working group
> consensus.  Hopefully the downgraded reference isn't a show stopper for
> the IESG.
>

[PS:] I don't have a problem with doing something more like this but of course it means we wouldn't have a MUST implement version of TLS which could cause interop issues.  Any objections to going this route?

>
> > [PS:] If you are ok with the above responses, I'd be happy to put out
> another revision early next week so the document can continue to make
> progress.
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 May 2012 23:14:52 +0100

Hi Paul,

Feel free to spin another rev whenever, I reckon we're
nearly there anyway.

I think the only remaining one is the PEN=0 IANA
consideration.

I'd be fine to issue the IETF LC with that outstanding
if need be, but better if we can get it sorted before
that. I'm not clear as to the precise intent of the
WG on this, so if folks could take a look that'd be
good. (That's issue 13 below)

Cheers,
S

> [PS:] Yes, in our case its after the Finished messages.   OpenSSL and Java have registerable callbacks that could be used to achieve this.

I'm still surprised that you can disable renego like that
after the Finished, but ok, let's see if someone reacts
to it during IETF LC.

> [PS:] So are you suggesting we add text to the IANA considerations to highlight that we're counting on them continuing to do a sequential assignment of numbers so as to maximize the time the 24 bit…

Not quite. The sequential allocation is a who-cares, but the
24 bit limit is worth noting maybe. Perhaps something along
the lines of "As with RFCs foo,bar we depend here on PEN's
being less than 24 bits wide, if IANA were to register a
wider PEN then that could not be used with NEA."

But as I said, it you wanna leave that out I won't yell
since its already the case for other RFCs.

> [PS:] Re-reading I can see why :).  We're trying to avoid the situation where a vendor implements PT-TLS and claims to be compliant with the spec yet won't interoperate with other PT-TLS compliant…

Ok, sounds like you really want to say "Implementations
MUST support foo,bar,baz featurs of this spec" somewhere.
But I guess see what re-wording seems to make sense to
you.

> [PS:] Yes, I was agreeing with your comment and mentioning that the customer could have other mitigating controls or countermeasures that would still allow PT-TLS to be used.

Ah. Gotcha. Sounds fine.

> [PS:] will change the "should" to "SHOULD" as you suggested if the software has a UI.

Ok

> [PS:] Good point, maybe that should say "IETF namespace" instead of "IETF standard".

Well, I guess its just a matter of getting whatever is
the intent written down precisely, which can sometimes
show up some ambiguity in the intent:-)

The question here is does the specification required rule
apply to the addition of new entries with PEN=0? If yes,
then that's not an IETF namespace either since TCG or
whoever could do that. If no, then what rule does apply?

> [PS:] I don't have a problem with doing something more like this but of course it means we wouldn't have a MUST implement version of TLS which could cause interop issues.  Any objections to going t…

Yep, its weasel words regardless. Weasel words with precedent
are probably better, much though I don't like 'em. (Note that
the WG decision here is sensible, but unfortunate.)

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 May 2012 11:23:34 +0100

> good. (That's issue 13 below)

Oops. Its actually issue 14;-)

S

---

From: Paul Sangster <[email-masked]>
Date: Tue, 29 May 2012 13:16:30 -0700

I'll work to get out an revision ASAP.  Just a final comment on the thread below...

> Sent: Tuesday, May 29, 2012 3:24 AM
> To: [email-masked]
> Cc: Paul Sangster
 
<snip>

> > show up some ambiguity in the intent:-)

[PS:] PA-TNC RFC did a little more complete job of explaining the namespace intentions.  Please take a look at RFC 5792 sections 2.1 and 2.2 and let us know whether you think those should be referenced (or duplicated in) PT-TLS.  The approach we're discussing is used by both PA-TNC and PB-TNC.

> > whoever could do that. If no, then what rule does apply?

[PS:] "For all of the IANA registries defined by this specification, new values are added to the registry by Expert Review with Specification Required, using the Designated Expert process defined in RFC 5226 [RFC5226]."  

If it helps we can stop referring the PT-TLS PEN=0 namespace as "IETF standard" and just informally call it the IETF's namespace since values using this namespace will at least have been expert reviewed in the IETF.

<Snip>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 May 2012 22:03:36 +0100

Hiya,

> [PS:] PA-TNC RFC did a little more complete job of explaining the namespace intentions.  Please take a look at RFC 5792 sections 2.1 and 2.2 and let us know whether you think those should be refere…

Aha! Precedent is enough to be going on with:-) Maybe
just stick with what you have and refer back to that
saying "same as there."

> If it helps we can stop referring the PT-TLS PEN=0 namespace as "IETF standard" and just informally call it the IETF's namespace since values using this namespace will at least have been expert rev…

Not saying "IETF standard" would have been better but if its
it other NEA RFCs then probably as well to stick with it.
Maybe add an explanatory sentence.

Cheers,
S.