Re: [tcpm] public-private keys for TCP-AO

You’d want basically one per connection (the point is to avoid reusing them). You’d be surprised how many connections a pair of endpoints use over time.

Joe

> On Oct 29, 2018, at 7:00 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> 
> There are use cases where I don't need to generate a LOT.
> One a month should be just fine, because I have no fear of them leaking into enemy hands.
> I posit that distributing one shared secret key is a LOT harder than distributing 1000 public keys.
>  
> Regards,
> Jakob.
>  
> From: Joe Touch <touch@strayalpha.com <mailto:touch@strayalpha.com>> 
> Sent: Monday, October 29, 2018 6:49 PM
> To: Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com>>
> Cc: tcpm@ietf.org <mailto:tcpm@ietf.org>
> Subject: Re: [tcpm] public-private keys for TCP-AO
>  
>  
> 
> 
> On Oct 29, 2018, at 6:41 PM, Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com>> wrote:
>  
> Because distributing public keys is easier.
> Private keys don't need to be distributed. They stay inside the machine that generates them.
>  
> Sure, but you need to generate private/public key pairs on both sides of the connection - many of them - and then distribute them to both sides. I.e., the work gets a LOT larger.
>  
>  
> Distributing and safe guarding symmetric keys is a major hassle.
>  
> Agreed, but you only need one such shared key between each endpoint pair because you can derive session keys algorithmically.
>  
> You can certainly TRY to work out the details as you suggest, but I suspect the number of keys needed would be prohibitive even for a single pair of endpoints.
>  
> Joe
> 
> 
>  
> Regards,
> Jakob.
>  
> From: Joe Touch <touch@strayalpha.com <mailto:touch@strayalpha.com>> 
> Sent: Monday, October 29, 2018 6:37 PM
> To: Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com>>
> Cc: tcpm@ietf.org <mailto:tcpm@ietf.org>
> Subject: Re: [tcpm] public-private keys for TCP-AO
>  
>  
> 
> 
> 
> On Oct 29, 2018, at 6:22 PM, Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com>> wrote:
>  
> Can you think of a way to do it that will work?
> Like the KDF is just a static list or something.
> The sender generates a set of key pairs and numbers them.
> It then puts the list of public keys into a file and distributes them to all receivers in the clear.
>  
> You’d have to find a way to specify the use of private and public keys on both sides, in advance, and distribute enough for the upcoming connections - then you’d have to hash into that list in a way that avoids reuse. At that point, why not just distribute symmetric keys and be done with it?
>  
> Joe
>  
> The KDF is just to index into this file.
>  
> Because the use case, at least, makes sense.
>  
> Regards,
> Jakob.
>  
> From: Joe Touch <touch@strayalpha.com <mailto:touch@strayalpha.com>> 
> Sent: Monday, October 29, 2018 6:13 PM
> To: Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com>>
> Cc: tcpm@ietf.org <mailto:tcpm@ietf.org>
> Subject: Re: [tcpm] public-private keys for TCP-AO
>  
>  
> 
> 
> 
> 
> On Oct 29, 2018, at 5:45 PM, Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com>> wrote:
>  
> Why was there not a public-private key algorithm specified for TCP-AO? Or did I miss it?
>  
> There has not been. I doubt it would make sense (see below).
> 
> 
> 
> 
> For example ECC.
> An MKT can specify a private key for the sender and a public key for the receivers.
>  
> Yes, but the MKT is derived into public/private keys using a KDF.
>  
> I am not aware of a KDF that can take a private key and generate a derived private key that would work with a correspondingly derived public key generated from the corresponding public key.
>  
> To use, the sender will hash the data, encrypt the hash and put the result into the MAC field.
> The receiver would decrypt the MAC field, then hash the data and verify the hash against the decrypted MAC.
> This way, the private key never needs to be exposed to anyone, simplifying key management.
> Is there any objection to getting this done?
>  
> See above; it doesn’t make sense with the way TCP-AO derives keys for each connection, AFAICT.
>  
> Joe
> 
> 
> 
> 
>  
> Regards,
> Jakob.
>  
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org <mailto:tcpm@ietf.org>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
>  
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org <mailto:tcpm@ietf.org>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
>  
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org <mailto:tcpm@ietf.org>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
>  
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org <mailto:tcpm@ietf.org>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>