On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote:
> On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote: > > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote: > > > > > > > > > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote: > > > > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote: > > > > ... > > > > > we do not have a reliable mechanism of differentiating between > > > > > external and > > > > > resumption PSKs while parsing Client Hello > > > > > > > > Well, a valid external PSK (identity) the server will of course > > > > recognize, and we have a SHOULD-level requirement that the > > > > obfuscated_ticket_age is zero for external PSKs. I haven't > > > > gotten > > > > to think through whether there is still potential for information > > > > leakage about external PSK identities, but it seems like there > > > > would > > > > not be, provided that the server prefers resumption to external- > > > > PSK > > > > full handshakes. > > > > > > > > > > I am concerned with the privacy issues linked to these "external > > > PSK > > > identities". If a system is set so that clients use static PSK > > > identities, then the identity is an identifier and the client's > > > movements and connections can be tracked. I don't think privacy is > > > improved if we make it easy to differentiate external identities > > > from > > > resumption tickets. > > > > Oh, of course, the privacy considerations of the current external > > PSK scheme are terrible! This follows naturally from external PSKs > > having not really been a first-class citizen while we were designing > > things; we stuffed resumption PSKs together with external PSKs for > > the convenience of having them use the same binder construct and > > only needing to have one extension at the end of the ClientHello. > > Resumption flows get single-use tickets for privacy preservation, > > and external PSKs get infinite use and a gigantic correlation > > channel. > > I agree. > > > > If you want to use PSK with some level of privacy, you might adopt > > > a > > > different setup. For example, servers could provision the clients > > > with a > > > set of single-use external PSK identities. But then, that looks a > > > lot > > > like resumption. Or, clients could generate single-use external PSK > > > identities by encrypting their long term identity and a nonce with > > > the > > > public key of the server, a design which of course has its own set > > > of > > > issues. > > > > > > > But, as you note, this is something of an open problem for how to do > > well, and this document is already approved by the IESG. (It's also > > not entirely clear that the TLS WG would be the best place to design > > this sort of scheme, though of course it could choose to do so.) > > > > So to me the open question is whether we consider enumeration of > > external PSK identifiers to be something we can address reasonably > > at this stage of the document's lifecycle at all. (I also note that > > the presence of a CVE number for a similar issue does not > > necessarily mean anything -- CVE assignments can occur for > > situations with no actual security impact and/or against the wishes > > of the software authors.) I don't think anyone has proposed a > > minimal change that would close the enumeration channel, and given > > that external PSKs already have bad privacy properties, it seems > > like we may just have to accept this state of affairs for this > > document. > > That's a good general remark, but not really the case for the > vulnerabilities that Hubert pointed out. > > > Hubert also says: > > > > % so there's no reliable way to say that, yes, this identity is or is > > not a > > % resumption ticket, if I can't decrypt it > > > > Mostly. External PSKs are established out of band, and that > > provisioning process *could* include knowledge that the > > obfuscated_ticket_age would always be zero when those PSKs are in > > use, and that would be reliable for those specific parties. > > I believe that this can happen in an interoperable way if the protocol > mandates it (which is not the case now). These specific parties may use > software from different vendors which may use different conventions if > the protocol is not clear enough. > > > It's probably also worth considering the two cases for server > > behavior when presented with a PSK id that is neither a known > > external PSK nor a known resumption ticket -- the server could > > either treat it as an unknown external PSK id or as a resumption > > ticket that fails to decrypt. The latter case fails because the > > attacker can try candidate external identities and the server falls > > back to a full handshake unless the PSK ID is good. (Well, maybe > > the server rejects PSK IDs that are shorter than a ticket would be.) > > The first case is not really usable since it would lead to spurious > > triggering of the proposed "at most one external PSK" check. > > > > So, in addition to the "we provision external PSKs only when we know > > that obfuscated_ticket_age will be zero", deployments could also > > agree that external PSK ids are shorter than a given length and > > resumption PSKs are larger, which would again provide a reliable > > differentiator between resumption and external. > > That cannot easily happen. I can have multiple servers answering to the > same hostname each using a different implementation. Any conventions > used in one implementation would not apply to another. > > > % I'd really prefer we exhaust other possibilities before sacrificing > > support > > % for multiple external PSK. With TLS 1.2 we had ticket_hint to guide > > PSK > > % selection, now we're left with just server IP or hostname. > > > > I think that "do nothing and accept external PSK enumeration as a > > risk" is more likely than sacrificing support for multiple external > > PSKs, personally. > > The problem is that you personally are not affected by that risk and I > guess that makes it easy for you to accept it. TLS1.2 with PSK did > explicitly prevent enumeration (by asking implementations to proceed to > handshake even with unknown usernames, and making up a key), meaning > that this is a risk that the designers of PSK (external) intentionally > ruled out. Going that path, it would be a step back in PSK security for > TLS1.3. > Nikos, Just as a clarification, I believe it's possible for a PSK-only implementation to avoid this attack by behaving uniformly for "unknown ID" and "invalid binder" -Ekr > regards, > Nikos > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
