Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-08.txt

[Julien Stern <[e-mail]>]

Stefan,

First, sorry again for coming late. It so happened that I did not have 
the chance to read this list for some time...

Anyway, I like the note you propose below much more than the current one.

I think that by trying to accomodate different views on this topic, the 
current note has become convoluted to a point which makes it both wrong 
and misleading:

It can easily be read as saying that the ESSCertID is useless.
It is also not very clearly defined:

"...a theoretical scenario involving a trusted malicious CA issuing a 
false but trusted TSA certificate..."

What is a "trusted malicious CA"?
What is a "false" TSA certificate?
What is a "trusted" TSA certificate?



Now, I hope to correctly summarize the private discussion we had some 
time ago by stating that:

1. there exists known certificate substitution attacks when neither 
ESSCertID v1 nor v2 is used, even without malicious CAs. (NOTE: I'm am 
not discussing the _semantic_ interpretation of these attacks in real 
life, since this usually leads to endless discussions. I'm simply saying 
that I can easily produce two largely different certificates that can 
validate the same data when ESSCertID is not used).
2. There aren't any known attacks when ESSCertID v1 is used
3. Even when collisions on SHA-1 are found, it is not clear that it 
would lead to attacks on ESSCertID v1
4. On the other hand, no-one has clearly demonstrated that ESSCertID v1 
will remain 100% safe when more and more weaknesses of SHA-1 are found

So, I think that what we essentially want to say is

1. Chill out, ESSCertID v1 is still considered safe for some time by the 
community
2. Going to ESSCertID v2 does not hurt. At worst, it will not change 
anything security-wise, at best it will improve security. (And will 
allow you to comply with some policies).


And well... that's very close to what I read in your last email ;)
Maybe being even more explicit like in the text proposed below could 
help reach a consensus, but I could totally live with the version as you 
wrote it.

--------------
This draft incorporates the security considerations of RFC 5035
[ESSV2] with further explanations in this section.

ESSCertID provides a means based on the SHA-1 hash algorithm for
identifying the certificate used to verify the signature on a time
stamp. The use of ESSCertIDv2 aims to enable implementers to comply
with policies that require phasing out all uses of the SHA-1
algorithm.

*While ESSCertIDv2 can only provide a higher security than the v1 
counterpart*, the update provided by this draft is *primarily* motivated 
by reasons of interoperability and migration to other hash algorithms 
rather than mitigating known security issues, *since there is not any 
known weakness in ESSCertIDv1 at the time of this publication*.
--------------

Best,

Julien

Stefan Santesson wrote:
> Julien,
> 
> The body of this draft has been done and agreed upon for quite some time
> now. The document is hold back only because we have not manage to agree on
> one security considerations section.
> Removing the security considerations section is not an option. All RFC
> documents must have one.
> 
> We are NOT trying to say that ESSCertID serves no security purpose.
> The original security considerations section was trying to say that the
> motivation for allow algorithm agility (through ESSCertIDv2) is to allow
> migration to other hash algorithm rather than reasons of security.
> 
> This approach did however receive serious pushback from Denis. We have since
> then tried to find a text that is both acceptable and accurate. So far
> unsuccessfully.
> 
> In the effort to describe the particular threat that a stronger hash would
> protect against, it turns out that this threat requires a malicious trusted
> CA. This is however something that breaks the fundamental security
> assumptions of PKI. If you trust a bad CA, you are smoked.. No matter how
> good your protocol is. As BCP 72 requires us to tell (in the security
> considerations) what threats are in, or out, of scope of the specified
> protocol. Thus, describing this threat also requires us to tell the reader
> that threats caused by a trusted malicious CA in general are out of scope
> for a protocol to solve.
> 
> Failing to do so may cause a reader to believe that he needs to migrate to
> ESSCertIDv2 to avoid serious security threats. This is not a desired outcome
> and could cause both confusion and interoperability issues trough premature
> and unmotivated migrations to ESSCertIDv2.
> 
> You are free to propose text here that meets the requirements of BCP 72
> section 5.
> 
> I personally would be happy with a short note saying what we originally
> wanted to say.. That is:
> 
> 
>    This draft incorporates the security considerations of RFC 5035
>    [ESSV2] with further explanations in this section.
> 
>    ESSCertID provides a means based on the SHA-1 hash algorithm for
>    identifying the certificate used to verify the signature on a time
>    stamp. The use of ESSCertIDv2 aims to enable implementers to comply
>    with policies that require phasing out all uses of the SHA-1
>    algorithm.
> 
>    The update provided by this draft is motivated by reasons of
>    interoperability and migration to other hash algorithms rather than
>    mitigating known security issues.
> 
> 
> ... And delete the rest.
> 
> /Stefan
> 
> 
> 
> On 09-10-22 5:14 PM, "Julien Stern" <[e-mail]> wrote:
> 
>> [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Public-Key Infrastructure (X.509) Working
>>> Group of the IETF.
>>>
>>>
>>> Title           : ESSCertIDv2 update for RFC 3161
>>> Author(s)       : S. Santesson, N. Pope
>>> Filename        : draft-ietf-pkix-rfc3161-update-08.txt
>>> Pages           : 8
>>> Date            : 2009-10-14
>>
>> Dear all,
>>
>> Sorry for jumping in late in the discussion.
>>
>> I disagree with the current proposed addition to the security
>> considerations section.
>>
>> In the various email exchanges on this list as well as on the ESTI ESI
>> list, it appears that what is currently under debate is whether the
>> ESSCertID is useful from a security standpoint. So people are trying to
>> argue about the feasability or the infeasability, as well as the
>> practicality and the real-life impact of various certificate
>> substitution attacks.
>>
>> I do not think that this is the point. The point of this update is to
>> allow the usage of the ESSCertID v2 (defined in RFC 5035) instead of the
>> ESSCertID v1.
>>
>> I do not think that adding a security consideration that is essentially
>> saying "oh, by the way, ESSCertID v2 is essentially useless
>> security-wise" when it is meant to be used in S/MIME, PKIX (3161, 5126),
>> CAdES, XAdES, PAdES, ECOM, etc fits in such an update. I'm not sure
>> either that such an update reflects the largest view of the community...
>>
>> People are free to believe that ESSCertID (v1 or v2) serves no security
>> purpose. Others are free to believe otherwise.
>>
>> But if the authors truly believe that the ONLY possible attack scenario
>> is the one roughly described in the security consideration section, then
>> let them prove it. Otherwise, remove the security consideration section.
>> (In my humble opinion, it is not correct anyway).
>>
>> Regards,
>>
>> --
>> Julien
>> _______________________________________________
>> pkix mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pkix
> 
>