Re: [TLS] CCS and key reset and renegotiation

Nico Williams <nico@cryptonector.com> Thu, 05 June 2014 16:27 UTC

MIME-Version: 1.0
In-Reply-To: <CABkgnnUD0vnt+pNgwMh4Hcq+DroncdDE87cJ7de+wsUB67=JKQ@mail.gmail.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> <CACsn0c=O5Xp82JqsxXsik+4NEG5h-0HSJ-NM1zhywJVg_oX1Dg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F4349C2@USMBX1.msg.corp.akamai.com> <CABkgnnUD0vnt+pNgwMh4Hcq+DroncdDE87cJ7de+wsUB67=JKQ@mail.gmail.com>
Date: Thu, 05 Jun 2014 11:27:18 -0500
Message-ID: <CAK3OfOhrKNiz7oKqWGWKxVB891LfuZMEuvHT1-VsROPX-fLUDw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n4PTnsE9YRvb-ohnAhRvxVLUYE0
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] CCS and key reset and renegotiation
Precedence: list

On Thu, Jun 5, 2014 at 10:53 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 5 June 2014 08:41, Salz, Rich <rsalz@akamai.com> wrote:
>>> I don't see why the incompetence of implementors should govern our
>>> decisions. If something cannot be implemented correctly it must be removed,
>>> but why is rekeying such a thing?
>>
>> Because the line between “often get it wrong” and “cannot be implemented” is
>> often a very thin one and it’s better to be cautious and safe, then
>> pedantically correct and usually broken.
>
>
> I tend to agree with Watson here.  This is a problem that happens
> during the initial handshake only.  Maybe we can design the handshake
> to ensure that CCS cannot be abused for TLS 1.3.  But I don't see how
> this vulnerability extends to subsequent handshakes or rekeying
> exchanges.

A single bit of state was not kept or checked.  How do we prevent that
sort of implementation bug with protocol design?  How could we prevent
the goto fail bug with protocol design?  (Well, DANE helps, to be
sure, by cutting out the PKIX.  But really, even then there will be
plenty of opportunities to commit bugs of these types.)

At some point using silly implementation bugs as a justification for
protocol design decisions... will probably lead to bad protocol design
decisions.

There are cases where I think that protocol design decisions do impact
implementation quality.  For example, using ASN.1 w/ BER/DER/CER in
new protocols is asking for trouble because a) cheap tooling is still
not widely available, b) BER is very redundant, and redundancy doesn't
help programmers get it right.  ASN.1 w/ PER, or XDR -- these are
superior to BER.

Nico
--

Re: [TLS] CCS and key reset and renegotiation Viktor Dukhovni
[TLS] CCS and key reset and renegotiation Salz, Rich
Re: [TLS] CCS and key reset and renegotiation Watson Ladd
Re: [TLS] CCS and key reset and renegotiation Nico Williams
Re: [TLS] CCS and key reset and renegotiation Salz, Rich
Re: [TLS] CCS and key reset and renegotiation Martin Thomson
Re: [TLS] CCS and key reset and renegotiation Peter Gutmann
Re: [TLS] CCS and key reset and renegotiation Watson Ladd
Re: [TLS] CCS and key reset and renegotiation Nico Williams
Re: [TLS] CCS and key reset and renegotiation Viktor Dukhovni
Re: [TLS] CCS and key reset and renegotiation Yoav Nir
Re: [TLS] CCS and key reset and renegotiation Viktor Dukhovni
Re: [TLS] CCS and key reset and renegotiation Yoav Nir
Re: [TLS] CCS and key reset and renegotiation Jeffrey Walton
Re: [TLS] CCS and key reset and renegotiation Peter Gutmann
Re: [TLS] CCS and key reset and renegotiation Watson Ladd
Re: [TLS] CCS and key reset and renegotiation Salz, Rich
Re: [TLS] CCS and key reset and renegotiation Watson Ladd
Re: [TLS] CCS and key reset and renegotiation Salz, Rich
Re: [TLS] CCS and key reset and renegotiation Paul Lambert
Re: [TLS] CCS and key reset and renegotiation Salz, Rich
Re: [TLS] CCS and key reset and renegotiation Peter Gutmann
Re: [TLS] CCS and key reset and renegotiation Michael StJohns