On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben <bka...@akamai.com> wrote:
> I have reviewed this document and have a few minor comments. I also have > many editorial notes that can be addressed out of band. > > In the abstract and introduction, we have text about the properties that > TLS is expected to provide, like confidentiality, authentication, etc. Do > we want to say anything about avoiding side channels that might leak > information about the data being exchanged? I know that we are not 100% > confident at what exactly we currently achieve in this area, but since we > have mechanisms that attempt to achieve it, maybe it is worth mentioning. > (In a similar vein, as davidben reminded me recently, an attacker “who has > complete control of the network”, as is our stated adversary, can do things > like trickle packets in one by one and try to see, e.g., where the end of > early data is and query handshake state. So some things may not be > avoidable.) > I'd be interested in seeing a PR in this area. In section 4.2.5.1 we talk about how for FFDH peers SHOULD validate each > other’s public key Y by ensuring that 1 < Y < p-1, which is supposed to > ensure that the peer is well-behaved and isn’t forcing the local system > into a small subgroup. Somehow I thought that additional checks were > needed to avoid being forced into a small subgroup, but I guess that > depends on what group it’s in, and I didn’t pull up the RFC 7919 reference > when I was reading this document. > These are the recommendations in 7919, I believe > In section 4.2.7, we note that the server MUST NOT send the > “psk_key_exchange_modes” extension, with the implication that the client > must observer the types of handshake messages that are subsequently > received in order to determine what the server selected. I think that we > had talked about this already some time ago, but just wanted to confirm > that we are okay with increasing the size of the client state machine in > this manner. > It's not subsequent messages. You determine it from the PreSharedKey and KeyShare extensions. > In section 4.5.1 we note that when client auth is not used, servers MAY > compute the remainder of the client-sent messages for the transcript so as > to issue a NewSessionTicket immediately after the server Finished. Do we > want to say anything about why a server might wish to do so? > I think I would rather not. The coverage of record payload protection (around section 5.2) seems to not > always make careful distinction between TLSPlaintext, TLSCiphertext, > TLSInnerPlaintext, and the fields therein. In some sense this is > editorial, but there were a lot of places that I flagged, so I wanted to > call it out to the broader audience and get more eyes on it. I also didn’t > find a description of where the length of the AEAD authentication tag gets > included into a length field for the ciphertext. > I'm not following this point. The way to think about this is that the ciphertext is a specific size. That may be encryption + auth tag or not (it's possible to design an AEAD algorithm that doesn't have a separate auth tag). -Ekr At the end of section 6.1 we have this little note that “it is assumed that > closing a connection reliably delivers pending data before destroying the > transport”, which, if I remember correctly previous discussion on this > list, is not actually true for linux. It is perhaps problematic to have an > assumption that we know is not going to be held for a large proportion of > implementations. > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
