Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[David Benjamin]

I'm having a bit of a hard time following email quotes containing diffs of
diffs, so I may be misinterpreting who is arguing for what, but I think I
agree with Daniel? I'm not sure. :-) I think:

- We can't usefully change the interpretation of ClientHellos without the
sigalgs extension. In particular, clients that support just SHA-256 need to
send it, so that existing servers do not interpret it to mean SHA-1.

- Since we're saying the client cannot offer SHA-1, the client's rules on
when to to omit sigalgs are effectively a no-op. That, in turn, means the
server rule's are a no-op.

- I agree that the sentence "Note: [...] as a practical matter one can
assume that the peer supports MD5 and SHA-1" reads like it's talking about
the server rules. Thus I think the diff applied in Section 6
of draft-ietf-tls-md5-sha1-deprecate-07 isn't right. We're explicitly not
redefining the missing extension, so it's not right to change the
assumptions one can make.

As for the actual diffs on RFC5246, I don't feel strongly, but my overall
inclination from this thread is that diffs are too confusing. How about we
drop Section 6, and leave all the mess around how to interpret a missing
extension alone? Missing extension remains another way to say SHA-1-only,
and we've said servers reject SHA-1-only. And then the first sentence of
Section 2 can be amended to say "Clients MUST include the
signature_algorithms extension and MUST NOT include MD5 and SHA-1 in it",
because I think we haven't actually forbidden clients from omitting the
extension.

If we want to call out where we're updating RFC5246, we can perhaps
introduce a new "Updates to RFC5246" section whose subsections are the old
Sections 2-5. Those indeed update the rules of RFC5246, just not as a bunch
of diffs.

David

On Fri, Jul 30, 2021 at 7:57 PM Sean Turner  wrote:

> Daniel,
>
> So the current proposal is that signature_algorithms is always included.
> I understand that with that in mind it might make sense to also remove the
> other text as well.
>
> What do others think?
>
> spt
>
> > On Jul 30, 2021, at 12:25, Daniel Migault  wrote:
> >
> > Hi,
> >
> > Just to sum, up my initial comment proposed to mention as being removed
> remove the texts mentioned below. Since Sean mentioned that removing a text
> with MUST can be problematic, for the first text we can also just explain
> that in the context of this draft, the first text ends in being some dead
> code. I would be interested to understand - and only for my personal
> understanding - why removing a text with MUST is harder than a text with
> MAY.
> >
> > My understanding is that the current proposal is to remove the second
> text, and that the case of the first text has not been concluded - of
> course unless I am missing something. As a result, I think I hope we can
> converge for the two texts and I am fine the first text being mentioned as
> removed or ending as  dead code.
> >
> >  """
> > If the client does not send the signature_algorithms extension, the
> > server MUST do the following:
> > -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
> >DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
> >sent the value {sha1,rsa}.
> >
> > -  If the negotiated key exchange algorithm is one of (DHE_DSS,
> >DH_DSS), behave as if the client had sent the value {sha1,dsa}.
> >
> > -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
> >ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
> > """
> >
> >
> > """
> > If the client supports only the default hash and signature algorithms
> > (listed in this section), it MAY omit the signature_algorithms
> > extension.
> > """
> >
> > Yours,
> > Daniel
> >
> > On Fri, Jul 30, 2021 at 5:10 AM Hannes Tschofenig <
> hannes.tschofe...@arm.com> wrote:
> > I have no problem with the suggestion.
> >
> > A few other observations:
> >
> > 1. FWIW: The reference to [Wang] is incomplete.
> >
> > 2. The references to the other papers use the websites of the authors or
> project websites. I would use more stable references.
> >
> > 3. Kathleen's affiliation is also outdated.
> >
> > 4. Is the update to RFC 7525 relevant given that there is an update of
> RFC 7525 in progress (see
> https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-01) and
> even near completion?
> >
> > 5. The title of the draft gives the impression that this update only
> refers to TLS 1.2 but later in the draft DTLS is also included via the
> reference to RFC 7525. Should the title be changed to "Deprecating MD5 and
> SHA-1 signature hashes in TLS/DTLS 1.2"?
> >
> > Ciao
> > Hannes
> >
> > -Original Message-
> > From: Iot-directorate  On Behalf Of
> Russ Housley
> > Sent: Wednesday, July 28, 2021 10:34 PM
> > To: Sean Turner ; IETF TLS 
> > Cc: iot-director...@ietf.org;
> draft-ietf-tls-md5-sha1-deprecate@ietf.org; last-c...@ietf.org
> > Subject: Re: [Iot-directorate] [TLS] [Last-Call] Iotdir last call review
> of 

Re: [TLS] WGLC for draft-ietf-tls-flags

[Christopher Wood]

Given the few responses received thus far, we're going to extend this WGLC for 
another two weeks. It will now conclude on August 13, alongside the WGLC for 
draft-ietf-tls-cross-sni-resumption.

Best,
Chris, for the chairs

On Fri, Jul 16, 2021, at 4:55 PM, Christopher Wood wrote:
> This is the second working group last call for the "A Flags Extension 
> for TLS 1.3" draft, available here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
> 
> Please review this document and send your comments to the list by July 
> 30, 2021. The GitHub repository for this draft is available here:
> 
> https://github.com/tlswg/tls-flags
> 
> Thanks,
> Chris, on behalf of the chairs
> 
> ___
> 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 draft-ietf-tls-cross-sni-resumption

[Christopher Wood]

Given the few responses received thus far, we're going to extend this WGLC for 
another two weeks. It will now conclude on August 13.

Best,
Chris, for the chairs

On Fri, Jul 16, 2021, at 4:55 PM, Christopher Wood wrote:
> This is the working group last call for the "Transport Layer Security 
> (TLS) Resumption across Server Names" draft, available here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/
> 
> Please review this document and send your comments to the list by July 
> 30, 2021. The GitHub repository for this draft is available here:
> 
> https://github.com/vasilvv/tls-cross-sni-resumption
> 
> Thanks,
> Chris, on behalf of the chairs
> 
> ___
> 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] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Martin Thomson]

On Sat, Jul 31, 2021, at 06:25, Carrick Bartle wrote:
>  are you opposed to fully deprecating FFDHE? If so, why?

No so much opposed as that it is not necessary.  Though the TLS 1.2 variant is 
- as others have noted - close to impossible to negotiate the "good" groups, 
it's not concretely bad when you use it in TLS 1.3.

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

Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Sean Turner]

Daniel,
 
So the current proposal is that signature_algorithms is always included.  I 
understand that with that in mind it might make sense to also remove the other 
text as well.

What do others think?

spt

> On Jul 30, 2021, at 12:25, Daniel Migault  wrote:
> 
> Hi,
> 
> Just to sum, up my initial comment proposed to mention as being removed 
> remove the texts mentioned below. Since Sean mentioned that removing a text 
> with MUST can be problematic, for the first text we can also just explain 
> that in the context of this draft, the first text ends in being some dead 
> code. I would be interested to understand - and only for my personal 
> understanding - why removing a text with MUST is harder than a text with MAY. 
> 
> My understanding is that the current proposal is to remove the second text, 
> and that the case of the first text has not been concluded - of course unless 
> I am missing something. As a result, I think I hope we can converge for the 
> two texts and I am fine the first text being mentioned as removed or ending 
> as  dead code.  
> 
>  """
> If the client does not send the signature_algorithms extension, the
> server MUST do the following:
> -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
>DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
>sent the value {sha1,rsa}.
> 
> -  If the negotiated key exchange algorithm is one of (DHE_DSS,
>DH_DSS), behave as if the client had sent the value {sha1,dsa}.
> 
> -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
>ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
> """
> 
> 
> """
> If the client supports only the default hash and signature algorithms
> (listed in this section), it MAY omit the signature_algorithms
> extension.
> """
> 
> Yours, 
> Daniel
> 
> On Fri, Jul 30, 2021 at 5:10 AM Hannes Tschofenig  
> wrote:
> I have no problem with the suggestion.
> 
> A few other observations:
> 
> 1. FWIW: The reference to [Wang] is incomplete.
> 
> 2. The references to the other papers use the websites of the authors or 
> project websites. I would use more stable references.
> 
> 3. Kathleen's affiliation is also outdated.
> 
> 4. Is the update to RFC 7525 relevant given that there is an update of RFC 
> 7525 in progress (see 
> https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-01) and even 
> near completion?
> 
> 5. The title of the draft gives the impression that this update only refers 
> to TLS 1.2 but later in the draft DTLS is also included via the reference to 
> RFC 7525. Should the title be changed to "Deprecating MD5 and SHA-1 signature 
> hashes in TLS/DTLS 1.2"?
> 
> Ciao
> Hannes
> 
> -Original Message-
> From: Iot-directorate  On Behalf Of Russ 
> Housley
> Sent: Wednesday, July 28, 2021 10:34 PM
> To: Sean Turner ; IETF TLS 
> Cc: iot-director...@ietf.org; draft-ietf-tls-md5-sha1-deprecate@ietf.org; 
> last-c...@ietf.org
> Subject: Re: [Iot-directorate] [TLS] [Last-Call] Iotdir last call review of 
> draft-ietf-tls-md5-sha1-deprecate-04
> 
> >   In Section 7.1.4.1: the following text is removed:
> 
>  If the client supports only the default hash and signature algorithms
>  (listed in this section), it MAY omit the signature_algorithms
>  extension.
> 
> >   Since it’s a MAY, I am a-okay with deleting. Anybody else see harm?
> 
> I don't see any harm.
> 
> Russ
> 
> --
> Iot-directorate mailing list
> iot-director...@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-directorate
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> -- 
> Daniel Migault
> Ericsson

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

Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Sean Turner]

> On Jul 30, 2021, at 05:08, Hannes Tschofenig  
> wrote:
> 
> I have no problem with the suggestion.
> 
> A few other observations:
> 
> 1. FWIW: The reference to [Wang] is incomplete.

The same ref was used in RFC 6194, but we could also use:
https://www.iacr.org/archive/crypto2005/36210017/36210017.pdf

> 2. The references to the other papers use the websites of the authors or 
> project websites. I would use more stable references.

We can replace:

http://shattered.io/static/shattered.pdf

with 

https://eprint.iacr.org/2017/190

and (is the INRIA site better?)

ttps://www.mitls.org/downloads/transcript-collisions.pdf

with

https://hal.inria.fr/hal-01244855/document

> 3. Kathleen's affiliation is also outdated.

Ah I thought we fixed that. Anyway we’ll change it to: CIS

> 4. Is the update to RFC 7525 relevant given that there is an update of RFC 
> 7525 in progress (see 
> https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-01) and even 
> near completion?

I do not have a problem moving the text. I might also solve the can a standard 
update a BCP question.

What do people think?

> 5. The title of the draft gives the impression that this update only refers 
> to TLS 1.2 but later in the draft DTLS is also included via the reference to 
> RFC 7525. Should the title be changed to "Deprecating MD5 and SHA-1 signature 
> hashes in TLS/DTLS 1.2"?

We could do (D)TLS 1/2 too.

> Ciao
> Hannes
> 
> -Original Message-
> From: Iot-directorate  On Behalf Of Russ 
> Housley
> Sent: Wednesday, July 28, 2021 10:34 PM
> To: Sean Turner ; IETF TLS 
> Cc: iot-director...@ietf.org; draft-ietf-tls-md5-sha1-deprecate@ietf.org; 
> last-c...@ietf.org
> Subject: Re: [Iot-directorate] [TLS] [Last-Call] Iotdir last call review of 
> draft-ietf-tls-md5-sha1-deprecate-04
> 
>>  In Section 7.1.4.1: the following text is removed:
> 
> If the client supports only the default hash and signature algorithms
> (listed in this section), it MAY omit the signature_algorithms
> extension.
> 
>>  Since it’s a MAY, I am a-okay with deleting. Anybody else see harm?
> 
> I don't see any harm.
> 
> Russ
> 
> --
> Iot-directorate mailing list
> iot-director...@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-directorate
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.

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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Carrick Bartle]

Hi Martin,

Actually, a clarification question (more relevant to the other thread 

 : are you opposed to fully deprecating FFDHE? If so, why?


> On Jul 29, 2021, at 5:41 PM, Martin Thomson  wrote:
> 
> I support the *contents* of this document.  The title, however, I can't agree 
> to.  So I want to be clear about the scope of the work, namely deprecating 
> semi-static FFDH and ECDH suites and any use of FFDHE ephemeral suites with 
> reused keys.
> 
> The draft limits the ban on ephemeral key reuse to FFDHE, which is right; I 
> could tolerate a prohibition on reuse for ECDH, but I know that we rely on 
> that for HPKE and other things, so it can't really be bad enough to ban.
> 
> Cheers,
> Martin
> 
> On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote:
>> This is a working group call for adoption for Deprecating FFDH(E) 
>> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 
>> > >). 
>> We had a presentation for this draft at the IETF 110 meeting and since 
>> it is a similar topic to the key exchange deprecation draft the chairs 
>> want to get a sense if the working group wants to adopt this draft 
>> (perhaps the drafts could be merged if both move forward).  Please 
>> review the draft and post your comments to the list by Friday, August 
>> 13, 2021.  
>> 
>> Thanks,
>> 
>> The TLS chairs
>> ___
>> 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

Re: [TLS] Point Compression

[Andrey Jivsov]

I propose a method to compress NIST curves as defined in
https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html

Its main benefit is that the compressed point fits into field size / group
order size. There is no additional byte needed.

This encoding is enabled by by modifying key generation. If key generation
code can be changed, the adjustment is one bignum subtraction. If key
generation is a black box, e.g. as if it is done by an HSM, we generate
another key pair until conditions are met.

On average, adjustment is needed every second key generation.

No adjustment is needed for ECDH.

The method is solely based on published books and research papers from the
past century.

I hope this helps.

On Fri, Jul 30, 2021 at 9:48 AM Carl Mehner  wrote:

> As requested during ekr's presentation
> , I will volunteer to write up a
> draft for defining new "supported groups" for compressed NIST curves. I
> didn't see/hear any objections during the tls-wg meeting, but thought
> I should probably confirm on the list before I got too far along in writing
> it...
>
> -carl
> ___
> 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] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Viktor Dukhovni]

On Fri, Jul 30, 2021 at 07:30:31PM +, Scott Fluhrer (sfluhrer) wrote:

> > Was it wrong to generate server-side DH parameters?
> 
> The problem is that it is hard for the client to distinguish between a
> well designed server vs a server that isn't as well written, and
> selects the DH group in a naïve way.

I am well aware that verifying the safety of the server's choice is
computationally taxing.

> Now, as I mentioned in the WG meeting, it would be possible to detect
> if the server proposes a safe prime (it's not especially cheap, being
> several times as expensive as the rest of the DH operations, but it's
> possible), and that would prevent most of the problems that can happen

I don't think it is realistic for the client to go to that much trouble.
The server's choice of parameters is signed by the server's public key.
What is the threat model here?  Is the client trying to avoid servers
that shoot themselves in the foot by verifiably choosing bad parameters?

The server could also have a strong DH group, but a terrible RNG with a
well known RSA private key:

http://dnssec-stats.ant.isi.edu/~viktor/mailcow.html

If the server is not one of these or similar, and attests to its choice
of DH parameters, and they happen to be less than ideal, so be it.
Server operators should be encouraged to choose strong parameters, but I
see little reason for clients to second-guess that choice.

If the DH parameter size is below a reasonable threshold (Logjam), a
client might balk, but otherwise I am not sure what practical problem
we're actually solving.

> Of course, this works only if the legacy servers you are talking about
> actually do use safe primes...

All the ones I know of use "openssl dhparam", which defaults to Sophie
Germain strong primes with generator 2.

I strongly doubt there's a non-negligible server population with weak
locally generated groups.  The only likely source of weak groups is
servers that used one the older now deemed weak groups published in
deprecated RFCs.

So it might suffice to refuse specific known weak "standard" groups,
which would have a much lower impact than requiring particular standard
groups with no mechanism to negotiate these.

-- 
Viktor.

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

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Scott Fluhrer (sfluhrer)]

> Was it wrong to generate server-side DH parameters?

The problem is that it is hard for the client to distinguish between a well 
designed server vs a server that isn't as well written, and selects the DH 
group in a naïve way.

For example, if the server just selects a random prime and a random generator 
value, well, that has a good probability of leaking quite a bit of information 
about the private exponents; leak enough, and the shared secret may be 
recoverable.  This is not obvious to someone new to the field; it is also very 
hard to detect by the client.

Now, as I mentioned in the WG meeting, it would be possible to detect if the 
server proposes a safe prime (it's not especially cheap, being several times as 
expensive as the rest of the DH operations, but it's possible), and that would 
prevent most of the problems that can happen (exception: if the server proposes 
an SNFS-friendly modulus, say, one with a very simple binary representation - 
that would reduce the security noticeably).  Of course, this works only if the 
legacy servers you are talking about actually do use safe primes...

-Original Message-
From: TLS  On Behalf Of Viktor Dukhovni
Sent: Friday, July 30, 2021 2:57 PM
To: tls@ietf.org
Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods 
in TLS

On Fri, Jul 30, 2021 at 05:14:08AM +, Peter Gutmann wrote:

> >The only other alternative is to define brand new TLS 1.2 FFDHE 
> >cipher code points that use negotiated groups from the group list.  
> >But it is far from clear that this is worth doing given that we now have 
> >ECDHE, X25519 and X448.
> 
> There's still an awful lot of SCADA gear that does FFDHE, and that's 
> never going to change from that.  The current draft as it stands is 
> fine, in fact it seems kinda redundant since all it's saying is "don't 
> do things that you should never have been doing in the first place", 
> but I assume someone needs to explicitly say that.  No need to go beyond that.

Can you explain what you mean by "don't do things that you should never have 
been doing in the first place"?

There are quite a few deployments that generate local strong (Sophie Germain 
prime) DH parameters.  These would break if the draft sails through as-is, and 
there's no mechanism for the client to inform the legacy server that its would 
be choice of DH parameters is not acceptable.

Was it wrong to generate server-side DH parameters?

-- 
Viktor.

___
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] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Viktor Dukhovni]

On Fri, Jul 30, 2021 at 05:14:08AM +, Peter Gutmann wrote:

> >The only other alternative is to define brand new TLS 1.2 FFDHE cipher code
> >points that use negotiated groups from the group list.  But it is far from
> >clear that this is worth doing given that we now have ECDHE, X25519 and X448.
> 
> There's still an awful lot of SCADA gear that does FFDHE, and that's never
> going to change from that.  The current draft as it stands is fine, in fact it
> seems kinda redundant since all it's saying is "don't do things that you
> should never have been doing in the first place", but I assume someone needs
> to explicitly say that.  No need to go beyond that.

Can you explain what you mean by "don't do things that you should never
have been doing in the first place"?

There are quite a few deployments that generate local strong (Sophie
Germain prime) DH parameters.  These would break if the draft sails
through as-is, and there's no mechanism for the client to inform the
legacy server that its would be choice of DH parameters is not
acceptable.

Was it wrong to generate server-side DH parameters?

-- 
Viktor.

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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Carrick Bartle]

Sorry, the title will be changed in the next version, which I'll be posting as 
soon as possible. You are correct about the scope of the work.


> On Jul 29, 2021, at 5:41 PM, Martin Thomson  wrote:
> 
> I support the *contents* of this document.  The title, however, I can't agree 
> to.  So I want to be clear about the scope of the work, namely deprecating 
> semi-static FFDH and ECDH suites and any use of FFDHE ephemeral suites with 
> reused keys.
> 
> The draft limits the ban on ephemeral key reuse to FFDHE, which is right; I 
> could tolerate a prohibition on reuse for ECDH, but I know that we rely on 
> that for HPKE and other things, so it can't really be bad enough to ban.
> 
> Cheers,
> Martin
> 
> On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote:
>> This is a working group call for adoption for Deprecating FFDH(E) 
>> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 
>> > >). 
>> We had a presentation for this draft at the IETF 110 meeting and since 
>> it is a similar topic to the key exchange deprecation draft the chairs 
>> want to get a sense if the working group wants to adopt this draft 
>> (perhaps the drafts could be merged if both move forward).  Please 
>> review the draft and post your comments to the list by Friday, August 
>> 13, 2021.  
>> 
>> Thanks,
>> 
>> The TLS chairs
>> ___
>> 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

Re: [TLS] Adoption call for "Secure Negotiation of Incompatible Protocols in TLS"

[David Schinazi]

I support adoption.
David

On Thu, Jul 29, 2021 at 5:33 PM Martin Thomson  wrote:

> On Fri, Jul 30, 2021, at 04:20, Christopher Wood wrote:
> > Based on positive feedback during this week's meeting, we'd like to
> > start an adoption call for "Secure Negotiation of Incompatible
> > Protocols in TLS." The document may be found here:
> >
> >https://datatracker.ietf.org/doc/draft-thomson-tls-snip/
>
> Yeah, I think we should do this.  Just in case there was any doubt.
>
> ___
> 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] Point Compression

[Carl Mehner]

As requested during ekr's presentation ,
I will volunteer to write up a draft for defining new "supported groups"
for compressed NIST curves. I didn't see/hear any objections during the
tls-wg meeting, but thought I should probably confirm on the list before I
got too far along in writing it...

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

Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Daniel Migault]

Hi,

Just to sum, up my initial comment proposed to mention as being removed
remove the texts mentioned below. Since Sean mentioned that removing a text
with MUST can be problematic, for the first text we can also just explain
that in the context of this draft, the first text ends in being some dead
code. I would be interested to understand - and only for my personal
understanding - why removing a text with MUST is harder than a text with
MAY.

My understanding is that the current proposal is to remove the second text,
and that the case of the first text has not been concluded - of course
unless I am missing something. As a result, I think I hope we can converge
for the two texts and I am fine the first text being mentioned as removed
or ending as  dead code.

 """
If the client does not send the signature_algorithms extension, the
server MUST do the following:
-  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
   DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
   sent the value {sha1,rsa}.

-  If the negotiated key exchange algorithm is one of (DHE_DSS,
   DH_DSS), behave as if the client had sent the value {sha1,dsa}.

-  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
   ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
"""


"""
If the client supports only the default hash and signature algorithms
(listed in this section), it MAY omit the signature_algorithms
extension.
"""

Yours,
Daniel

On Fri, Jul 30, 2021 at 5:10 AM Hannes Tschofenig 
wrote:

> I have no problem with the suggestion.
>
> A few other observations:
>
> 1. FWIW: The reference to [Wang] is incomplete.
>
> 2. The references to the other papers use the websites of the authors or
> project websites. I would use more stable references.
>
> 3. Kathleen's affiliation is also outdated.
>
> 4. Is the update to RFC 7525 relevant given that there is an update of RFC
> 7525 in progress (see
> https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-01) and
> even near completion?
>
> 5. The title of the draft gives the impression that this update only
> refers to TLS 1.2 but later in the draft DTLS is also included via the
> reference to RFC 7525. Should the title be changed to "Deprecating MD5 and
> SHA-1 signature hashes in TLS/DTLS 1.2"?
>
> Ciao
> Hannes
>
> -Original Message-
> From: Iot-directorate  On Behalf Of
> Russ Housley
> Sent: Wednesday, July 28, 2021 10:34 PM
> To: Sean Turner ; IETF TLS 
> Cc: iot-director...@ietf.org;
> draft-ietf-tls-md5-sha1-deprecate@ietf.org; last-c...@ietf.org
> Subject: Re: [Iot-directorate] [TLS] [Last-Call] Iotdir last call review
> of draft-ietf-tls-md5-sha1-deprecate-04
>
> >   In Section 7.1.4.1: the following text is removed:
>
>  If the client supports only the default hash and signature algorithms
>  (listed in this section), it MAY omit the signature_algorithms
>  extension.
>
> >   Since it’s a MAY, I am a-okay with deleting. Anybody else see harm?
>
> I don't see any harm.
>
> Russ
>
> --
> Iot-directorate mailing list
> iot-director...@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-directorate
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
Daniel Migault
Ericsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Hannes Tschofenig]

I have no problem with the suggestion.

A few other observations:

1. FWIW: The reference to [Wang] is incomplete.

2. The references to the other papers use the websites of the authors or 
project websites. I would use more stable references.

3. Kathleen's affiliation is also outdated.

4. Is the update to RFC 7525 relevant given that there is an update of RFC 7525 
in progress (see 
https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-01) and even 
near completion?

5. The title of the draft gives the impression that this update only refers to 
TLS 1.2 but later in the draft DTLS is also included via the reference to RFC 
7525. Should the title be changed to "Deprecating MD5 and SHA-1 signature 
hashes in TLS/DTLS 1.2"?

Ciao
Hannes

-Original Message-
From: Iot-directorate  On Behalf Of Russ 
Housley
Sent: Wednesday, July 28, 2021 10:34 PM
To: Sean Turner ; IETF TLS 
Cc: iot-director...@ietf.org; draft-ietf-tls-md5-sha1-deprecate@ietf.org; 
last-c...@ietf.org
Subject: Re: [Iot-directorate] [TLS] [Last-Call] Iotdir last call review of 
draft-ietf-tls-md5-sha1-deprecate-04

>   In Section 7.1.4.1: the following text is removed:

 If the client supports only the default hash and signature algorithms
 (listed in this section), it MAY omit the signature_algorithms
 extension.

>   Since it’s a MAY, I am a-okay with deleting. Anybody else see harm?

I don't see any harm.

Russ

--
Iot-directorate mailing list
iot-director...@ietf.org
https://www.ietf.org/mailman/listinfo/iot-directorate
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls