[TLS] Re: ECH Proxy Mode

[A A]

> So we can't use the legacy_session_id_echo of SH. We only need client to carry ECH, right? So server just need to simply repeat what Session ID it received in Client Hello. 11.09.2024, 17:45, "涛叔" :According to https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3A client which receives a legacy_session_id_echo field that does not match whatit sent in the ClientHello MUST abort the handshake with an "illegal_parameter" alert.So we can't use the legacy_session_id_echo of SH.On Sep 11, 2024, at 17:35, A A  wrote:I don't think need to use random, we can use Session ID, which is deprecated since TLS 1.3. Random is used to derive master key, AFAIK.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] I-D Action: draft-ietf-tls-tlsflags-14.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-tlsflags-14.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   A Flags Extension for TLS 1.3
   Author:  Yoav Nir
   Name:draft-ietf-tls-tlsflags-14.txt
   Pages:   9
   Dates:   2024-09-13

Abstract:

   A number of extensions are proposed in the TLS working group that
   carry no interesting information except the 1-bit indication that a
   certain optional feature is supported.  Such extensions take 4 octets
   each.  This document defines a flags extension that can provide such
   indications at an average marginal cost of 1 bit each.  More
   precisely, it provides as many flag extensions as needed at 4 + the
   order of the last set bit divided by 8.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-14

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-tlsflags-14

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] [Errata Verified] RFC9147 (8100)

[RFC Errata System]

The following errata report has been verified for RFC9147,
"The Datagram Transport Layer Security (DTLS) Protocol Version 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8100

--
Status: Verified
Type: Editorial

Reported by: David Benjamin 
Date Reported: 2024-09-12
Verified by:   

Section: 4.1

Original Text
-
   *  If the first byte is alert(21), handshake(22), or ack(proposed,
  26), the record MUST be interpreted as a DTLSPlaintext record.

Corrected Text
--
   *  If the first byte is alert(21), handshake(22), or ack(26), the
  record MUST be interpreted as a DTLSPlaintext record.

Notes
-
This appears to be a remnant from before the codepoint was officially allocated.

--
RFC9147 (draft-ietf-tls-dtls13-43)
--
Title   : The Datagram Transport Layer Security (DTLS) Protocol 
Version 1.3
Publication Date: April 2022
Author(s)   : E. Rescorla, H. Tschofenig, N. Modadugu
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

[Mark Robinson]

I want to thank everyone for your feedback. It's been super helpful.

I think I should elaborate on what the problem is and how it can be fixed.

I've worked with a lot of companies who want to use mTLS (as bas as the
name is) to increase security but don't know how to do it in a way that
won't reduce reliability. For example, many companies require a certificate
signed by a public CA and then *emailed* to them. They have the annual cert
expiry of a regular cert combined with a manual (and hackable process) that
basically  guarantees downtime when someone goes on vacation.

What I'd like to cover:
- How two orgs (that aren't CAs) can exchange keys
- How to rotate keys
- What parameters keys should be set, and how keys should be validated
- When and how keys should be updated
- All of this without manual steps or #$%#$%ing email.

Setting up cross-validation of TLS should be a single line change for high
performing organizations and should never, ever, ever involve email certs
between customer service reps.

Mark

On Wed, Sep 11, 2024 at 4:30 PM Peter Gutmann 
wrote:

> Andrei Popov  writes:
>
> >I'm with Richard on this one. Not a fan of the "mTLS" concept: it causes
> >confusion where customers ask whether "mTLS" is a different protocol or a
> >specific TLS implementation? However, it can be argued that this
> unfortunate
> >term has already taken root.
>
> +1, Richard pretty much said everything I have concerns about but saved me
> a
> lot of typing.  mTLS *is* TLS, there's no need to give it a special name
> for
> marketing(?) purposes.
>
> Having said that, I'd have no problems with a "TLS Profile for xxx", which
> is
> what it really seems to be.
>
> (And I'll add an obligatory comment that what (m)TLS does isn't mutual
> authentication, it's unidirectional authentication in both directions, but
> that boat has long since sailed.  If you wanted to have actual mTLS it'd
> have
> to use PSK).
>
> Peter.
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

[Viktor Dukhovni]

On Fri, Sep 13, 2024 at 08:08:12PM -0700, Mark Robinson wrote:

> I want to thank everyone for your feedback. It's been super helpful.
> 
> I think I should elaborate on what the problem is and how it can be fixed.
> 
> I've worked with a lot of companies who want to use mTLS (as bas as the
> name is) to increase security but don't know how to do it in a way that
> won't reduce reliability. For example, many companies require a certificate
> signed by a public CA and then *emailed* to them. They have the annual cert
> expiry of a regular cert combined with a manual (and hackable process) that
> basically  guarantees downtime when someone goes on vacation.
> 
> What I'd like to cover:
> - How two orgs (that aren't CAs) can exchange keys
> - How to rotate keys
> - What parameters keys should be set, and how keys should be validated
> - When and how keys should be updated
> - All of this without manual steps or #$%#$%ing email.
> 
> Setting up cross-validation of TLS should be a single line change for high
> performing organizations and should never, ever, ever involve email certs
> between customer service reps.

Trusting an arms-length 3rd party public CA to authenticate access to
one's systems by one's business partners is a murky business...

The best one can do without devolving responsibility to unaccountable
3rd-parties is self-service portals, where authorised admininstrators
from each business partner can on a self-service basis:

- Generate, and download a PKCS#12 bundle with a private key and
  matching certificate issued by the relying party's CA.

- Authorise a previously downloaded key.

- Deauthorise a previously authorised key.

On the client side, the use of an X.509 certificate (rather than say a
raw public key) is then soley to grease the protocol wheels, the names
in the certificate are irrelevant, the server has its own list of
authorised keys and identity mappings.

In other words, carefully implemented, the client-side of "mTLS" is more
PK than PKI.  Or, more precisely, all the infrastructure is on the
relying party side.

-- 
Viktor.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org