ure bloat. I think it makes a lot of sense
to question the support of features nobody uses. Therefore I'm very
interested to hear why anybody would want to use DSA. "Just because
someone could" isn't a good reason.
(Also DSA has a well-known weakness with bad random numbers.)
s 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
Therefore: I think a MUST is better.
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpwV5RTpF9Bz.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
severely changes the security expectations one can have from a
browser.
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpasQL35Nfoo.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.
e number of options if they don't
make sense.
Therefore: Please don't introduce another algorithm into TLS - unless
you have very good arguments (i.e. it is vastly better than the other
options or you have serious arguments why you think AES-GCM and
chacha20/poly1305 are in danger of being
own by previous results, even the OpenSSL
implementation was lacking proper countermeasures not that long ago,
but it's not impossible)
Deprecating the RSA keyexchange just became a bit harder with Google's
intent to deprecate DHE in Chrome and use RSA as the fallback if the
host doesn't do E
On Thu, 3 Dec 2015 18:45:14 -0500
Watson Ladd wrote:
> On Tue, Dec 1, 2015 at 3:02 PM, Hanno Böck wrote:
> > So as long as you make sure you implement all the proper
> > countermeasures against that you should be fine. (Granted: This is
> > tricky, as has been shown by p
much variation. Let's keep things simpler, let's reduce
the algorithm zoo.)
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpARhQ8AV2Cs.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
think we should go with fewer options in the future. Can we
strip that down to - below 5 or something? (personal opinion: Strip
down to 2, but this may be too radical for now.)
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpkrBJu0EUUI.pgp
Description: OpenPG
1.5 in TLS 1.3 is reasonable.
Let's not repeat the mistakes from the past.
[1]
https://blog.filippo.io/bleichenbacher-06-signature-forgery-in-python-rsa/
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpFny99O0zsR.pgp
Description: OpenPGP digital signature
_
So how do we warn you next time?
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpNpM6LT2ltE.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
were designed in the past (i.e. TLS 1.2 times)
where it was often considered desirable to add as much flexibility as
possible.
(Also FWIW the relevance of DH is pretty small these days. I think the
largest web clients simply don't support it at all.)
--
Hanno Böck
https:/
in the meantime.
I would assume it's very likely that SCSV serves no useful purpose today
and hasn't done so for years.
--
Hanno Böck
https://hboeck.de/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
hout heartbeat, which is a good thing as long as it's not
used anyway. If it gets used in DTLS then at least make sure that
doesn't mean it also has to be enabled in TCP-based normal TLS at the
same time.
--
Hanno Böck
https://hboeck.de/
ately why it's been created).
Why would you even write a recommendation for what people should do
with TLS 1.2-only implementations? (I understand this is merely
relevant for implementations not supporting TLS 1.3 at all.) Shouldn't
the recommendation be: "Don't.
not seek to
support a wide variety of algorithms.
I'd oppose any specification of new cipher suites without a good
justification, and I think this is an opinion many here share.
--
Hanno Böck
https://hboeck.de/
___
TLS mailing list
TLS@ietf.org
https:
ile stapling implementation is
not a good idea. This has improvde in Apache recently, however requires
a maybe not widely known option ("MDStapling") that is not the default.
I'm not sure about the situation in nginx.
--
Hanno Böck
https://hboeck.de/
rver, thus
making client connections potentially faster.
2. It avoids a potential privacy issue for clients who would otherwise
leak their intent to connect to a specific host to their CA.
tl;dr I think enabling OCSP stapling on servers almost always makes
sense.
--
Hanno Böck
https:/
ures that likely let things fail early in
various situations where things go wrong.
--
Hanno Böck
https://hboeck.de/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
any version unknown to us" is certain to cause breakage in the
future. Whoever built this is harming the Internet, full stop.
I really don't understand why there is such intransparency over this
issue. Why can't we at least make clear who are the companies
responsible for this nonsen
Hi,
The deployment of TLS 1.3 was delayed because Internet middleboxes
broke when they saw unknown TLS data.
I guess it's plausible to assume that the same problem will show up
with compressed certificates. Has any thought been given to that?
--
Hanno Böck
https://hboeck.de/
mail/jabbe
o "rescue" it over into the next
protocol.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
that. (I'm also
considering writing an RSA-kex-diediedie RFC when I find time for it.)
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
field with TLS
1.4 or a large post quantum key exchange message).
The question I want to ask: What can we do *now* to stop this from
happening when TLS 1.4 will be deployed? I have the feeling GREASE
won't be enough...
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE737
a company that
already created two independent problems for TLS 1.3 will do the same in
future products that mess with TLS in "new and exciting ways".
And for the unlikely case that Cisco is able to learn from past mistakes
I'm absolutely sure there will be others creating simil
rs breaking TLS with the
actors who are worried about things like SNI encryption. I'm not sure I
see any reason not to consider these actors as anything but opposed to
the work of this group.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937
oyments of TLS
(aka browsers). They have no significant advantage over the other
choices. They pretty much exist because Germany wanted to have their
homegrown crypto algorithm, too, meaning they exist for nationalistic
reasons, not technical ones. So deprecating them has the same reason we
don&#
maximally large number of
algorithms specified for TLS. To the contrary, I believe it'd be good
to keep things as simple as possible and limit choices if there's no
good reason for them.
I don't think there's any reason for the brainpool curves except NIH
syndrome.
--
Hanno Böck
ht
almost
inevitably will lead to more trouble in the future.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Some implementations will end up adding them and coupled with
implementation flaws we may end up in a situation where inadvertently
insecure ciphersuites are chosen.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E2
y and I believe that of many people is that the protocol
should avoid implementation pitfalls whereever possible. And I believe
an authentication-only ciphersuite is a dangerous implementation
pitfall.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.d
ainst
RSA PKCS #1 1.5, one against encryption and one against - badly
implemented - signatures)
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpOvHDhmYRgZ.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS
se explain.
(shameless plug: I wrote my thesis about PSS, in case anyone wants to
read it: https://rsapss.hboeck.de/ - it's been a while, don't be too
hard on me if I made mistakes)
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB5
postquantum is ahead) I doubt anything else than the
primitives we already have in standards will ever be viable.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpnn2C2wYISN.pgp
Description: OpenPGP digital signature
___
TLS ma
original Bleichenbacher attack (and all its variants including drown)
is based on separating different errors, the Vaudenay attack is.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpYHTQr5FQIB.pgp
Description: OpenPGP digital signature
___
il-archive/web/tls/current/msg20207.html
[3]
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Notes_on_TLS_-_SSL_3.0_Intolerant_Servers
[4] https://www.ietf.org/mail-archive/web/tls/current/msg10657.html
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
lerance and
tell people to fix their stuff.
I'm now also collecting some data and have some preliminary
suspicion on affected devices. My numbers roughly match yours that we
are in the more or less 3% area of 1.3 intolerance.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.
oo much about the
randomness part here. Unlike with other situations (e.g. ecdsa/dsa) the
randomness is not a piece that once you take it away everything blows
up.
[1] https://tools.ietf.org/html/rfc3447
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpOIJowXJ
C2 etc. - yet? We
could just stuff that in)
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
pgpOQJMA9gIKG.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://w
ciphersuite you should have some good arguments why
they offer something that the current ones don't. Ideally these should
be specific. (Aka "Someone could need that for hypothetical situation
XYZ" is not very compelling. "I am developing a widely used product
where this would im
to change TLS 1.3 in a way that
such keys would be simply forbidden. But I did a check on the censys
data and there were too many of them in the wild, so I thought it
wasn't a feasible idea.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E
t way is to support that
at the end points (let alone any arguments why you're doing traffic
inspection in the first place and whether those reasons are good ones).
If you don't like that then TLS may be not the right protocol for your
use case.
--
Hanno Böck
https://hboeck.de/
mail/ja
g
tech that's available instead of inventing new tech.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
this. Now."
3. Call for a boycott of the vendors who are not able to fix this.
Seriously... If only 2 or 3 of the large companies that are involved
here would do this I am sure we don't have such problems any more in
the future.
--
Hanno Böck
https://hboeck.de/
ma
ngrade to 1.2.
Given that this would also mean there's no visible incentive to fix
things it would very likely mean keeping this broken workaround for
many years to come.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E
45 matches
Mail list logo
