Re: [TLS] Consensus on PR 169 - relax certificate list requirements
Yoav Nir writes: >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”. That's quite possibly the worst thing to test it with, because it's what everyone else also tests against, so it's the thing that everyone makes their code compatible with. The SSH equivalent is Putty, the standard conformance test for SSH RFC compliance is "will Putty connect to it?". Since Putty bends over backwards to accomodate broken implementations, you end up with a "conformance test" that doesn't really test anything. What you need to test with is a fairly picky implementation with good diagnostics. I rather like Mike's server, https://www.mikestoolbox.org/. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Friday 28 August 2015 20:17:11 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. It still doesn't say exactly which hash should be used with which sizes. and unlike RSA, the signature itself doesn't specify it either so hash truncation attacks are not impossible > 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. those sizes are not really interoperable: https://bugzilla.redhat.com/show_bug.cgi?id=1238369 because of the above (GnuTLS takes the conservative approach which is incompatible with NSS implementation) > Which really highlights the question: who would actually use it? Since 1024 bit is too weak and 2048 bit and 3072 bit is underspecified for TLS 1.2 it already isn't recommended for use (which means that the biggest deployment of DSA - US Gov - can't really use those bigger sizes, and in fact the Common Access Card already transitioned to RSA with the change to 2048 bit). -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Working Group Last Call for draft-ietf-tls-chacha20-poly1305-00
This is the working group last call for draft-ietf-tls-chacha20-poly1305-00. Please send any comments on the TLS working group list by September 16, 2015. Thanks, J&S ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
>> > > 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. > > It still doesn't say exactly which hash should be used with which sizes. I believe you are supposed to provide equivalent security levels across algorithms. If you are honoring NIST's recommendations, then you can find them in SP 800-57 Part 1, Revision 3 (http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf); and SP 800-131 A-Rev.1 (Draft) (http://csrc.nist.gov/publications/drafts/800-131A/sp800-131a_r1_draft.pdf). ECRYPT, NESSIE, and others provide similar recommendations. We can probably add the IETF to the list :) > and unlike RSA, the signature itself doesn't specify it either so hash > truncation attacks are not impossible > >> 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. > > those sizes are not really interoperable: > https://bugzilla.redhat.com/show_bug.cgi?id=1238369 > because of the above (GnuTLS takes the conservative approach which is > incompatible with NSS implementation) > >> Which really highlights the question: who would actually use it? > > Since 1024 bit is too weak and 2048 bit and 3072 bit is underspecified > for TLS 1.2 it already isn't recommended for use (which means that the > biggest deployment of DSA - US Gov - can't really use those bigger > sizes, and in fact the Common Access Card already transitioned to RSA > with the change to 2048 bit). Regarding "who would actually use it": folks in US Federal (and those doing business in US Federal) don't have the choices that others have. Jeff ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Alissa Cooper's No Objection on draft-ietf-tls-padding-02: (with COMMENT)
Alissa Cooper has entered the following ballot position for draft-ietf-tls-padding-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ -- COMMENT: -- Would be nice to include a reference to something that explains or at least identifies the implementation that hangs when receiving ClientHellos of a certain size. Otherwise one wonders why it's easier to define this extension than it is to just fix that one implementation (assuming it is only one). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Alvaro Retana's No Objection on draft-ietf-tls-padding-02: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-tls-padding-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ -- COMMENT: -- As Alissa, I was wondering why it wasn’t easier to fix the one implementation instead. The shepherd wrote: "Since then it has been found that this extension can server (sic) to alleviate issues with issues in several vendor's products. There was good consensus to move forward with this document as it may find further applicability in the future.” So it looks like the problem is not just one implementation… If the WG now thinks that this extension may be valuable for other things besides fixing bugs, then it might be nice to reword some of the document to not focus on what seems to be one bug and just present the extension for what it is: padding. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Alvaro Retana's No Objection on draft-ietf-tls-padding-02: (with COMMENT)
> > > As Alissa, I was wondering why it wasn’t easier to fix the one > implementation instead. > > Because it's widely fielded, and browsers don't know in advance what kind of server they are talking to. > The shepherd wrote: "Since then it has been found that this extension can > server (sic) to alleviate issues with issues in several vendor's > products. There was good consensus to move forward with this document as > it may find further applicability in the future.” So it looks like the > problem is not just one implementation… > There's another potential future application for DTLS to allow the client to pad out the ClientHello to MTU size (or rather for the server to insist on it) thus reducing the risk of amplification. -Ekr > If the WG now thinks that this extension may be valuable for other things > besides fixing bugs, then it might be nice to reword some of the document > to not focus on what seems to be one bug and just present the extension > for what it is: padding. > > > ___ > 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
Re: [TLS] DSA support in TLS 1.3.
On Tuesday, September 01, 2015 11:24:59 am Jeffrey Walton wrote: > Regarding "who would actually use it": folks in US Federal (and those > doing business in US Federal) don't have the choices that others have. They, however, obviously do have the choice of switching from DSA to ECDSA, so that argument doesn't make much sense here. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Tue, Sep 1, 2015 at 1:16 PM, Dave Garrett wrote: > On Tuesday, September 01, 2015 11:24:59 am Jeffrey Walton wrote: >> Regarding "who would actually use it": folks in US Federal (and those >> doing business in US Federal) don't have the choices that others have. > > They, however, obviously do have the choice of switching from DSA to ECDSA, > so that argument doesn't make much sense here. > I suppose that depends on how threatened you feel by Certicom's claimed patents on EC. Did the IETF ever procure a waiver on any claims when used in TLS? Jeff ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-ietf-tls-padding-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : A TLS ClientHello padding extension Author : Adam Langley Filename: draft-ietf-tls-padding-03.txt Pages : 4 Date: 2015-09-01 Abstract: This memo describes a TLS extension that can be used to pad ClientHello messages to a desired size. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-padding-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-padding-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
There is a third option: you don't get to use TLS 1.3 until the government requirements are updated. I'm fine with that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On 9/1/15, 13:54 , "TLS on behalf of Dave Garrett" wrote: >On Tuesday, September 01, 2015 01:24:05 pm Jeffrey Walton wrote: >>> They, however, obviously do have the choice of switching from DSA to >>>ECDSA, so that argument doesn't make much sense here. >> >> I suppose that depends on how threatened you feel by Certicom’s claimed >>patents on EC. > >If the US Federal government actually got sued over ECC patents, I would >hope they'd just abolish them and move on. I don’t think it’s as simple as that. US government licensed some of the ECC technology from Certicom. But I’ve heard Certicom claim that the licensing terms are so narrow that only direct national security applications qualify for that license. This isn’t something where vendors (and their lawyers) can rely on “would hope”. >This is all a side-discussion, here, though. The US government's >requirements are not our concern here. Dropping DSA in TLS leaves two >perfectly fine options available to them, RSA & ECDSA, plus a new one yet >to be added by the CFRG. They have to eventually keep up with things just >like everyone else. If they want to be sloppy and keep DSA around, it's >not like they couldn't just ignore that part of the eventual TLS 1.3 RFC >within their own ecosystem. Everyone else, however, will be fine with the >rest. The problem is that standardization of an algorithm or a technology by IETF or IRTF is completely unrelated to the patent/licensing status of that algorithm or technology. So unless Certicom comes forward and explicitly releases its IPR, most of the vendors would consider the patended and therefore toxic. I know I would. And forcing those vendors to spend money on licensing isn’t going to work (recall RSA). This would be a strong reason to hold on to DSA until the ECC patents expire. (Like it happened with RSA.) smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Tue, Sep 1, 2015 at 2:02 PM, Blumenthal, Uri - 0553 - MITLL wrote: > On 9/1/15, 13:54 , "TLS on behalf of Dave Garrett" on behalf of davemgarr...@gmail.com> wrote: > >>On Tuesday, September 01, 2015 01:24:05 pm Jeffrey Walton wrote: They, however, obviously do have the choice of switching from DSA to ECDSA, so that argument doesn't make much sense here. >>> >>> I suppose that depends on how threatened you feel by Certicom’s claimed >>>patents on EC. >> >>If the US Federal government actually got sued over ECC patents, I would >>hope they'd just abolish them and move on. > > I don’t think it’s as simple as that. US government licensed some of the > ECC technology from Certicom. But I’ve heard Certicom claim that the > licensing terms are so narrow that only direct national security > applications qualify for that license. Did Certicom ever have patents applying to the use of ECDHE in TLS? It's not clear that they did: certainly RFC 6090 goes so far as to claim that there are patent-free implementation methods based on pre-1985 sources. > > This isn’t something where vendors (and their lawyers) can rely on “would > hope”. > >>This is all a side-discussion, here, though. The US government's >>requirements are not our concern here. Dropping DSA in TLS leaves two >>perfectly fine options available to them, RSA & ECDSA, plus a new one yet >>to be added by the CFRG. They have to eventually keep up with things just >>like everyone else. If they want to be sloppy and keep DSA around, it's >>not like they couldn't just ignore that part of the eventual TLS 1.3 RFC >>within their own ecosystem. Everyone else, however, will be fine with the >>rest. > > The problem is that standardization of an algorithm or a technology by > IETF or IRTF is completely unrelated to the patent/licensing status of > that algorithm or technology. So unless Certicom comes forward and > explicitly releases its IPR, most of the vendors would consider the > patended and therefore toxic. I know I would. And forcing those vendors to > spend money on licensing isn’t going to work (recall RSA). > > This would be a strong reason to hold on to DSA until the ECC patents > expire. (Like it happened with RSA.) And what patents are you concerned about, and when were they issued? > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On 9/1/15 14:49 , Watson Ladd wrote: On Tue, Sep 1, 2015 at 2:02 PM, Blumenthal, Uri - 0553 - MITLL wrote: On 9/1/15, 13:54 , "TLS on behalf of Dave Garrett" wrote: On Tuesday, September 01, 2015 01:24:05 pm Jeffrey Walton wrote: They, however, obviously do have the choice of switching from DSA to ECDSA, so that argument doesn't make much sense here. I suppose that depends on how threatened you feel by Certicom’s claimed patents on EC. If the US Federal government actually got sued over ECC patents, I would hope they'd just abolish them and move on. I don’t think it’s as simple as that. US government licensed some of the ECC technology from Certicom. But I’ve heard Certicom claim that the licensing terms are so narrow that only direct national security applications qualify for that license. Did Certicom ever have patents applying to the use of ECDHE in TLS? It's not clear that they did: certainly RFC 6090 goes so far as to claim that there are patent-free implementation methods based on pre-1985 sources. I do not know. It is not my field of expertise, and I'm not employed by a commercial vendor to really care. So I have neither skills nor incentives (nor time!) to research patents issued for ECC to figure how they could impact my work, because in general they cannot. But I'm conscious of other people for who it could be important. This isn’t something where vendors (and their lawyers) can rely on “would hope”. This is all a side-discussion, here, though. The US government's requirements are not our concern here. Dropping DSA in TLS leaves two perfectly fine options available to them, RSA & ECDSA, plus a new one yet to be added by the CFRG. They have to eventually keep up with things just like everyone else. If they want to be sloppy and keep DSA around, it's not like they couldn't just ignore that part of the eventual TLS 1.3 RFC within their own ecosystem. Everyone else, however, will be fine with the rest. The problem is that standardization of an algorithm or a technology by IETF or IRTF is completely unrelated to the patent/licensing status of that algorithm or technology. So unless Certicom comes forward and explicitly releases its IPR, most of the vendors would consider the patended and therefore toxic. I know I would. And forcing those vendors to spend money on licensing isn’t going to work (recall RSA). This would be a strong reason to hold on to DSA until the ECC patents expire. (Like it happened with RSA.) And what patents are you concerned about, and when were they issued? See above. I am not tracking patents - have neither time, nor interest in doing that. But I'm not releasing commercial software. I think somebody made a list of the patents owned by Certicom, but I can't recall the details. That would be the first thing to look at, IMHO. Since (AFAIK) nobody here is a patent lawyer (and even if there were :), any recommendation or opinion regarding those patents posted here isn't worth much. E.g. if you implement and sell ECDSA or EdDSA, and are sued by e.g. Certicom for not licensing it from them - who's going to pay your legal fees? Probably not the participants of this forum. :) It boils down to Certicom (and other companies???) holding some IPR on (some?) ECC technology that commercial vendors must license from them, or risk lawsuits. The famed NSA deal doesn't seem to be wide enough to cover the industry because of that "national security applications" clause that is a subject to interpretation. And those companies (intentionally?) keep the scope of their patents vague... At least this is how I understand the state of the field. smime.p7s Description: S/MIME Cryptographic Signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Tue, Sep 1, 2015 at 12:17 PM, Blumenthal, Uri -- 0553 -- MITLL < u...@ll.mit.edu> wrote: > I am not tracking patents - have neither time, nor interest in doing that. > But I'm not releasing commercial software. I think somebody made a list of > the patents owned by Certicom, but I can't recall the details. That would > be the first thing to look at, IMHO. Dan Bernstein has made lists of ECC patents here: http://cr.yp.to/ecdh/patents.html http://ed25519.cr.yp.to/software.html (see "Patents" at the bottom of the page) According to him, no extant patents should apply to the CFRG curves or EdDSA (and it's seeming highly likely that the CFRG signature algorithm will greatly resemble or be EdDSA) -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
DJB's work is good and commendable. I personally think that EdDSA (and ECDSA, for that matter) are not covered by Certicom's patents. But IANAL (I Am Not A Lawyer)... I *can* understand vendors who would hold until either an explicit IPR release is posted, or the (potentially!) relevant patents expire. On 9/1/15 15:23 , Tony Arcieri wrote: On Tue, Sep 1, 2015 at 12:17 PM, Blumenthal, Uri -- 0553 -- MITLL mailto:u...@ll.mit.edu>> wrote: I am not tracking patents - have neither time, nor interest in doing that. But I'm not releasing commercial software. I think somebody made a list of the patents owned by Certicom, but I can't recall the details. That would be the first thing to look at, IMHO. Dan Bernstein has made lists of ECC patents here: http://cr.yp.to/ecdh/patents.html http://ed25519.cr.yp.to/software.html (see "Patents" at the bottom of the page) According to him, no extant patents should apply to the CFRG curves or EdDSA (and it's seeming highly likely that the CFRG signature algorithm will greatly resemble or be EdDSA) smime.p7s Description: S/MIME Cryptographic Signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Tuesday, September 1, 2015, Blumenthal, Uri -- 0553 -- MITLL < u...@ll.mit.edu> wrote: > But IANAL (I Am Not A Lawyer)... I *can* understand vendors who would hold > until either an explicit IPR release is posted, or the (potentially!) > relevant patents expire. > > Then those hypothetical people should use RSA signatures and FFDHE key exchange -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
>> But IANAL (I Am Not A Lawyer)... I *can* understand vendors who would hold >> until either an explicit IPR release is posted, or the (potentially!) >> relevant patents expire. > > Then those hypothetical people should use RSA signatures and FFDHE key > exchange > Ah, but they are not hypothetical. For example, one OpenSSL customer commissioned the project to provide a modified EC implementation to avoid some of the potential patents. The result was the downloads with *-ecp in their name (ftp://ftp.openssl.org/source/). I think the minefield in this discussion is the bikeshedding. External, non-technical pressures and requirements exists, and they are not easily dismissed with "Just use X". For example, in US Federal, its C&A and FIPS. In Europe or Asia, it might be political and distrust of NIST. I'd love to see one true cipher, but I don't think its going to happen. Its not feasible (and its not a technical limitation). Jeff ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Alissa Cooper's No Objection on draft-ietf-tls-padding-02: (with COMMENT)
> On Aug 31, 2015, at 11:36 PM, Alissa Cooper wrote: > > Alissa Cooper has entered the following ballot position for > draft-ietf-tls-padding-02: No Objection > > -- > COMMENT: > -- > > Would be nice to include a reference to something that explains or at > least identifies the implementation that hangs when receiving > ClientHellos of a certain size. RFCs are forever. I don’t see much value in a “F5 had a bug in 2011” sentence in an RFC. OTOH such perpetual bad publicity (much like the “NETSCAPE_BUG” and “MICROSOFT_BUG” constants in OpenSSL code) may in the future discourage vendors from being as forthcoming with relevant information as F5 were in this case. > Otherwise one wonders why it's easier to > define this extension than it is to just fix that one implementation > (assuming it is only one). The implementation has been fixed for years. Many of their customers had not upgraded their firmware when discussion of this extension began. This is similar to how a vulnerability in home router firmware that was patched in 2004 was still present in new home routers sold in 2014 that were vulnerable to Shellshock. Unfortunately not every vendor can push upgrades to all customers the way browser vendors do. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
