ignificant 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
___
TLS mailin
nstead 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 marking in IANA.
--
Rega
.
--
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
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.redhat.com
Red Hat C
c7919), 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 Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/
is not 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
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 From an External
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 exchange
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
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, Brno, Czec
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
/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
___
TLS mailing list
TLS@ietf.org
.
--
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
ached 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
organization. Do not c
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
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'Brien
Subject: RE: [EXTERNAL][TLS] Merkle Tree Certificates
CAUTION: This
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
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web
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 deliberately broken
om 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 basically unexploitable with properly behaving
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
(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, Dec 20, 2022 at 4
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 mentioned
://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, Czech Republic
___
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 some
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?
https://www.rfc
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.org
https
eir 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ňova 99/71, 612 45,
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, 612 45
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 definitely
ementation 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.redhat.com
Red Hat Czech s.r.o., Purky
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.org
https
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 s.r.o
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 properly handle all
sn'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.cz.redhat
in 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
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 00 Brno, Czech Republic
(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., Purkyňova 115, 612 00
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).
... Chrome
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
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 Czech s.r.o
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 115, 612 00 Brno
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
pends 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 Kario
Senior Qu
er 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 Christopher Wood ...
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 Brno, Czech Republic
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,
> > >
'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
Senior Quality Eng
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
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 Republic
signature.asc
Description: This i
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:
> > >
agree with 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 propose an
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 work is
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 initia
ketRequestContents.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.' ?
--
Regards,
Hubert
he 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.r.o., Purkyňova 115,
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.com
Red Hat Czech s.r
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 → HKDF-Extract
--
Regards,
Hubert
ution 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
> nonprofit co
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.
___
t 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 upon seeing such
legacy va
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
n 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 Quality Eng
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 SHA1
icitly 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
Descr
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:
> ht
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
> >> > Merkle-
hors, 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 included in the ClientHello
--
R
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.
>
> You are
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
Description: This is a digitally
gt; 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 among the bleeding-e
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 possib
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
> >
ersion -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 list
>
n the server or client intend to use an "unpublished"
(term not defined in RFC) the behaviour of them is unspecified
what about resumption and renegotiation?
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 11
On Wednesday, 27 March 2019 14:51:43 CET Martin Thomson wrote:
> On Tue, Mar 26, 2019, at 14:30, Hubert Kario wrote:
> > On Tuesday, 26 March 2019 09:07:51 CET Martin Thomson wrote:
> > > We don't trust that the key share or certificate is good either, but
> > > once
On Tuesday, 26 March 2019 16:38:11 CET Yoav Nir wrote:
> > On 26 Mar 2019, at 14:45, Hubert Kario wrote:
> >
> > On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
> >> Hi. Today at the TLS meeting, there was a discussion at the mic about
> >> 1-bit ex
ll remember the bugs related to ASN.1 parsing from inside of
PKCS#1 v1.5 signatures
--
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: Th
se things are part of the protocol, not destined for application
(or even if they are, they are actionable only after the handshake finished)
> On Mon, Mar 25, 2019, at 19:12, Hubert Kario wrote:
> > On Monday, 25 March 2019 17:02:34 CET David Schinazi wrote:
> > > Ah, I s
On Monday, 25 March 2019 19:31:24 CET Yoav Nir wrote:
> > On 25 Mar 2019, at 19:23, Hubert Kario wrote:
> >
> > On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
> >> Yeah, so this looks very much like the IKE mechanism (the draft even says
> >&
may
have multiple Internet uplinks, every other connection may end up with a
different IP (albeit from a small pool), so a public IP of any particular
connection does not reliably indicate public IP of subsequent connections.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security
On Monday, 25 March 2019 17:02:34 CET David Schinazi wrote:
> Ah, I see - thanks. In other words, the proposal requires trusting the
> server and the reply comes before the identity of the server has been
> authenticated.
exactly
> David
>
> On Mon, Mar 25, 2019 at 4:54 PM H
own and
then he'll be able to generate arbitrary encrypted EncryptedExtensions message
the forgery will be noticed only after the CertificateVerify is processed
> Thanks,
> David
>
> On Mon, Mar 25, 2019 at 12:31 PM Hubert Kario wrote:
> > I wanted to rise one comme
.
--
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.
___
TLS mailing list
ation of RFC 5246 all signature_algorithms
> supported by server must be included in certificate request message (and
> client hello has nothing to do with certificate request message)!
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red H
On Wednesday, 27 February 2019 13:52:57 CET Stephen Farrell wrote:
> On 27/02/2019 12:30, Hubert Kario wrote:
> > I'm not sure which part for the key_share extension you mean as being
> > empty, but the key_exchange in the KeyShareEntry can't be empty, per RFC
> > 8446
ed by Hubert [0]. Please
> >> chime in there or here so that we can address his comment one way
> >> or the other.
> >>
> >> Thanks, Chris, Joe, and Sean
> >>
> >> [0]
> >> https://mailarchive.ietf.org/arch/msg/tls/nr4dA2JqcpqAjh-oY_
On Wednesday, 13 February 2019 20:01:10 CET Eric Rescorla wrote:
> On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario wrote:
> > On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote:
> > > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote:
> > > > On Wednes
1 - 100 of 380 matches
Mail list logo
