Re: [TLS] Fixing TLS
On Tue, 2016-01-12 at 19:13 +0200, Yoav Nir wrote: > Hi, Peter > > Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or > 2.0) that this WG is working on right now, why? > Other groups are not working on HTTP/1.2 or IKEv1.1 or any other > $protocolv$(major-1).$(minor+1). Note that these are not security protocols and they don't benefit from a formal analysis of a protocol. Such an analysis takes several years to be done and it often applies to small parts of the protocol. Switching to a new version invalidates all the existing analysis. That is of course not necessarily bad, but as we are moving towards formally verified protocols it is very bad to give these two options: 1. Stay with a formally verified but with known vulnerabilities protocol 2. Switch to a new unknown protocol which has not been studied by as many cryptographers but is _believed_ to solve the issues found in TLS. > Any TLS library that exists now doesn’t have an implementation of > either “your” TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to > get an upgraded version of your favorite library. So the upgrade path > is no smoother for either protocol. If this had been brought up > before the work on the current draft started, maybe we would be > convinced. As it is, I don’t see the point. The main problem of TLS 1.2 is that it is vulnerable to cross-protocol attacks and there is no way to mitigate that. There was such an attack described in 2012 and another in 2015 [0]. Whether there will be a new one in 2017 is an open question. Switching to a protocol like TLS 1.3 as it is today to fix that thing it is an overkill. That is because TLS 1.3 is a rewrite of the protocol, and requires a rewrite of the code base. Given that the majority of the issues in TLS implementations are in the code bases and not in the protocol, it is very risky to switch to such a new version just like that. For old systems it most likely will never happen and they will remain vulnerable. [0]. https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fixing TLS
> Switching to a protocol like TLS 1.3 as it is today to fix that thing it is > an overkill. The primary purpose of a security protocol is to support security as best as possible. Knowing security gaps causes distrust in general. Probably not in the security protocol experts community, but in the overall communications and information technology industry. The quantification of "overkill" should be rated from that trust perspective in my opinion. Albrecht -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Nikos Mavrogiannopoulos Sent: Mittwoch, 13. Januar 2016 10:54 To: Yoav Nir; Peter Gutmann Cc: Subject: Re: [TLS] Fixing TLS On Tue, 2016-01-12 at 19:13 +0200, Yoav Nir wrote: > Hi, Peter > > Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or > 2.0) that this WG is working on right now, why? > Other groups are not working on HTTP/1.2 or IKEv1.1 or any other > $protocolv$(major-1).$(minor+1). Note that these are not security protocols and they don't benefit from a formal analysis of a protocol. Such an analysis takes several years to be done and it often applies to small parts of the protocol. Switching to a new version invalidates all the existing analysis. That is of course not necessarily bad, but as we are moving towards formally verified protocols it is very bad to give these two options: 1. Stay with a formally verified but with known vulnerabilities protocol 2. Switch to a new unknown protocol which has not been studied by as many cryptographers but is _believed_ to solve the issues found in TLS. > Any TLS library that exists now doesn’t have an implementation of > either “your” TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to > get an upgraded version of your favorite library. So the upgrade path > is no smoother for either protocol. If this had been brought up > before the work on the current draft started, maybe we would be > convinced. As it is, I don’t see the point. The main problem of TLS 1.2 is that it is vulnerable to cross-protocol attacks and there is no way to mitigate that. There was such an attack described in 2012 and another in 2015 [0]. Whether there will be a new one in 2017 is an open question. Switching to a protocol like TLS 1.3 as it is today to fix that thing it is an overkill. That is because TLS 1.3 is a rewrite of the protocol, and requires a rewrite of the code base. Given that the majority of the issues in TLS implementations are in the code bases and not in the protocol, it is very risky to switch to such a new version just like that. For old systems it most likely will never happen and they will remain vulnerable. [0]. https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf regards, Nikos ___ 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] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448
> On 12 Jan 2016, at 21:31, Ilari Liusvaara wrote: > >> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote: >> >>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson wrote: >>> >>> The same concern still applies: what does it mean to allocate code >>> point for the 4492bis-05 description? >> >> Allocating code points just means an implementation of draft-05 is >> likely to interoperate just fine with an implementation of the final >> RFC. >> >> Of course nothing is ever final until the RFC is out, so there’s >> always a risk involved, but it is considered prudent to allocate >> numbers when we’re reasonably certain of the calculations and on- >> the-wire formats. Any debate about whether we should or should not >> check certain inputs for certain conditions need not be a bar for >> allocating numbers. > > Assuming CFRG chairs really did declare consensus on Ed448 hash, then > the final characteristics of Ed448 are known and I have a reference > implementation. > > And the PKIX draft looks implementable (has wrong example?) > > More serious interop hazard is what to do with X25519/X448 and THS > (some of the proposed stuff is not wire-compatible). This CFRG co-chair would like to see an updated CFRG draft before the code point is allocated. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fixing TLS
On Tuesday 12 January 2016 15:14:13 Dave Garrett wrote: > On Tuesday, January 12, 2016 03:03:42 pm Andrei Popov wrote: > > On Tuesday, January 12, 2016 02:39:15 pm Dave Garrett wrote: > > > I hope that Google's efforts to get QUIC as-is specced out go > > > quickly and smoothly, and that it can be used as a basis to > > > develop an official total TCP/TLS replacement.> > > If this were the path forward (and I doubt that it is), I would very > > much prefer Peter Gutman's evolutionary TLS 1.3. > I was just chatting a bit off-list, and apparently I wasn't aware of > QUIC's latest plans, so it's not as clear as I previously said. > Unfortunately, it seems that they have yet to actually write anything > down (a too frequent pattern with QUIC), so I can't really comment on > what I'd like to see happen in this realm anymore. > > In any case, ~whatever~ comes after TLS 1.3 will hopefully have some > major changes. I have no idea what that will be, but TLS 1.3 comes > first. That's a discussion for a future time. I remember this one quote, not sure who is it attributed to, but it goes something like this: "I don't know what will replace Ethernet, but I'm sure it also will be called Ethernet" -- Regards, Hubert Kario Senior 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
Re: [TLS] Fixing TLS
On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote: > On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann > > wrote: > > Yoav Nir writes: > > To expand on this, I'll take Ilari Liusvaara's comments: > >>Bleeding edge ideas? They essentially re-invented SIGMA, which is > >>over 10 years old. The basic framework for doing 0-RTT is the > >>obvious one. The only new algorithm prsent since TLS 1.2 is HKDF, > >>which is just 5 years old. > >> > >>So I don't see anything "experimential" ideas, mechanisms or > >>algorithms in there > >> > > When SSLv3 was introduced, it also used ideas that were 10-20 years > > old (DH, RSA, DES, etc, only SHA-1 was relatively new). They were > > mature algorithms, lots of research had been published on them, and > > yet we're still fixing issues with them 20 years later (DH = 1976, > > SSLv3 = 1996, Logjam = 2015). > We all understand that the security of a protocol is not a function > not of the primitives but of the way the protocol works. The confusion > between export and nonexport DH shares was noted almost immediately > in SSLv3. Furthermore, 512 bit DH is weak: I don't know how this is a > discovery in 2015, given that the reasons for this were all worked > out in the early 90's. So no, Logjam is not a result of unknown > issues appearing after 20 years, but ignoring known issues. > > > TLS 2.0-called-1.3 will roll back the 20 years of experience we have > > with all the things that can go wrong and start again from scratch. > > SIGMA, at ten years old, is a relative newcomer to DH's 20 years > > when it was used in SSLv3, but in either case we didn't discover > > all the problems with it until after the protocol that used it was > > rolled out. We currently have zero implementation and deployment > > experience with 2.0-called-1.3 [0], which means we're likely to > > have another 10-20 years of patching holes ahead of us. This is > > what I meant by "experimental, bleeding-edge". > > There is an old joke about the resume with one years experience > repeated 20 times. All of the problems in TLS have been known for > decades, as I've repeatedly demonstrated on this list. All of them > were known to cryptographers at the time TLS was being designed and > deployed. It does not take deployment to trigger analysis. Exactly this: BEAST and Lucky 13 "possible" problem was described in the RFC itself. Same thing for the "new" Bicycle attack - described in the RFC for TLS 1.0 and repeated in each version since. So lets not repeat those mistakes - if there are possible issues, lets fix those, now. -- Regards, Hubert Kario Senior 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
Re: [TLS] Fixing TLS
Hello Hubert, On Wed, Jan 13, 2016 at 2:52 PM, Hubert Kario wrote: > On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote: > > On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann > > > > wrote: > > > Yoav Nir writes: > > > To expand on this, I'll take Ilari Liusvaara's comments: > > >>Bleeding edge ideas? They essentially re-invented SIGMA, which is > > >>over 10 years old. The basic framework for doing 0-RTT is the > > >>obvious one. The only new algorithm prsent since TLS 1.2 is HKDF, > > >>which is just 5 years old. > > >> > > >>So I don't see anything "experimential" ideas, mechanisms or > > >>algorithms in there > > >> > > > When SSLv3 was introduced, it also used ideas that were 10-20 years > > > old (DH, RSA, DES, etc, only SHA-1 was relatively new). They were > > > mature algorithms, lots of research had been published on them, and > > > yet we're still fixing issues with them 20 years later (DH = 1976, > > > SSLv3 = 1996, Logjam = 2015). > > We all understand that the security of a protocol is not a function > > not of the primitives but of the way the protocol works. The confusion > > between export and nonexport DH shares was noted almost immediately > > in SSLv3. Furthermore, 512 bit DH is weak: I don't know how this is a > > discovery in 2015, given that the reasons for this were all worked > > out in the early 90's. So no, Logjam is not a result of unknown > > issues appearing after 20 years, but ignoring known issues. > > > > > TLS 2.0-called-1.3 will roll back the 20 years of experience we have > > > with all the things that can go wrong and start again from scratch. > > > SIGMA, at ten years old, is a relative newcomer to DH's 20 years > > > when it was used in SSLv3, but in either case we didn't discover > > > all the problems with it until after the protocol that used it was > > > rolled out. We currently have zero implementation and deployment > > > experience with 2.0-called-1.3 [0], which means we're likely to > > > have another 10-20 years of patching holes ahead of us. This is > > > what I meant by "experimental, bleeding-edge". > > > > There is an old joke about the resume with one years experience > > repeated 20 times. All of the problems in TLS have been known for > > decades, as I've repeatedly demonstrated on this list. All of them > > were known to cryptographers at the time TLS was being designed and > > deployed. It does not take deployment to trigger analysis. > > Exactly this: BEAST and Lucky 13 "possible" problem was described in the > RFC itself. Same thing for the "new" Bicycle attack - described in the > RFC for TLS 1.0 and repeated in each version since. > > So lets not repeat those mistakes - if there are possible issues, lets > fix those, now. > But we should leave the description of the fixed problems somewhere to avoid them in future. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fixing TLS
On Wednesday 13 January 2016 15:11:47 Dmitry Belyavsky wrote: > Hello Hubert, > > On Wed, Jan 13, 2016 at 2:52 PM, Hubert Kario wrote: > > On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote: > > > On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann > > > > > > wrote: > > > > Yoav Nir writes: > > > > > > > > To expand on this, I'll take Ilari Liusvaara's comments: > > > >>Bleeding edge ideas? They essentially re-invented SIGMA, which > > > >>is > > > >>over 10 years old. The basic framework for doing 0-RTT is the > > > >>obvious one. The only new algorithm prsent since TLS 1.2 is > > > >>HKDF, > > > >>which is just 5 years old. > > > >> > > > >>So I don't see anything "experimential" ideas, mechanisms or > > > >>algorithms in there > > > >> > > > > When SSLv3 was introduced, it also used ideas that were 10-20 > > > > years > > > > old (DH, RSA, DES, etc, only SHA-1 was relatively new). They > > > > were > > > > mature algorithms, lots of research had been published on them, > > > > and > > > > yet we're still fixing issues with them 20 years later (DH = > > > > 1976, > > > > SSLv3 = 1996, Logjam = 2015). > > > > > > We all understand that the security of a protocol is not a > > > function > > > not of the primitives but of the way the protocol works. The > > > confusion between export and nonexport DH shares was noted almost > > > immediately in SSLv3. Furthermore, 512 bit DH is weak: I don't > > > know how this is a discovery in 2015, given that the reasons for > > > this were all worked out in the early 90's. So no, Logjam is not > > > a result of unknown issues appearing after 20 years, but ignoring > > > known issues. > > > > > > > TLS 2.0-called-1.3 will roll back the 20 years of experience we > > > > have > > > > with all the things that can go wrong and start again from > > > > scratch. > > > > > > > > SIGMA, at ten years old, is a relative newcomer to DH's 20 > > > > years > > > > > > > > when it was used in SSLv3, but in either case we didn't discover > > > > all the problems with it until after the protocol that used it > > > > was > > > > rolled out. We currently have zero implementation and > > > > deployment > > > > experience with 2.0-called-1.3 [0], which means we're likely to > > > > have another 10-20 years of patching holes ahead of us. This is > > > > what I meant by "experimental, bleeding-edge". > > > > > > There is an old joke about the resume with one years experience > > > repeated 20 times. All of the problems in TLS have been known for > > > decades, as I've repeatedly demonstrated on this list. All of them > > > were known to cryptographers at the time TLS was being designed > > > and > > > deployed. It does not take deployment to trigger analysis. > > > > Exactly this: BEAST and Lucky 13 "possible" problem was described in > > the RFC itself. Same thing for the "new" Bicycle attack - described > > in the RFC for TLS 1.0 and repeated in each version since. > > > > So lets not repeat those mistakes - if there are possible issues, > > lets fix those, now. > > But we should leave the description of the fixed problems somewhere to > avoid them in future. yes, decisions and recommendations should have rationale attached to them. And especially for recommendations, I don't see why we couldn't incorporate them in the RFC - at least for one, if the rationale is proven wrong it will be easier to explain why the recommendation should be disregarded. -- Regards, Hubert Kario Senior 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
Re: [TLS] Fixing TLS
Hubert Kario writes: >So lets not repeat those mistakes Exactly, there are more than enough new ones for 2.0-called-1.3 to make that we don't (necessarily) have to repeat existing ones (although I'm sure we will in some cases). And that's exactly my point, we're throwing away 20 years of refining TLS 1.x and more or less starting again with 2.0-called-1.3, with a whole new set of mistakes to make. I really don't want to spend the next 20 years patching all the holes that will be found in 2.0-called-1.3, I've already had enough of that for the 1.x version. TLS needs an LTS version that you can just push out and leave to its own devices, for the same reason that other products also have LTS versions, that lots of people have better things to do with their life than playing bugfix whack-a-mole for the duration of it. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fixing TLS
On Wednesday 13 January 2016 12:32:05 Peter Gutmann wrote: > Hubert Kario writes: > >So lets not repeat those mistakes > > Exactly, there are more than enough new ones for 2.0-called-1.3 to > make that we don't (necessarily) have to repeat existing ones > (although I'm sure we will in some cases). > > And that's exactly my point, we're throwing away 20 years of refining > TLS 1.x and more or less starting again with 2.0-called-1.3, with a > whole new set of mistakes to make. I really don't want to spend the > next 20 years patching all the holes that will be found in > 2.0-called-1.3, I've already had enough of that for the 1.x version. The only thing I saw in the "TLS 1.2.1" proposal that isn't already available is the longer Finished hash and a new signature type. Something that an extension can easily fix, rest is just a matter of setting a policy *and following it* with respect to used extensions and settings. If you want to patch it up like this, please do. But TLS 1.3 fixes more problems. > TLS needs an LTS version that you can just push out and leave to its > own devices, for the same reason that other products also have LTS > versions, that lots of people have better things to do with their > life than playing bugfix whack-a-mole for the duration of it. You're asking for impossible. The problems mentioned were not introduced into the protocols intentionally to make them obsolete, they are there because they weren't seen as big enough to fix. That's the mistake I say we should not repeat - "no issue left behind, no matter how small". -- Regards, Hubert Kario Senior 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
Re: [TLS] Fixing TLS
> TLS needs an LTS version that you can just push out and leave to its own > devices So don't you have that with TLS 1.1 and appropriate cipher and option choices? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fixing TLS
Salz, Rich wrote: > >> TLS needs an LTS version that you can just push out and leave to its own >> devices > > So don't you have that with TLS 1.1 and appropriate cipher and option choices? Actually, you already have that with TLSv1.0 plus the known mitigations. The only cryptographical improvement of TLSv1.1 over TLSv1.0 can be sufficiently achieved with 1+(n-1) record splitting -- for those few situations where this difference is meaningful at all. Only web-browsers that will happily execute any attacker supplied active-content plus the abuse of SSL known as SSL-VPNs need the record-splitting mitigation for block-ciphers in TLSv1.0. -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448
Hi All, Looks like I jumped too soon on this one. In particular, both the CFRG signature draft and 4492bis need to be updated. Let's hold of on code point assignment until then. Thanks, Joe (crawling back under my rock now) On Wed, Jan 13, 2016 at 3:04 AM, Alexey Melnikov wrote: > > > On 12 Jan 2016, at 21:31, Ilari Liusvaara > wrote: > > > >> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote: > >> > >>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson > wrote: > >>> > >>> The same concern still applies: what does it mean to allocate code > >>> point for the 4492bis-05 description? > >> > >> Allocating code points just means an implementation of draft-05 is > >> likely to interoperate just fine with an implementation of the final > >> RFC. > >> > >> Of course nothing is ever final until the RFC is out, so there’s > >> always a risk involved, but it is considered prudent to allocate > >> numbers when we’re reasonably certain of the calculations and on- > >> the-wire formats. Any debate about whether we should or should not > >> check certain inputs for certain conditions need not be a bar for > >> allocating numbers. > > > > Assuming CFRG chairs really did declare consensus on Ed448 hash, then > > the final characteristics of Ed448 are known and I have a reference > > implementation. > > > > And the PKIX draft looks implementable (has wrong example?) > > > > More serious interop hazard is what to do with X25519/X448 and THS > > (some of the proposed stuff is not wire-compatible). > > This CFRG co-chair would like to see an updated CFRG draft before the code > point is allocated. > > ___ > 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
[TLS] chacha/poly for http/2
We (OpenSSL) have already tested interop of chacha/poly with other browsers and TLS stacks, and now it all works. (The official IETF version, not the QUIC version). We (Akamai) are planning on enabling it for our customers in a few weeks, in case anyone might be interested. Thanks. /r$, a me who is part of both of the we's above :) -- 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] chacha/poly for http/2
Chrome is also expecting to ship the cipher in Chrome 49. It's available in Canary and Dev channel right now. It should interop with OpenSSL's master branch as of when I last tested this. David On Wed, Jan 13, 2016 at 12:48 PM Salz, Rich wrote: > We (OpenSSL) have already tested interop of chacha/poly with other > browsers and TLS stacks, and now it all works. (The official IETF version, > not the QUIC version). > > > > We (Akamai) are planning on enabling it for our customers in a few weeks, > in case anyone might be interested. > > > > Thanks. > > > > /r$, a me who is part of both of the we’s above J > > > > -- > > 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
[TLS] Length of a variable-length vector: Could it be an odd multiple?
I have a question about the even-vs-odd restrictions on the length of a valid variable-length vector defined in TLS specification after reading the section 4.3 of RFC 5246 [1] which states that: "The length of an encoded vector must be an even multiple of the length of a single element (for example, a 17-byte vector of uint16 would be illegal)." Does it also means that an 18-byte vector of uint16 would be illegal? (18 is an odd multiple of 2, not an *even* multiple of 2) To put it differently, given the following definitions for Foo and Bar: opaque Foo[2]; Foo Bar<4..8>; Is it correct to say that there does not exist any valid 6-byte value of type Bar? (6 is not an even multiple of 2) [1]: https://tools.ietf.org/html/rfc5246#section-4.3 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Length of a variable-length vector: Could it be an odd multiple?
On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: > I have a question about the even-vs-odd restrictions on the length of > a valid variable-length vector defined in TLS specification after > reading the section 4.3 of RFC 5246 [1] which states that: "The length > of an encoded vector must be an even multiple of the length of a > single element (for example, a 17-byte vector of uint16 would be > illegal)." > It means "whole-number" as opposed to fractional, i.e., there should not be unused "junk bytes" at the end. -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Length of a variable-length vector: Could it be an odd multiple?
On Thu, Jan 14, 2016 at 4:53 AM, Benjamin Kaduk wrote: > It means "whole-number" as opposed to fractional, i.e., there should not > be unused "junk bytes" at the end. > > -Ben Ah, so that is not about even vs odd numbers at all. Thank you very much for the quick clarification! ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fixing TLS
Salz, Rich writes: >> TLS needs an LTS version that you can just push out and leave to its own >> devices > >So don't you have that with TLS 1.1 and appropriate cipher and option >choices? That's the approach suggested previously by Peter Bowen, assemble it yourself from a huge list of extensions. The problem there is that you're after a fixed, known-good config drawn from the maybe 10 extension-RFCs you'd need to cover (from Peter's post + a few extra to cover new things), I don't want to go through all of those and count up the possible options but I'm pretty sure I'd need to resort to special notation to express the magnitude of combinations once you plug them into the nCk formula. Based on the feedback I've had, I'm kinda tempted to do a TLS 1.2 LTS draft that specifices just a single boolean flag, "use this known-good configuration and not the 6.023e23 other ones and you should be good for the next decade or so". That can then be baked into long-term systems and devices and left alone while people get on with other things. (Speaking of feedback, still got a bucketload of private email to respond to, including stuff from people I didn't know where on the list any more, turns out there's a lot more reading than writing, I'm working through it...). Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fixing TLS
Nikos Mavrogiannopoulos writes: >That is because TLS 1.3 is a rewrite of the protocol, and requires a rewrite >of the code base. Given that the majority of the issues in TLS >implementations are in the code bases and not in the protocol, it is very >risky to switch to such a new version just like that. +1. This is exactly what the 1.2LTS approach (at least it has a name now :-) is trying to address. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fixing TLS
On Thu, Jan 14, 2016 at 12:14:48AM +, Peter Gutmann wrote: > Salz, Rich writes: > > >> TLS needs an LTS version that you can just push out and leave to its own > >> devices > > > >So don't you have that with TLS 1.1 and appropriate cipher and option > >choices? > > Based on the feedback I've had, I'm kinda tempted to do a TLS 1.2 LTS draft > that specifices just a single boolean flag, "use this known-good configuration > and not the 6.023e23 other ones and you should be good for the next decade or > so". That can then be baked into long-term systems and devices and left alone > while people get on with other things. To actually fix the known problems with TLS 1.2, you would at minimum need a new extension, since there is currently no way to fix the broken server authentication. Then there are the other security fix extensions (at least three already). Those all would need to be impiled. And then there is the TLS 1.2 Diffie-Hellman issue... -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
