Re: [TLS] adoption call for draft-dt-tls-external-psk-guidance

I support adoption. > On May 21, 2020, at 10:12 PM, Sean Turner wrote: > > This is a WG document adoption call for draft-dt-tls-external-psk-guidance > (aka Guidance for External PSK Usage in TLS). This effort was kicked off > @IETF106 by Ben Kaduk and supported by others in the audience.

[TLS] The TLS WG has placed draft-dt-tls-external-psk-guidance in state "Call For Adoption By WG Issued"

The TLS WG has placed draft-dt-tls-external-psk-guidance in state Call For Adoption By WG Issued (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-dt-tls-external-psk-guidance/ ___ TLS mailing list

[TLS] adoption call for draft-dt-tls-external-psk-guidance

This is a WG document adoption call for draft-dt-tls-external-psk-guidance (aka Guidance for External PSK Usage in TLS). This effort was kicked off @IETF106 by Ben Kaduk and supported by others in the audience. There was also some nominal amount of support for adopting the draft at the last

[TLS] consensus call: changing cTLS and ECH to standards track

It looks like the intended status for both draft-ietf-tls-ctls (aka cTLS) and draft-ietf-tls-esni (aka ECH) should be changed. It appears that both should be set to standards track; cTLS is now Informational and ECH is Experimental. If you object to changing the track for either of these drafts

Re: [TLS] Banning implicit CIDs in DTLS

On Thu, May 21, 2020, at 9:22 AM, Thomas Fossati wrote: > Hi Chris, > > On 21/05/2020, 17:00, "Christopher Wood" wrote: > > *One proposal to address this is by extending the AAD to include the > > pseudo-header. However, the chairs feel this is an unnecessary > > divergence from QUIC. > > I

Re: [TLS] Banning implicit CIDs in DTLS

On Fri, May 22, 2020, at 01:58, Christopher Wood wrote: > PR #148 I think that this is the right solution to this problem. > *One proposal to address this is by extending the AAD to include the > pseudo-header. However, the chairs feel this is an unnecessary > divergence from QUIC. I'm not

Re: [TLS] Bikeshedding ECHO

I actually already merged it :) On Thu, May 21, 2020 at 12:48 PM Christopher Wood wrote: > To make it official, here's a PR making that change: > >https://github.com/tlswg/draft-ietf-tls-esni/pull/236 > > Please have a look. I'll merge in the next day or so. > > Thanks! > Chris (no hat) > >

Re: [TLS] Bikeshedding ECHO

To make it official, here's a PR making that change: https://github.com/tlswg/draft-ietf-tls-esni/pull/236 Please have a look. I'll merge in the next day or so. Thanks! Chris (no hat) On Thu, May 21, 2020, at 8:58 AM, Sean Turner wrote: > Okay let’s call this done! ECH it is. > > spt > >

Re: [TLS] Bikeshedding ECHO

On 5/21/20 11:52 AM, Erik Nygren wrote: Are there any objections to "ECH" or should we just go with that? I have no objection, but would benefit from consensus on whether it (ECH) is an initialism or acronym. My opinion is that it is best as an initialism (as is, e.g., TLS).

Re: [TLS] Banning implicit CIDs in DTLS

Hi Chris, On 21/05/2020, 17:00, "Christopher Wood" wrote: > *One proposal to address this is by extending the AAD to include the > pseudo-header. However, the chairs feel this is an unnecessary > divergence from QUIC. I don't understand the "unnecessary" in the above para, i.e., why are we so

Re: [TLS] Banning implicit CIDs in DTLS

This would be my preferred resolution On Thu, May 21, 2020 at 8:59 AM Christopher Wood wrote: > PR #148 in the DTLS 1.3 draft ( > https://github.com/tlswg/dtls13-spec/pull/148) proposes banning implicit > CIDs. This comes at an obvious cost in terms of bytes on the wire. However, > in

[TLS] Banning implicit CIDs in DTLS

PR #148 in the DTLS 1.3 draft (https://github.com/tlswg/dtls13-spec/pull/148) proposes banning implicit CIDs. This comes at an obvious cost in terms of bytes on the wire. However, in discussions on a parallel thread [1 and related], it's noted that this removes header malleability. Given that

Re: [TLS] Bikeshedding ECHO

Okay let’s call this done! ECH it is. spt Sent from my iPhone >> On May 21, 2020, at 11:53, Erik Nygren wrote: >  > Are there any objections to "ECH" or should we just go with that? > (I'd like to update the parameter name in SRVB/HTTPSSVC accordingly based on > what gets decided.) > > >>

Re: [TLS] Bikeshedding ECHO

Are there any objections to "ECH" or should we just go with that? (I'd like to update the parameter name in SRVB/HTTPSSVC accordingly based on what gets decided.) On Wed, May 20, 2020 at 11:37 PM Tommy Pauly wrote: > ECH is good. Go for it! > > Tommy > > On May 20, 2020, at 11:34 AM, Erik

Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

On Thu, May 21, 2020 at 10:51 AM Russ Housley wrote: > > > On May 21, 2020, at 10:12 AM, Ryan Sleevi wrote: > > > On Wed, May 20, 2020 at 6:40 PM Russ Housley wrote: > >> MINOR >> >> Section 1 also says: >> >>Because the above problems do not relate to the CA's inherent >>function of

Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

> On May 21, 2020, at 10:12 AM, Ryan Sleevi wrote: > > > On Wed, May 20, 2020 at 6:40 PM Russ Housley > wrote: > MINOR > > Section 1 also says: > >Because the above problems do not relate to the CA's inherent >function of validating possession of names,

Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

* While I have no objection to the DelegationUsage extension, I wonder is an extended key usage would provide the same confidence in the certificate. FWIW, a new extendedKeyUsage value would be easier to add into OpenSSL, and I’m looking at adding this there (sic).

Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

On Wed, May 20, 2020 at 6:40 PM Russ Housley wrote: > MINOR > > Section 1 also says: > >Because the above problems do not relate to the CA's inherent >function of validating possession of names, > > The CA is responsible for confirming that the public key in the > certificate