[TLS] Fwd: TLS Digest, Vol 134, Issue 12

[Sankalp Bagaria <[e-mail]>]

Hello,

Truncating 20-byte hash to one byte is NOT a good idea since this would result
in ONLY 255 (2^8 - 1) unique certificates to be identified. This will result in
many certificates sharing the same 1-byte hash ie, 2^160 certificates are mapped
to the 255 1-byte hash. This is NOT desirable and collision may occur.

It is true that the hash, in this case, is not used for cryptographic purpose
but to simply identify the right cached certificate at the server. But, same
hash-truncated-to-one-byte may be assigned to two or more certificates at the
server. Chances of all certificates being unique at the server side is
255*254*253*....*(255-n+1) where n is the total number of certificates at the
server side. That means, chances of two certificates at server - side having
same hash-truncated-to-one-byte is (1-
(255/255)*(254/255)*(253/255)*...*((255-n+1)/255)). It is a small quantity
(approx. 0.005) but not negligible.

The problem occurs if wrong certificate is chosen at the server side. This may
be avoided by:
1) Sending a full 20-byte hash or hash truncated to a larger number than just
one byte
2) Detecting whether two certificates have same 1-byte hash at the server side
and requesting a full Handshake in such cases.

Thanks and Regards,
Sankalp Bagaria.


---------- Forwarded message ----------
From: <[e-mail] <mailto:[e-mail]> >
Date: Fri, Sep 11, 2015 at 12:30 AM
Subject: TLS Digest, Vol 134, Issue 12
To: [e-mail] <mailto:[e-mail]>


Send TLS mailing list submissions to
        [e-mail] <mailto:[e-mail]>

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
or, via email, send a message with subject or body 'help' to
        [e-mail] <mailto:[e-mail]>

You can reach the person managing the list at
        [e-mail] <mailto:[e-mail]>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of TLS digest..."


Today's Topics:

   1. Re:  WGLC for draft-ietf-tls-cached-info-19 (Hannes Tschofenig)
   2. Re:  WGLC for draft-ietf-tls-cached-info-19 (Martin Thomson)


----------------------------------------------------------------------

Message: 1
Date: Thu, 10 Sep 2015 13:14:52 +0200
From: Hannes Tschofenig < [e-mail]
<mailto:[e-mail]> >
To: Martin Thomson < [e-mail] <mailto:[e-mail]>
>
Cc: " [e-mail] <mailto:[e-mail]> " < [e-mail] <mailto:[e-mail]>
>
Subject: Re: [TLS] WGLC for draft-ietf-tls-cached-info-19
Message-ID: < [e-mail] <mailto:[e-mail]> >
Content-Type: text/plain; charset="utf-8"

Hi Martin,

thanks for your feedback. I have discussed the topic with my co-worker
Manuel.

Another way of seeing the use of the hash by the client is to help the
server to select the pick certificate (or other cached data). It does
not have a security purpose as such, it is only a way to prevent the
server accidentally including the wrong information. For example, this
can happen when the server has multiple certificates to choose from then
it should pick the right one (and I am not talking about the SNI case
here).

Without the possibility for picking the wrong value we could have as
well omitted the hash altogether. The actual function used to compete
the fingerprint isn't that important as long as it helps to make sure
that the correct value can be chosen with a reasonable probably. In the
worst case, the wrong value is chosen and the exchange failed. The
client will then have to re-start the exchange without the cached info
feature.

As such, you are certainly right that the hash does not need to be long
since the changes of selecting the wrong information is very low. In
case of the certificate the security actually comes from the private
key: the server needs to demonstrate that it knows the privacy key in
the exchange.

Regarding the use of the TLS PRF I am not sure that this will work since
the actual function is the result of the negotiated cipher and not known
at the time when the client and the server exchange their hello messages.

Ciao
Hannes

PS: Additing extra text with information about what is included in the
hash will be added to make sure that implementers compute the hash over
the correct fields of the message.


On 08/24/2015 08:35 PM, Martin Thomson wrote:
> Hi Hannes,
>
> On 24 August 2015 at 09:38, Hannes Tschofenig < [e-mail]
> <mailto:[e-mail]> > wrote:
>>> I'd like to see the document explicitly note that msg_type and length
>>> from the handshake message are not covered by the hash.  The
>>> description of what is covered is a little too terse (and badly
>>> formatted).
>>
>> There are multiple message type / message length fields included in the
>> message and I am not sure which of those you rare referring to.
>>
>> The msg_type and msg_length from the record layer is not part of the
>> fingerprint calculation. The spec only focuses on the certificate
>> message in Section 4.1 and the CertificateRequest message in Section
>> 4.2. These message do, however, also contain length information.
>
> I refer to the msg_type and length from the handshake message, which
> are the only things with that name in the TLS spec.
>
> You use the name `CertificateRequest`, which leads me to conclude that
> you mean the struct identified as such, which is *inside* the
> handshake message.  (I'm fine with hashing that part, I just want to
> have it be very clear.)
>
>> I included an example into the document. See Appendix A:
>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-20.txt
>> <https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-20.txt>
>
> This includes the msg_type and length.  Which means that you should
> talk about hashing `Handshake` instead.
>
>>> I'm not sure that I like the lack of both negotiation and signaling
>>> for the hashes that are used here.
>>
>> We had a negotiation capability in earlier versions of the document but
>> it appeared to be an overkill.
>
> Yeah, that's why I'm thinking that this can use the PRF hash.
>
>> What is there now is essentially an indication of the hash algorithm
>> based on what the client presents with the CachedInformationType
>> structure.
>
> I don't see that anywhere.  The algorithm seems to be fixed to SHA-256
> in the current draft (and your copy).
>
>>>  Though I think the chances of a
>>> collision being found, or that a collision would lead to an attack,
>>> are slim, I would rather see this use the PRF hash so we have at least
>>> that much flexibility.
>>
>> While there is indeed a possibility for hash collisions those will still
>> lead to a failed exchange since the TLS server will not possess the
>> correct private key that corresponds to the cached certificate.
>
> Right, this might be all that the analysis requires.
>
>>>  If the current design is retained, I would
>>> like to see a little discussion of this in the document.  A little
>>> analysis of the properties we expect the hash to provide would also be
>>> good.
>>>
>>> I think that truncated hashes might be advantageous from the server
>>> side.  Given that the server only uses hashes to identify which of the
>>> offered (available, known?) cached information is in use, is there any
>>> reason you can't save additional space by arbitrarily truncating the
>>> hash?  In many cases I would imagine that the client would be offering
>>> only one option and even if there were a small number of options
>>> presented, a single byte would suffice to disambiguate.
>>>
>>> I'm trying to think why you might want the full-length hash on the
>>> client side, but I believe that the only problem there is that there
>>> might be a collision between the certificates that a server might
>>> offer if you truncate too aggressively.  The connection still relies
>>> on the server presenting proof of knowledge of a key that the client
>>> extracts from a certificate bound to the server identity, so I believe
>>> that it would be equally secure if you removed all mention of
>>> certificates from the protocol.  And that makes me nervous, because
>>> I'm fairly sure that Karthik will tell me that I'm wrong very shortly;
>>> since we've put in a lot of work to cover key fields in the handshake
>>> hash, and I'm concerned that this could be exploited somehow.
>>>
>>> The more I think about this, the more I think that we need a little
>>> more analysis on this point (i.e., what properties the hash function
>>> needs to provide and why).  If it has already happened, mention of
>>> that in the security considerations is needed.
>>>
>>> (I think that truncation on the server side is safe if the client uses
>>> a strong hash function to identify the certificate, but I'm frequently
>>> wrong about these things.)
>>>
>> There are three designs possible for referencing the cached state, namely
>>
>> 1) The client creates the reference.
>> 2) The server creates the reference.
>> 3) There is no reference at all.
>
> I'm not suggesting that you change the design, just provide a
> description of the properties that it provides - and those that it
> relies on.
>
> On the surface at least, it seems OK to rely on a weak guarantee of
> collision resistance from the hash.  Failure only results in handshake
> failure, after which the client can fall back.  That suggests that a
> truncated hash output could be used, potentially saving quite a few
> bytes in the client's first flight.  I'd like to do that if it is
> possible.
>
> However, I'm concerned that eliding identity will lead to a weakness
> somewhere.  For instance, if the client uses a shorter hash, then the
> server might pick up different certificates.  Or, it means that
> identity is not bound to the session hash as directly.  If, as you
> say, we can rely on this being a direct selector for a private key
> where the security is bound to that private key, then maybe it's OK.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 530 bytes
Desc: OpenPGP digital signature
URL: <
https://mailarchive.ietf.org/arch/browse/tls/attachments/20150910/5282d422/attachment.asc
<https://mailarchive.ietf.org/arch/browse/tls/attachments/20150910/5282d422/attachment.asc>
>

------------------------------

Message: 2
Date: Thu, 10 Sep 2015 07:59:30 -0700
From: Martin Thomson < [e-mail]
<mailto:[e-mail]> >
To: Hannes Tschofenig < [e-mail]
<mailto:[e-mail]> >
Cc: " [e-mail] <mailto:[e-mail]> " < [e-mail] <mailto:[e-mail]>
>
Subject: Re: [TLS] WGLC for draft-ietf-tls-cached-info-19
Message-ID:
        <CABkgnnU_r=CmNuaX8kOoxYPoBJ052= [e-mail]
<mailto:[e-mail]> >
Content-Type: text/plain; charset=UTF-8

Hi Hannes,

I've followed a similar chain of thought myself.  I think that the
right answer here is similar to what you describe: the security of TLS
does not depend on the presence of the certificate at all, rather it
depends on the use of a private key that the client trusts.  That most
clients rely on the certificate for getting the information they need
to make that trust decision and that the certificate happens to be
carried in TLS in most cases is largely consequential.

On that basis, I would be happy then to accept any hash, even a
truncated hash in both directions.  In most cases, I suspect that 8
bits would be plenty, though I imagine that clients will want to send
a few more than that just to reduce the odds of having to receive a
certificate.

--Martin


On 10 September 2015 at 04:14, Hannes Tschofenig
< [e-mail] <mailto:[e-mail]> > wrote:
> Hi Martin,
>
> thanks for your feedback. I have discussed the topic with my co-worker
> Manuel.
>
> Another way of seeing the use of the hash by the client is to help the
> server to select the pick certificate (or other cached data). It does
> not have a security purpose as such, it is only a way to prevent the
> server accidentally including the wrong information. For example, this
> can happen when the server has multiple certificates to choose from then
> it should pick the right one (and I am not talking about the SNI case
> here).
>
> Without the possibility for picking the wrong value we could have as
> well omitted the hash altogether. The actual function used to compete
> the fingerprint isn't that important as long as it helps to make sure
> that the correct value can be chosen with a reasonable probably. In the
> worst case, the wrong value is chosen and the exchange failed. The
> client will then have to re-start the exchange without the cached info
> feature.
>
> As such, you are certainly right that the hash does not need to be long
> since the changes of selecting the wrong information is very low. In
> case of the certificate the security actually comes from the private
> key: the server needs to demonstrate that it knows the privacy key in
> the exchange.
>
> Regarding the use of the TLS PRF I am not sure that this will work since
> the actual function is the result of the negotiated cipher and not known
> at the time when the client and the server exchange their hello messages.
>
> Ciao
> Hannes
>
> PS: Additing extra text with information about what is included in the
> hash will be added to make sure that implementers compute the hash over
> the correct fields of the message.
>
>
> On 08/24/2015 08:35 PM, Martin Thomson wrote:
>> Hi Hannes,
>>
>> On 24 August 2015 at 09:38, Hannes Tschofenig < [e-mail]
>> <mailto:[e-mail]> > wrote:
>>>> I'd like to see the document explicitly note that msg_type and length
>>>> from the handshake message are not covered by the hash.  The
>>>> description of what is covered is a little too terse (and badly
>>>> formatted).
>>>
>>> There are multiple message type / message length fields included in the
>>> message and I am not sure which of those you rare referring to.
>>>
>>> The msg_type and msg_length from the record layer is not part of the
>>> fingerprint calculation. The spec only focuses on the certificate
>>> message in Section 4.1 and the CertificateRequest message in Section
>>> 4.2. These message do, however, also contain length information.
>>
>> I refer to the msg_type and length from the handshake message, which
>> are the only things with that name in the TLS spec.
>>
>> You use the name `CertificateRequest`, which leads me to conclude that
>> you mean the struct identified as such, which is *inside* the
>> handshake message.  (I'm fine with hashing that part, I just want to
>> have it be very clear.)
>>
>>> I included an example into the document. See Appendix A:
>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-20.txt
>>> <https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-20.txt>
>>
>> This includes the msg_type and length.  Which means that you should
>> talk about hashing `Handshake` instead.
>>
>>>> I'm not sure that I like the lack of both negotiation and signaling
>>>> for the hashes that are used here.
>>>
>>> We had a negotiation capability in earlier versions of the document but
>>> it appeared to be an overkill.
>>
>> Yeah, that's why I'm thinking that this can use the PRF hash.
>>
>>> What is there now is essentially an indication of the hash algorithm
>>> based on what the client presents with the CachedInformationType
>>> structure.
>>
>> I don't see that anywhere.  The algorithm seems to be fixed to SHA-256
>> in the current draft (and your copy).
>>
>>>>  Though I think the chances of a
>>>> collision being found, or that a collision would lead to an attack,
>>>> are slim, I would rather see this use the PRF hash so we have at least
>>>> that much flexibility.
>>>
>>> While there is indeed a possibility for hash collisions those will still
>>> lead to a failed exchange since the TLS server will not possess the
>>> correct private key that corresponds to the cached certificate.
>>
>> Right, this might be all that the analysis requires.
>>
>>>>  If the current design is retained, I would
>>>> like to see a little discussion of this in the document.  A little
>>>> analysis of the properties we expect the hash to provide would also be
>>>> good.
>>>>
>>>> I think that truncated hashes might be advantageous from the server
>>>> side.  Given that the server only uses hashes to identify which of the
>>>> offered (available, known?) cached information is in use, is there any
>>>> reason you can't save additional space by arbitrarily truncating the
>>>> hash?  In many cases I would imagine that the client would be offering
>>>> only one option and even if there were a small number of options
>>>> presented, a single byte would suffice to disambiguate.
>>>>
>>>> I'm trying to think why you might want the full-length hash on the
>>>> client side, but I believe that the only problem there is that there
>>>> might be a collision between the certificates that a server might
>>>> offer if you truncate too aggressively.  The connection still relies
>>>> on the server presenting proof of knowledge of a key that the client
>>>> extracts from a certificate bound to the server identity, so I believe
>>>> that it would be equally secure if you removed all mention of
>>>> certificates from the protocol.  And that makes me nervous, because
>>>> I'm fairly sure that Karthik will tell me that I'm wrong very shortly;
>>>> since we've put in a lot of work to cover key fields in the handshake
>>>> hash, and I'm concerned that this could be exploited somehow.
>>>>
>>>> The more I think about this, the more I think that we need a little
>>>> more analysis on this point (i.e., what properties the hash function
>>>> needs to provide and why).  If it has already happened, mention of
>>>> that in the security considerations is needed.
>>>>
>>>> (I think that truncation on the server side is safe if the client uses
>>>> a strong hash function to identify the certificate, but I'm frequently
>>>> wrong about these things.)
>>>>
>>> There are three designs possible for referencing the cached state, namely
>>>
>>> 1) The client creates the reference.
>>> 2) The server creates the reference.
>>> 3) There is no reference at all.
>>
>> I'm not suggesting that you change the design, just provide a
>> description of the properties that it provides - and those that it
>> relies on.
>>
>> On the surface at least, it seems OK to rely on a weak guarantee of
>> collision resistance from the hash.  Failure only results in handshake
>> failure, after which the client can fall back.  That suggests that a
>> truncated hash output could be used, potentially saving quite a few
>> bytes in the client's first flight.  I'd like to do that if it is
>> possible.
>>
>> However, I'm concerned that eliding identity will lead to a weakness
>> somewhere.  For instance, if the client uses a shorter hash, then the
>> server might pick up different certificates.  Or, it means that
>> identity is not bound to the session hash as directly.  If, as you
>> say, we can rely on this being a direct selector for a private key
>> where the security is bound to that private key, then maybe it's OK.
>>
>



------------------------------

Subject: Digest Footer

_______________________________________________
TLS mailing list
[e-mail] <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>


------------------------------

End of TLS Digest, Vol 134, Issue 12
************************************
-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------