> On Fri, Aug 26, 2011 at 11:14 AM, <ned+ietf@xxxxxxxxxxxxxxxxx> wrote: > > > > +1. If you want signatures, do them properly. Don't pretend a transfer > > protection mechanism covering exactly one hop provides real object security, > > because it doesn't. > > > It ensures that what you're getting is the same as what the IETF has > on file, No, it really doesn't do that. There can be, and usually are, a lot of steps involves besides the one https hop. > and (assuming you trust the IETF's archive integrity, which > is a separate problem) On the contrary, it's the same problem. You're just pretending that solving an insignificant subset of that problem is useful. It isn't. > what everyone else on the list received. This, OTOH, *is* a separate problem, one that isn't addressed in any way by https on archive archive access. Nor does a signed archive address this issue. Nonrepudiation of delivery is in fact a very difficult problem to solve - the algorithms I'm aware of for it either involve a TTP or are exceptionaly ugly - and the fact that the architecture of our email services isn't designed for it doesn't exactly help. (In case you care, it's the nontransactional nature of POP and IMAP that gets in the way of doing nonrepudiation of delivery at the email protocol level.) We're very lucky that we don't operate in a regime where this is actually a requirement. (And such regimes do exist, although the solutions they actually use tend to be hacks.) > It > seems to me it's more important to know that than to know that stuff > sent to the list actually came from who it claims to come from. Does > it really matter if a proposed standard wasn't really designed by who > the archive says it was designed by? And now you're talking about yet a third problem - nonrepudiation of submission. It's completely doable, but only by significantly increasing the barriers to participation by requiring signed messages. I don't believe the benefits come even close to the costs. > > And as for the "encrypt so the really secret stuff doesn't stand out" argument, > > that's fine as long as it doesn't cause inconvenience to anyone. That's clearly > > not the case here. And I'm sorry, the "mistakes were made" notion doesn't > > really fly: Certificates aren't a "set it and forget it" thing, so if you > > haven't noted expiration dates on someone's to-do list so they can be updated > > before expiration, you're not doing it right. > Yeah, it seems like the IETF would be on top of certificate > expiration, having invented it. But I think having the encryption is a > very good thing. Some government interests would be happy to keep > information about some aspects of IETF business away from their > citizenry, and have the resources to launch a MITM attack. (Of course, > those governments may also have the resources to sign a fake > certificate, but that is, again, a separate problem.) I'm sorry, but the notion that the present use of https provides any sort of protection against this sort of thing is just silly. The simple facts that the archives are also available via regular http and that there is no stated policy about the availability of archives via https means the present setup is completely vulnerable to downgrade attacks. Again, if you really care about this sort of stuff, the archives need to be timestamped and signed. > Once the certificate expiration business is fixed, it should be fairly > simple to make sure it's kept up to date so that this sort of thing > doesn't happen again. 10+ years of experience with multiple certificates having multiple failures says this is, at best, a crapshoot. Ned _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf