Re: [TLS] backwards compatibility section updates

Brian Smith <brian@briansmith.org> Sun, 28 December 2014 17:16 UTC

MIME-Version: 1.0
In-Reply-To: <201412280713.10015.davemgarrett@gmail.com>
References: <201412280713.10015.davemgarrett@gmail.com>
Date: Sun, 28 Dec 2014 09:15:22 -0800
Message-ID: <CAFewVt6tFvRs79J7LtcGqgVYFG7eu7O+wxbEVgEBh7vs-TDLUA@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4eeJd5RuqKpipRq9WXxgiZKEOGg
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] backwards compatibility section updates
Precedence: list

Dave Garrett <davemgarrett@gmail.com> wrote:
> Suggestions for other things that might be warranted to add:
>
> 1) Require SCSV?

No. Anything related to non-secure fallback should be put in the
separate downgrade-scsv draft, and not in the TLS specification, since
implementations shouldn't be doing the non-secure downgrade anyway.

> 2) Require/recommend Encrypt-then-MAC on fallback?

No. The TLS 1.3 spec should focus on specifying TLS 1.3, which doesn't
allow CBC-mode cipher suites. Another document can deal with
recommending Encrypt-then-MAC.

> 3) Add note about ClientHello length bug in certain implementations?
>     (what officially happened to the padding extension?)

IIUC, F5 servers that have the ClientHello length bug probably also
have the POODLE bug, so a client implementing the padding extension
may actually be a loss for security. Also, some Cisco server
implementations do not work with the padding extension. So, I don't
think it makes sense to recommend the padding extension in the spec.

Cheers,
Brian

[TLS] backwards compatibility section updates Dave Garrett
Re: [TLS] backwards compatibility section updates Brian Smith