FWIW, I have followed this discussion. I have to say that IBS would not necessarily be my first choice of crypto solutions, particularly in a standards track spec. But it is interesting. I do not mind the definition of a new ICV with IBS. But it does have the issues Stephen and and Martin point out.
I have balloted No-Obj. Jari On 30 Oct 2014, at 11:46, Dearlove, Christopher (UK) <chris.dearl...@baesystems.com> wrote: > I have a number of problems with this (including at some points not being > clear what exactly is being defined), but I'll start with the first major > one. X generates a public key related to SSK. But that's useless, Y does not > know it. The whole point is that X and Y can be in total ignorance of each > other until Y receives a message from X. There is no secure channel from X to > Y to distribute a public key (including not via A). So now how does Y > validate PVT? All Y knows about X is X's identity. > > So you may believe we can do better (this needs to be retaining the key > properties we have here). So far I do not. I don't expect to either, but > we'll see. Note that a system that distributes public keys is a different > tradeoff in the space. A valid one, but not the one here. (It is neither > absolutely better or worse, as each has advantages over the other.) > > I think you are mistaken about the issue with RFC 6507. The issue you have is > that the authority knows all. But we didn't sleepwalk into that. That's > completely known, and acceptable in some cases. This is for use in those > cases. The issue similarly applies to MIKEY-SAKKE (RFC 6509) that is what RFC > 6507 was issued to support. (It also applies to various people offering > IBE-based encryption schemes for email, but that's another story.) > > And it's up front in this draft. From the Introduction > > The disadvantage referred to is that the trusted authority has > complete authority, even more so than a conventional certificate > authority. > > (and the rest of that paragraph). And it's said again in the Security > Considerations section. > > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearl...@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Martin Thomson [mailto:martin.thom...@gmail.com] > Sent: 29 October 2014 18:48 > To: Dearlove, Christopher (UK) > Cc: adr...@olddog.co.uk; draft-ietf-manet-ibs....@tools.ietf.org; > gen-art@ietf.org > Subject: Re: Gen-ART review of draft-ietf-manet-ibs-03 > > ----------------------! WARNING ! ---------------------- This message > originates from outside our organisation, either from an external partner or > from the internet. > Consider carefully whether you should click on any links, open any > attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions on > reporting suspicious email messages. > -------------------------------------------------------- > > On 29 October 2014 03:52, Dearlove, Christopher (UK) > <chris.dearl...@baesystems.com> wrote: >> Any objection that something better can be done needs to provide that >> something better, not just say "asymmetric, therefore something better". > > That's a totally fair comment. I was trying for expediency, since that is > fairly obvious to me. Here's a rough sketch: > > A has the same properties you describe: a secret that only it knows > (KSAK) and a paired public value (KPAK) that it can distribute. > > X generates a secret (analogous to SSK) and passes a signature over some > material (optionally its identity, as you note above, plus the paired public > value) to A. A provides X with a signature over the both the public value > and identity that X can subsequently use to claim that identity to others > with the KPAK (analogous to PVT). X is expected to keep that value secret > also. > > Then X can send message in the form (data || PVT || sig(SSK, data || PVT)), > and Y can validate both sig and PVT to establish that this is valid. > > I'm not saying that this is strictly better. It is more complex; RFC > 6507 seems to cleverly roll the identity of X into the public key it uses to > sign. But this has the property that private keys aren't shared. That means > that you can implement this using an HSM that enforces a strict containment > for keys. It also means that you can establish a parallel bases for trust to > the single authority. > > > I think that this highlights the reason we call out downrefs in the process. > As a standalone information RFC, the abstract presentation of RFC 6507 is > perfectly innocuous. But it's application to a standards track effort does > open questions about suitability. > > You claim that this is an improvement over the status quo, and that is quite > clear. The scheme prevents participants from impersonating each other, which > might not have been possible with a system based on a shared symmetric key. > It does however, require that all trust is placed in an authority. I believe > that we can do better. > > Maybe the property I'm describing here not valuable in the deployment context > this is designed for and maybe this can be addressed by establishing firm > expectations about applicability. Maybe a simple applicability statement > would suffice. That is above my pay grade to decide. I'll defer to the IESG > on this one. > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
