Re: [TLS] [solwo...@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto]

2016-04-11 Thread Kurt Roeckx
On Mon, Apr 11, 2016 at 01:08:39PM -0400, Viktor Dukhovni wrote: > > > On Apr 11, 2016, at 12:36 PM, D. J. Bernstein wrote: > > > > I agree that the original goal of extensible "query types" in DNS (see > > RFC 1034, third paragraph) was ruined by poor implementation work (which > > was in turn

Re: [TLS] [solwo...@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto]

2016-04-11 Thread Eric Rescorla
To add one more point here: the WG was very uncomfortable with having any kind of long-term delegation mechanism, which a static signature of this type would be (though perhaps it would be a weaker form of attack if you required an online signature as part of the handshake, as draft-12 does, in whi

Re: [TLS] [solwo...@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto]

2016-04-11 Thread Eric Rescorla
On Mon, Apr 11, 2016 at 9:36 AM, D. J. Bernstein wrote: > Eric Rescorla writes: > > DNS-based priming is a seemingly attractive concept but unfortunately > isn't > > really workable here, for several reasons: > > 1. It requires DNS security > > No, it doesn't. MinimaLT sticks to the existing X.50

Re: [TLS] [solwo...@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto]

2016-04-11 Thread Viktor Dukhovni
> On Apr 11, 2016, at 12:36 PM, D. J. Bernstein wrote: > > I agree that the original goal of extensible "query types" in DNS (see > RFC 1034, third paragraph) was ruined by poor implementation work (which > was in turn encouraged by other aspects of the DNS protocol design, but > let me not get

Re: [TLS] [solwo...@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto]

2016-04-11 Thread D. J. Bernstein
Eric Rescorla writes: > DNS-based priming is a seemingly attractive concept but unfortunately isn't > really workable here, for several reasons: > 1. It requires DNS security No, it doesn't. MinimaLT sticks to the existing X.509 PKI for easy deployability. The same server key that you're using for

Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto

2016-04-11 Thread Viktor Dukhovni
> On Apr 11, 2016, at 9:05 AM, Martin Rex wrote: > > The TTL of a DNS record is *NOT* protected by DNSSEC, and can be > regenerated at will by an attacker, will be regenerated by intermediate > DNS server and its purpose is purely cache-management, *NOT* security. > > Only the "Signature Expira

Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto

2016-04-11 Thread Salz, Rich
> > Can you compare the TTL of the ephemeral key record with the A/ > > record TTL? Are they related? If someone can get phony records into > > DNS, can they then become the real MLT server? For how long? > > > Admittedly I don't know anything about MLT, but your question indicates > what

Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto

2016-04-11 Thread Martin Rex
Salz, Rich wrote: >> In MinimaLT, the current ephemeral key for the server is added to >> the DNS record fetched during the DNS lookup. These entries expire fairly >> quickly, ensuring that old keys are never used. > > Can you compare the TTL of the ephemeral key record with the > A/ rec

Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto

2016-04-11 Thread Salz, Rich
> In MinimaLT, the current ephemeral key for the server is added to > the DNS record fetched during the DNS lookup. These entries expire fairly > quickly, ensuring that old keys are never used. Can you compare the TTL of the ephemeral key record with the A/ record TTL? Are they relate