Re: [TLS] Consensus on PR 169 - relax certificate list requirements
On 08/26/2015 11:42 PM, Dave Garrett wrote: > On Wednesday, August 26, 2015 05:11:01 pm Joseph Salowey wrote: >> It looks like we have good consensus on PR 169 to relax certificate list >> ordering requirements. I had one question on the revised text. I'm >> unclear on the final clause in this section: >> >> "Because certificate validation requires that trust anchors be distributed >> independently, a self-signed certificate that specifies a trust anchor MAY >> be omitted from the chain, provided that supported peers are known to >> possess any omitted certificates they may require." >> >> I just want to make sure there isn't the intention of omitting certificates >> that are not seif-signed. > > Well, technically anything can be omitted; it just won't validate. :p Firefox completes chains with intermediate certificates it has seen in other certificate chains. This is an endless source of headaches if you use headless clients which do not perform this caching. In this light, MUST NOT automatically complete incomplete chains, except with a trusted root certificate (self-signed or not) might an attractive option. Except that Mozilla could claim its self-learning trust store is just magically growing root certificates in the sense of such a requirement (although such certificates are necessarily intermediate, otherwise it would not be safe to mark them as trusted automatically). -- Florian Weimer / Red Hat Product Security ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
Hi all, I thank everyone who took time to think about the issue. The tone of my message below asked for a discussion of "allowed"/optional support for DSA with key size of 2K or bigger. So there would not be a required support for it. There is a number of validated DSA implementations out there with key size of 2K (http://csrc.nist.gov/groups/STM/cavp/documents/dss/dsanewval.htm) ( of course I don't know the number of the implementations without validations). DSA with 2K or bigger key sizes were added to FIPS 186 in June 2009 (FIPS 186-3). TLSs are used in more places than just public servers and common browsers. For the people who use DSA in TLSs, it would be nice if they could run TLS 1.3 with DSA if they choose to do so. Quynh. From: TLS on behalf of Dang, Quynh Sent: Friday, August 28, 2015 3:17 PM To: e...@rtfm.com; tls@ietf.org Subject: [TLS] DSA support in TLS 1.3. Hi all, DSA is supported in the previous versions of TLS. It would be nice if someone who uses DSA can use it in TLS 1.3 as well. People who don't use DSA, then they don't use DSA. People who use DSA right, it should be fine for them to use DSA. I don't see a convincing reason to remove support of DSA in TLS 1.3. Quynh. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Mon, 31 Aug 2015 12:13:09 + "Dang, Quynh" wrote: > TLSs are used in more places than just > public servers and common browsers. For the people who use DSA in > TLSs, it would be nice if they could run TLS 1.3 with DSA if they > choose to do so. I think we all know that TLS is more than browsers. However the "people who use DSA in TLS" are currently a mere statement from you, we don't know if they exist. Several people have asked you whether you can name use cases. You haven't answered. As long as that's the case this discussion is pointless. We shouldn't keep DSA just because someone we don't know might have a use case we can't imagine. If you can tell us a) who is using DSA b) why they think this has an advantage we can have a useful discussion. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgp_GgoJZKH3_.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus on PR 169 - relax certificate list requirements
On 08/31/2015 05:54 PM, Martin Thomson wrote: > On 31 August 2015 at 05:02, Florian Weimer wrote: >> MUST NOT automatically complete incomplete chains > > Um, no. I realize that this is a feature that is hard for others to > replicate, but being able to reach sites is important to people. All > browsers do this, and I don't see any reason to stop. The reason to stop is that people only test with long-running, well-used browser profiles, and it is difficult to explain to them that things don't work if you just installed a fresh system. I lost countless hours to that. As in other cases, browsers papering over site configuration errors causes ecosystem damage. -- Florian Weimer / Red Hat Product Security ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus on PR 169 - relax certificate list requirements
> On Aug 31, 2015, at 6:56 PM, Florian Weimer wrote: > > On 08/31/2015 05:54 PM, Martin Thomson wrote: >> On 31 August 2015 at 05:02, Florian Weimer wrote: >>> MUST NOT automatically complete incomplete chains >> >> Um, no. I realize that this is a feature that is hard for others to >> replicate, but being able to reach sites is important to people. All >> browsers do this, and I don't see any reason to stop. > > The reason to stop is that people only test with long-running, well-used > browser profiles, and it is difficult to explain to them that things > don't work if you just installed a fresh system. I lost countless hours > to that. As in other cases, browsers papering over site configuration > errors causes ecosystem damage. I feel the pain (I know some administrators who have made this mistake), but it’s always best to test with something like “openssl s_client”. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate DH_anon in favor of raw public keys?
On Fri, Aug 28, 2015 at 06:33:17PM +, Viktor Dukhovni wrote: > On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote: > Furthermore, anon-DH has strong privacy properties, the server > sends no identity information, not even a public key. Any > channel-binding at the next layer is privacy protected. Using raw public signature keys doesn't change that. It just requires generating a signature key every time. For devices/protocols where DH_anon is common (perhaps because they do channel binding) the proposal at hand is annoying and CPU-wasting, but hardly fatal. I'm not sure how I feel about this. The idea that we always do a DH key exchange and always have a server signature means we can greatly reduce the number of ciphersuites, so that's quite helpful. We'd have to apply this to PSK too to make it really worthwhile. > My view is that anon_DH should either be supported properly (be > defined for the same symmetric cipher combinations as ciphersuites > with certs or public keys) or as proposed not supported at all. Yes, DH_anon should be first-class. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate DH_anon in favor of raw public keys?
On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams wrote: > On Fri, Aug 28, 2015 at 06:33:17PM +, Viktor Dukhovni wrote: > > On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote: > > Furthermore, anon-DH has strong privacy properties, the server > > sends no identity information, not even a public key. Any > > channel-binding at the next layer is privacy protected. > > Using raw public signature keys doesn't change that. It just requires > generating a signature key every time. > > For devices/protocols where DH_anon is common (perhaps because they do > channel binding) the proposal at hand is annoying and CPU-wasting, but > hardly fatal. > > I'm not sure how I feel about this. The idea that we always do a DH key > exchange and always have a server signature means we can greatly reduce > the number of ciphersuites, so that's quite helpful. We'd have to apply > this to PSK too to make it really worthwhile. Certainly it would be nice to get rid of PSK too but just getting rid of DH_anon makes a non-trivial difference. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate DH_anon in favor of raw public keys?
On Mon, Aug 31, 2015 at 09:18:34AM -0700, Eric Rescorla wrote: > On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams > wrote: > > I'm not sure how I feel about this. The idea that we always do a DH key > > exchange and always have a server signature means we can greatly reduce > > the number of ciphersuites, so that's quite helpful. We'd have to apply > > this to PSK too to make it really worthwhile. > > Certainly it would be nice to get rid of PSK too but just getting rid of > DH_anon makes a non-trivial difference. How would we get rid of PSK [without DH]? What would the impact be on IoT devices? Could we have a fake-DH-and-signature PSK scheme to make it easy on IoTs? Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate DH_anon in favor of raw public keys?
On Mon, Aug 31, 2015 at 9:45 AM, Nico Williams wrote: > On Mon, Aug 31, 2015 at 09:18:34AM -0700, Eric Rescorla wrote: > > On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams > > wrote: > > > I'm not sure how I feel about this. The idea that we always do a DH > key > > > exchange and always have a server signature means we can greatly reduce > > > the number of ciphersuites, so that's quite helpful. We'd have to > apply > > > this to PSK too to make it really worthwhile. > > > > Certainly it would be nice to get rid of PSK too but just getting rid of > > DH_anon makes a non-trivial difference. > > How would we get rid of PSK [without DH]? What would the impact be on > IoT devices? Could we have a fake-DH-and-signature PSK scheme to make > it easy on IoTs? I guess I wasn't clear: I'm not in favor of getting rid of PSK. I'm saying that even if we still have PSK, removing DH_anon as an explicit mode makes things simpler. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate DH_anon in favor of raw public keys?
On Mon, Aug 31, 2015 at 09:48:10AM -0700, Eric Rescorla wrote: > On Mon, Aug 31, 2015 at 9:45 AM, Nico Williams > wrote: > > How would we get rid of PSK [without DH]? What would the impact be on > > IoT devices? Could we have a fake-DH-and-signature PSK scheme to make > > it easy on IoTs? > > I guess I wasn't clear: I'm not in favor of getting rid of PSK. I'm > saying that even if we still have PSK, removing DH_anon as an explicit > mode makes things simpler. I wasn't either. I was asking about requiring the use of DH [and a server signature] when using PSK. Let's get back to removing DH_anon for a minute. What would the impact be on TCPINC proposals using TLS as their basis? They really need anonymity, leaving it to the application to do channel binding. (The application might be using TLS itself, oddly enough.) Do we really want to force servers to generate an unnecessary signing key, compute an unnecessary signature, and to then force clients to verify said unnecessary signature (if they don't then there's a subliminal channel)?? I think "no", unless the signature algorithm used is cheap [and weak], which probably adds other complications. Back to PSK: How is PSK with PFS going to work? How is PSK w/o PFS going to work? Anyways, my current take is that we should not get rid of the DH_anon ciphersuites. I grant that the existing applications (ignoring TPCINC?) could take the performance hit, but in the longer term it seems likely to be more problematic than helpful. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Monday, August 31, 2015 08:43:16 am Hanno Böck wrote: > If you can tell us > a) who is using DSA > b) why they think this has an advantage > we can have a useful discussion. Not to mention: c) why they aren't switching to ECDSA Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On 08/28/2015 08:17 PM, Geoffrey Keating wrote: Jeffrey Walton writes: Also, if DSA was to be supported, one would need to specify how to determine the hash function (use of fixed SHA-1 doesn't fly). And 1024-bit prime is too small. FIPS186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf) partially remediates the issue. DSA now includes 2048 and 3072 sizes. This is true, but if TLS 1.3 was to specify DSA, it should require the 2048 or 3072 sizes (since 1024 is last century's crypto), and existing implementations do not necessarily support those today. That's sort of a generic statement. I know NSS supports 2048 and 3072 bit DSA. Which really highlights the question: who would actually use it? ECDSA can be smaller, faster, and more secure all at once; and if you don't like ECDSA or want an alternative, there's RSA. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls smime.p7s Description: S/MIME Cryptographic Signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
