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

[Yaron Sheffer <[e-mail]>]

Hi Sean,

Thanks for your review. Please see my comments below.

	Yaron

On 09/17/2013 06:08 PM, Sean Turner wrote:
> On 9/8/13 4:25 AM, Yaron Sheffer wrote:
[...]
>
> 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.

Thanks for pointing it out. It is very useful. And it agrees on the #1 
cipher suite with our upcoming -01 (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).

>
> 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.

TLS 1.2 is sort-of implicit in the draft. Also, there have been 
proposals to backport GCM to 1.0 and 1.1. I'm not sure if it makes sense 
(vs. wholesale transition to 1.2), but if that happens, fine.

>
> 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.
>

I agree.
> 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.
>

Ralph contributed excellent text on PFS for -01.

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

Except that nobody wants to come forward with a proposal for such 
algorithms, because so much is unfortunately broken. E.g. I don't think 
you can recommend AES-CBC without some of the mitigations people have 
implemented.

>
> 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)

I simply don't have the time to do it. But here's someone who did: 
http://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/

>
> On the procedural notes:

Let's go into this when we discuss WG adoption. Currently the draft is 
strictly lower case.

>
> 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