[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] advertizing the minimum TLS supported version [was: Last Call: <draft-ietf-tls-downgrade-s
From:       Michael Clark <michael () metaparadigm ! com>
Date:       2015-01-22 11:06:31
Message-ID: 54C0D9B7.2000000 () metaparadigm ! com
[Download RAW message or body]

On 22/1/15 6:40 pm, Michael Clark wrote:
> On 22/1/15 6:24 pm, Nikos Mavrogiannopoulos wrote:
>> On Thu, 2015-01-22 at 18:11 +0800, Michael Clark wrote:
>>>> 3. Forbidding SSL 3.0 version from the record layer breaks perfectly
>>>> valid clients, which advertise TLS 1.2. These clients can only use a
>>>> variant of fallback dance to connect to broken servers which impose
>>>> those limits. Please _DON'T CREATE MORE REASONS FOR FALLBACK DANCES_.
>>> OK. Then an extension to indicate supported versions would in fact be an
>>> improvement as it would be protected by verify_data.
>>
>> Some time ago, I had proposed a method for clients to advertise the list
>> of protocols they support, for the same reason. To allow the server to
>> fallback to their preferred protocol:
>> https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-more-extensions-00#section-4
> 
> Good idea. Thanks I understand now. More logical than SCSV to have the
> minimum version in the handshake hash.


I would audit the handshake hash in an open implementation to be certain
and (based on new information in *my head* at least):

a) support Nikos proposal to advertise the list of protocols as
   a better short/medium term mitigation in preference to SCSV as
   this is the real issue. We could easily make the SCSV mistake if
   we were unaware of the handshake hash construction. I did.

b) TLSv1.3 in the medium to long should authenticate the entire
   handshake. There shouldn't be any unauthenticated bytes that
   can be tampered with. This would be in concert with reviewing
   verify_data_length and the 12 octet and the wording that defers
   to the cipher suite to increase it, but then they don't.
   TLSv1.3 could address this in a more permanent way.

So the thought experiment still stands, rather we made a false
assumption on authentication of the handshake. Some bytes can
be tampered with.

I will be reading (Open|Boring)SSL code to make sure. The reality
is however that when I reasoned from the spec, I saw hash(handshake)
but I did not see the wording that specified whether this is
the content of the handshake record or the whole record. I will look
for the wording in the spec. If it is there and specifies only the
content then it is a little mistake (for some value of little).

The reasoning in my prior email still stands despite the *pivot*
on the knowledge of the handshake hash construction.

I will read code...


[prev in list] [next in list] [prev in thread] [next in thread]