[TLS] open issues for draft-ietf-tls-chacha20-poly1305-00
Hi, An open issue for draft-ietf-tls-chacha20-poly1305-00 raised by Eric Rescorla is that this draft doesn't use the draft-TLS 1.3 mechanism for setting the nonce per record [0]. Is there any support for switching these ciphersuites to draft-TLS 1.3 nonce mechanism even for TLS 1.2? The alternative is to use the TLS 1.2 mechanism with the redundant bytes redacted as the draft is now [1]. Are there any other issues than the listed above which may prevent early code point assignment? [0]. https://www.ietf.org/mail-archive/web/tls/current/msg16374.html [1]. https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-00 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 0-RTT & resumption
On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara < ilari.liusva...@elisanet.fi> wrote: > On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote: > > > > > > We agreed on how to do this in Prague. The sticking point was > establishing > > the cipher suite. I have WIP text on my machine for both of these which I > > will be > > sending early next week, once I get enough sleep to be able to clean it > up, > > so I'd ask people to sit tight till then. > > > > Okay, now the PR (#211) seems to be up, let's review Oops. It wasn't supposed to be done. I meant to make it a PR against my own branch so that I could get early comments from MT, but obviously that didn't work out. Regardless, thanks for your comments. - Lacks client-driven client authentication[1]. All client auth is server > driven, which I think isn't very useful in real world (there are all > sorts of bad hacks[2] trying to work around lack of client-driven auth). > This is just extending existing practice for 1-RTT handshakes. I tend to agree with you that it would be good to change that, but I didn't want to do that in this PR, because it would be a big semantic change in TLS. I suggest you start a new thread on this topic, or perhaps add it to Andrei's client auth thread? - EncryptedExtensions looks to be mandatory in some exchanges, optional > in others. I agree it should be mandatory in all (issue #213). > Me too. That's just editing error. > - "The client's cryptographic determining parameters match the parameters > that the server has negotiated based on the rest of the ClientHello." > ... Does that mean the client has to guess what ciphersuite the server > will choose (more than pure-PSK vs. GDHE, which is unvaoidable with > just one encrypted block)? > The client knows what the server selected based on his previous offer and the server's configuration (which by hypothesis is still extant) so the server should choose the same value again. > - Am I reading the syntax wrong, or does the extensions field in server > configuration only allow exactly one extension (shouldn't it be zero > or more)? > Yes. good catch. Also, regarding issue #212, unless the Certificate is handled specially, > it would mean that the signature does not cover certificate. And not > signing the certificate (esp. the public key within) causes problems > in some exotic cases (I don't know if any of those cases pop up in TLS > 1.3). > This seems like a good argument. > I think it would simplify the security analysis a bit if CertificateVerify > was always immediately before Finished and covered everything before that > point. > Isn't this always the case presently? Are you just thinking we should say it's a rule? -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
On 3 August 2015 at 17:21, Andrei Popov wrote: >> use CertificateRequest within the handshake, and the new content type >> outside of it > > Would the client then also use this new content type for Certificate and > CertificateVerify messages (when these are sent after the handshake is > complete)? Yeah, I think that's best. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00
On 4 August 2015 at 05:37, Nikos Mavrogiannopoulos wrote: > Is there any support for > switching these ciphersuites to draft-TLS 1.3 nonce mechanism even for > TLS 1.2? The alternative is to use the TLS 1.2 mechanism with the > redundant bytes redacted as the draft is now [1]. Personally, I would rather see the nonce construction follow the form defined in the respective TLS version. That means including redundant bytes in TLS 1.2 and only getting the full advantage when we move to TLS 1.3. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00
> Personally, I would rather see the nonce construction follow the form > defined in the respective TLS version. Yes, consistency. +1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
I'm not opposed to using a new content type in this way, if folks feel that this makes things better. Cheers, Andrei -Original Message- From: Martin Thomson [mailto:martin.thom...@gmail.com] Sent: Tuesday, August 4, 2015 9:13 AM To: Andrei Popov Cc: tls@ietf.org Subject: Re: [TLS] Review of PR #209 On 3 August 2015 at 17:21, Andrei Popov wrote: >> use CertificateRequest within the handshake, and the new content type >> outside of it > > Would the client then also use this new content type for Certificate and > CertificateVerify messages (when these are sent after the handshake is > complete)? Yeah, I think that's best. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00
On Tue, Aug 4, 2015 at 12:20 PM Salz, Rich wrote: > > Personally, I would rather see the nonce construction follow the form > > defined in the respective TLS version. [DB: Adding back in for context: > "That means including redundant bytes in TLS 1.2 and only getting the full > advantage when we move to TLS 1.3."] > > Yes, consistency. +1 > I think this already came up: https://www.ietf.org/mail-archive/web/tls/current/msg16365.html This is a waste of bandwidth. Consistency is generally good, but a weak argument here. The complexity is minimal. If you don't care about decrypting in-place, none of this matters. If you do care, you already have to deal with: - RC4 and TLS 1.0 CBC use no prefix on the ciphertext - AES-GCM, TLS 1.1+ 3DES use an 8-byte prefix - TLS 1.1+ AES CBC use a 16-byte prefix Adding a 0-byte prefix cipher doesn't make anything worse. It already must vary. As for following what's defined in TLS 1.2, RFC 5246 just says that GenericAEADCipher has a nonce_explicit field and: Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the GenericAEADCipher.nonce_explicit part. It then describes the 1.2 AES-GCM scheme, but prefaced with "In many cases, it is appropriate to [...]". Saying nonce_explicit is empty and the nonce is built from the sequence number is perfectly consistent here. David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00
On 4 August 2015 at 10:24, Wan-Teh Chang wrote:
> The consistency you want to see seems to be
> consistency with the AES GCM cipher suites, rather than with TLS 1.2.
Yes, this is correct.
RFC 5288:
struct {
opaque salt[4];
opaque nonce_explicit[8];
} GCMNonce;
RFC 6655:
struct {
opaque salt[4];
opaque nonce_explicit[8];
} CCMNonce;
Interestingly, RFC 6655 removes the explicit nonce for DTLS, but DTLS
only (if I'm reading it correctly).
Either way, I think that we should attempt to be consistent with
these. Which suggests that perhaps we can adopt a zero-length
explicit nonce and borrow the 6655 DTLS construction.
As for the wasted bytes, I don't care for that. We will fix that later.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
