[Cryptography] Client certificates as a defense against MITM attacks

[Guido Witmond]

On 03/16/14 23:49, Viktor Dukhovni wrote:
> On Sun, Mar 16, 2014 at 08:56:05PM +0100, Guido Witmond wrote:
> 
>>> This doesn't solve the "first connection between a pair of parties
>>> neither of whom has any way of identifying the other".  
>>
>> Again, DNSSEC and DANE do identify the server.
> 
> We might recognize the fact that introduction and key continuity
> are potentially separate problems.  After DNSSEC + DANE act as an
> introducer of strangers, where a TTP is largely unavoidable, we
> might from that point on use ideas along the lines of:
> 
>     https://tools.ietf.org/html/draft-perrin-tls-tack-02
> 
> to make network MITM considerably more difficult.  The main difficulty
> is that with domains key continuity cannot be assured.  Domains
> are sometimes transferred to new owners, and in those cases it is
> not clear whether the new owner's keys will be signed by the previous
> owner.
> 
> This means that automated lights-out applications (say MTA to MTA
> email) can't rely on Tack working indefinitely for all domains, and
> some process for handing re-keying on domain transfer needs to be
> designed that does not immediate bring back the MITM risks that
> Tack is designed to avoid.
> 

Viktor, you are ahead of me.

With my Eccentric-Authentication, I haven't reached the state of
rekeying yet.

I still try to drum up support for the idea that total strangers can
connect securely.

When two people connnect, they don't need rekeying of their original key
anymore, they have established an independent channel. To keep it going
throughout the years, rekeying of their private keys might be necessary.
However, that's out of my scope. At least for now.

Remember that when two people need to rekey their channel, there is no
need for domain names. Each party knows the other purely by their public
key. That's the identifier that's important.

Regards, Guido Witmond.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140317/e13e9fc3/attachment.pgp>