Martin, You say "_the_real_TLS_protocol_characteristics_" like they are written down somewhere. Would you care to provide a pointer? -- Eric -----Original Message----- From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Martin Rex Sent: Monday, April 07, 2014 5:17 PM To: John C Klensin Cc: IETF-Discussion; Tim Bray; The IESG; Stewart Bryant Subject: Re: Security for various IETF services John C Klensin wrote: > > Ted Lemon <ted.lemon@xxxxxxxxxxx> wrote: >> >> Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote: >>> >>> Yes, we ought move away from passwords if/when we ever find an >>> acceptably better solution, and yes, people ought manage their >>> passwords well, but neither are today's reality more's the >>> pity. >> >> Perhaps it would be worth setting up support for client certs >> as a way to log in to IETF services. If we won't start, why >> would someone else? > > If we are really serious about promoting/ encouraging security, > I'd really like to see this as an option. Not only would it be > responsive to Ted's question, but, if we made it available and > almost no one used it, it would give us a lot of information > about the course we are on. TLS _client_ certificates are typically used in closed groups, where a single CA is issuing all these certs. TLS client cert authentication has a few small issues. The TLS server needs to explicitly request the client cert (unsolicited client certs are not possible/not allowed), and when the server asks for them in the initial handshake, the client certificates will travel the network _in_the_clear_. Requesting client certificates only in the renegotiation handshake has it own set of problems, besides twice the full handshake crypto overhead. For TLS renego problems and fixes see rfc5746 and https://secure-resumption.com/ I also think that discontinuing the _public_ services of the IETF over traditional, insecure channels (HTTP, anon-FTP, plain SMTP, whatever) should require a threat analysis. Different to what a lot of folks believe, TLS is neither a panacea nor magic pixie dust. In order to determine whether doing X-over-TLS really provides the desired security characteristics, it is necessary to know what security properties one is looking for. The reason why there was an issue with TLS renegotiation is that applications boldly assumed properties which never existed in the first place -- and that problem would have been obvious if anyone of those abusing TLS renegotiation for delayed authentication would have actually cared to check for _the_real_TLS_protocol_characteristics_ instead of believing in TLS magic pixie dust. -Martin