Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

[Martin Rex]

Hubert Kario  wrote:
> 
> there are attacks, like BEAST, that TLS 1.0 is vulnerable to that
> TLS 1.1 and TLS 1.2 are not - that's a fact there are ciphersuites
> that are invulnerable to Lucky13 and similar style of attacks that
> can not be used with TLS 1.0 or TLS 1.1 - that's a fact

BEAST is an attack against Web Browsers (and the abuse known as SSL-VPNs),
it is *NO* attack against TLS -- whose design properties are described
in appendix F of rfc5246, and there is a trivial workaround for those
few apps that were affected.  Continued mentioning of BEAST really
only means one thing: severe crypto-cluelessness.

  http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html

There are two things that BEAST showed:
   Running arbitrary attacker-supplied active content is a bad idea!
   Performing protocol version downgrade dances is a bad idea.

Lucky thirteen applies equally to all three:  TLSv1.0, TLSv1.1 and TLSv1.2,
but was a real-world issue only for borked implementations of DTLS (those
implementations that were providing a no-limits guessing oracle.


> 
> that doesn't sound to me like "ZERO security benefit",

You seem to be confusing the difference between
  (1) ensuring that TLSv1.2 support is enabled
with
  (2) disabling TLSv1.0 + TLSv1.1 support.

If you do (1), then (2) does not add security benefits.

> 
>> On digitally_signed, is proven that TLSv1.2 as defined by rfc5246
>> is the weakest of them all.
> 
> yes, provided that:
>  - MD5 is actually in use
>  - or Joux does not hold and MD5+SHA1 is _meaningfully_ stronger[1]
> than SHA-1 alone *and* SHA-1 is actually in use

MD5 || SHA-1  is **ALWAYS** meaninfully stronger than SHA-1 alone, *NO* if!

>  
>> The POODLE paper
>>https://www.openssl.org/~bodo/ssl-poodle.pdf
>> 
>> asserts that many clients doing downgrade dances exist, and at the
>> time of publication, this includes Mozilla Firefox, Google Chrome and
>> Microsoft Internet Explorer.
> 
> either we consider clients that haven't been updated for half a decade now to 
> be of importance, then disabling support for old protocol versions has 
> meaningful security benefit, or we ignore them as they include insignificant 
> percentage of users and are vulnerable to much easier attacks anyway
> 
> so, which way is it?

MSIE seems to still be doing downgrade dances _today_, btw.


-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-external-psk-importer-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : Importing External PSKs for TLS
Authors : David Benjamin
  Christopher A. Wood
Filename: draft-ietf-tls-external-psk-importer-00.txt
Pages   : 8
Date: 2019-05-14

Abstract:
   This document describes an interface for importing external PSK (Pre-
   Shared Key) into TLS 1.3.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-00
https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Daniel Migault]

On Tue, May 14, 2019 at 2:27 PM Hubert Kario  wrote:

> On Tuesday, 14 May 2019 20:09:36 CEST Daniel Migault wrote:
> > section 2:
> >
> > I am wondering whether SHOULD NOT could be replaced by  MUST NOT. On the
> > one hand, deprecation should be smooth, but on the other hand I am
> reading
> > that rfc6194 and rfc6151 already started the deprecation. I would rather
> > favour MUST NOT.
> >
> > Maybe we need to also indicate that MD5 or SHA-1 are ignored by the
> > receiver.
>
> that was the intention behind my suggestion for SHOULD NOT - i.e. the
> server
> MUST be able to handle ClientHello that does advertise them, but in
> practice
> ignore them based on required handling for SKE and CV
>
>
got it, then the text needs to be explicit in each case we should not hide
ourselves behind a vague SHOULD.


> > section 3:
> >
> > The title section maybe should be Certificate Request (without 's').
> > Similarly to the previous section I would suggest MUST NOT and specifying
> > how the client would behave upon receiving MD5 or SHA-1 as hash.
>
> same as above
>
> > section 6:
> >
> > The current rfc5246 rely on default sha-1 and md5. To ease
> interoperability
> > I am wondering if we strongly recommend to provide the signature
> algorithm
> > extension in addition to the default sha256.
>
> no, sha-1 is the default in case the extension is omitted, but then we
> also
> specify that if the extension is omitted now, the negotiation MUST fail
> the recommendation for sha256 is that it in practice has to be included in
> the
> extension as some servers use the extension to select server certificate,
> so
> omitting sha256 there will cause the connection to fail
>
> Works for me. I believe the reasoning worth being mentioning. In addition,
the section update of 5246 coudl also emphasis changes are not limited to
the NEW text.


> 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
>
> I had the same question ;-) and of course not the response.  I believe
that we should clarify this and document the choice for MUST/SHOULD.

> --
> 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://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Hubert Kario]

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-tls-md5-sha1-deprecate-04.txt
> > 
> > why did you drop SHA-1 from Section 4 and 5?
> 
> It was done following this comment from David Cooper.
> 
> "
> [..] While they may be subject to collision attacks, SHA-1 is still
> considered secure in cases in which collision resistance is not required,
> and I do not believe that collision resistance is required when SHA-1 is
> used to create the "signatures" in the ServerKeyExchange and
> CertificateVerify messages.
> "

SLOTH paper disagrees on that as far as CertificateVerify message is concerned

SP 800-52 rev-2 does not provide much in terms of justification why SLOTH 
paper would be wrong and allows for SHA-1 signatures only in TLS 1.0 and TLS 
1.1, it does not explicitly state that SHA-1 signatures in TLS 1.2 are 
allowed...
-- 
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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Hubert Kario]

On Tuesday, 14 May 2019 20:09:36 CEST Daniel Migault wrote:
> section 2:
> 
> I am wondering whether SHOULD NOT could be replaced by  MUST NOT. On the
> one hand, deprecation should be smooth, but on the other hand I am reading
> that rfc6194 and rfc6151 already started the deprecation. I would rather
> favour MUST NOT.
> 
> Maybe we need to also indicate that MD5 or SHA-1 are ignored by the
> receiver.

that was the intention behind my suggestion for SHOULD NOT - i.e. the server 
MUST be able to handle ClientHello that does advertise them, but in practice 
ignore them based on required handling for SKE and CV
 
> section 3:
> 
> The title section maybe should be Certificate Request (without 's').
> Similarly to the previous section I would suggest MUST NOT and specifying
> how the client would behave upon receiving MD5 or SHA-1 as hash.

same as above
 
> section 6:
> 
> The current rfc5246 rely on default sha-1 and md5. To ease interoperability
> I am wondering if we strongly recommend to provide the signature algorithm
> extension in addition to the default sha256.

no, sha-1 is the default in case the extension is omitted, but then we also 
specify that if the extension is omitted now, the negotiation MUST fail
the recommendation for sha256 is that it in practice has to be included in the 
extension as some servers use the extension to select server certificate, so 
omitting sha256 there will cause the 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 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Loganaden Velvindron]

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-tls-md5-sha1-deprecate-04.txt
>
> why did you drop SHA-1 from Section 4 and 5?
>
> It was done following this comment from David Cooper.
"
[..] While they may be subject to collision attacks, SHA-1 is still
considered secure in cases in which collision resistance is not required,
and I do not believe that collision resistance is required when SHA-1 is
used to create the "signatures" in the ServerKeyExchange and
CertificateVerify messages.
"



> the note about SHA-1 in HMAC applies to ciphersuites, to state explicitly
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

[Hubert Kario]

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
> >> 
> >> MD5 deprecated ?  Nope, glaring emtpy:
> >>   https://www.rfc-editor.org/errata_search.php?rfc=5246
> >> 
> >> MD5 removed ? Mostly, but several implementors had to be prodded with
> >> 
> >>   with CVE-2015-7575 (SLOTH) to remove it.
> > 
> > I meant in practice
> > 
> >> The real issue at hand is:
> >>   Prohibiting TLSv1.0 and TLSv1.1 is going to result in lots of
> >>   interop problems, while at the same time providing *ZERO*
> >>   security benefit.
> > 
> > that's your opinion, not an established fact
> 
> You got this backwards.
> 
> There is a bold assertion that disabling TLSv1.0 and TLSv1.1 (alone)
> would provide security benefits, but a complete lack of proof.

there are attacks, like BEAST, that TLS 1.0 is vulnerable to that TLS 1.1 and 
TLS 1.2 are not - that's a fact
there are ciphersuites that are invulnerable to Lucky13 and similar style of 
attacks that can not be used with TLS 1.0 or TLS 1.1 - that's a fact

that doesn't sound to me like "ZERO security benefit", and similar issues were 
the reason why we generally don't use SSL2 and SSL3 any more and why RFC 7568 
was published

> On digitally_signed, is proven that TLSv1.2 as defined by rfc5246
> is the weakest of them all.

yes, provided that:
 - MD5 is actually in use
 - or Joux does not hold and MD5+SHA1 is _meaningfully_ stronger[1] than SHA-1 
   alone *and* SHA-1 is actually in use

those are big if's

 1 - where meaningfully = at least by a work factor of 2^10
 
> >>   What *WOULD* provide *HUGE* benefit, would be to remove the
> >>   dangerous "protocol version downgrade dance" from careless
> >>   applications,
> >>   that is the actual problem known as POODLE, because this subverts the
> >>   cryptographic procection of the TLS handshake protocol.
> >>   
> >>   We've known this downgrade dance to be a problem since the discussion
> >>   of what became rfc5746.  Prohibiting automatic protoocol version
> >>   downgrade dances is going to ensure that two communication peers
> >>   that support TLSv1.2 will not negotiate a lower TLS protocol version.
> > 
> > which exact piece of popular software actually still does that?
> > It ain't curl, it ain't Chrome, it ain't Firefox.
> 
> It definitely was implemented in Chrome and Firefox, which is how this
> poor document got onto standards track:

key words: "still" and "was"
 
> The POODLE paper
>https://www.openssl.org/~bodo/ssl-poodle.pdf
> 
> asserts that many clients doing downgrade dances exist, and at the
> time of publication, this includes Mozilla Firefox, Google Chrome and
> Microsoft Internet Explorer.

either we consider clients that haven't been updated for half a decade now to 
be of importance, then disabling support for old protocol versions has 
meaningful security benefit, or we ignore them as they include insignificant 
percentage of users and are vulnerable to much easier attacks anyway

so, which way is it?

-- 
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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Daniel Migault]

Hi,

Please find some comments.

Yours,
Daniel

Introduction

I would suggest a reference to rfc6194 for sha1 digest as well as for
hmac-sha1.

I believe more text in the introduction may be needed to expose how the
document impacts TLS 1.2.

Typically, the impacted structure is HashAlgorithm, This structure is used
by SignatureAndHashAlgorithm which defines the Signature Algorithms
extension and is included in messages such as CertificateRequest  In
addition a number of messages rely on this extension (, ServerKeyExchange,
CertificateVerify) and they will be impacted by the current document.

Updating the HashAlgorithm registry was caught in the previous version by
updating the enum. While this is not the standard procedure to deprecate a
registry entry, I believe the intention was there. I would rather suggest
to do that in the IANA section..

section 2:

I am wondering whether SHOULD NOT could be replaced by  MUST NOT. On the
one hand, deprecation should be smooth, but on the other hand I am reading
that rfc6194 and rfc6151 already started the deprecation. I would rather
favour MUST NOT.

Maybe we need to also indicate that MD5 or SHA-1 are ignored by the
receiver.

section 3:

The title section maybe should be Certificate Request (without 's').
Similarly to the previous section I would suggest MUST NOT and specifying
how the client would behave upon receiving MD5 or SHA-1 as hash.

I believe SHA-1 has been dropped in section 4 and 5.

section 6:

The current rfc5246 rely on default sha-1 and md5. To ease interoperability
I am wondering if we strongly recommend to provide the signature algorithm
extension in addition to the default sha256.

section 7:

The new text is missing a capital letter: s/severs/Servers.

Unless i am missing something, I would limit the update to the scope of the
draft and leave the sentence discussing the group unchanged. .

In the following paragraph and s/MUST not/MUST NOT/.

I believe the IANA section is missing:

TLS HashAlgorithm should have the values

1 md5 Y [RFCTBD]
2 sha1 Y [RFCTBD]


Yours,
Daniel


On Tue, May 14, 2019 at 7:25 AM 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-tls-md5-sha1-deprecate-04.txt
>
> why did you drop SHA-1 from Section 4 and 5?
>
> the note about SHA-1 in HMAC applies to ciphersuites, to state explicitly
> 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___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

[Kathleen Moriarty]

On Tue, May 14, 2019 at 12:33 PM David Benjamin 
wrote:

> > which exact piece of popular software actually still does that?
>> > It ain't curl, it ain't Chrome, it ain't Firefox.
>>
>> It definitely was implemented in Chrome and Firefox, which is how this
>> poor document got onto standards track:
>>
>>https://tools.ietf.org/html/rfc7507
>>
>>  TLS Fallback Signaling Cipher Suite Value (SCSV)
>> for Preventing Protocol Downgrade Attacks
>>
>> >
>> > It also isn't something done automatically
>> > by any TLS implementation that's even remotely popular:
>> > OpenSSL, NSS, GnuTLS, schannel, Secure Transport, go...
>>
>> It is impossible to do this transparently, because the a connection
>> is ususable after a fatal TLS hanshake failure (or unexpected socket
>> closure).
>>
>> Any application-level cleartext negotiation will have to be repeated
>> as well, and the TLS implementation typically does not know about it.
>> (such as HTTP CONNECT or STARTTLS)
>>
>> The POODLE paper
>>https://www.openssl.org/~bodo/ssl-poodle.pdf
>>
>> asserts that many clients doing downgrade dances exist, and at the
>> time of publication, this includes Mozilla Firefox, Google Chrome and
>> Microsoft Internet Explorer.
>>
>
> Chrome has not done a downgrade dance for over three years now (Chrome 50,
> released in April 2016), even for TLS 1.3. Indeed much of the fuss around
> TLS 1.3 was so clients could avoid repeating this mess.
>

Martin,

There's also value in people having fewer choices as security problems are
often the result of misconfigurations.  A lower number of protocols to
support, chose from, and configure correctly is helpful to the larger
number of implementers.  Additionally, there is at least one library that
planned to remove support for 1.0 and 1.1.  This means that is product
teams need to continue support, they have to run an older version of the
library, plus newer ones for 1.3.  This gets messy and increases the chance
of error.  The chance of misconfiguration is not insignificant (by product
teams or implementers of those products).

Best regards,
Kathleen


>
> David
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 

Best regards,
Kathleen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

[Martin Rex]

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
>> 
>> MD5 deprecated ?  Nope, glaring emtpy:
>>   https://www.rfc-editor.org/errata_search.php?rfc=5246
>> 
>> MD5 removed ? Mostly, but several implementors had to be prodded with
>>   with CVE-2015-7575 (SLOTH) to remove it.
> 
> I meant in practice
> 
>> The real issue at hand is:
>> 
>>   Prohibiting TLSv1.0 and TLSv1.1 is going to result in lots of
>>   interop problems, while at the same time providing *ZERO*
>>   security benefit.
> 
> that's your opinion, not an established fact

You got this backwards.

There is a bold assertion that disabling TLSv1.0 and TLSv1.1 (alone)
would provide security benefits, but a complete lack of proof.
On digitally_signed, is proven that TLSv1.2 as defined by rfc5246
is the weakest of them all.

>> 
>>   What *WOULD* provide *HUGE* benefit, would be to remove the
>>   dangerous "protocol version downgrade dance" from careless applications,
>>   that is the actual problem known as POODLE, because this subverts the
>>   cryptographic procection of the TLS handshake protocol.
>>  
>>   We've known this downgrade dance to be a problem since the discussion
>>   of what became rfc5746.  Prohibiting automatic protoocol version
>>   downgrade dances is going to ensure that two communication peers
>>   that support TLSv1.2 will not negotiate a lower TLS protocol version.
> 
> which exact piece of popular software actually still does that?
> It ain't curl, it ain't Chrome, it ain't Firefox.

It definitely was implemented in Chrome and Firefox, which is how this
poor document got onto standards track:
   
   https://tools.ietf.org/html/rfc7507

 TLS Fallback Signaling Cipher Suite Value (SCSV)
for Preventing Protocol Downgrade Attacks

>
> It also isn't something done automatically 
> by any TLS implementation that's even remotely popular:
> OpenSSL, NSS, GnuTLS, schannel, Secure Transport, go...

It is impossible to do this transparently, because the a connection
is ususable after a fatal TLS hanshake failure (or unexpected socket closure).

Any application-level cleartext negotiation will have to be repeated
as well, and the TLS implementation typically does not know about it.
(such as HTTP CONNECT or STARTTLS)

The POODLE paper
   https://www.openssl.org/~bodo/ssl-poodle.pdf

asserts that many clients doing downgrade dances exist, and at the
time of publication, this includes Mozilla Firefox, Google Chrome and
Microsoft Internet Explorer.


-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] early code-point assignment request for draft-ietf-tls-dtls-connection-id-04

[Kraus Achim (INST/ECS4)]

Hi Joe,

> request to our AD
 
is there an "expected date" for that requested assignment of early code-points?
I tried to find something on the IANA page, but wasn't successful.
 
Mit freundlichen Grüßen / Best regards 

Achim Kraus

(INST/ECS4) 
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | 
GERMANY | http://www.bosch-si.com 

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. 
Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic



From: TLS  On Behalf Of Joseph Salowey
Sent: Montag, 15. April 2019 17:18
To: Achim Kraus 
Cc:  
Subject: Re: [TLS] early code-point assignment request for 
draft-ietf-tls-dtls-connection-id-04

No concerns from the working group so I made the request to our AD.  

Cheers,

Joe

On Mon, Apr 15, 2019 at 6:55 AM Achim Kraus  wrote:
Hello Joe,

did the working group receive any concerns about the early code-point
assignment? I hope not. Hannes did again a very great job and so I
closed my open issues on the github repo.
Is there any schedule for the early code-point assignment?
I plan a next eclipse-californium milestone release and it would be very
great, if I could include the values of the early assigned code-points.

best regards
Achim Kraus

Am 05.04.19 um 22:18 schrieb Joseph Salowey:
> We have received a request for early code-point assignment of values for
> draft-ietf-tls-dtls-connection-id-04.  We believe that only editorial
> changes are pending. Please respond to this list of you have concerns
> about these assignments by April 12, 2019.
>
> Thanks,
>
> Joe, Sean and Chris
>
> ___
> TLS mailing list
> mailto:TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Hubert Kario]

On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote:
> Latest draft is here:
> https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt

why did you drop SHA-1 from Section 4 and 5?

the note about SHA-1 in HMAC applies to ciphersuites, to state explicitly 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: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Loganaden Velvindron]

[comments in-line]

On Fri, May 10, 2019 at 5:47 AM Martin Thomson  wrote:

> It might pay to spend more time on explaining what you are trying to do.
>
> The goal appears to be to remove a dependency on signature schemes that
> include these weaker hash functions.  But the introduction just says that
> the functions are bad.
>
> We've updated the draft.


> You should be very clear about what effect this has on the use of SHA-1 in
> HMAC for record protection.  It looks like you don't intend to deprecate
> that.  Say that.
>
> Added.

> The change to the enum is silly.  Overall, I think that the updates to
> 5246 are unnecessary.  Concentrate on 7525.
>
> Removed change to enum.

> The 7525 text starts with "When using RSA", so it could be read to not
> apply to ECDSA.  That would be a mistake.  I recommend splitting the
> paragraph into talking about the group size (the first sentence) and a
> separate paragraph on hash functions used as part of the signing process.
>
> This change was also incorporated.

> As part of that, this probably needs to be a MUST: "Clients SHOULD
> indicate to servers that they request SHA-256, by using the "Signature
> Algorithms" extension defined in TLS 1.2."
>
> And then I think we should publish something.  Like David, I'm acutely
> aware of the compatibility hazard that this presents, but it's no less
> worth doing.
>
> We also agree with you.
Latest draft is here:
https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt

>
> On Fri, May 10, 2019, at 00:12, Loganaden Velvindron wrote:
> > Hi all,
> >
> > Following the recent thread on TLS 1.0 and TLS 1.1 deprecation, we
> > came up with a proposal to deprecate md5 and sha1 for digital
> > signatures in the TLS 1.2 spec.
> >
> > Please find the draft at this url:
> > https://tools.ietf.org/html/draft-lvelvindron-tls-md5-sha1-deprecate-03
> >
> > We look forward to your feedback.
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls