uld happen any day now), and at least some of the underlying
rationales are certainly applicable to TLS.
yes, the question is if we want to pair P-256 with ML-KEM-512 or with
ML-KEM-768 for the "FIPS compatible fast option" hybrid key exchange group.
I don't have a strong opinion either way
ey_share over anything else, omitting P-256+PQ from the
supported_groups is likely to cause interoperability issues.
Thus, that combination should be Recommend=Y. (and to hammer the point
further: X448 is Recommend=Y, and basically nobody is including that
group in key_share, we need P-256+PQ at the
On Friday, 7 June 2024 19:08:22 CEST, D. J. Bernstein wrote:
Hubert Kario writes:
I think the openssl compile is missing the `enable-ec_nistp_64_gcc_128`
option?
Results on the same Comet Lake of a fresh run of the script with that
option added to the Configure line
On Friday, 7 June 2024 17:29:35 CEST, John Mattsson wrote:
Hubert Kario wrote:
Such small differences in performance should absolutely have no effect on
IETF selecting an algorithm or not.
I completely disagree. As long as people argue that we need
symmetric rekeying and reuse of key share
On Friday, 7 June 2024 15:54:17 CEST, D. J. Bernstein wrote:
Hubert Kario writes:
Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H
x25519 derive shared secret: 35062.2 op/s
P-256 derive shared secret: 22741.1 op/s
The Intel Core i7-10850H microarchitecture is Comet Lake. To see numbers
from
rver_name, as it MAY
be used by the server to figure out if it can resume a session or not, so
it's recommended to repeat it even if the client intends and expects the
session to be resumed
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Ha
ove to see x25519 in governmental standards, I think it's
better to spend energy making sure that we deploy ML-KEM as soon as
possible,
in hybrid mode, both with x25519 *and* NIST curves (at the very least P-256
and
P-384).
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto
s e-mail does not constitute a contract offer, a contract
amendment, or an acceptance of a contract offer unless
explicitly and conspicuously designated or stated as such.
,
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purk
tion from what the specification requires.
One more thing: we are finalizing RFC 8446-bis right now, so if there is
WG consensus to require that clients offer all MTI curves in the key_shares
of their initial CH, then that would be a straightforward text change.
I definitely don't agree with
Critera requirements will have to use
P-384+ML-KEM.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
TLS mailing list -- tls@ietf.org
To unsub
S.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
to migrate a significant population of existing users
to better practice.
--
Viktor.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
instead of a MUST NOT, but the
sentiment was they should be generally discouraged.
Please respond with any comments on this proposal by April 30,2024.
I still don't like deprecating/discouraging/SHOULD NOTig FFDHE, but
I'm still for the proposal, and OK with using "D" for mark
kex in TLS.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
surprised that we need to do it... (put it down as "not opposed")
If adopted, I'll definitely take a look on it from the perspective
of testing, and including the test coverage in tlsfuzzer
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redha
uence (as most servers that can't
do ECC also ignore rfc7919), so there's chance that they are bad.
The other is if the server has static key share, then it's vulnerable to
Raccoon attack.
None of which are fixed by EMS
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL
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
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
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
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
, 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,
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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?
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
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
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
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
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
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
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
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
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
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
alert" and "abort the handshake with an X alert" mean that the
implementation MUST send alert X if it sends any alert.
so while unfortunate, not really internally inconsistent
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www
turn that it will be used incorrectly by somebody
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
___
TLS mailing list
TLS@ietf.org
https
– I expect
that
if we do allow 2040 flags, the extension in 10 or 20 years will commonly
include
just few set bits and plenty of zeros – wasting bandwidth again
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612
or newest ticket
(and disregard races on this lookup) and a garbage-collection process that
removes old tickets every few hours will work ok.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o.
On Thursday, 12 December 2019 21:55:42 CET, Nick Harper wrote:
On Thu, Dec 12, 2019 at 8:27 AM Hubert Kario wrote:
On Thursday, 12 December 2019 16:50:45 CET, David Benjamin wrote:
On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote:
...
so because Google decided one thing, everybody has
On Thursday, 12 December 2019 16:50:45 CET, David Benjamin wrote:
On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote:
On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: ...
... some TLS stacks don't
support renegotiation as a server at all (BoringSSL and Go).
... C
On Thursday, 12 December 2019 16:26:41 CET, Ryan Sleevi wrote:
On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote:
If TLS 1.2 was looking insecure, I would be with you on this
one. But given
that TLS 1.2 can be configured to be as secure as TLS 1.3, I think
introducing
weak points to TLS 1.3
On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote:
On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara
wrote:
On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote:
On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote:
One test I just tried:
- Smartcard
d send RSA PKCS#1v1.5 client signature (scheme 0x0401) in
comparable situation.
[3] My guess would be that browser asks drivers for RSA-PSS, which they
do not support, causing the error.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat C
essages
from an actual attacker (which, need I remind, MUST be handled correctly
and
result in orderly connection shutdown, one that hopefully includes Alert
messages)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 11
lswg/draft-ietf-tls-md5-sha1-deprecate/pull/2
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/3
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czec
, it depends if the SHA-1 was advertised by client or not
if it was advertised (because of certificates, see above), then
handshake_failure is correct; if it wasn't advertised but the
signature_algorithms were included, then yes, client should abort with
illegal_parameter
--
Regards,
Hubert
On Friday, 15 November 2019 13:00:14 CET, Daniel Migault wrote:
Hi Hubert,
On Thu, Nov 14, 2019 at 12:33 PM Hubert Kario wrote:
On Thursday, 14 November 2019 18:18:52 CET, Daniel Migault wrote:
Hi Hubert,
I understand the reasons for SHOULD. At least this should be documented.
To
what if the server misbehaves?
Yours,
Daniel
On Thu, Nov 14, 2019 at 11:59 AM Hubert Kario wrote:
On Thursday, 14 November 2019 17:19:55 CET, Daniel Migault wrote:
Hi Chris,
Thanks for the responses, please see my comments inline.
Yours,
Daniel
On Thu, Nov 14, 2019 at 11:02 AM Christoph
count requested
by
client mandatory?
Because I see it only increasing complexity of implementation for no
benefit.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00
On Monday, 21 October 2019 17:43:52 CEST David Benjamin wrote:
> On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario wrote:
> > On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote:
> > > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00,
> > >
f you're
using TLS 1.3 that means you are not using legacy crypto" has non
insignificant value too.
This document erodes that.
So I'm against adoption of this draft by the WG.
If it is adopted, I will review and provide feedback on it.
--
Regards,
Hubert Kario
Sen
t; https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-03
except for the "vend" and "vended" typos, looks good to me
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., P
ption key expiring
> Yours,
> Daniel
>
> On Mon, Oct 7, 2019 at 10:46 AM Hubert Kario wrote:
> > On Saturday, 5 October 2019 14:08:45 CEST Christopher Wood wrote:
> > > On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote:
> > > > On Thursday, 3 October 2019 22:1
On Saturday, 5 October 2019 14:08:45 CEST Christopher Wood wrote:
> On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote:
> > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote:
> > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote:
> > > > On Wednesday
er to still
send them in case of resumption and STEK rollover of PHA, but I'm not sure if
we're not too far into the weeds...
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Rep
On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote:
> On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote:
> > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote:
> > > I understand the meaning of count is the higher limit of ticket and the
> > &
t; On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood wrote:
> > On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote:
> > > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote:
> > > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote:
> > >
On Wednesday, 2 October 2019 13:18:07 CEST Hubert Kario wrote:
> On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote:
> > On Tue, Oct 1, 2019 at 5:27 AM John Mattsson >
> > 40ericsson@dmarc.ietf.org> wrote:
> > > Dan Brown wrote:
> > >
th you about the policy here. To be honest, I just didn't notice
> this; and it would probably need some github spelunking to figure out the
> history of these references.
>
> If someone wanted to propose an erratum that would fix this, I would be
> very appreciative.
I just did propo
On Wednesday, 2 October 2019 00:15:13 CEST Peter Gutmann wrote:
> Hubert Kario writes:
> >a lax DER parser sounds like an oxymoron to me... :)
>
> That's why I assumed it was an accident/error. Writing a spec that relies
> on buggy parser implementations in order to wor
On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote:
> On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote:
> > > > ```
> > > > Servers MUST NOT send more than 255 tickets to clients.
> > > > ```
> > > >
> > > > per wha
On Monday, 30 September 2019 16:40:57 CEST Dan Brown wrote:
> A brief reminder below about 2 new extra elements of ECDSA-Sig-Value.
>
> > -Original Message-
> > From: TLS On Behalf Of Hubert Kario
> > Sent: Monday, September 30, 2019 8:56 AM
>
> ...
>
On Monday, 30 September 2019 15:36:36 CEST Christopher Wood wrote:
> On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote:
> > On Saturday, 28 September 2019 01:59:42 CEST Christopher Wood wrote:
> > > This version addresses some of the comments we received from Hubert a
> >
On Monday, 30 September 2019 15:56:19 CEST Jeremy Harris wrote:
> On 30/09/2019 14:36, Christopher Wood wrote:
> > On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote:
> >> Clients must therefore
> >> bound the number of parallel connections they initiate
nge the value of TicketRequestContents.count in
second ClientHello messages sent in response to a HelloRetryRequest.
```
'A server MUST abort the connection with an "illegal_parameter" if the value
of the extension changed, it was added or removed in second ClientHello.
directly from the text. So I
think the RFC 8446 should be updated with an erratum that specifies the source
of the ECDSA-Sig-Value structure.
1 - https://www.secg.org/sec1-v2.pdf
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.
ted with it and published under the auspice of IETF to also be
available in English
it's a matter of practicality, not politics
1 - other automated internet translation services are available
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.c
to be negotiated.
yes, option 1 sounds like a safer bet given the number of unknowns we have to
work with
(though the exact proposed mechanism is a bit clunky)
both leave open the question how the secrets should be combined – some kind of
concatenation scheme or another round of Derive-Secret → HKD
stribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprof
his expectation. I'd say it should abort with unsupported_extension.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_
be more prescriptive about handling of situation
when all sigalgs in CR are unusable to the client, but given the RFC overall
and Alert description explanations, I think sending handshake_failure in such
situation is quite uncontroversial.
and of course, the client MUST NOT abort the connection up
On Tuesday, 14 May 2019 20:16:17 CEST Loganaden Velvindron wrote:
> On Tue, May 14, 2019 at 3:24 PM Hubert Kario wrote:
> > On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote:
> > > Latest draft is here:
> > > https://www.ietf.org/id/draft-lvelvindron-tl
connection to fail
this is also partially the reason for a SHOULD NOT instead of MUST NOT for
section 2 and 3 – I do not know how those servers handle interaction between
SHA-1 missing in the extension and root CA (self-signed certificate) being
signed by SHA-1
--
Regards,
Hubert Kario
Senior Q
On Tuesday, 14 May 2019 16:52:49 CEST Martin Rex wrote:
> Hubert Kario wrote:
> > Martin Rex wrote:
> >> Hubert Kario wrote:
> >>> MD5 was deprecated and removed by basically every library
> >>> and can't be used in TLS 1.2, I specifically meant
y that
ciphersuites like TLS_DHE_RSA_WITH_AES_128_CBC_SHA are _not_ deprecated by it
SKE and CV don't use HMAC
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description
On Friday, 10 May 2019 00:24:49 CEST Martin Rex wrote:
> Hubert Kario wrote:
> > MD5 was deprecated and removed by basically every library
> > and can't be used in TLS 1.2, I specifically meant SHA1
>
> MD5 deprecated ? Nope, glaring emtpy:
>
On Wednesday, 8 May 2019 02:31:57 CEST Martin Rex wrote:
> Hubert Kario wrote:
> >> Thanks to Peter Gutmann for the summary:
> >> https://mailarchive.ietf.org/arch/msg/tls/g0MDCdZcHsvZefv4V8fssXMeEHs
> >>
> >> which you may have missed.
> >
>
On Tuesday, 7 May 2019 01:57:30 CEST Martin Rex wrote:
> Hubert Kario wrote:
> > On Friday, 3 May 2019 16:56:54 CEST Martin Rex wrote:
> >> Hubert Kario wrote:
> >> > We've been over this Martin, the theoretical research shows that for
> >> > Me
ted it with the draft authors, the conclusion was that it
probably should be a separate RFC.
1 - while in practice one popular implementation actually used it as a
"required" list – it would abort connections when the sigalg of the
certificate it had wasn't inc
On Friday, 3 May 2019 16:56:54 CEST Martin Rex wrote:
> Hubert Kario wrote:
> > We've been over this Martin, the theoretical research shows that for
> > Merkle- Damgård functions, combining them doesn't increase their security
> > significantly.
>
> Yo
On Friday, 3 May 2019 16:56:54 CEST Martin Rex wrote:
> Hubert Kario wrote:
> > We've been over this Martin, the theoretical research shows that for
> > Merkle- Damgård functions, combining them doesn't increase their security
> > significantly.
>
> Yo
ms that.
So, please, use a bit less inflammatory language when you have no factual
arguments behind your assertions.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Descrip
time the RFC
> starts to change operator behaviour the "market share" of TLS 1.0 will be
> substantially lower than I see today even with SMTP, XMPP, NTTP and the
> like.
>
> [ I would speculate that TLS 1.0's share is noticeably higher among MTAs
> generally than
On Tuesday, 2 April 2019 18:29:18 CEST Christian Huitema wrote:
> On 4/2/2019 4:42 AM, Hubert Kario wrote:
> > On Monday, 1 April 2019 23:05:41 CEST Martin Thomson wrote:
> >> On Mon, Apr 1, 2019, at 12:40, Hubert Kario wrote:
> >>>>> would possibly
On Monday, 1 April 2019 23:05:41 CEST Martin Thomson wrote:
> On Mon, Apr 1, 2019, at 12:40, Hubert Kario wrote:
> > > > would possibly reduce the size of is ServerHello or
> > > > EncryptedExtensions
> > >
> > > Those are messages where we have
On Friday, 29 March 2019 10:24:44 CEST Martin Thomson wrote:
> On Thu, Mar 28, 2019, at 14:46, Hubert Kario wrote:
> > what about resumption and renegotiation?
>
> No certificates in resumption.
>
> No resumption in TLS 1.3 (and I don't care about TLS 1.2 any more).
On Friday, 29 March 2019 10:23:51 CEST Martin Thomson wrote:
> On Thu, Mar 28, 2019, at 14:54, Hubert Kario wrote:
> > what about making sure that the legacy and flags remain in-sync? we will
> > have to send the legacy encoding for many years to come, so only thing it
> >
gt; > version -01:
> >
> > HTML: https://datatracker.ietf.org/doc/html/draft-nir-tls-tlsflags
> > DIFF: https://www.ietf.org/rfcdiff?url2=draft-nir-tls-tlsflags-01
> >
> > Yoav
> >
> > ___
> > TLS mailing
1 - 100 of 463 matches
Mail list logo
