On Sunday 12 July 2015 16:39:37 Simon Josefsson wrote:
> Hubert Kario writes:
> > As is described in secion 5.1. of RFC 4492, and then reiterated in
> > section 2.2. of this draft - the elliptic_curves (a.k.a. supported_groups)
> > guides both the ECDH curves and curves under
table chain using the provided certificates
> and decides to abort the handshake, then it MUST send an
> "unsupported_certificate" alert message and close the connection.
> ====
What about the cert chain offered by client to server as a resp
On Tuesday 14 July 2015 17:23:44 Simon Josefsson wrote:
> Hubert Kario writes:
> > On Sunday 12 July 2015 16:39:37 Simon Josefsson wrote:
> >> Hubert Kario writes:
> >> > As is described in secion 5.1. of RFC 4492, and then reiterated in
> >> > sectio
On Monday 20 July 2015 14:39:03 Ilari Liusvaara wrote:
> On Mon, Jul 20, 2015 at 12:55:37PM +0200, Hubert Kario wrote:
> > On Tuesday 14 July 2015 17:23:44 Simon Josefsson wrote:
> > > Compare how we "reuse" the ECDHE ciphersuite values to refer to
> > >
or ECDHE key exchange if its preferred one is not advertised by client (in
most cases that means what happens if the client doesn't advertise P-256
curve). Then that curve is removed and the process repeated until the server
picks a ciphersuite that doesn't use ECDHE or aborts co
re new APIs for configuration, that in turn
means that not only libraries will need to be modified to add support for
TLS1.3 configuration but applications too - that will slow adoption
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czec
erverConfiguration, for clients with invalid clocks, would essentially
> never be cacheable. These clients wouldn’t benefit from
> ServerConfiguration.
the hint on tickets is already relative, so +1 on relative in server
configuration too
--
Regards,
Hubert Kario
Quality Engineer, QE BaseO
te from the TLS1.3 document
> and then have someone write a separate draft that adds a
> column to the registry where we can mark old crap as
> deprecated?
>
> Not sure if it'd work though.
https://tools.ietf.org/html/rfc7525 lists 4 RECOMMENDED ciphers, 6 if you
include
On Thursday 23 July 2015 11:43:45 Dave Garrett wrote:
> On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote:
> > vast swaths of web servers are misconfigured; introducing a more complex
> > mechanism to server configuration when the existing situation is
> > inc
other doesn't, the
details are voodoo witchcraft.
The way to remove all this legacy junk is to work towards sensible defaults in
libraries (RFC7568, RFC7465 style), not by putting antifeatures in protocol
specifications.
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS S
apoint, either the scan that was used as basis of that curve
> pruning doesn't support DSA, or there are no servers that even have
> DSA certs.
>
> I think I heard some time back that there are only 4 (or some other very
> small number) valid DSA SSL certs in the entiere public I
On Friday 24 July 2015 12:57:42 Dave Garrett wrote:
> On Friday, July 24, 2015 06:43:17 am Hubert Kario wrote:
> > And I completely agree. FREAK and Logjam wouldn't happen at all if we
> > didn't drag with us stuff that was considered legacy 10 years ago.
> >
> &
ciphersuite would be
DES, RC4, export grade...
That would allow us to reiterate in the TLS1.3 spec that they are a big no-no,
and that if you claim support for TLS1.3 you should never negotiate them with
a similarly modern peer.
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote:
> On Tue, Jul 28, 2015 at 05:41:58PM +0200, Hubert Kario wrote:
> > I see one possible problem with TLS1.3 not being a superset of TLS1.2.
> >
> > Consider the following:
> > Server which supports TLSv1.3 but i
On Saturday 01 August 2015 23:16:42 Florian Weimer wrote:
> * Hubert Kario:
> > On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote:
> >> In that case, it should be said that a client MUST NOT advertise
> >> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ci
ndshake was out of range or inconsistent with
> other fields. This message is always fatal.
>
> Is this alert suitable for the described scenario?
no, it's for values that are explicitly bound to some specific range (e.g.
client_random length tag always needs to be 32)
verify_da
de to TLS
> 1.2 (and FALLBACK_SCSV is useless here).
how is it useless?
A server which support at most TLS1.2 that receives a TLS1.2 client hello with
FALLBACK_SCSV MUST continue the connection with TLS1.2
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Se
24 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
vide information about
secret data, but there's very little of such data during handshaking,
where the vast majority of alerts apply and where they are most useful
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova
can count on one hand the Mandatory-to-Implement ciphersuites.
It's quite obvious that if you don't support anything but non-export RSA
key exchange, you don't need to be able to parse Server Key Exchange
messages...
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
W
in the
> thread) for why a server would choose not to send alerts, e.g. out of
> an abundance of caution. So, "MUST send" is clearly too far.
Sorry, but there are no good reasons why not to send them. Not sending
them may cause interoperability issues in the future, so a
e, but it will become one
in the future.
The same way as TLS protocol version in Client Hello
--
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
D
On Friday 18 September 2015 15:13:37 Bill Frantz wrote:
> On 9/18/15 at 4:27 AM, hka...@redhat.com (Hubert Kario) wrote:
> >except that a TLS1.3 version intolerant implementation won't
> >show its ugly head until TLS1.4 gets deployed
>
> Is there a reason a test suite ca
On Friday 18 September 2015 13:24:33 Brian Smith wrote:
> On Fri, Sep 18, 2015 at 4:36 AM, Hubert Kario
wrote:
> > On Friday 18 September 2015 00:58:19 Martin Rex wrote:
> > > Easier troubleshooting is IMO a sufficient rationale to justify
> > > existence of the al
essed data, so we can't
have extensions-after-extensions (which theoretically could have 3 byte
length field). That limitation is present since RFC 3546 [Extensions],
which explicitly says:
This overrides the "Forward compatibility note" in [TLS].
--
Regards,
Hubert Kario
Qual
On Monday 21 September 2015 15:04:17 Dave Garrett wrote:
> On Monday, September 21, 2015 07:22:03 am Hubert Kario wrote:
> > On Monday 21 September 2015 00:20:21 Dave Garrett wrote:
> > > A strong reason is it not being possible to change due to the need
> > > for TL
-located with NDSS in San Diego
> in late February 2016.
aren't we still missing the 0-RTT mode?
--
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 d
2. clients MUST NOT trust certificates which derive their authenticity
though SHA-1 (or weaker) signatures
but saying that the server MUST NOT send SHA-1 (or other certs) is, as
Victor said, an overreach
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
uch quicker (in
the same flight), but the window still exists.
That makes it dangerous when going from low to high security context,
not so much other way round.
--
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
tion.py
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-interleaved-application-data-in-renegotiation.py
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-openssl-3712.py
you can run them by:
pip install tlslite-ng
git clone https://github.com/tomato42/tlsfuzzer.git
On Wednesday 21 October 2015 20:17:31 Dave Garrett wrote:
> Congrats on releasing an RFC that has day one 100% server support. :p
oh, I'm sure there's at least one server out there that is intolerant to
this one specific extension ]:->
--
Regards,
Hubert Kario
Senior Qual
working.
Until you have to get a refund on a $500 purchase through such broken
web server...
--
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 d
uot;uncomptessed" should be "uncompressed"
--
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
deed it is problematic:
https://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guest
--
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: Th
move some from one column to another,
> that seems like a great mailing list discussion which I will let the
> chairs drive.
why max_fragment_length [RFC6066] is not to be supported in TLSv1.3?
https://tools.ietf.org/html/draft-ietf-dice-profile-17#section-15 states
that this is a MUST for IoT TLS profi
y send key shares and servers MUST
abort connection with something like illegal_parameter if that happens
--
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: Th
On Friday 27 November 2015 20:33:46 Xuelei Fan wrote:
> On Fri, Nov 27, 2015 at 8:12 PM, Hubert Kario
wrote:
> > On Friday 27 November 2015 10:50:40 Xuelei Fan wrote:
> > > > On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote:
> > > > > Can key_share
> If the orders are not consistent, if I can choose from two options:
> continue or alter, I would choose the continue option.
alter what?
> Alert message
> is expensive in practice.
Note that this alert will never be sent to a client that is behaving
according to specification unles
n that basis I would support that proposal. But that frankly seems
> to me likely a bit too much to ask given the diversity of TLS
> implementations and use-cases. Tell me if you believe otherwise.
That will just round up to a multiple of 256 bytes the data sizes
transmitted. Hardly an im
On Tuesday 01 December 2015 00:14:14 Jacob Appelbaum wrote:
> On 11/30/15, Hubert Kario wrote:
> > On Monday 30 November 2015 10:58:48 Bryan A Ford wrote:
> >> On 11/30/15 2:40 AM, Peter Gutmann wrote:
> >> > Nikos Mavrogiannopoulos writes:
> >> >>
cat macros and wedding pictures on
their social network of choice. If the old version of browser works or
an other browser works then it /obviously/ is the new browsers fault
that the connection fails so it's the /new/ browser that is broken.
So the browser vendor implements out-of-protocol fall
On Friday 16 October 2015 22:36:10 Kurt Roeckx wrote:
> On Fri, Oct 16, 2015 at 04:05:34PM +0200, Hubert Kario wrote:
> > On Friday 16 October 2015 09:16:01 Watson Ladd wrote:
> > > Unfortunately I don't know how to verify this. Can miTLS cover
> > > this
> >
use rsa as
> their fallback for hosts not doing ecdhe. ecdhe implementations
> weren't widespred until quite recently. A lot of patent foo has e.g.
> stopped some linux distros from shipping it.
Then maybe Chrome should reconsider.
I think we're overstating the compatibility cos
On Saturday 05 December 2015 23:54:25 Peter Gutmann wrote:
> Hubert Kario writes:
> >miTLS does accept Application Data when it is send between Client
> >Hello and Client Key Exchange and rejects it when it is sent between
> >Change Cipher Spec and Finished.
>
> Giv
On Saturday 05 December 2015 19:20:11 Watson Ladd wrote:
> On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann
wrote:
> > Hubert Kario writes:
> >>miTLS does accept Application Data when it is send between Client
> >>Hello and Client Key Exchange and rejects it when it
e:
It [Client Key Exchange message] MUST immediately
follow the client certificate message, if it is sent.
or, at section 7.4.9:
A Finished message is always sent immediately after a change
cipher spec message
The question is, which one takes precedence?
--
Regards,
Hubert Kario
yes there is one.
Java implementation of TLS can send Application Data during subsequent
handshakes.
--
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
Descriptio
2/tlslite-ng/blob/master/tlslite/utils/chacha20_poly1305.py
There's also support for the obsolete draft-00 of the TLS ciphersuites.
--
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,
1.2
so if we include rekeying in TLS, I'd suggest to set its limit to
something fairly low for dig data transfers, that is gigabytes, not
terabytes, otherwise we'll be introducing code that is simply not tested
for interoperability
(with AES-NI you can easily transfer gigabytes in
dition/implementation much more
invasive to the underlying library, OTOH, we have multiple ciphers which
use SHA-384 PRF. I think I just need to remind the delay after which NSS
added support for SHA-384 compared to introduction to AES-128-GCM TLS
ciphers...
--
Regards,
Hubert Kario
Senior Quality
On Monday 28 December 2015 21:08:10 Florian Weimer wrote:
> On 12/21/2015 01:41 PM, Hubert Kario wrote:
> > if the rekey doesn't allow the application to change authentication
> > tokens (as it now stands), then rekey is much more secure than
> > renegotiation was in TLS
On Monday 04 January 2016 13:02:57 Florian Weimer wrote:
> On 01/04/2016 12:59 PM, Hubert Kario wrote:
> > On Monday 28 December 2015 21:08:10 Florian Weimer wrote:
> >> On 12/21/2015 01:41 PM, Hubert Kario wrote:
> >>> if the rekey doesn't allow the applica
o why TLS1.3 should? Especially in just one place?
--
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.
___
On Monday 04 January 2016 09:44:57 Eric Rescorla wrote:
> On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario
wrote:
> > On Thursday 24 December 2015 01:04:59 Christian Huitema wrote:
> > > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote:
> > > >> Similarly
d use of MD-5 in implementations of stuff
like PAdES-A. Though it should strongly recommend allowing its use in
only *very* specific circumstances.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., P
possible at the time - only now we are closing on migration from
them
so, it was a _bad_ decision, but calling it a "braindead" one is a bit
over the top, sorry
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky
le test suites would be a good step toward
> implementing this strategy.
shameful plug: https://github.com/tomato42/tlsfuzzer and the underlying
https://github.com/tomato42/tlslite-ng
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o.,
tributed 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, Brn
eatedly 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
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
> > >
>
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&#x
56 implies P-256 and ecdsa_sha384
> implies P-384. I don't know if any such "Suite B client" actually
> exists, though.
OpenSSL since version 1.0.2 has a setting to enforce strict Suite B
compliance
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security t
84_sha512
> - ecdsa_p521_sha256
> - ecdsa_p521_sha384
> - ecdsa_p521_sha512
> - eddsa_ed25519
> - eddsa_ed448
Then what ECDHE share gets signed?
if the same as the curve, what about FFDHE, what about ECDHE-RSA? why no
- rsapss_dh2048_sha256
- rsapss_dh3072_sha256
- rsapss_dh409
ng[1] and current
OpenSSL master (0e76014e584ba7), using draft-ietf-tls-chacha20-
poly1305-04 implementation.
1 - https://github.com/tomato42/tlslite-ng/tree/chacha-ecdhe
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 9
On Tuesday 19 January 2016 16:50:18 David Benjamin wrote:
> On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario
wrote:
> > On Friday 15 January 2016 20:45:34 David Benjamin wrote:
> > > Hi folks,
> > >
> > > This is a proposal for revising SignatureAlgorithm/H
x27;s available at this point is conditioning TLS
> 1.3 support on appropriate hardware. For this reason TLS 1.3 it
> probably won't be enabled by default in the product I work on. I
> would prefer for TLS 1.3 to be enabled by default and write the code
> to decide whethe
On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote:
> On 01/22/2016 03:14 AM, Hubert Kario wrote:
> >> The only solution that's available at this point is conditioning
> >> TLS
> >> 1.3 support on appropriate hardware. For this reason TLS 1.3 it
> >>
ecially if the other way of doing things is just as interoperable,
and just as secure (if implemented properly) as the mandated one...
SHOULD with explanation why it's there is definitely better approach
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.c
On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote:
> On 01/22/2016 01:14 PM, Hubert Kario wrote:
> > On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote:
> >> On 01/22/2016 03:14 AM, Hubert Kario wrote:
> >>>> The only solution that's available at
On Monday 25 January 2016 19:32:57 Andrey Jivsov wrote:
> On 01/25/2016 03:11 PM, Russ Housley wrote:
> > On Jan 25, 2016, at 2:43 PM, Hubert Kario wrote:
> >> On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote:
> >>> On 01/22/2016 01:14 PM, Hubert Kario wrot
don't have the code to handle RSA-PSS certificates.
But that doesn't mean that there is no code that can do that.
--
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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Monday, 19 July 2021 21:37:08 CEST, Peter Gutmann wrote:
Hubert Kario writes:
It only doesn't matter if you don't want to verify the certificate...
It's one thing to be able to be able to verify an RSA-PSS signature on TLS
level, it's entirely another to be able to
On Tuesday, 20 July 2021 16:18:38 CEST, Peter Gutmann wrote:
Hubert Kario writes:
I suggest you go back to the RFCs and check exactly what is
needed for proper
handling of RSA-PSS Subject Public Key type in X.509.
Specifically when the
"parameters" field is present.
Looking a
compliant
when they are configured to not support SHA-1.
RFC5246 requires the server to abort with illegal_parameter if the
CV included an algorithm that wasn't advertised in CR.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech
it's too strong for CH.
Maybe
also NST.
--
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
___
TLS mailing list
TLS@ietf
at use browser's implementation of
certificate
verification and revocation.
And while they are significant users of TLS, they're definitely not the
only important users of TLS.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.red
On Monday, 31 January 2022 21:18:52 CET, Ryan Sleevi wrote:
On Mon, Jan 31, 2022 at 12:08 PM Hubert Kario wrote:
Browsers are the only software that use browser's implementation of
certificate
verification and revocation.
And while they are significant users of TLS, they're defi
t for OCSP stapling. So in practice, for OCSP stapling to become
common,
the implementations of those need to filter down to long-term supported
distributions...
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 6
ee as their future.
The same thing they did for the past 30 years: try to ignore it.
It's just that we now have the OneCRL for the "Too Big To Fail" websites
(/s).
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky
consensus calls
on other issues in separate threads.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
___
TLS mailing list
TLS@ietf
On Tuesday, 20 December 2022 19:37:14 CET, Rob Sayre wrote:
On Tue, Dec 20, 2022 at 4:53 AM Hubert Kario wrote:
Thus the deprecation of it is a matter of taste, not
cryptographic
necessity.
I'm sorry if I'm being dense here, but isn't all of this a
SHOULD NOT in RFC 9325?
On Tuesday, 20 December 2022 23:56:22 CET, Martin Thomson wrote:
On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote:
use of FFDHE with large key sizes is the best protection against
store-and-decrypt-later attacks
This doesn't deprecate use of FFDHE in TLS 1.3, for which we
have
ing from
https://firefox-source-docs.mozilla.org/security/nss/legacy/key_log_format/index.html
but maybe that is no longer the best reference.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czec
On Wednesday, 21 December 2022 19:13:36 CET, Rob Sayre wrote:
On Wed, Dec 21, 2022 at 5:59 AM Hubert Kario wrote:
Telling people that they shouldn't use the only things they can use means...
Well, I'd be curious to know what the use cases are.
The stuff Uri Blumenthal already
y behaving (see RFC 7919, which is referenced
in our draft).
It's also easy and quick to verify that the server *is* behaving correctly
and thus is not exploitable.
On Wed, Dec 21, 2022 at 5:14 AM Hubert Kario wrote:
On Tuesday, 20 December 2022 19:37:14 CET, Rob Sayre wrote:
On Tue, De
ry bodies.
We have RFC2119, so I think we should stick to it.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
protocol that will stop the server from sending
the master secret straight to KGB^W GRU in Moscow. Irrespective of the
TLS version and key exchange parameters used.
On Mon, 2 Jan 2023 at 15:52, Hubert Kario wrote:
On Thursday, 22 December 2022 23:26:26 CET, Carrick Bartle wrote:
the latter is basica
On Tuesday, 3 January 2023 11:33:39 CET, Peter Gutmann wrote:
Hubert Kario writes:
It's also easy and quick to verify that the server *is* behaving correctly
and thus is not exploitable.
It's also a somewhat silly issue to raise, if we're worried about a server
using deli
ntional mechanisms with post-
quantum signatures. Merkle Tree certificates integrate the roles of
X.509 and Certificate Transparency, achieving comparable security
properties with a smaller message size, at the cost of more limited
applicability.
The IETF Secretariat
--
Regar
usted now instead of a
more limited set of roots. This change is not trivial in my
eyes, but the end goal is similar, to shrink the amount of auth
data.
-Original Message-
From: TLS On Behalf Of Hubert Kario
Sent: Monday, March 13, 2023 11:08 AM
To: David Benjamin
Cc: ; Devon O&#x
On Tuesday, 21 March 2023 17:06:54 CET, David Benjamin wrote:
On Tue, Mar 21, 2023 at 8:01 AM Hubert Kario wrote:
On Monday, 20 March 2023 19:54:24 CET, David Benjamin wrote:
I don't think flattening is the right way to look at it. See my
other reply for a discussion about flattening
tively better than cached info.
-----Original Message-
From: Hubert Kario
Sent: Wednesday, March 22, 2023 8:46 AM
To: David Benjamin
Cc: Kampanakis, Panos ;
; Devon O'Brien
Subject: RE: [EXTERNAL][TLS] Merkle Tree Certificates
CAUTION: This email originated from outside of the
very least.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
th regards to
javacard https://arxiv.org/abs/1810.01662 but not sure if it can be
applied to TLS.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
it implemented in the web servers
3. backport those changes to stable branches (of both libraries and web
servers)
4. either rebase or backport the changes to long-term support Linux
distributions
It takes years for such changes to trickle down.
--
Regards,
Hubert Kario
Principal Quality
, PRF, and integrity protection mechanism. The key
exchange is fully controlled by supported_groups and key_share extensions.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45,
hard check (connection will fail if the key exchange
uses
custom DH parameters) good few years ago now.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Friday, 14 July 2023 18:03:25 CEST, Peter Gutmann wrote:
Hubert Kario writes:
FIPS requires to support only well known groups (all of them 2048 bit or
larger), and we've received hardly any customer issues after implementing
that as hard check (connection will fail if the key exc
etter than
you or me. Since they had their reasons for choosing custom,
“can change … to use well-known groups” (obviously) does not
apply.
Regards,
Uri
On Jul 14, 2023, at 12:33, Hubert Kario wrote:
!---|
This Message Is F
to use PKCS#1 v1.5 padding.
All the details can be found on the vulnerability page:
https://people.redhat.com/~hkario/marvin/
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
1 - 100 of 463 matches
Mail list logo
