Hi folks,
Please take a look at the following PR which documents a suggestion
made by Karthik Bhargavan about how to prevent protection against
downgrade against downgrade from TLS 1.3 to TLS 1.2 and below.
https://github.com/tlswg/tls13-spec/pull/284
The idea is that if a TLS 1.3 server recei
A few more words on this proposal.
- The goal is to protect TLS 1.3 clients and servers from attacks on TLS 1.*
ciphersuites.
E.g. if a new attack on the MD5 | SHA1 concatenation in TLS 1.0 is
announced,
connections between TLS 1.3 clients and servers would still be protected.
Similarl
On Fri, 09 Oct 2015 12:48:38 -, Karthikeyan Bhargavan
wrote:
- We note that RSA ciphersuites already provide a version downgrade
mitigation,
although it has itself caused many headaches due to bleichenbacher
attacks.
But if a server implements good side-channel resistance to
blei
> For reference, the version field in the TLS premaster secret is not checked
> by many servers, IIRC some of them have large market shares.
That’s good to know. It would be tempting to recommend that TLS 1.3 servers
disable RSA (encryption) ciphersuites for all protocol versions, but I guess
On Fri, Oct 9, 2015 at 3:09 PM, Karthikeyan Bhargavan <
karthik.bharga...@gmail.com> wrote:
>
> > For reference, the version field in the TLS premaster secret is not
> checked by many servers, IIRC some of them have large market shares.
>
> That’s good to know. It would be tempting to recommend th
On Oct 9, 2015, at 8:48 AM, Karthikeyan Bhargavan
mailto:karthik.bharga...@gmail.com>> wrote:
- There is a 1/(2^N) chance that valid connections to TLS 1.2 servers will be
dropped by
TLS 1.3 clients, because of this proposal. This only happens for servers
that do not
use the unix timest
On Fri, Oct 9, 2015 at 3:23 PM, Short, Todd wrote:
>
>
> On Oct 9, 2015, at 8:48 AM, Karthikeyan Bhargavan <
> karthik.bharga...@gmail.com> wrote:
>
> - There is a 1/(2^N) chance that valid connections to TLS 1.2 servers will
> be dropped by
>TLS 1.3 clients, because of this proposal. This on
On Fri, Oct 09, 2015 at 02:23:30PM +0200, Eric Rescorla wrote:
> Hi folks,
>
> Please take a look at the following PR which documents a suggestion
> made by Karthik Bhargavan about how to prevent protection against
> downgrade against downgrade from TLS 1.3 to TLS 1.2 and below.
>
> https://gi
The chairs have read through this thread and do not see any new information
that would cause the working group to reconsider the decision to remove
compression from TLS 1.3. Discussions about clarifying the language and
intent of the document are OK.
Thanks,
J&S
On Thu, Oct 8, 2015 at 6:42 PM,
Joseph Salowey wrote:
>
> The chairs have read through this thread and do not see any new information
> that would cause the working group to reconsider the decision to remove
> compression from TLS 1.3.
I am (and I was) perfectly fine with removing compression from TLSv1.3.
(btw. our own implemen
On Friday, October 09, 2015 12:49:02 pm Viktor Dukhovni wrote:
> I think this is "too clever" (a "hack" not a design) and offers
Every fix to an issue in this 20 year old protocol will be a hack.
> incomplete protection (does nothing to protect RSA key transport).
Better than none, for a very lo
It's largely arbitrary, but the reasoning is as follows. There are
apparently
some TLS 1.2 servers which randomly generate the entire server random
(and https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00 would
encourage more to do so). The chance of a false positive between such
a server
On Fri, Oct 09, 2015 at 10:23:09PM +0200, Eric Rescorla wrote:
> It's largely arbitrary, but the reasoning is as follows. There are
> apparently some TLS 1.2 servers which randomly generate the entire server
> random (and https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00
> would
> enc
On Friday, October 09, 2015 04:38:00 pm Viktor Dukhovni wrote:
> So even 2^{-48} is perhaps not quite low enough.
Going to a full 64-bit looks like a good idea to me. The loss of those 4 bytes
of entropy for old versions isn't likely to matter at all, though, please
correct me if someone thinks
> It's largely arbitrary, but the reasoning is as follows.
And so that we can put "TLS1.3" as the six bytes in UTF-8.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Watson Ladd wrote:
>
> Why is it important that clients be permitted to signal support for
> compression and TLS 1.3 conditionally? Remember, we also want to phase
> out the use of compression in TLS 1.2.
compression in TLS is *NOT* generally bad, and not generally a problem.
It may be a problem
On Fri, Oct 9, 2015 at 2:23 AM, Eric Rescorla wrote:
> Please take a look at the following PR which documents a suggestion
> made by Karthik Bhargavan about how to prevent protection against
> downgrade against downgrade from TLS 1.3 to TLS 1.2 and below.
>
> https://github.com/tlswg/tls13-spec
> 1. Why would the server ever receive a TLS 1.2 or below ClientHello from a
> client that supports TLS 1.3? Why doesn't the already-standardized downgrade
> SCSV mechanism work for those cases?
The attack we’re protecting against is the following:
- a TLS 1.3 client sends a client hello and the
18 matches
Mail list logo
