but they do change and the server does use them?
you are not suggesting that which value will be used (from first or second
CH), or if the connection will be aborted, to be implementation dependant
*by design* , do you?
> -Ekr
>
> On Tue, Feb 12, 2019 at 4:53 AM Hubert Kario wro
On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote:
> On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote:
> > On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote:
> > > I concur with what I take to be MT's position here:
> > >
> >
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 Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote:
> > > I'n not sure I understand your question, but I'll try to answe
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
019.
> >>
> >> NOTE: There is one outstanding issue raised 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]
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
>
ntation 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
tacks.
--
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
n 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
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
LAN 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 Secu
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
> >> so)
>
ose 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
we all 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
Descriptio
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
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
> > >
hen 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ňo
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
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
> >
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 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 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
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
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
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
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 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
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 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:
>
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 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
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 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
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
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.
_
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
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
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
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.
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.
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
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 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 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 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
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 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:
> > >
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 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
> > &
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 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
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
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
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
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,
> > >
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
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
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
, 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
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
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
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
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
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 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 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
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.
– 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
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
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
er than the
biggest ECC curve that's widely supported (secp384) is the current
recommended minimum by ENISA and long term minimum by NIST (3072).
Using keys 5 times larger still is not impossible, so while it may not
buy us extra 20 years after ECC is broken, 10 years is not impossible
and 5
ust adding a quick blurb for this in there somewhere
> seems like the simplest solution to me.
The standard says that it must be a valid domain name, and those are
IIRC limited to 255 characters.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.co
t at least a
recommendation what to do if you want to avoid 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
signature.asc
Description:
On Monday 07 March 2016 23:32:55 Martin Thomson wrote:
> On 7 March 2016 at 23:02, Hubert Kario wrote:
> > well, if some people don't care about their implementation being
> > fingerprintable, let them be, but there should but at least a
> > recommendation what to do
On Monday 07 March 2016 15:23:17 Scott Fluhrer wrote:
> > -Original Message-
> > From: Hubert Kario [mailto:hka...@redhat.com]
> > Sent: Monday, March 07, 2016 6:43 AM
> > To: tls@ietf.org
> > Cc: Scott Fluhrer (sfluhrer); Nikos Mavrogiannopoulos; Hanno Bö
On Tuesday 08 March 2016 16:53:18 Scott Fluhrer wrote:
> > -Original Message-
> > From: Hubert Kario [mailto:hka...@redhat.com]
> > Sent: Monday, March 07, 2016 12:18 PM
> > To: Scott Fluhrer (sfluhrer)
> > Cc: tls@ietf.org; Nikos Mavrogiannopoulos; Hanno Bö
On Tuesday 08 March 2016 18:41:32 Viktor Dukhovni wrote:
> On Tue, Mar 08, 2016 at 07:24:37PM +0100, Hubert Kario wrote:
> > No, I said that we have no reason to believe that quantum computers
> > won't follow exponential increase in number of qbits they can
> > ha
gnature algorithms (hash especially) on Server and Client Key Exchange
messages?
Finally, I'd prefer the tls-lts to mostly say "see those other
extensions? I really do mean it" + some pleasantries like the "no
rehandshake".
--
Regards,
Hubert Kario
Senior Quality Engineer, QE
On Saturday 19 March 2016 09:30:26 Peter Gutmann wrote:
> Hubert Kario writes:
> >also, if it really is supposed to be Long Term Support, why it
> >doesn't say anything about implementation explicitly being able to
> >handle big key sizes? both RSA and DHE?
>
> I
On Monday 21 March 2016 12:35:25 Peter Gutmann wrote:
> Hubert Kario writes:
> >Note that I asked for "being able to handle", not "selects and uses".
>
> The issue here is that a Cortex M3 isn't going to be able to handle
> RSA-2048, no matter what an R
to modify server
state upon receiving GET request
and even just the fact that the server thinks it has processed so many
requests can be damaging (think timestamping service in which you pay
per request)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
R
t tomorrow (you know, in the "Long Term")
it's a waste of time to patch up attacks that are still largely
theoretical if you leave a mile wide hole in the fence
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r
On Tuesday 22 March 2016 09:55:07 Peter Gutmann wrote:
> Hubert Kario writes:
> >it doesn't explain where this "RSA-SHA-256" is used. IMHO it is
> >ambiguous.
> >
> >The "no MAC truncation" is also not explicit about what the sizes
> >sh
On Tuesday 22 March 2016 10:45:32 Martin Thomson wrote:
> On 22 March 2016 at 06:40, Hubert Kario wrote:
> > Only in theory, in practice you can do most of the same things in
> > GET's as you can in POSTs.
> >
> > in other words, basically web frameworks
)
given that we're trying to predict future, Extra Sensory Perception is a
good acronym to use ;)
--
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
ess this by creating a “Suite B Mode”, but that seems
> to address a specific case but leave the generic case unresolved.
Only the new OpenSSL actually can use more than one curve on the server
side...
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat
; for 2048 with "MUST use
ephemeral key share" is IMHO more appropriate
> I'd
> state secp384r1 (...) as "NOT RECOMMENDED" to bother with,
> but still permitted
I'd say it is a tad bit too strong of a wording for the strongest curve
supported by SChann
d include any of these 56-bit
> ciphers in any profile for TLS that is intended to provide security.
> So what is the benefit?
1. Showing why the code points are reserved.
2. Having official list of code points which must not be enabled (so
that scanners can be complete)
--
Regards,
On Tuesday 29 March 2016 15:09:16 Yoav Nir wrote:
> > On 29 Mar 2016, at 2:15 PM, Hubert Kario wrote:
> >
> > On Friday 25 March 2016 22:07:02 Yoav Nir wrote:
> >>> On 25 Mar 2016, at 8:16 PM, Yuhong Bao
> >>> wrote:
> >>>
> >>>
oint that
we need to assign new IDs to existing extensions.
--
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.
_
l? It would be nice to have some kind of stick for the broken
implementations...
--
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
but some are. So what does the browser
> do when a server resets the connection after seeing the ClientHello?
>
> Blank screen with a failure message?
fallback to check if the connection failure is caused by TLSv1.3, and if
it is, display error message and put the blame squarely on th
On Thursday 02 June 2016 14:49:52 David Benjamin wrote:
> On Thu, Jun 2, 2016 at 6:40 AM Hubert Kario wrote:
> > On Wednesday 01 June 2016 22:29:06 David Benjamin wrote:
> > > In case folks hoped we could bump the ClientHello version without
> > > those dreaded browser
On Thursday 02 June 2016 15:07:53 David Benjamin wrote:
> On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario wrote:
> > On Thursday 02 June 2016 11:39:20 Yoav Nir wrote:
> > > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos
> > > > wrote:>
> > > >
On Thursday 02 June 2016 15:22:03 David Benjamin wrote:
> On Thu, Jun 2, 2016 at 11:07 AM David Benjamin
> wrote:
> > On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario
wrote:
> >> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote:
> >> > > On 2 Jun 2016,
y.
--
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.
___
TLS mailing lis
, in current editor's draft, key_share or pre_shared_key
> > is always present and none are meaningful in TLS.1.2.
>
> But they cannot be used to distinguish TLS 1.3 with any future
> versions, if these two extensions still exist in TLS 1.4, 1.5, ... .
TLSv1.4 and TLSv1.5 can
y;
just because there are few bad apples.
> With respect to the concern of version numbers being moved to a
> non-fixed position, we could just require that the new version list
> extension be first or last in the extensions list.
it's still after the variable-length list of ciphersuites
cenarios would they be used? How is it
different from the captive_portal?
--
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: T
201 - 300 of 463 matches
Mail list logo
