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

[Viktor Dukhovni]

> On 6 Aug 2021, at 3:31 pm, Benjamin Kaduk 
>  wrote:
> 
>> That said, I've given up fighting potentially counter-productive "raising 
>> the floor"
>> rather than "the celing" on all fronts, and now try to focus on just the 
>> most important
>> cases.  Thus have accepted the fact that sadly no anon (EC)DH ciphers are 
>> available with
>> TLS 1.3.
> 
> Well, yes, because TLS 1.3 ciphers only indicate the hash function and AEAD.

Yes, correct on a technicality: for anon_DH I'd need a null signature scheme,
but the intended point was that TLS without server certificates is presently
not supported in TLS 1.3.  I have not chose to campain to bring it back at
this time...

-- 
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

[Benjamin Kaduk]

On Fri, Aug 06, 2021 at 03:03:47PM -0400, Viktor Dukhovni wrote:
> 
> That said, I've given up fighting potentially counter-productive "raising the 
> floor"
> rather than "the celing" on all fronts, and now try to focus on just the most 
> important
> cases.  Thus have accepted the fact that sadly no anon (EC)DH ciphers are 
> available with
> TLS 1.3.

Well, yes, because TLS 1.3 ciphers only indicate the hash function and AEAD.

-Ben

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

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

[Viktor Dukhovni]

> On 6 Aug 2021, at 2:51 pm, Ilari Liusvaara  wrote:
> 
> As note: the DH_anon and ECDH_anon names are a bit misleading: Those
> two are actually ephemeral (but are still rarely a good idea to use)

For what it is worth, anon DH, and anon ECDH ciphers are used by default
in Postfix when doing unauthenticated opportunistic TLS.  Since the server
certificate is ignored, we don't bother to solicit one, or offer one if the
client does not care.

See also:

  https://datatracker.ietf.org/doc/html/rfc7672#section-8.2

where I explained that I see security advantages to making transparent the
client's non-use of a server certificate.

That said, I've given up fighting potentially counter-productive "raising the 
floor"
rather than "the celing" on all fronts, and now try to focus on just the most 
important
cases.  Thus have accepted the fact that sadly no anon (EC)DH ciphers are 
available with
TLS 1.3.

-- 
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

[Ilari Liusvaara]

On Thu, Jul 29, 2021 at 02:50:20PM -0700, Joseph Salowey wrote:
> This is a working group call for adoption of Deprecating Obsolete Key
> Exchange Methods in TLS  (draft-aviram-tls-deprecate-obsolete-kex-00
> ).
> There was support for adopting this draft at the IETF 111 meeting.  Please
> review the draft and post your comments to the list by Friday, August 13,
> 2021.

Adopt. And then fold the material from deprecate-ffdhe in.

Then I think nobody cares about KRB5 key exchange:

- There are no AES ciphers for it.
- It does not work with TLS 1.3 at all, and there are no plans to make
  it work.


-Ilari

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

Re: [TLS] RFC8446 backward compatibility question

[Valery Smyslov]

Hi Toerless,

> Eric,
> 
> What you call "pretty clear" is IMHO quite indirect. And yes, i tried
> to find evidence and stumbled exactly on that second example and then was
> not 100% sure...
> 
> My comments where just trying to provide friendly feedback from
> a TLS uneducated reader. Remember that TLS is just recently starting
> to proliferate into markets like IoT, so an expectation of knowledge about
> 6000 years of TLS history may not to be expected for broadest readership
> of the RFCs (*).
> 
> Another way to educate what you may consider to be "non-core" readership,
> is maybe some form of "TLS operational considerations". Your prior answer
> about that TLS server cluster consideration would also nicely fit into
> something like that. Maybe something for opsec wg..

UTA WG is concerned with using TLS in applications.
In particular, RFC 7525 (currently being updated, see 
draft-ietf-uta-rfc7525bis) 
gives some operational recommendations on supporting different versions of TLS.

Regards,
Valery.

> Cheers
> Toerless
> 
> (*) Not sure about the number. Could have been egyption or chinese history ;-)
> 
> 
> On Thu, Aug 05, 2021 at 03:23:42PM -0700, Eric Rescorla wrote:
> > On Thu, Aug 5, 2021 at 2:37 PM Toerless Eckert  wrote:
> >
> > > Thanks for the explanation.
> > >
> > > My main concern was just to understand clearly what requirements
> > > have to be written into RFC when one wants to ensure that TLS 1.2 needs
> > > to be supported as the fallback in a particular solution.
> > >
> > >  With TLS 1.3 not mandating support for TLS 1.2, in such cases one
> > > still needs to write MUST support TLS 1.2
> >
> >
> > That's correct.
> >
> > when one thought
> > > a MUST TLS 1.3 might have sufficed (assuming it included TLS 1.2
> > > support). A bit more explanatory text in 8446 might have helped.
> > >
> >
> > TBH, I think this is pretty clear in the document. We don't generally expect
> > that support for version X includes support for version X-1. Moreover, there
> > is text in the document which doesn't make much sense if you couldn't
> > just have a TLS 1.3 stack:
> >
> >  This document defines TLS version 1.3.  While TLS 1.3 is not directly
> >   compatible with previous versions, all versions of TLS incorporate a
> >   versioning mechanism which allows clients and servers to
> >   interoperably negotiate a common version if one is supported by both
> >   peers.
> >
> >
> > Or
> >
> >   TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627
> > ]
> >extension which digested large parts of the handshake transcript into
> >the master secret.  Because TLS 1.3 always hashes in the transcript
> >up to the server Finished, implementations which support both TLS 1.3
> >and earlier versions SHOULD indicate the use of the Extended Master
> >Secret extension in their APIs whenever TLS 1.3 is used.
> >
> > -Ekr
> >
> >
> >
> >
> >
> > > Also, the immediate status change of "obsoleted by 8446" may
> > > make readers think that TLS 1.3 can take care of migration
> > > from TLS 1.2 all by itself, when indeed it can not unless you
> > > still also mandate implementing TLS 1.2. Of course we do not
> > > have a better keyword vocabulary. Something like "Sunset by: 8446".
> > >
> > > Cheers
> > > Toerless
> > >
> > > On Thu, Aug 05, 2021 at 09:16:37PM +, Salz, Rich wrote:
> > > > >I am trying to figure out if every implementation compliant with
> > > > RFC8446 is also necessarily interoperable with an RFC5246 peer, or
> > > if this
> > > > is just a likely common, but still completely optional
> > > implementation choice.
> > > >
> > > > It is possible to have a single stack that implements TLS.[123].
> > > OpenSSL, among many others does this.  Some have implemented ONLY TLS 1.3;
> > > that code tends to be cleaner (in a nerd esthetic sense) than code that
> > > implements multiple protocols. Some servers even "hand off" pre-1.3
> > > protocols to separate implementations (libraries); FB and Amazon used to 
> > > do
> > > that.
> > > >
> > > > The wire protocol for TLS 1.3 uses some deliberately-reserved extension
> > > fields so that a server which doesn't do 1.3 can fail cleanly, and a 
> > > server
> > > that DOES will work. And also the other way, a 1.3 client can work fine
> > > with both a 1.3 server and a 1.[12] server.
> > > >
> > > > It's easy to rationale 1.3-only for clients. It is harder to rationalize
> > > 1.3-only for servers if you are intending those servers to be generally
> > > accessible on the public Internet.
> > > >
> > > >
> > >
> > > --
> > > ---
> > > t...@cs.fau.de
> > >
> > > ___
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
> > >
> 
> --
> ---
> t...@cs.fau.de
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls