Using TLS in Applications
charter-ietf-uta-01

[Ballot comment]
I second Spencer's comment—I have no idea what "definitions" means in that bullet item. :)

Otherwise I am enthusiastically in favor of this work being done.

[Ballot comment]
- Consider, and possibly define, a standard way for an application client and
server to use unauthenticated encryption through TLS when server and/or client
authentication cannot be achieved.

I guess the tradeoff of unauthenticated encryption will be documented. Maybe it's so obvious that we don't need to mention that in the charter ... No strong feeling about this.

[Ballot comment]
In this text: This WG has the following tasks:

- Update the definitions for using TLS over a set of representative application
protocols.

would it be helpful to say where these definitions are now? If they are in some RFC nnnn, perhaps it's helpful to say "updating the definitions in RFC nnnn".

[Ballot comment]
- I'd really like the charter to explicitly call out server-to-server unauthenticated encryption as a work item.

- I'm bummed that the unauthenticated client-to-server item was softened to "consider", and would like to understand why that is necessary.

[Ballot comment]
Yes I said yes as a Mrs. Bloom once said:-)

Thanks Barry for those changes - they're good improvements.

One more suggestion, nowhere near blocking for now:

OLD:

  Internal changes to TLS will be made
  only in concert with and agreement from the TLS working group.

NEW:

  No changes to TLS itself will be made in this WG, and the WG
  will ensure that changes to current versions of popular TLS libaries
  will not be required to conform to the WG's specifications.

I really don't see why this WG would need to or should make any
internal changes to TLS. The TLS_PSK one is not such a change
and would be outside a libary, as would the others I believe.
I'm fine if we raise this topic during external review though.

[Ballot comment]
Note that there's a storm in httpbis as they discuss doing this with HTTP 2.0.  This charter is looking at best practices for HTTP 1.1, *not* for anything related to 2.0.

[Ballot comment]
Note that there's a storm in httpbis as they discuss doing this with HTTP 2.0.  This charter is looking at best practices for HTTP 1.1, *not* for anything related to 2.0.  I'll be editing the proposal soon to say that, and to address Stephen's comments.

[Ballot comment]
Yes I said yes as a Mrs. Bloom once said:-)

- I'd delete the 3rd bullet or at least s/Define a/If necessary, define a/
since I don't think this will be needed really, and would be better
not done. (The exception being a possible well-known TLS-PSK
value.)

- Maybe add "and no internal changes to TLS that would affect
a library implementation" in the 2nd last para.

- I'd add something somewhere to give a sense of urgency to
something. I don't much care what, but that sense should be
there.