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

[Benjamin Kaduk <[e-mail]>]

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., [e-mail], 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

On Wed, Nov 21, 2018 at 11:59:11PM +0000, Robert wrote:
> 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 <[e-mail]> wrote:
> 
> > On Wed, Nov 21, 2018 at 3:35 AM Robert <[e-mail]> 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.
> >
> >> 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 <[e-mail]> 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=[e-mail]> 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.
> >>>>
> >>>> 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 <[e-mail]> 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=[e-mail]> wrote:
> >>>>>
> >>>>>> 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