On 19/08/16 19:05, Adam Langley wrote: >> > Right, exactly. (Ideally, the device doesn't even know it's being >> > audited until the user logs in to the Web UI and says, "okay, now, >> > ratchet the session and then share the old keys with this auditor that >> > I am going to introduce you to, so it can decrypt some earlier >> > ciphertext I've been capturing." So we don't want a parallel channel >> > and we don't even want the device to have to know about the audit >> > beforehand.) >> > > I think that this is the most interesting case.
And for me, the dodgiest, by far. The scope for an "auditor" (what is that?) actually being an attacker is IMO way too high to consider standardising that kind of feature and any idea that it'd involve informed consent of someone seems to me fictional. I'd be opposed to that fwiw, as an individual participant. As an AD, I'd look excruciatingly closely at the process for demonstrating that there's a real WG and IETF consensus for that kind of feature and that its potential for conflicting with other BCPs and well established IETF positions is very carefully considered. S.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
