Re: [TLS] Alvaro Retana's No Objection on draft-ietf-tls-padding-02: (with COMMENT)
On Sep 01, 2015, at 12:49, Eric Rescorla wrote: > > 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 one thing I’ll add in addition to what’s in the msg to Alissa is that the time from Brian raising an issue to having testable patches to fix the issue was about two days. And, this all happened back at the end of ’13; what can I say the wheels of standardization move slowly while fixing an issue that might affect a noticeable swath of the Internet moves a little faster. spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] RC4 cipher with NNTP (RFC 4642)
Hi all, Since the publication of RFC 7465 "Prohibiting RC4 Cipher Suites", there has been a discrepancy with the requirements of Section 5 of RFC 4642 "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)": NNTP client and server implementations MUST implement the TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite and SHOULD implement the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is important, as it assures that any two compliant implementations can be configured to interoperate. All other cipher suites are OPTIONAL. Shouldn't something be done about that? Maybe a new RFC obsoleting RFC 4642 (which could at the same time become a standard instead of a proposed standard)? or do you have other ideas? What would be the best wording to replace the above paragraph? Should one or several ciphers still be explicitly mentioned, or the paragraph totally removed? (RFC 5246 that standardizes TLS 1.2 already has a Section 9 about the mandatory TLS_RSA_WITH_AES_128_CBC_SHA cipher suite.) Of course, if you see other things that should be amended in RFC 4242, do not hesitate to tell. Thanks beforehand, -- Julien ÉLIE « Vous savez, les idées, elles sont dans l'air. Il suffit que quelqu'un vous en parle de trop près, pour que vous les attrapiez ! » (Raymond Devos) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RC4 cipher with NNTP (RFC 4642)
> Maybe a new RFC obsoleting RFC 4642 (which could at the same time > become a standard instead of a proposed standard)? Is there any reason why NNTP cannot just use the UTA specifications? (It's been awhile since I "dabbled" in NNTP :) /r$ -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RC4 cipher with NNTP (RFC 4642)
On Wed, Sep 02, 2015 at 04:39:59PM +0200, Julien ?LIE wrote: > Since the publication of RFC 7465 "Prohibiting RC4 Cipher Suites", there has > been a discrepancy with the requirements of Section 5 of RFC 4642 "Using > Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)": > >NNTP client and server implementations MUST implement the >TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite and SHOULD implement the >TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is >important, as it assures that any two compliant implementations can >be configured to interoperate. All other cipher suites are OPTIONAL. It would be best if NNTP did not specify MTI TLS ciphersuites and left that to the relevant TLS specifications. Instead, it would be more useful to specify a minimum TLS protocol version, and require each side to support the MTI ciphers for each supported protocol version. It seems that 4642 is rather muddy on whether TLS in NNTP is opportunistic or not. On the one hand it requires server authentication, which seems to be mitigation of active attacks via mandatory TLS, and on the other it talks about clients possibly continuing despite absence of STARTTLS capability or STARTTLS failure. If an update is published, it should resolve the opportunistic vs. mandatory TLS confusion, possibly by describing two separate modes of operation. AFAIK, NNTP peering relationships are fairly static, and mandatory TLS seems like the way to go in that case. But if NNTP servers contact other servers "on the fly", then opportunistic TLS may be appropriate and one might even consider DANE to harden that. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RC4 cipher with NNTP (RFC 4642)
Hi Viktor, It would be best if NNTP did not specify MTI TLS ciphersuites and left that to the relevant TLS specifications. Instead, it would be more useful to specify a minimum TLS protocol version, and require each side to support the MTI ciphers for each supported protocol version. OK thanks, that seems wise. It seems that 4642 is rather muddy on whether TLS in NNTP is opportunistic or not. On the one hand it requires server authentication, which seems to be mitigation of active attacks via mandatory TLS, and on the other it talks about clients possibly continuing despite absence of STARTTLS capability or STARTTLS failure. If an update is published, it should resolve the opportunistic vs. mandatory TLS confusion, possibly by describing two separate modes of operation. Noted, thanks. AFAIK, NNTP peering relationships are fairly static, and mandatory TLS seems like the way to go in that case. But if NNTP servers contact other servers "on the fly", then opportunistic TLS may be appropriate and one might even consider DANE to harden that. You're right that NNTP peering is fairly static. However, TLS is rarely used for NNTP peering between two servers. TLS is more wide-spread for the connection of a news client to a news server so as to read or post articles. -- Julien ÉLIE « Vous savez, les idées, elles sont dans l'air. Il suffit que quelqu'un vous en parle de trop près, pour que vous les attrapiez ! » (Raymond Devos) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RC4 cipher with NNTP (RFC 4642)
Note: RFC 4642 does not seem to have been a work product of the TLS WG, so you probably want to raise this in UTA. -Ekr On Wed, Sep 2, 2015 at 7:53 AM, Salz, Rich wrote: > > Maybe a new RFC obsoleting RFC 4642 (which could at the same time > > become a standard instead of a proposed standard)? > > Is there any reason why NNTP cannot just use the UTA specifications? > (It's been awhile since I "dabbled" in NNTP :) > > /r$ > > > -- > Senior Architect, Akamai Technologies > IM: richs...@jabber.at Twitter: RichSalz > ___ > 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] RC4 cipher with NNTP (RFC 4642)
Hi Rich, Maybe a new RFC obsoleting RFC 4642 (which could at the same time become a standard instead of a proposed standard)? Is there any reason why NNTP cannot just use the UTA specifications? When you speak about the UTA specifications, is it RFC 7525 "Recommendations for Secure Use of Transport Layer Security and Datagram Transport Layer Security"? I do not see other document published by the UTA WG that could otherwise apply. Yet, NNTP still needs an RFC to specify the use of TLS because two specific NNTP response codes are defined for the STARTTLS command: 382 Continue with TLS negotiation 580 Can not initiate TLS negotiation and the STARTTLS capability has to be standardized in response to the CAPABILITIES command -- which is a new command that did not exist when you wrote INN :-) Maybe I misunderstood your remark about the UTA specification, though. -- Julien ÉLIE « Vous savez, les idées, elles sont dans l'air. Il suffit que quelqu'un vous en parle de trop près, pour que vous les attrapiez ! » (Raymond Devos) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RC4 cipher with NNTP (RFC 4642)
On Wed, Sep 02, 2015 at 05:13:08PM +0200, Julien ?LIE wrote: > >AFAIK, NNTP peering relationships are fairly static, and mandatory > >TLS seems like the way to go in that case. But if NNTP servers > >contact other servers "on the fly", then opportunistic TLS may > >be appropriate and one might even consider DANE to harden that. > > You're right that NNTP peering is fairly static. However, TLS is rarely > used for NNTP peering between two servers. TLS is more wide-spread for the > connection of a news client to a news server so as to read or post articles. I would also expect that a given user's choice of NNTP server is also fairly static, and in any case user-agents likely want valid certificates and mandatory TLS (as with IMAP and SUBMIT). If so, I don't see much of a role for opportunistic TLS in NNTP, in which case, the updated spec can be simplified to say that clients SHOULD know whether TLS is expected of their peer, and if so refuse to proceed unless they obtain an authenticated encrypted channel (per all reasonable UTA TLS BCP guidelines, and with support for the MTI ciphers appropriate for all supported TLS versions). In the server-to-server case, once DANE succeeds or fails to get traction for SMTP and XMPP, one might explore using DANE rather than the public CA "Web PKI". But this is premature at this time. With peering largely static, "Web PKI" works well enough, and clients can if they desire more security restrict which CAs they are willing to accept as issuers of the fixed peer's certificate. -- Viktor. ___ 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 Sep 02, 2015, at 02:26, Yoav Nir wrote: > >> 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 I agree with Yoav. By way of additional background: The extension fixes an issue that Brian Smith brought to the WG’s attention [0]. It’s related to ALPN deployment; he was running into failures when handshakes were larger than 255 bytes. Brian got some numbers from Kurt Roeckx, who relayed them from Ivan Ristic, and these numbers showed that around 2.9% of the web servers surveyed on the Internet had this problem. That number kind of got the WG’s attention because yeah the implementer can fix their code in a patch, but they can’t really force that patch to be deployed everywhere. spt [0] https://mailarchive.ietf.org/arch/msg/tls/v7tEam3Wi5GjpEXxF_71qPY0Ojo ___ 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 Sep 2, 2015, at 7:09 AM, Sean Turner wrote: > > On Sep 02, 2015, at 02:26, Yoav Nir wrote: > >> >>> 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 > > I agree with Yoav. > > By way of additional background: The extension fixes an issue that Brian > Smith brought to the WG’s attention [0]. It’s related to ALPN deployment; he > was running into failures when handshakes were larger than 255 bytes. Brian > got some numbers from Kurt Roeckx, who relayed them from Ivan Ristic, and > these numbers showed that around 2.9% of the web servers surveyed on the > Internet had this problem. That number kind of got the WG’s attention > because yeah the implementer can fix their code in a patch, but they can’t > really force that patch to be deployed everywhere. Thanks, this is the kind of helpful context I was going for. I would suggest adding something like this at the end of the first paragraph in section 1: "This is desirable given that fully comprehensive patching of affected implementations is difficult to achieve.” Alissa > > spt > > [0] https://mailarchive.ietf.org/arch/msg/tls/v7tEam3Wi5GjpEXxF_71qPY0Ojo ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Tue, Sep 01, 2015 at 05:58:33PM +, Salz, Rich wrote: > 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. I think they already have, with NSA seemingly saying RSA3k is OK for up to TOP SECRET (unless I misunderstood). The same table from NSA that mentions RSA (and the 3k limit) does not mention DSA (the only other signature algo is ECDSA with 384 limit). So maybe even US govt. is not using DSA? -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Ben Campbell's No Objection on draft-ietf-tls-padding-03: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-tls-padding-03: 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: -- -- Abstract: More in the abstract would be nice. Why'd would one want to do this? -- 1, first paragraph, last sentence: Can you elaborate on this? The motivation seems weak without a bit more. When would you choose to use this at all? Wouldn't it make more sense to fix the bug? -- 5, last sentence: Do you expect anyone to implement this MAY? It seems like this either needs to be stronger, or removed as a "why bother"? -- 6: I'm not sure I understand the meaning of "permanently assign the early code point for the padding extension in its ExtensionType registry". Does this mean that an early allocation was done for this? If so, it seems like the IANA section should still describe the code point being registered, or perhaps give a pointer to or description of the early allocation. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RC4 cipher with NNTP (RFC 4642)
On Sep 02, 2015, at 11:20, Julien ÉLIE wrote: > Hi Rich, > >>> Maybe a new RFC obsoleting RFC 4642 (which could at the same time >>> become a standard instead of a proposed standard)? >> >> Is there any reason why NNTP cannot just use the UTA specifications? > > When you speak about the UTA specifications, is it RFC 7525 "Recommendations > for Secure Use of Transport Layer Security and Datagram Transport Layer > Security"? > I do not see other document published by the UTA WG that could otherwise > apply. > > Yet, NNTP still needs an RFC to specify the use of TLS because two specific > NNTP response codes are defined for the STARTTLS command: > > 382 Continue with TLS negotiation > 580 Can not initiate TLS negotiation > > and the STARTTLS capability has to be standardized in response to the > CAPABILITIES command -- which is a new command that did not exist when you > wrote INN :-) > > > Maybe I misunderstood your remark about the UTA specification, though. Julien, I guess I’m not following why we need a new NNTP draft either. If you’re looking or something that specifically updates the NNTP MTI cipher suites, then there isn’t such an RFC. But, RFC 7525 (aka BCP 195) points to RFC 7465 that prohibits RFC4 (for all versions of TLS), so if an NNTP implementer is faithfully implementing TLS and related RFCs then they’ll end up supporting TLS 1.2 with one of the cipher suites in s4.2 of RFC 7525. If you really, really want to have something that updates RFC 4642 (likely referring to BCP 195), then there’s nothing stopping you from writing that draft. If you get no nibbles on said draft from the ietf-nntp list I’d try UTA (http://datatracker.ietf.org/wg/uta/charter/). Note that said draft is out-of-scope for the TLS WG. spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ben Campbell's No Objection on draft-ietf-tls-padding-03: (with COMMENT)
On Wed, Sep 02, 2015 at 06:28:13PM -0700, Ben Campbell wrote: > -- 6: > I'm not sure I understand the meaning of "permanently assign the early > code point for the padding extension in its ExtensionType registry". > Does this mean that an early allocation was done for this? If so, it > seems like the IANA section should still describe the code point being > registered, or perhaps give a pointer to or description of the early > allocation. The OpenSSL tls1.h header file contains: /* * ExtensionType value for TLS padding extension. * http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml * http://tools.ietf.org/html/draft-agl-tls-padding-03 */ # define TLSEXT_TYPE_padding 21 The IANA entry for extension "21" is: 21 padding (TEMPORARY - registered 2014-03-12, expires 2016-03-12) [draft-ietf-tls-padding] -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] '15 TLS Fall Interim Logistics
All, Andrei has graciously offered to host us at Microsoft in Redmond, WA [0]. We’re going to need a list of those that plan to attend in person in order to make sure there’s a badge for you to get into the buildings. Please fill out the following doodle poll if you plan to attend in person: http://doodle.com/ei6px58ip59gr85y. Note that we’re in different buildings/rooms each day. Here are the specifics: 09/21: 16071 NE 36th Way, REDMOND, WA, 98052 (East Campus bldg. 37 room 1727) 09/22: 3850 148th Ave NE, REDMOND, WA, 98052 (West Campus Studio H room 1022) More details as we get them. The original meeting announcement can be found at: https://mailarchive.ietf.org/arch/msg/tls/lfJjrpjZoidONUTIvDWzM5V52ug spt [0] For those of you flying, you still fly into Seattle, WA. Don’t be confused when you see the doodle poll that says “Redmond, WA". ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
