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

From: [email-masked]
Date: Wed, 14 Oct 2009 02:45:02 -0700 (PDT)

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

This document updates RFC 3161 [RFC3161]. It allows the use of
ESSCertIDv2 defined in RFC 5035 [ESSV2] to specify the hash of a
signer certificate when the hash is calculated with a function other
than SHA-1 [SHA1].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161-update-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Julien Stern <[email-masked]>
Date: Thu, 22 Oct 2009 17:14:28 +0200

> 	Filename        : draft-ietf-pkix-rfc3161-update-08.txt

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

---

From: Dino Esposito <[email-masked]>
Date: Thu, 22 Oct 2009 17:42:54 +0200

I totally agree with Julien
After long discussions we agreed that the first draft by Denis had to be 
rejected because it went beyond the limited scope of allowing SHA-2.
So, as I wrote some times ago, this update is just to allow an 
implementer to be compliant with some regulations or policies ruling out 
SHA-1. Period
Any other issue is out of scope

Julien Stern wrote:
> ESSCertID is useful from a security standpoint. So people are trying 
> to argue about the feasability or the infeasability, as well as the 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 23 Oct 2009 11:58:02 +0200

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

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 23 Oct 2009 14:16:51 +0200

Stefan,

I could agree with the "minimalist" text you propose by changing a single word in it.

Change "known" into "new".

Then, the last paragraph would become:

   The update provided by this draft is motivated by reasons of
   interoperability and migration to other hash algorithms rather than
   mitigating new security issues.

Can you live with it ?

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : Julien Stern,pkix 
Date : 2009-10-23, 11:58:02
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-08.txt

Julien,

... And delete the rest.

/Stefan

---

From: Julien Stern <[email-masked]>
Date: Fri, 23 Oct 2009 15:15:27 +0200

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.

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

*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

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 26 Oct 2009 13:19:17 +0200

Denis,

I have spoken with Nick and we can both live with this change.

The new security considerations section would then read:

I will include this in the 09 draft and hope the rest of this list can agree
to this text.

/Stefan

On 09-10-23 2:16 PM, "Denis Pinkas" <[email-masked]> wrote:

>> De  : pkix-bounces <mailto :[email-masked]>
>>  
>> À  : Julien  Stern,pkix <mailto :[email-masked],[email-masked]>
>>  
>> .... And delete the rest.
>> 
>> /Stefan
>> 
>> 
>> 
>> On  09-10-22 5:14 PM, "Julien Stern" <[email-masked] <mailto:
>> [email-masked]> >  wrote:
>> 
>>> > [email-masked] <mailto: [email-masked]>   wrote:
>>>> >> This draft is a work item  of the Public-Key Infrastructure (X.509)
>>>> Working
>>>> >> Group of the  IETF.
>>>> >> 
>>>> >> 
>>> > [email-masked] <mailto: [email-masked]>
>> [email-masked] <mailto: [email-masked]>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 27 Oct 2009 13:32:32 +0200

In absence of any objection I ask that the WGLC to be closed for this
document with the conclusion that all raised issues has been addressed in
draft 09.

On the closure of the WGLC I suggest that this document is done in PKIX and
ready for the IESG.

/Stefan