Subject: [ANNOUNCE] new release of the ParrotTalk protocol specification, version 3.7

From: Robert <[email-masked]>
Date: Tue, 20 Nov 2018 06:09:04 +0000

Please read my Facebook post introducing the features of the new version 3.7 protocol of ParrotTalk, now a 5 message handshake, 3 messages like TLS 1.3 and an initial 2 message negotiation to determin which version of the protocol to use. My release of the Squeak/Pharo implementation which is capable of supporting both v3.6 and v3.7 in the same SessionAgent, spawning Sessions with either version, based on the negotiation. The Java version at https://github.com/CallistoHouseLtd/ParrotTalk can only talk v3.6 right now. The interesting feature of the Squeak/Pharo implementation is that it supports version negotiation for either version. Tests are all green.

https://www.facebook.com/robert.withers

best regards,
Robert

---

From: Robert <[email-masked]>
Date: Tue, 20 Nov 2018 06:21:41 +0000

My apologies. Here is the direct link to my post: https://www.facebook.com/robert.withers/posts/2245642509052313

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

---

From: Robert <[email-masked]>
Date: Tue, 20 Nov 2018 16:36:58 +0000

I am unsure why Facebook is considered a violation of what a sensible person would reach to, as it is not any sort of phishing scam. I also have a github project (https://github.com/CallistoHouseLtd/ParrotTalk) and the README.MD should prove descriptive. To satisfy your curiousity regarding what ParrotTalk is here is a description.

ParrotTalk is an encrypted connection framework. Currently allowing anonymous 2048-bit key negotiation to establish user-provided encryption cipher and user-provided encoding and decoding, both through a provided SessionAgentMap to a starting SessionAgent server. Please look in the test case ThunkHelloWorldTest for building these maps and running a connection iwth data passing after encryption is established. There is a 4-way negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048 signature validation and DH 2048 primes to establish the key used within the selected Cipher. The Cipher and Encoder are selected by name through the negotiation protocol. Currently three Ciphers are selectable, AESede, DESede, and DES. There are two encoders tested, asn1der, and Bytes. This protocol is described here, in these documents.

The two protocol documents v3.6 and v3.7 are hosted on github:
https://github.com/CallistoHouseLtd/ParrotTalk/blob/master/docs/ParrotTalkFrameDesign-3.7.pdf

and
https://github.com/CallistoHouseLtd/ParrotTalk/blob/master/docs/ParrotTalkFrameDesign-3.6.pdf

Here is the IETF draft I wrote up for version 3.6, though not yet updated for version 3.7. The slides should suffice:

https://github.com/CallistoHouseLtd/ParrotTalk/blob/master/docs/draft-withers-parrot-talk-v36-00.pdf

Kindly,
Robert

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 20, 2018 8:44 AM, Ted Lemon <[email-masked]> wrote:

> It would help to give enough information about what ParrotTalk is so that we know whether it's worth visiting the link.   However, that's moot, since it's a facebook link, and no sensible person is going to visit it.
>
> On Tue, Nov 20, 2018 at 1:09 AM Robert <robert.withers=[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Nov 2018 11:31:33 -0800

Robert,

I took a quick look at this document. To be honest, it's a bit hard to make
sense of. There's quite a bit of code and code-like stuff, abd not very
much text. So, for instance, looking at page 18, I see "sharedKey :=
diffieHellman sharedKeyPadPositiveByteArray", but I don't see definitions
for either diffieHellman or sharedKeyPadPositiveByteArray, so I don't know
how to do this computation. If you would like people to provide opinions on
this document, you will probably need to flesh it out more.

With that said, a preliminary question: can you expand on the ways in which
you believe this protocol to be superior to other Authenticated Key
Agreement protocols that we have already standardized in IETF, such as IKE,
SSH, or TLS?

-Ekr

On Tue, Nov 20, 2018 at 8:37 AM Robert <robert.withers=
[email-masked]> wrote:

> I am unsure why Facebook is considered a violation of what a sensible
> person would reach to, as it is not any sort of phishing scam. I also have
> a github project (https://github.com/CallistoHouseLtd/ParrotTalk) and the
> README.MD should prove descriptive. To satisfy your curiousity regarding
> what ParrotTalk is here is a description.
>
> ParrotTalk is an encrypted connection framework. Currently allowing
> anonymous 2048-bit key negotiation to establish user-provided encryption
> cipher and user-provided encoding and decoding, both through a provided
> SessionAgentMap to a starting SessionAgent server. Please look in the test
> case ThunkHelloWorldTest for building these maps and running a connection
> iwth data passing after encryption is established. There is a 4-way
> negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048
> signature validation and DH 2048 primes to establish the key used within
> the selected Cipher. The Cipher and Encoder are selected by name through
> the negotiation protocol. Currently three Ciphers are selectable, AESede,
> DESede, and DES. There are two encoders tested, asn1der, and Bytes. This
> protocol is described here, in these documents.
>
> Here is the IETF draft I wrote up for version 3.6, though not yet updated
> for version 3.7. The slides should suffice:
>
>
>
> It would help to give enough information about what ParrotTalk is so that
> we know whether it's worth visiting the link.   However, that's moot, since
> it's a facebook link, and no sensible person is going to visit it.
>
>> Please read my Facebook post introducing the features of the new version
>> 3.7 protocol of ParrotTalk, now a 5 message handshake, 3 messages like TLS
>> 1.3 and an initial 2 message negotiation to determin which version of the
>> protocol to use. My release of the Squeak/Pharo implementation which is
>> capable of supporting both v3.6 and v3.7 in the same SessionAgent, spawning
>> Sessions with either version, based on the negotiation. The Java version at
>> https://github.com/CallistoHouseLtd/ParrotTalk can only talk v3.6 right
>> now. The interesting feature of the Squeak/Pharo implementation is that it
>> supports version negotiation for either version. Tests are all green.
>>

---

From: Robert <[email-masked]>
Date: Wed, 21 Nov 2018 11:34:54 +0000

Yes, I should add the parameters used for difffieHellman. It is standard DH key exchange with a generator of 2 and the prime is prime from rfc3526: 2048-bit MODP Group (https://tools.ietf.org/html/rfc3526#section-3). SharedKeyPadPositiveByteArray, adds an intial 0 if the bytes are 2s complement negative. This matches the byteArray produced by Java's diffieHellman.

I will try to give my opinion why this protocol is superior. It is a minimal protocol to establish an encrypted connection. I view it as a positive that it does not use Certificates, you just need public and private keys for each agent. While being minimal, the protocol still allows negotiation of the cipher used and the encoder used. I use this protocol as the session layer beneath my distributed capabilities layer, called Raven. I have implemented SSL and SSH before. You can find them in the Cryptography repository for Squeak/Pharo, although they are broken at this time. I am considering porting these onto the ThunkStack design of ParrotTalk. For myself, that is the real advantage of the ParrotTalk protocol is its implementation in Squeak/Pharo and its Java implementation. I would suggest that you load the code and explore the design. After many iterations I came up with the ThunkStack, managing the connection. The other aspect which is a strong advantage is that all the headers used in the message flow are defined as ASN1 structures, so this represents a solid standard for messaging to bring about the minimal protocol. With my Java code, one can see the ASN1 encoder and the ParrotTalk impl can be easily ported to new languages, thus my one issue with ParrotTalk is to implement in C, C++, C#, Objective-C, Rust, Dart, etcetera. Port ASN1 then port ParrotTalk. Currently, ParrotTalk in Squeak/Pharo and Java are bit-compatible and interoperable.

A frame has this structure:
{ 8-byte frame spec | ASN1 Header | [payload] }

A data frame over the wire looks like this with frame embedding:
{8-byte spec | MAC (20-byte mac) | [ spec | Encrypted (ivSequence) | [ spec | Encoded | [ spec | RawData | [ RavenMessage ] ] ] ] }

Regarding the comm stack, during Rendezvous, prior to an encrypted connection settling, here is what the stack looks like with the send buffering thunk and the SessionOperations managing the state machine and the SecurityOps for rendezvous negotiation
1: RavenTerminal
2: Session
3: SendFramesBuffer
4: SessionOperations (SecurityOps)
5: ReceivingFrameBuffer
6: SocketThunk

And when rendezvous completes the fully encrypted stack looks like this:
1: RavenTerminal
2: Session
3: EncoderThunk (for de/serialization)
4: CustomsThunk (for MAC validation)
5: CipherThunk (for encryption)
6:; ImmigrationThunk (for MAC access)
7: SessionOperations (SecurityOps cleared)
8: ReceivingFrameBuffer
9: SocketThunk
When I find the time and motivation, I may work SSL and SSH into the ThunkStack design as both implementations in the Cryptography repository are BROKEN. In porting SSL (TLS 1.2) I may extend to the new TLS 1.3, which has a quick three msg negotiation.

I primarily documented both versions of the ParrotTalk protocol in two slideshows in the specified PDFs from my earlier msg and documented in the readme.MD.

I hope I answered your questions to your satisfaction.

Best,
Robert
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 20, 2018 2:31 PM, Eric Rescorla <[email-masked]> wrote:

> Robert,
>
> I took a quick look at this document. To be honest, it's a bit hard to make sense of. There's quite a bit of code and code-like stuff, abd not very much text. So, for instance, looking at page 18, I see "sharedKey := diffieHellman sharedKeyPadPositiveByteArray", but I don't see definitions for either diffieHellman or sharedKeyPadPositiveByteArray, so I don't know how to do this computation. If you would like people to provide opinions on this document, you will probably need to flesh it out more..
>
> With that said, a preliminary question: can you expand on the ways in which you believe this protocol to be superior to other Authenticated Key Agreement protocols that we have already standardized in IETF, such as IKE, SSH, or TLS?
>
> -Ekr
>
> On Tue, Nov 20, 2018 at 8:37 AM Robert <robert.withers=[email-masked]> wrote:
>
>>> It would help to give enough information about what ParrotTalk is so that we know whether it's worth visiting the link..   However, that's moot, since it's a facebook link, and no sensible person is going to visit it.
>>>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Nov 2018 07:44:21 -0800

On Wed, Nov 21, 2018 at 3:35 AM Robert <[email-masked]> wrote:

> Yes, I should add the parameters used for difffieHellman. It is standard
> DH key exchange with a generator of 2 and the prime is prime from rfc3526:
> 2048-bit MODP Group (https://tools.ietf.org/html/rfc3526#section-3).
> SharedKeyPadPositiveByteArray, adds an intial 0 if the bytes are 2s
> complement negative. This matches the byteArray produced by Java's
> diffieHellman.
>

OK. You should specify this. I would like to note two points here:

- I do not see nonces being mixed in. This is potentially safe if you
guarantee fresh DH shares for each connection, but if both sides replay
their DH shares (which I don't see you forbidding), then you have some very
serious key reuse problems. For this reason, you would be better served to
add some nonces. Perhaps I missed something.
- It's generally not a good idea to assume that the DH function provides
contributive behavior. If you compare to (e.g., TLS 1.3), you will see that
the current style is to mix in most of the protocol transcript.

> I will try to give my opinion why this protocol is superior. It is a
> minimal protocol to establish an encrypted connection. I view it as a
> positive that it does not use Certificates, you just need public and
> private keys for each agent.
>

This is possible to do with TLS as well, using RFC 7250.

. For myself, that is the real advantage of the ParrotTalk protocol is its
> implementation in Squeak/Pharo and its Java implementation. I would suggest
> that you load the code and explore the design.
>

I doubt that I or others are likely to do that. If you want people to
review your protocol, it's usually necessary to produce a sufficiently
clear document that they are able to understand the document without
reference to the code. As I indicated in my previous message, in my opinion
that is not the case for the document as-is.

After many iterations I came up with the ThunkStack, managing the
> connection. The other aspect which is a strong advantage is that all the
> headers used in the message flow are defined as ASN1 structures, so this
> represents a solid standard for messaging to bring about the minimal
> protocol. With my Java code, one can see the ASN1 encoder and the
> ParrotTalk impl can be easily ported to new languages, thus my one issue
> with ParrotTalk is to implement in C, C++, C#, Objective-C, Rust, Dart,
> etcetera. Port ASN1 then port ParrotTalk. Currently, ParrotTalk in
> Squeak/Pharo and Java are bit-compatible and interoperable.
>

This form of interoperability is generally a property of all the protocols
we design, regardless of the language used to specify the protocol.

As you observe, it is often helpful to specify the protocol messages (PDUs)
for a protocol in a formal language, and depending on the relative
complexity of the PDUs compared to the complexity of the language, this
might or might not minimize implementation effort. For instance, TLS is
specified in such a language [0] though IKE is not (it uses bit diagrams).
Of course, it is also possible to retroactively design formal languages
which allow you to express PDU formats which were previously expressed in
bit diagrams and the like. So I'm not sure if I perceive this to be a
sufficiently large advantage to justify designing an entirely new AKE.

-Ekr

[0] And in fact I believe that there is at least one TLS implementation
which processes the formal language more or less directly.

> {8-byte spec | MAC (20-byte mac) | [ spec | Encrypted (ivSequence) | [
> spec | Encoded | [ spec | RawData | [ RavenMessage ] ] ] ] }
>
>
>
> Regarding the comm stack, during Rendezvous, prior to an encrypted
> connection settling, here is what the stack looks like with the send
> buffering thunk and the SessionOperations managing the state machine and
> the SecurityOps for rendezvous negotiation
> 1: RavenTerminal
> 2: Session
> 3: SendFramesBuffer
> When I find the time and motivation, I may work SSL and SSH into the
> ThunkStack design as both implementations in the Cryptography repository
> are BROKEN. In porting SSL (TLS 1.2) I may extend to the new TLS 1.3, which
> has a quick three msg negotiation.
>
> I primarily documented both versions of the ParrotTalk protocol in two
> slideshows in the specified PDFs from my earlier msg and documented in the
> readme.MD.
>
> I took a quick look at this document. To be honest, it's a bit hard to
> make sense of. There's quite a bit of code and code-like stuff, abd not
> very much text. So, for instance, looking at page 18, I see "sharedKey :=
> this document, you will probably need to flesh it out more..
>
> With that said, a preliminary question: can you expand on the ways in
> which you believe this protocol to be superior to other Authenticated Key
>> a github project (https://github.com/CallistoHouseLtd/ParrotTalk) and
>> the README.MD should prove descriptive. To satisfy your curiousity
>> regarding what ParrotTalk is here is a description.
>>
>> we know whether it's worth visiting the link..   However, that's moot,
>> since it's a facebook link, and no sensible person is going to visit it.
>>

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 21 Nov 2018 19:08:39 +0300

Hi,

I will try to give my opinion why this protocol is superior. It is a minimal protocol to establish an encrypted connection. I view it as a positive that it does not use Certificates, you just need public and private keys for each agent. 

          IKEv2 also supports raw public keys (RFC7670). And it can be profiled to extremely 

          simple protocol, maintaining interoperability with full-featured spec (see RFC7815).

          Regards,

          Valery Smyslov.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Nov 2018 17:31:37 +0100

Hi Robert,

maybe adding to all the good comments that Eric Rescorla gave, this one statement stuck out for me:

> On Nov 21, 2018, at 12:34, Robert <robert.withers=[email-masked]> wrote:
> 
> strong advantage is that all the headers used in the message flow are defined as ASN1 structures

There are quite a few people who would perceive this as a disadvantage.  ASN.1 (or X.409, as it was called then) was a great new idea in 1983, but 35 years later we now know more about its downsides (and, not to forget, those of its dominating set of encoding rules, BER).  If you want to stay close to the PKI, it may seem natural to continue to use it, but it seems you count freedom from X.509 certificates as a feature, and that would bring you closer to newer formats such as CBOR and COSE (RFC 8152), which you may want to look at.

Obviously, representation formats are much less important than the security properties of the protocol itself, which I cannot comment on as I haven’t seen it.  They still can be an important factor in implementation stability and interoperability, as we have for example experienced when ASN.1 helped sink H.323 some 20 years ago.  But there is also a security aspect, which you can gauge by counting the number of CVEs that mention ASN.1 decoder implementations.

Grüße, Carsten

---

From: Robert <[email-masked]>
Date: Wed, 21 Nov 2018 23:59:11 +0000

Hello Eric,

I have updated the IETF document. You are absolutely right, I derived this document from my implementations and much of it is still code pastes to document the hash padding, for instance. I went through and changed to the describing the message structures to now be proper ASN1 Structure definitions, but there are still many code pastes from Squeak and Java.

I added the text describing the Diffie Hellman Key Exchange is in Section 6.1 on page 12.

https://github.com/CallistoHouseLtd/ParrotTalk/blob/master/docs/draft-withers-parrot-talk-v36-01.pdf

I am sure I do not understand how to go about adding nonces, to the DH Key Exchange. Could you speak to how I should create and use them, please?  I am using this Java code to generate a secret:

SecureRandom random = SecureRandom.getInstance("SHA1PRNG");
secret = definitePrime(prime.bitLength(), random);

I am unsure how to add Nonces. If nonces would produce more reliable security, I am all for adding it if I knew how. As well, I hear you say I should mix in the protocol transcript, by which I think you mean the bytes sent over the wire up to this point. I am using such transcript bytes in calculating the signature. Are you suggesting I add them into the DH calculation of the secret?

You see, I am very implementation focussed and not very bright when it comes to the abstract level of discussing security. I took this protocol from the VatTP of Erights.org and modified it somewhat. (I removed the searchPath). I am very grateful for you all taking the time to consider my proposal and giving me such good feedback.

Humbly,
Robert

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, November 21, 2018 10:44 AM, Eric Rescorla <[email-masked]> wrote:

> - I do not see nonces being mixed in. This is potentially safe if you guarantee fresh DH shares for each connection, but if both sides replay their DH shares (which I don't see you forbidding), then you have some very serious key reuse problems. For this reason, you would be better served to add some nonces. Perhaps I missed something.
> - It's generally not a good idea to assume that the DH function provides contributive behavior. If you compare to (e.g., TLS 1.3), you will see that the current style is to mix in most of the protocol transcript.
>
>> . For myself, that is the real advantage of the ParrotTalk protocol is its implementation in Squeak/Pharo and its Java implementation. I would suggest that you load the code and explore the design.
>
> I doubt that I or others are likely to do that. If you want people to review your protocol, it's usually necessary to produce a sufficiently clear document that they are able to understand the document without reference to the code. As I indicated in my previous message, in my opinion that is not the case for the document as-is.
>
>> After many iterations I came up with the ThunkStack, managing the connection. The other aspect which is a strong advantage is that all the headers used in the message flow are defined as ASN1 structures, so this represents a solid standard for messaging to bring about the minimal protocol. With my Java code, one can see the ASN1 encoder and the ParrotTalk impl can be easily ported to new languages, thus my one issue with ParrotTalk is to implement in C, C++, C#, Objective-C, Rust, Dart, etcetera. Port ASN1 then port ParrotTalk. Currently, ParrotTalk in Squeak/Pharo and Java are bit-compatible and interoperable.
>
> This form of interoperability is generally a property of all the protocols we design, regardless of the language used to specify the protocol.
>
> As you observe, it is often helpful to specify the protocol messages (PDUs) for a protocol in a formal language, and depending on the relative complexity of the PDUs compared to the complexity of the language, this might or might not minimize implementation effort. For instance, TLS is specified in such a language [0] though IKE is not (it uses bit diagrams). Of course, it is also possible to retroactively design formal languages which allow you to express PDU formats which were previously expressed in bit diagrams and the like. So I'm not sure if I perceive this to be a sufficiently large advantage to justify designing an entirely new AKE.
>
> -Ekr
>
> [0] And in fact I believe that there is at least one TLS implementation which processes the formal language more or less directly.
>

---

From: Robert <[email-masked]>
Date: Thu, 22 Nov 2018 00:24:05 +0000

Hello Valery,

I have never looked at IKE. I have implemented TLS 1.2 (http://www.squeaksource.com/Cryptography/SSL-CDavidShaffer.19.mcz) and SSH (http://www.squeaksource.com/Cryptography/SSH-rww.12.mcz), but they are both currently broken for some reason. It has been a number of years since I revisited them, and now I am thinking of porting them to the ThunkStack design of ParrotTalk. I would need a new ReceivingFrameBuff for them as ParrotTalks frames are different than either of those protocols. And of course a specific SessionOperations managing the state machine and message processing of each protocol. As I have said I am an implementation guy, as I think the code documents itself and test cases document the usage of the protocol. I really like to see them running in Squeak, but decided to shoot for interoperability with Java. Long ago Squeak Community decided correctly to use OpenSSL, as it is tested, approved and accepted.

Best,
Robert

---

From: Robert <[email-masked]>
Date: Thu, 22 Nov 2018 00:29:36 +0000

Hallo Carsten,

Yes, I wanted to solidify the structure definitions of ParrotTalk with ASN1, which I wrote an encoder for many years ago in Squeak, found in this package (http://www.squeaksource.com/Cryptography/Cryptography-rww.115.mcz). Once I defined Choice, then all my headers became parsable and with Explicit tagging I could decode any header. It actually makes the ProtocolOffered/ProtocolAccepted unneeded, as the first message header decodes to either a v3.6 header (IWant) or a v3.7 header Hello_v3_7, and my protocol selector state machine can determine which version is in use. This is entirely due to using ASN1 DER encoding. I ported my ASN1 encoder to Java to be able to provide identical structure definitions, in code. I like it better than annotation based ASN.1.

https://github.com/CallistoHouseLtd/ASN1

I would ask those interested in implementations to load up my code and see my design. That is the strong suit I have, are the implementations.

Along with IKE I should look at CBOR and COSE.

Cheers,
Robert

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, November 21, 2018 11:31 AM, Carsten Bormann <[email-masked]> wrote:

> > On Nov 21, 2018, at 12:34, Robert robert.withers=[email-masked] wrote:

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 23 Nov 2018 19:04:55 -0600

Hi Robert,

I have two comments:

(1) You keep referring to an "IETF document", but linking to a PDF in a
github repo.  This is pretty jarring, as the normal IETF workflow is to
submit an internet-draft to the IETF datatracker (via
https://datatracker.ietf.org/submit/) and then we can use normal IETF tools
for viewing the document.  If there is no submitted I-D or intent to do so,
the work should not be called an "IETF document".  (In some usages of the
term, an "IETF document" would further need to be adopted by an IETF WG (or
similar) for the term to apply.)

(2) This list is the general IETF discussion list, with the list charter
at https://tools.ietf.org/html/rfc3005 .  Given that you are talking about
a new (to the IETF) key exchange protocol, I would suggest taking the
discussion to a more topical list, e.g., [email-masked], rather than
subjecting the entire IETF discusion list to this traffic, which is in
effect preliminary technical discussions that are likely to only be of
interest to those interested in the more specific topical area.

-Ben