On Thu, Dec 5, 2019 at 4:42 PM Christian Huitema <huitema@xxxxxxxxxxx> wrote:
>> Second, my actual concern. Compression may leak information, because different
>> certificate chains will compress differently. The authors mention that an
>> attacker will not be able to inject data in the certificate chain, and thus
>> that attacks of the CRIME variety are unlikely. That's correct, but that's not
>> the entire story.
>>
>> TLS 1.3 will encrypt the compressed certificate message but the length of that
>> message could be deduced from the length of the server's encrypted message.
>> Attackers might be able to derive from that length the identity of the server,
>> even if the SNI is encrypted.
>>
>> One could say that in the absence of compression the length of the certificate
>> chain is also available. Indeed, the problem is flagged in
>> draft-ietf-tls-esni-05, which states in section 5.3 that "it (the server)
>> SHOULD pad the Certificate message, via padding at the record layer, such that
>> its length equals the size of the largest possible Certificate (message)
>> covered by the same ESNI key."
>>
>> Certificate compression introduces a level of complexity here. If only some
>> servers in the anonymity set support compression, attackers can work with a
>> smaller anonymity subset. If all attackers support compression, the padding
>> should try to match the largest Compressed Certificate.
>>
>> It might be good to discuss this issue in the security consideration section.
> I agree tha this is worth discussing, but it seems like it belongs in the ESNI
> draft itself, so implementers of ESNI will be more likely to take compression
> into consideration. That is, we can expand the section you quoted to also
> explicitly mention certificate compression. What do you think? I can look into
> proposing a PR for this.
I agree with you that the bulk of the work belongs in the ESNI draft.
However, it would be nice to have a short reminder of the issue in the
security section of the compression draft. Something like:
Although the Certificate extension is encrypted in TLS 1.3, third
parties can deduce some information about the certificate from the
length of the handshake messages. Compression does not prevent this
issue, as different certificate chains will compress to different
lengths. When privacy is desired, implementers need to consider
appropriate padding strategies. Discussion of these padding strategies
is out of scope for this document.
-- Christian Huitema
Thanks!
Filed a PR addressing this issue: https://github.com/tlswg/certificate-compression/pull/31
Cheers,
Victor.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
