y,* uses.
what it does is it introduces a second glitch
speaking of confusion, do you know that e-mail clients by "SSL" mean "SSL/TLS"
and by "TLS" mean "STARTTLS"?
(note the port numbers)
https://sils.unc.edu/it-services/email-faq/outlook
https://ma
ment is demonstrably false)
yes, it is much worse
--
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.
___
ot worth bothering with?
>
> I feel like we're unlikely to come up with enough modes that we run out
> of space, so it is probably okay to grease it. But I would be okay if
> people wanted to not do so, too.
>
> -Ben
+1 to greasing psk_key_exchange_modes
--
Regards,
Hubert
tory
> algorithm).
sorry for the slight off-topic: how can you create such certificates with
openssl command line util?
--
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
ally reject technically malformed CH2 messages (ones with more
changes than prescribed) as you won't be able to create a CH1 that creates the
matching HMAC.
I do not think that stateless HRR is special enough to mess around with
message transcript hash...
--
Regards,
Hubert Kario
Senior
of Internet facing servers that
require SHA-1 being advertised for connection to be successful.
SHOULD NOT is a good compromise for it.
--
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 Repu
ac.
That's a big difference between it, and ealy data, where to server there's no
difference between correct ciphertext encrypted with unknown key and string of
random data.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.
dn't "NamedCurve" references be renamed to "NamedGroup" (e.g. in
Section 5.5.1.)
--
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
RSA_WITH_AES_128_GCM_SHA256
> >o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> >o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> >o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
looks like an "E" is missing here
--
Regards,
Hubert Kario
Senior Quality Engineer, QE
with a salt, sending
the salt and the resulting hash, making the server calculate the same hash
with each of the virtual host names it supports and comparing with the client
provided value?
(apologies if that was already proposed and rejected)
--
Regards,
Hubert Kario
Senior Quality Engineer
On Wednesday, 10 May 2017 20:25:22 CEST Viktor Dukhovni wrote:
> > On May 10, 2017, at 1:28 PM, Hubert Kario wrote:
> >
> > Couldn't we "encrypt" the SNI by hashing the host name with a salt,
> > sending
> > the salt and the resulting hash, making the
On Wednesday, 10 May 2017 21:28:48 CEST Ilari Liusvaara wrote:
> On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote:
> > Yes, encrypted SNI was discussed and ultimately rejected.
> >
> > But do we really have to send the literal value? Don't we need to just
On Wednesday, 10 May 2017 21:04:53 CEST Viktor Dukhovni wrote:
> > On May 10, 2017, at 2:47 PM, Hubert Kario wrote:
> >
> > But in general, I wonder if we didn't approach the SNI from the wrong side
> > - as I said, we may not need to encrypt it, we just make su
the key to encrypt the SNI. But if we don't want the names to
leak, how do I authenticate the key without telling the server what
certificate I will accept to authenticate the key?
That doesn't look to me like a problem we can solve with typical symmetric or
asymmetric crypto - it lo
designing a new opt-in
> system.
>
> The argument I'm making here isn't about implementation; it's about what to
> think about implementing to deal with the issues here.
I respectfully disagree. That system requires tight coupling between the TLS
implementation and DNS.
On Monday, 15 May 2017 22:10:00 CEST Dave Garrett wrote:
> On Monday, May 15, 2017 07:56:44 am Hubert Kario wrote:
> > On Saturday, 13 May 2017 07:21:06 CEST Dave Garrett wrote:
> > > On Friday, May 12, 2017 11:17:45 pm Christian Huitema wrote:
> > > > EKR did propo
98.5%)
P-384 = 49233 (98.5%)
P-256 + P-384 = 49233 (98.5%)
P-256 + !P-384 = 10 (0.02%)
!P-256 + P-384 = 0 (0%)
--
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, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
> On 07/21/2017 08:23 AM, Hubert Kario wrote:
> > Signature Algorithms for ECDSA now define both the curve and the hash
> >
> > algorithm:
> > ecdsa_secp256r1_sha256(0x0403),
> >
On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> On 07/21/2017 09:34 AM, Hubert Kario wrote:
> > On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
> >> On 07/21/2017 08:23 AM, Hubert Kario wrote:
> >>> Signature Algorithms for ECDSA now defi
On Monday, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote:
> On 07/24/2017 05:49 AM, Hubert Kario wrote:
> > On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> >> I'm afraid I don't understand this remark. There is the caveat to which
> >> Il
lientHello
that the client sends. But the value of 'truncated' is an enigma.
--
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
On Friday, 28 July 2017 14:45:40 CEST Benjamin Kaduk wrote:
> On 07/28/2017 07:41 AM, Hubert Kario wrote:
> > (looking at -21)
> >
> > Section 4.2.10.2 PSK binder refers to ClientHello1[truncated] as the value
> > that needs to be used as parameter to Transcript-Hash.
On Monday, 31 July 2017 02:28:44 CEST Martin Thomson wrote:
> On 28 July 2017 at 23:44, Hubert Kario wrote:
> > something like this:
> >ClientHello1 is the initial ClientHello and ClientHello2 is the
> >ClientHello
> >send by client as a response to Hel
sent to
the list would indicate), quite a bit of text is missing.
--
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
ssage took (even if it gets the information that the received message
was padded, which is not possible with current common library APIs).
So even if the application takes exactly as much time to process a long
request as it does to process a short request, the length of that processing
will leak.
-
simple when you
just are sending acknowledgement message), the timing will still be leaked.
1 - https://www.imperialviolet.org/2013/02/04/luckythirteen.html (very bottom)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova
On Tuesday, 15 August 2017 00:55:50 CEST Colm MacCárthaigh wrote:
> On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario wrote:
> > the difference in processing that is equal to just few clock cycles is
> > detectable over network[1]
>
> The post you reference actually says the opp
algorithms, but TLS itself). Ideally
> TLS 1.3 itself shouldn't use data-size depending calculations itself
> such as the one described here.
>
> regards,
> Nikos
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://
On Tuesday, 15 August 2017 15:54:15 CEST Ilari Liusvaara wrote:
> On Tue, Aug 15, 2017 at 03:31:56PM +0200, Hubert Kario wrote:
> > I've created a Pull Request that introduces requirement for constant time
> > processing of padding and an example on how to do it:
> >
&g
On Tuesday, 15 August 2017 18:27:27 CEST Colm MacCárthaigh wrote:
> On Tue, Aug 15, 2017 at 1:55 PM, Hubert Kario wrote:
> > On Tuesday, 15 August 2017 00:55:50 CEST Colm MacCárthaigh wrote:
> >> On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario wrote:
> >> ... a
t life cycle.
>
> -Ekr
>
>
>
> On Tue, Aug 15, 2017 at 6:54 AM, Ilari Liusvaara
>
> wrote:
> > On Tue, Aug 15, 2017 at 03:31:56PM +0200, Hubert Kario wrote:
> > > I've created a Pull Request that introduces requirement for constant
> > > ti
On Tuesday, 15 August 2017 19:42:30 CEST Benjamin Kaduk wrote:
> On 08/14/2017 01:26 PM, Ilari Liusvaara wrote:
> > On Mon, Aug 14, 2017 at 08:03:08PM +0200, Hubert Kario wrote:
> >> Current (21) draft references RFC 6961 in multiple places, in particular
> >
to be identical to
first one with few exceptions, the server does not need to parse or verify it
fully before responding with Server Hello.
--
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 R
heck
limitations of the EE certificate before you select signing algorithm.
But that is also the case if you are using HSM for signing and it doesn't
support necessary algorithms (in extreme case, it may even require disabling
TLS 1.3 support completely).
--
Regards,
Hubert Kario
Senior Qualit
mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
--
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
If both rsa_pss_sha256 and rsa_pkcs1_sha256 are sent, then all 6 combinations
should be supported by client.
--
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, Cze
S 1.3 so implementers don't have to bother
> with this.
what about hardware tokens that support only specific hashes or signatures?
(I've seen ones that can do only RSA with SHA256 and SHA-1, but not SHA-384 or
SHA-512) Isn't it basically the same code path (though the limitatio
hash you are suggesting should be "the same everywhere".
I'm quite sure you're not suggesting that we should limit TLS 1.3 to SHA256
only (no SHA384 or SHA512), are you?
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat
ock size for CBC ciphers - 16 bytes
- max padding - 16 bytes
since MAC size is the exact multiple of block size, the padding starts in
worst possible place if the MAC size is arranged on block boundary. Thus the
worst case scenario padding length is 16 bytes. Same in case of EtM.
--
R
nd signatureAlgorithm is chosen by the CA, and it is quite common
already that e.g. a P-384 CA signs with SHA384 a P-256 intermediate CA that
then signs EE with a SHA-256. I really don't think that *all* hashes should be
the same.
How exactly using more secure parameters for longer lived
ference for
RSA and server wants to respect it.
Situation with two RSA keys with different limitations is not much different.
We still want to pick a certificate that can be used to make a signature that
client claims it will be able to verify - rsa_pss_sha256.
--
Regards,
Hubert Kario
Senior Quali
ern there.
>
> On Thu, Sep 14, 2017 at 12:17 AM, Hannes Tschofenig
>
> wrote:
> > Hi Hubert,
> >
> > your proposal to include the worst case calculations are indeed another
> > possibility. It provides more information for the developer than the
> > current
f our employees use Chrome.
>
> So tell them not to use Chrome, says the manager.
>
> Because for the manager the decision to update the middlebox is all risk
> with no rewards.
also the middlebox vendor will say that "we do not support TLS1.3", after you
spell out that p
On Thursday, 12 October 2017 15:16:08 CEST Stephen Farrell wrote:
> (With the obvious caveat that I hate the whole
> idea... :-)
to be clear: me too
> On 12/10/17 13:57, Hubert Kario wrote:
> >> Anyway, I think key life length could be addressed in later drafts, but
> >
On Friday, 13 October 2017 14:45:35 CEST Stephen Farrell wrote:
> On 13/10/17 12:05, Hubert Kario wrote:
> > On Thursday, 12 October 2017 15:16:08 CEST Stephen Farrell wrote:
> >> (With the obvious caveat that I hate the whole
> >> idea... :-)
> >
> > to be
ve to get the cooperation of the
> > clients.
> > If a middlebox has sufficient power to block traffic, force clients into
> > opting in, and coerce servers into opting in, it seems like they have
> > sufficient alternative options that are of equivalent effort ("e
oundaries, with no defined key schedule, usage
> requirements or forward secrecy. Clearly, the consensus has been
> willing to accept that trade-off, and there is definite wiggle room.
which part of the HTTP 0-RTT usage policy does say that that is acceptable?
--
Regards,
Hubert Kario
Senior Qu
nnot combine, e.g.,
> ServerHello (plaintext) and EncryptedExtensions (encrypted with the
> handshake traffic key) messages in one record?
given that it's the record layer that is encryped, not the handshake message,
I'm not sure how would you put an unencrypted and encrypted ha
tes to TLS 1.2 (I expect them to
> publish those shortly). We expect to have further measurements from
> Chrome as well as from Firefox by the WG meeting.
>
> Please take a look and hopefully we can close on this in Singapore.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE
On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote:
> On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario wrote:
> > In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious
> > failures as rare as possible is a good way to make that happen.
> >
> &
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
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
___
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
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
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
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
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
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
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
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 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
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
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
401 - 463 of 463 matches
Mail list logo
