Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt

[Sean Turner <[e-mail]>]

On 9/8/13 4:25 AM, Yaron Sheffer wrote:
> This is an early version of my proposal for a BCP-like document, to
> inform the industry on what can be done with existing implementations,
> while TLS 1.3 is still not ready.
>
> I would appreciate your comments of course. Specifically,
> I would like to fill in the Implementation Status table (Sec. 5) and
> would be glad to receive solid information (dates, planned dates,
> version numbers) from implementers.
>
> Thanks,
>      Yaron

Yaron,

Thanks for this draft, I'm supportive of it, and hope that the WG adopts 
it.  They've not had a history of adopting algorithm drafts, but this is 
one I think they should strongly consider adopting especially because it 
impacts the base specification.

A couple of things come to mind:

1. TLS isn't just used by browsers, but Brian Smith is also proposing 
some changes to the cipher suites offered by browsers 
(https://briansmith.org/browser-ciphersuites-01.html).  It'd be good to 
review those recommendations especially since he's recommending a few 
TLS_ECDHE suites ahead of TLS_DHE suites (assuming I'm reading the 
recommendation properly).  Also note that there's some information about 
implementation support there as well.

2. An implication of your draft is that version TLS 1.2 is preferred 
over other TLS versions.  That is kind of already done with the 
obsoletes trail from 1.0 to 1.1 to 1.2, but maybe it's time to dust off 
the issue of whether it's worth providing guidance on SHOULD NOT use SSL 
3.0/ TLS version 1.0/1.1.  Two caveats: 1) Unsure if it is practical to 
knock off older versions based on an algorithm recommendation given the 
deployment numbers, and 2) I'm also not sure this kind of recommendation 
needs to go in this draft.

3. (not specific to the draft) Going forward for TLS 1.3 maybe we should 
consider splitting out the MTI algorithms from the base specification so 
that we can update the MTIs on a regular basis without having to revise 
the base specification, which is what IPsec, S/MIME, PKIX, etc. have done.

4. I like Stephen's idea of explaining why PFS is needed.  Note that 
there's some information in RFC 4949 about PFS that you could start from.

5. Providing BCP algorithms for earlier TLS versions is okay in my mind 
essentially because those versions are still out there.

6. I'm torn on the idea of adding an appendix on how to 
add/remove/configure algorithms.  If it's information that's not readily 
available then I'd say it'd be worth documenting, but whether it goes in 
this draft or another I'd leave to the authors/wg.  (i.e., not sure we'd 
need to have a death match over the commands to input to apache to get 
this draft done)

On the procedural notes:

1. Don't worry about whether the draft's intended status is BCP or 
standards track.  I'd have no problem sponsoring it regardless; I've 
been down this path before, BCPs can document what is being done already 
or what we want to done now and in the future.

2. Feel free to use 2119 language, but depending on how you write it it 
might not be necessary.

spt