>>>>> "John" == John Levine <johnl@xxxxxxxx> writes:
>> Roughly we need to consider how DKIM is used, not just define a
>> technology. We need to talk about bad uses of DKIM as soon as
>> we are aware that they are sufficinetly likely that they are
>> worth considering.
John> Here's a concrete suggestion: it is clear that the bad uses
John> of DKIM people have mentioned are a subset of the bad uses
John> of STARTTLS.
That's not clear to me.
I'd never really considered the question though so it may well be true.
John> I have seen concerns that third party reputation lists might
John> be used to create walled gardens or closed networks with
John> DKIM. This is not just a theoretical risk with STARTTLS.
John> People have already done exactly that, since TLS unlike DKIM
John> already includes the facilities for third parties to
John> indicate which keys they like and which ones they don't.
Interesting I'll admit that I have not run into people who seem to
have a problem with a self-signed starttls cert in practice, although
I might not have noticed. Also, I don't configure MTAs or my MUA to
offer a client cert, only a server cert.
I agree it is possible and am happy to take your word for it that someone has done so.
John> And the TLS world is dominated by a single signer whose
John> signing policies are opaque.
Really? Are you sure the TLS world is not dominated by users clicking
OK trust this cert for anything they see, combined with a lot of self
signed certs and certs from a variety of CAs? I do expect that most
web sites tend to have Verisign certs, but I have no idea about other
uses of TLS.
John> So how about if we simply reuse the warning language about
John> STARTTLS from RFC 3207?
What warning language? I can't find anything related to this problem.
I may not be looking carefully enough.
John> If that's not adequate, do we need
John> to write similar warnings about STARTTLS?
Quite possibly.
--Sam
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf