Hi Paul, Regarding the original email, I'm not a fan of (1) as then implementations have to handle receiving two different FQDN IDr's for example. Having something like (2) where the new notify can only appear once and it explicitly is there to select the key sounds best IMHO.
Regarding the hidden-in-TLS feature (I like that name, thanks Paul), I don't think this would help as the goal is to not reply to SA_INIT from an untrusted party so changing the AUTH is too late. David > On Nov 30, 2017, at 05:52, Paul Wouters <[email protected]> wrote: > > On Thu, 30 Nov 2017, Valery Smyslov wrote: > >> Doesn't ID_KEY_ID unambiguously determine the FQDN? > > Yes, but indirectly and incoveniently. > >> Moreover, while ID_KEY_ID is often an opaque data, an FQDN >> reveals perceived responder identity to an active attacker, >> so there are some privacy concerns... > > Any internet-wide opportunistic method depends on some public method to > find public keys, so that information, FQDN or opaque, is available > to the attacker anyway. > > However, come to think of it, the IDr payload could help David for his > hidden-in-TLS feature so it would not depend on PPK. > > Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
