Re: [saag] SHA-1 to SHA-n transition

Cannot connect to the site. Get a 404  error. Can someone post this deck to SAAG? 

________________________________________
From: saag-bounces@ietf.org [saag-bounces@ietf.org] On Behalf Of Hannes Tschofenig [Hannes.Tschofenig@gmx.net]
Sent: Sunday, February 22, 2009 4:58 AM
To: 'Eric Rescorla'; 'Stephen Kent'
Cc: saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n transition

Hi Ekr,

Stephen is referring to the nice presenation at the Black Hat conference,
see
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Ma
rlinspike-Defeating-SSL.pdf

I don't think that there is anything new in there but the slide set provides
a nice sate-of-the-art summary and points to the importance of properly
designed user interfaces. On the latter issue I have also noticed that in
the IETF we used to say that user-interface aspects are outside the scope of
our work. This leads to totally ignoring the way how the user utilizes the
protocols we develop (even though I understand that we don't want to
standardize a particular interface itself). However, for the complete
solution the user experience is something really important. My recent
examples were user interface aspect matter are: authorization policies we
use in the SIP environment, SIP Identity/SIP Security, early warning
messages, all sorts of identity management solutions (although they are
mostly developed outside the IETF).

Ciao
Hannes

>-----Original Message-----
>From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On
>Behalf Of Eric Rescorla
>Sent: 22 February, 2009 04:07
>To: Stephen Kent
>Cc: saag@ietf.org
>Subject: Re: [saag] SHA-1 to SHA-n transition
>
>At Sat, 21 Feb 2009 11:10:03 -0500,
>Stephen Kent wrote:
>> I agree wit Phil's suggestion that we begin work on this
>topic sooner
>> rather than later.  Solutions probably will require coordination
>> between folks in both PKIX and TLS, plus some browser
>experts from the
>> APP area.
>
>I should note that TLS 1.2 already has support for SHA-n, as
>well as mechanisms for indicating that an implementation will
>accept these certificates. Deployment of 1.2 has been minimal
>so far, but I'm not aware of any new protocol design work that
>needs to be done here.
>
>> Since we're talking about how well browsers implement PKI mechanisms
>> in the context of SSL/TLS, it is worth noting a presentation at last
>> week's Black Hat conference in D.C. The presentation
>provided details
>> on how several browsers remain vulnerable to attacks because they
>> fails to check the Basic Constraints extension. This
>oversight of one
>> of those pristine principles of PKIX ( we can use the
>acronym P3 going
>> forward) and allows a web sites to act as a CA, based o the EE cert
>> issued to it by any of the trust anchors embedded in the browser.
>
>I agree that this is a problem.
>
>
>> Another vulnerability, and matching MITM attack, is enabled by the
>> issuance of certs that contain wildcard DNS names. This is not, a
>> violation of P3, because PKIX caved to pressure from the TLS WG, to
>> accommodate web site operators who wanted to purchase one
>cert from a
>> TTP that could be used to verify the EE certs for multiple web sites.
>> I argued against this, but lost. The phrase "I told you so" comes to
>> mind :-).
>
>Can you briefly describe how this leads to MITM attacks? This
>is something I haven't heard before.
>
>Best,
>-Ekr
>_______________________________________________
>saag mailing list
>saag@ietf.org
>https://www.ietf.org/mailman/listinfo/saag
>

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag