[TLS] a slightly different DTLSShortCiphertext
Hi all, In an off-list discussion on the wire format for DTLS CID Eric raised the point that a DTLSShortCiphertext header is completely stuffed, and it'd be impossible to grab another bit from the sequence number (already down to 12 bits) to signal the presence of a CID. I made a proposal for a slightly different layout of DTLSShortCiphertext that makes room for the CID bit, which I'd like to bring to the list for further scrutiny: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1|E|C|X|X|X|sequence | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | | + [CID,] encrypted_record + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 Where: - First 4 bits are the same as in current DTLSShortCiphertext (demux + low order epoch bit) - Subsequent 4 bits are: C, the connection-id indicator followed by 3 reserved bits (to be greased, I suppose) - Then, a 16-bit sequence number. It'd still be 4 bytes shorter than usual DTLSCiphertext, so I guess it's OK to keep calling it "short". There is the question about these 3 reserved bits, which seem like good candidates for greasing, I guess. What do people think? Cheers, thanks ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Thu, 1 Mar 2018, Shumon Huque wrote: I do not know if the draft authors and/or WG have an appetite to do the much more major change suggested by Viktor (i.e in-protocol pinning TTL commitment and requiring subsequent denial of existence proof if DANE is removed). I think it is worth discussing in London and/or some people meeting up to talk about this and bring something to the list/WG. The original idea of this extension I believe (and one of my reasons behind writing RFC 7901) was to provide an alternative path for DNS that couldn't be blocked or broken and that provides DNS answers without additional latency. To me, that always included proof of non-existence, as it would come in as the answer to a DNS chain-query via TLS headers as the transport. I don't know why this got turned into something that is almost like DNS but not quite DNS. I think that is a mistake. The TLS extension should be nothing more (and nothing less) than stappled DNS suitable for a DNS routines. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
Hi folks, This is way outside the range of my DISCUSS, so maybe we should change the thread title. Paul, can you walk me through the security value of a proof of nonexistence here? Perhaps describe an attack that it stops. -Ekr On Sat, Mar 3, 2018 at 7:09 PM, Paul Wouters wrote: > On Thu, 1 Mar 2018, Shumon Huque wrote: > > I do not know if the draft authors and/or WG have an appetite to do the >> much >> more major change suggested by Viktor (i.e in-protocol pinning TTL >> commitment >> and requiring subsequent denial of existence proof if DANE is removed). >> > > I think it is worth discussing in London and/or some people meeting up > to talk about this and bring something to the list/WG. > > The original idea of this extension I believe (and one of my reasons > behind writing RFC 7901) was to provide an alternative path for DNS > that couldn't be blocked or broken and that provides DNS answers without > additional latency. To me, that always included proof of non-existence, > as it would come in as the answer to a DNS chain-query via TLS headers > as the transport. > > I don't know why this got turned into something that is almost like DNS > but not quite DNS. I think that is a mistake. > > The TLS extension should be nothing more (and nothing less) than > stappled DNS suitable for a DNS routines. > > Paul > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
[ Not replying for Paul, I'm sure he he'll post views separately ] > On Mar 3, 2018, at 10:21 PM, Eric Rescorla wrote: > > Paul, can you walk me through the security value of a proof of nonexistence > here? Perhaps describe an attack that it stops. My take is: Non-existence proofs can clear a pinned DANE policy, where a client would other require ongoing delivery TLSA records (after initially seeing them from the server). The data would not be pinned, that's what the DNSSEC signed TLSA records are for. The attack in question is downgrade to just PKIX (with fraudulently obtained certificates). Such a downgrade makes PKIX-TA(0) and PKIX-EE(1) ineffective, and downgrades DANE TlSA to DV certs which are strictly weaker. Therefore, if the extension were to include an extended pin-TTL, then denial of existence becomes useful, and indeed the pinning is primarily a means to make it downgrade-resistant. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
