RE: Security for various IETF services

[Eric Gray <[e-mail]>]

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:[e-mail]] 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 <[e-mail]> wrote:
>>
>> Stephen Farrell <[e-mail]> 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