Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string.

On Dec 27, 2014 11:50 AM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> On 12/24/2014 4:01 PM, Eric Rescorla wrote:
>>
>>
>>> > >
>>> > > That is, it would be digital signature of:
>>> > >
>>> > > - 32 padding bytes (or ClientRandom)
>>> > > - 32 padding bytes (or ServerRandom)
>>> > > - Context string
>>> > > - Ciphersuite ID (to provode domain separation)
>>> > > - handshake_hash(transcript)
>>> > >
>>> >
>>> > So to be clear, you are proposing that we might (for instance) have
>>> > a signature with (say) SHA-1 over a handshake hash computed with
>>> > SHA-256?
>>>
>>> Yes.
>>>
>>> E.g ECDSA/SHA1 for signatures and
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>>> for connection. That would result in SHA-1 signature over SHA-256 hash.
>>>
>>>
>>> The other way around can't happen with any current ciphersuite (because
>>> every current one has prf-hash of either SHA-256 or SHA-384).
>>
>>
>> Thanks for the clarification. What do other people think about this
suggestion?
>>
>> -Ekr
>
>
> Three items -
>
> Doing it this way means that SHA1 is a permanent part of TLS1.3 - every
implementation will need it.  It also means that the security of the
handshake transcript part is no better than that given by SHA1 so if
further attacks on SHA1 are discovered, the fix will be TLS1.4.  That
applies regardless of which hash we select.   That said, SHA256 is probably
a better choice that SHA1 given that SHA1 is deprecated for signatures
[while this isn't exactly using it in signatures, I will note that  ECDSA
(SHA256(SHA1(data)) has the same strength as ECDSA(SHA1(data)) - I would
have to think a bit whether the addition of the 4 possibly fixed (or
chosen) elements would increase the security back to SHA256 levels]

I think you are misreading. A certificate may use SHA1 as a supported
signing algorithm, while SHA256 is the PRF. In short the order got flipped
around, or I misread AGL's proposal/example.

The reason for this proposal is a known weakness in TLS 1.2 that narrowly
escaped being a vulnerability.

>
> If the client is willing to negotiate to TLS1.2, the client will still
need to run multiple hashes in parallel until it gets the tls version
selection confirmation (and the cipher suite selection) from the server as
we're not changing how the TLS1.2 signature is calculated.
>
> Lastly, if we do the above, please add a uint32 length(transcript) value
before handshake_hash(transcript) to at least make extension attacks a bit
more difficult.

This doesn't make any sense. We're talking about signatures, not PRF MAC.
Length extension doesn't matter.

>
>
>
> Mike
>
>
>
>>
>>>
>>>
>>>
>>>
>>> -Ilari
>>
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>