[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-saag
Subject:    Re: [saag] [TLS] Fwd:  Pinning
From:       Nikos Mavrogiannopoulos <nmav () gnutls ! org>
Date:       2012-06-06 12:17:18
Message-ID: CAJU7zaLi4i9-kYSk7M0YM+4o5be3G3enYmY12irxCB0WwXE+GQ () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jun 5, 2012 at 11:17 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> From the SAAG mailing list, but appropriate here. I bet that Sean would appreciate \
> all discussion to go on on the SAAG mailing list... Begin forwarded message:
> > From: Sean Turner <turners@ieca.com>
> > Subject: [saag] Pinning
> > There are many proposals for how to say which key or certificate or trust anchor \
> > should be used by the client in a TLS session that it is about to open. These \
> > proposals include making that decision in the DNS \
> > (https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the application \
> > after TLS has happened once, to be remembered in the future \
> > (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and in the TLS \
> > handshake (https://datatracker.ietf.org/doc/draft-perrin tls-tack/). If more than \
> > one of these protocols are deployed, operational mistakes could lead to a client \
> > getting conflicting information.

The fact that more than one protocols can be deployed is an advantage.
In that case an attacker needs to control more infrastructure in order
to perform an attack on a TLS session. If you compare to the current
situation where the attacker only needs to control a random CA, it
looks like an improvement. Of course the situation can be improved by
restricting to few of these approaches rather than all (more peer
verification paths is better, but also increases the probability of
something going wrong unintentionally and thus false alarms).

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


[prev in list] [next in list] [prev in thread] [next in thread]