Moving discussion from TLS-WG to WEBSEC-WG. See below. ---------- Forwarded message ---------- From: Ralf Skyper Kaiser <[email protected]> Date: Tue, Nov 19, 2013 at 10:15 AM Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd To: Dan Harkins <[email protected]> Cc: "[email protected]" <[email protected]>
Hi Dan, The security risk lies within the implementation. The capable client will always offer TLS-PWD. Simplified, this is how pinning will be implemented: The client receives the server's certificate. The client checks if the server's certificate (or better the SPKI) is already known to the client (e.g. pinned) and if the server's certificate is different to the pinned certificate then the connection fails. The draft assumes that certificate based server authentication is the only authentication that exists. The draft does not discuss the scenario where TLS-PWD is used. In such a case I'm concerned that the part of the client source code that checks for pinning is not triggered and by-passed. The client goes into the TLS-PWD mode. Instead what should be pinned is the SPKI _and_ that certificate based server-authentication must be used. E.g. once a client has pinned a certificate for a host it should not allow TLS-PWD. This is obvious to us but not obvious to the developer and should be explicitly mentioned. (It could be mentioned in websec-rfc as you say but that's beyond draft status and additions are no longer practical). Mentioning it in the TLS-PWD draft will hopefully prevent an insecure implementation. regards, Ralf On Mon, Nov 18, 2013 at 9:51 PM, Dan Harkins <[email protected]> wrote: > > Hi Ralf, > > On Tue, November 12, 2013 2:28 am, Ralf Skyper Kaiser wrote: > > Hi, > > > > could not find it in the draft: > > > > the interoperability with draft-ietf-websec-key-pinning-08 should be > > mentioned explicitly to prevent > > an attack scenario. (e.g. user has pinned certificate for google.com. > > Attacker MITM forces > > client to do tls-pwd. Client should not allow this). E.g. once a host is > > pinned no other server-side > > auth mechanism should be allowed. > > If the client doesn't want to do TLS-pwd then it won't include the > mandatory extension in its client hello and it won't include any TLS-pwd > ciphersuites. I don't see how this attack happens. > > Perhaps the necessary requirements to deal with pinning certificates > for websec should be dealt with in the draft you mention. > > regards, > > Dan. > > > >
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
