headers
Ben Laurie | 1 Oct 2010 18:02
Picon
Favicon

Re: [TLS] Cert Enumeration and Key Assurance With DNSSEC

On 1 October 2010 08:29, Phillip Hallam-Baker <hallam <at> gmail.com> wrote:
> The reason that I started with the requirement to use SSL is that security
> policy relating to trust criteria is meaningless until you have a statement
> that use of SSL is required.

I can't agree with this. If a user types an https URL, say, then
there's every reason security policy should apply despite the lack of
a statement that SSL is required.

> I have no objection to doing security policy. But I do have a real objection
> to an approach that negates PKIX semantics as the TLSFP approach does.

Then I'd like to see your proposal for _optionally_ allowing PKIX to
be overridden.
Permalink | Reply | 1 comment |
headers
Sean Turner | 2 Oct 2010 00:04

[Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt]

While writing an update for the MD2, MD4, and MD5 security 
considerations, somebody pointed out that we should do the same for 
SHA-1.  We ended up doing SHA-0 too.  Below is a link to the draft. 
Please send comments to saag/cfrg.

spt

-------- Original Message --------
Subject: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt
Date: Fri,  1 Oct 2010 13:30:02 -0700 (PDT)
From: Internet-Drafts <at> ietf.org
Reply-To: internet-drafts <at> ietf.org
To: i-d-announce <at> ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Security Considerations for the SHA-0 and SHA-1 
Message-Digest Algorithms
	Author(s)	: T. Polk, S. Turner, L. Chen
	Filename	: draft-turner-sha0-sha1-seccon-00.txt
	Pages		: 7
	Date		: 2010-10-1
	
    This document updates the security considerations for the SHA-1
    message digest algorithm.  Additionally, it discusses security
    considerations for the SHA-0 message digest algorithm.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-turner-sha0-sha1-seccon-00.txt
(Continue reading)

Permalink | Reply | 11 comments |
headers
Paul Hoffman | 2 Oct 2010 18:25

Re: [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt]

At 6:04 PM -0400 10/1/10, Sean Turner wrote:
>While writing an update for the MD2, MD4, and MD5 security considerations, somebody pointed out that we
should do the same for SHA-1.  We ended up doing SHA-0 too.  Below is a link to the draft. Please send comments
to saag/cfrg.

4. Guidance

   SHA-1 no longer provides an acceptable security level when used in
   digital signature applications.  IETF protocol designers SHOULD NOT
   specify digital signature algorithms using SHA-1 as mandatory to
   implement.  IETF protocols that rely on SHA-1 based digital
   signatures MUST include countermeasures that mitigate SHA-1's reduced
   collision resistance by randomized hashing (e.g., as specified in
   [SP800-107]).

   HMAC-SHA-1 remains secure and is the preferred keyed hash algorithm
   for IETF protocol design.

   As noted above, any use of SHA-0 is strongly discouraged. Discussions
   regarding the strength of SHA-0 were included for completeness only.
   SHA-0 has no functional or performance advantage, and SHA-1 is
   considered significantly more secure.

There are many serious issues here. First the procedural ones.

- It is not "guidance" if you use "MUST": it is a mandate. In this case, it is not clear why the authors get to
make a mandate on IETF protocol designers. If it is because two of the authors are Security ADs, the
document should say so explicitly (although then you have to explain why you dragged Lily into it). If it is
because two of the authors are from NIST, the document should say so explicitly (although then you have to
explain why you dragged Sean into it).
(Continue reading)

Permalink | Reply | 10 comments |
headers
Ben Laurie | 2 Oct 2010 22:16
Picon
Favicon

Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

On 1 October 2010 16:15, Phillip Hallam-Baker <hallam <at> gmail.com> wrote:
>
>
> On Fri, Oct 1, 2010 at 6:05 PM, Matt McCutchen <matt <at> mattmccutchen.net>
> wrote:
>>
>> On Fri, 2010-10-01 at 11:29 -0400, Phillip Hallam-Baker wrote:
>> > In particular I am very concerned about the particular approach being
>> > taken to security policy. What the proposers are attempting to do is
>> > to create a mechanism that allows a site that only uses one particular
>> > high assurance CA to 'protect' themselves against SSL certificates
>> > being issued by low assurance CAs.
>> >
>> > As such, this is an objective I approve of and is one that I would
>> > like to see supported in a generalized security policy. It should be
>> > possible for a site to make security policy statements of the form
>> > 'all valid PKIX certs for example.com have cert X in the validation
>> > path'.
>> >
>> > What I object to is the approach being taken which is to use DNSSEC to
>> > replace PKIX certificate validation entirely.
>>
>> Realize that I, and I would guess many other site admins, want precisely
>> that.  PKIX is complicated, whereas once I have a DNSSEC signed zone,
>> placing my TLS server's certificate in the zone and knowing that clients
>> will accept that certificate and no other could hardly be simpler.  And
>> why shouldn't I be allowed to do it?  I have complete authority over my
>> zone (even for the most part in the present public CA system).  Nobody
>> gave PKIX a monopoly on the determination of certificate acceptability.
>>
(Continue reading)

Permalink | Reply | 76 comments |
headers
der Mouse | 3 Oct 2010 02:53

Re: [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt]

> - The third sentence, on randomized hashing, is not based on reality.
> Few if any of the current IETF protocols show how to carry the random
> number used.

This is not necessarily a reason not to use randomized hashes; the
random number could, for example, be prepended to the "real" hash.

> This sentence essentially says "all IETF protocols must use an
> unspecified protocol".

This, however, is valid...absent a standardized way to package the
random number together with the "real" hash, at least.

> [proposed alternative text]
> Even if SHA-1's collision resistance was as good as was expected,

While I realize the subjunctive is on its way out in English, there's
no need to hurry the process, and there are still people, like me, who
have a little internal voice piping up saying something uncomplimentary
about the literacy level of the author upon seeing something like this.

You might want to fix it, if only to avoid the negative emotional
colour it provokes in some readers.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 3 Oct 2010 06:14
Picon
Picon
Picon
Favicon

Re: [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC

Phillip Hallam-Baker <hallam <at> gmail.com> writes:

>The attack surface is the number of paths that are open to an attacker.
>
>In the current model there is only one trust path, the PKIX path.

Which isn't so much a path as a twelve-lane motorway with elevated cloverleaf
interchanges, twenty-four-hour drive-through catering stops, and large neon
signs every few km inviting every attacker to join in.

>In the new model, the attacker has a choice of trust paths, the PKIX path and
>the DNSSEC path and they can attack either of them.

Or you can block off the PKIX motorway and leave only the (possibly) smaller
DNSSEC two-lane road.

(I'm not sure whether DNSSEC has a smaller overall attack surface than PKIX,
but chances are it does because the only security protocol with an even larger
attack surface than PKIX is XMLsec, whose attack surface is so huge that it
won't fit on the planets surface but actually extends several km out into
space).

Peter.
Permalink | Reply | 0 comments |
headers
Tobias Gondrom | 3 Oct 2010 22:50
Favicon

Re: [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt]

 Must say I agree with Paul's concerns below (and in particular
hesitated too when I read the intended "MUST NOT" effect of a guidance
informational draft on standards documents).
However, I think the general idea to write a guidance ID is a good idea
from Tim, et al.

One further comment: I am a bit uncertain to why you refer to SHA-256
from the SHA-2 family only (and thus not mention/exclude SHA-512)?

Tobias

On 10/02/2010 05:25 PM, Paul Hoffman wrote:
> At 6:04 PM -0400 10/1/10, Sean Turner wrote:
>> While writing an update for the MD2, MD4, and MD5 security considerations, somebody pointed out that we
should do the same for SHA-1.  We ended up doing SHA-0 too.  Below is a link to the draft. Please send comments
to saag/cfrg.
> 4. Guidance
>
>    SHA-1 no longer provides an acceptable security level when used in
>    digital signature applications.  IETF protocol designers SHOULD NOT
>    specify digital signature algorithms using SHA-1 as mandatory to
>    implement.  IETF protocols that rely on SHA-1 based digital
>    signatures MUST include countermeasures that mitigate SHA-1's reduced
>    collision resistance by randomized hashing (e.g., as specified in
>    [SP800-107]).
>
>    HMAC-SHA-1 remains secure and is the preferred keyed hash algorithm
>    for IETF protocol design.
>
>    As noted above, any use of SHA-0 is strongly discouraged. Discussions
(Continue reading)

Permalink | Reply | 6 comments |
headers
Stephen Farrell | 4 Oct 2010 18:05
Picon
Picon

Re: [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC


On 04/10/10 15:37, Martin Rex wrote:
> One thing that needs to be addressed/solved is the key/cert rollover
> for any TLS-Server, so that it is possible to list more than one
> server cert as "valid" for a Server through DNS, at least for the
> time of the transition/rollover.

Maybe a side-issue here, but this came up in the W3C WSC work and
I wrote up an idea for that (not based on DNS) which is RFC 5697. [1]
No idea if anyone is using or would use it, though I did have a student
implement it, so it *could* work. (Note: that's an experimental-track
RFC, as it ought be:-)

S.

[1] http://tools.ietf.org/html/rfc5697
Permalink | Reply | 3 comments |
headers
Dan Harkins | 4 Oct 2010 19:51

Re: [Cfrg] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt]


On Sun, October 3, 2010 2:35 pm, Paul Hoffman wrote:
>>One further comment: I am a bit uncertain to why you refer to SHA-256
>>from the SHA-2 family only (and thus not mention/exclude SHA-512)?
>
> Because the IETF almost always deals only with 128-bit strength security,
> and using SHA-384 or SHA-512 is just as waste of processor and network
> resources in such cases.

  That's an odd statement. There is suite B guidance for use of quite alot
of IETF protocols-- TLS, SSH, IKE/IPsec, S/MIME-- that provide for more
than "128-bit strength security". The qualifier ("almost always") even adds
to the oddness. Check out the D-H groups for use in IKE. They run the gamut
of strength estimates. Arguably neither of the cryptographic suites for
IPsec from RFC 4308, of which you are the author, provides 128-bits of
strength security (the required D-H groups afford approximately 80 to
"VPN-A" and 112 bits to "VPN-B").

  We continue to define the use of ciphers with > 128 bit keys. We
continue to define the use of D-H groups that produce shared secrets
of > 128 bits of approximate strength. Hash algorithms that can be used
in key derivation, key confirmation, and digital signatures which afford
greater than 128-bits of approximate strength should not be excluded.

  Dan.
Permalink | Reply | 3 comments |
headers
Paul Hoffman | 4 Oct 2010 20:13

Re: [Cfrg] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt]

At 10:51 AM -0700 10/4/10, Dan Harkins wrote:
>On Sun, October 3, 2010 2:35 pm, Paul Hoffman wrote:
>>>One further comment: I am a bit uncertain to why you refer to SHA-256
>>>from the SHA-2 family only (and thus not mention/exclude SHA-512)?
>>
>> Because the IETF almost always deals only with 128-bit strength security,
>> and using SHA-384 or SHA-512 is just as waste of processor and network
>> resources in such cases.
>
>  That's an odd statement. There is suite B guidance for use of quite alot
>of IETF protocols-- TLS, SSH, IKE/IPsec, S/MIME-- that provide for more
>than "128-bit strength security". The qualifier ("almost always") even adds
>to the oddness. Check out the D-H groups for use in IKE. They run the gamut
>of strength estimates. Arguably neither of the cryptographic suites for
>IPsec from RFC 4308, of which you are the author, provides 128-bits of
>strength security (the required D-H groups afford approximately 80 to
>"VPN-A" and 112 bits to "VPN-B").

Right; this my purposeful vagueness above.

>  We continue to define the use of ciphers with > 128 bit keys. We
>continue to define the use of D-H groups that produce shared secrets
>of > 128 bits of approximate strength. Hash algorithms that can be used
>in key derivation, key confirmation, and digital signatures which afford
>greater than 128-bits of approximate strength should not be excluded.

All true, but not relevant to the text I gave. The draft as it stands *also* doesn't say what to do for
signatures that are meant to be at strengths greater than 128 bits; it is about not using SHA-0 at all and not
specifying SHA-1 as the default.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane