Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Mohit Sethi]

Hi Jonathan, all,

Thank you for explaining why you think client_certificate_type extension 
is unsuitable. And apologies if you had also explained this earlier. I 
somehow don't remember seeing a response to my previous comment about 
the possibility of using the client_certificate_type extension 
(https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/).


Thank you for referring to the text in RFC 7250. However, if we look at 
Section 4.4.2 of RFC8446 
(https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2); it has 
the following:



If the corresponding certificate type extension
("server_certificate_type" or "client_certificate_type") was not
negotiated in EncryptedExtensions, or the X.509 certificate type was
negotiated, then each CertificateEntry contains a DER-encoded X.509
certificate.


At least to me, the part on "or the x.509 certificate type was 
negotiated" implies that the client_certificate_type and 
server_certificate_type extensions can indeed be used to negotiate the 
usage of x.509 certificate type.


I certainly find the approach of using the client_certificate_type 
extension better than an mTLS flag. Maybe initially the extension was 
predominantly designed for use with RPKs, but I think the extension is 
well-suited to indicate the availability of an x.509 certificate on the 
client. Besides, mutual authentication (mTLS) is not exclusive to 
certificates. It is perfectly possible to have mutual authentication 
with RPKs and with PSKs.


--Mohit

PS: Regardless of how the adoption call ends and which mechanism we 
pick, I do think a mechanism for a TLS client to solicit a 
CertificateRequest from a TLS server is needed. Based on the discussion 
thus far, I still prefer using the client_certificate_type extension.


PPS: Not sure if it is necessary or the right place, but RFC8446bis 
could clarify the usage of the client_certificate_type extension for 
soliciting mutual authentication. I'd be happy to submit a pull request.


On 4/4/24 19:11, Jonathan Hoyland wrote:

Hi Dennis,

RFC 7250 Section 4.1 says:
If the client has no remaining certificate types to send in
the client hello, other than the default X.509 type, it MUST omit the
client_certificate_type extension in the client hello.
That seems to explicitly exclude sending the single entry 0 to me.
Regards,
Jonathan


On Thu, 4 Apr 2024, 16:43 Dennis Jackson, 
 wrote:


Hi Jonathan,

My reading of RFC 7250 is the same as Mohits. Although the RFC
talks about raw public keys and a new codepoint for them, it is
building on RFC 6091 which defined a similar extension and the
X509 codepoint.

It seems fine for you to send the client_certificate_type
extension with the single entry 0 (X509). You also have the option
of using a value assigned for private use (224 and up) for your
specific use case of indicating a search engine crawler willing to
provide a client cert.

Best,
Dennis

On 04/04/2024 11:17, Jonathan Hoyland wrote:

Hi all,

Thanks for the feedback here.

With respect to RFC 7250, as I mentioned earlier on list, there
seen to be two issues. First it changes the semantics of the
extension slightly, and second the RFC explicitly excludes x.509
certs.

IIUC the semantics of the extension are "I have a weird client
cert", not "I have a client cert".

With respect to whether this needs to be a working group item,
I'm not particularly averse to this being an independent document
if that's where the WG thinks it should go.
In my opinion, however, there are two things that it would be
good to get input from the TLS WG on.

One, this is a change from all previous versions of TLS in which
the client cannot induce auth, does enabling this break anyone's
assumptions?

Two, I'd like a low flag number because it saves bytes on the
wire, but there is a discussion to be had as to how common this
flag will be versus other flags.
(Non-attack) Bot traffic is very common, but it's not the
majority of traffic by any means.

Regards,

Jonathan



On Thu, 4 Apr 2024, 01:17 Christopher Patton,
 wrote:

It would be great to here from Jonathan (the author) if RFC
7250 is already sufficient for this use case.

On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi  wrote:

Please see my earlier comment regarding this draft:

https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Eric Rescorla]

On Thu, Apr 4, 2024 at 7:38 PM Mike Bishop  wrote:

> Ekr, can I ask you to clarify this a little? I fully agree that extensions
> to TLS which support a particular application-layer protocol should be done
> in that protocol’s working group unless and until it’s demonstrated that
> many unrelated applications will need something similar. (At which point,
> it probably makes sense to build the general thing, either in TLS or a new
> WG.) But this isn’t that.
>
>
>
> For something that concerns the TLS exchange itself, the TLS WG does still
> seem like the natural home to me. Where are you suggesting the standards
> work happens instead? Are you suggesting that this should be registered to
> the I-D, or go to a new/different working group? The former path seems like
> it won’t get the review it needs, and I’m not sure any other WGs are
> appropriately chartered for the latter.
>

I'm suggesting it be registered based on the ID.

When you say "get the review it needs", I think that's at the heart of the
question. My position is that the TLS WG (and the IETF generally) should
spend its limited resources on things which are important and likely to
receive wide deployment. Other code points can just be registered and
marked "recommended=N". Of course, they won't get review, but nothing stops
people from registering all kinds of bad ideas without review; that's why
the registries were open.

Here's what would make me interested in seeing the TLS WG spend time on
this: a critical mass of both servers and clients of the type contemplated
here (e.g., search engines or crawlers) who say they would actually use it.

-Ekr


>
>
> Personally, I support adoption for the use case. It sounds like there’s an
> alternative design that might need to be hammered out, but since it appears
> a document may be needed for either path, let’s adopt and argue about that
> later.
>
>
>
> *From:* TLS  *On Behalf Of *Eric Rescorla
> *Sent:* Wednesday, April 3, 2024 10:28 AM
> *To:* Watson Ladd 
> *Cc:* Christopher Patton ; TLS
> List 
> *Subject:* Re: [TLS] Adoption call for TLS Flag - Request mTLS
>
>
>
>
>
>
>
> On Tue, Apr 2, 2024 at 10:36 PM Watson Ladd  wrote:
>
>
>
> On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla  wrote:
>
> Adoption should not be required to register a code point [0], as the
> policy is Specification Required.
>
>
>
> I'm mildly negative on adopting this document. What is the reason we need
> to spend WG time on this, rather than just having a code point assignment?
>
>
>
> Well, don't we want to say how this is supposed to work somewhere?
>
>
>
> Why? The attitude I am trying to get away from is that the TLS WG has to
>
> be involved in every extension to TLS. Rather, we should decide what things
>
> are important and spend time on them and then let others extend TLS
> independently
>
> in areas we don't think are important.
>
>
>
> -Ekr
>
>
>
> I doubt this will take much time.
>
>
>
> -Ekr
>
>
>
> [0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13
> should clearly have
>
> a policy which matches 8447 S 7, which is to say that an I-D is sufficient.
>
>
>
>
>
> On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton  40cloudflare@dmarc.ietf.org> wrote:
>
> I'd like to see this problem solved. There was some discussion about
> whether an I-D is needed or all we needed was to register a code point
> somewhere. If most agree that an I-D is needed, then let's adopt it. I'm
> happy to review.
>
>
>
> Chris P.
>
>
>
> On Tue, Apr 2, 2024 at 12:22 PM Sean Turner  wrote:
>
> At the IETF 119 TLS session there was some interest in the mTLS Flag I-D (
> https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see
> previous list discussions at [0]. This message is to judge consensus on
> whether there is sufficient support to adopt this I-D.  If you support
> adoption and are willing to review and contribute text, please send a
> message to the list.  If you do not support adoption of this I-D, please
> send a message to the list and indicate why.  This call will close on 16
> April 2024.
>
> Thanks,
> Deirdre, Joe, and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
> ___
> 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
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Mike Bishop]

Ekr, can I ask you to clarify this a little? I fully agree that extensions to 
TLS which support a particular application-layer protocol should be done in 
that protocol’s working group unless and until it’s demonstrated that many 
unrelated applications will need something similar. (At which point, it 
probably makes sense to build the general thing, either in TLS or a new WG.) 
But this isn’t that.

For something that concerns the TLS exchange itself, the TLS WG does still seem 
like the natural home to me. Where are you suggesting the standards work 
happens instead? Are you suggesting that this should be registered to the I-D, 
or go to a new/different working group? The former path seems like it won’t get 
the review it needs, and I’m not sure any other WGs are appropriately chartered 
for the latter.

Personally, I support adoption for the use case. It sounds like there’s an 
alternative design that might need to be hammered out, but since it appears a 
document may be needed for either path, let’s adopt and argue about that later.

From: TLS  On Behalf Of Eric Rescorla
Sent: Wednesday, April 3, 2024 10:28 AM
To: Watson Ladd 
Cc: Christopher Patton ; TLS List 

Subject: Re: [TLS] Adoption call for TLS Flag - Request mTLS



On Tue, Apr 2, 2024 at 10:36 PM Watson Ladd 
mailto:watsonbl...@gmail.com>> wrote:

On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
Adoption should not be required to register a code point [0], as the policy is 
Specification Required.

I'm mildly negative on adopting this document. What is the reason we need to 
spend WG time on this, rather than just having a code point assignment?

Well, don't we want to say how this is supposed to work somewhere?

Why? The attitude I am trying to get away from is that the TLS WG has to
be involved in every extension to TLS. Rather, we should decide what things
are important and spend time on them and then let others extend TLS 
independently
in areas we don't think are important.

-Ekr

I doubt this will take much time.

-Ekr

[0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13 should 
clearly have
a policy which matches 8447 S 7, which is to say that an I-D is sufficient.


On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton 
mailto:40cloudflare@dmarc.ietf.org>>
 wrote:
I'd like to see this problem solved. There was some discussion about whether an 
I-D is needed or all we needed was to register a code point somewhere. If most 
agree that an I-D is needed, then let's adopt it. I'm happy to review.

Chris P.

On Tue, Apr 2, 2024 at 12:22 PM Sean Turner 
mailto:s...@sn3rd.com>> wrote:
At the IETF 119 TLS session there was some interest in the mTLS Flag I-D 
(https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see 
previous list discussions at [0]. This message is to judge consensus on whether 
there is sufficient support to adopt this I-D.  If you support adoption and are 
willing to review and contribute text, please send a message to the list.  If 
you do not support adoption of this I-D, please send a message to the list and 
indicate why.  This call will close on 16 April 2024.

Thanks,
Deirdre, Joe, and Sean

[0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org<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] Adoption call for TLS Flag - Request mTLS

[Dennis Jackson]

Ah, I wonder what the motivation was for it being a MUST rather than a 
SHOULD.


That still leaves open sending a private use value - which would allow 
you to de-conflict with others uses.



On 04/04/2024 17:11, Jonathan Hoyland wrote:

Hi Dennis,

RFC 7250 Section 4.1 says:
If the client has no remaining certificate types to send in
the client hello, other than the default X.509 type, it MUST omit the
client_certificate_type extension in the client hello.
That seems to explicitly exclude sending the single entry 0 to me.
Regards,
Jonathan


On Thu, 4 Apr 2024, 16:43 Dennis Jackson, 
 wrote:


Hi Jonathan,

My reading of RFC 7250 is the same as Mohits. Although the RFC
talks about raw public keys and a new codepoint for them, it is
building on RFC 6091 which defined a similar extension and the
X509 codepoint.

It seems fine for you to send the client_certificate_type
extension with the single entry 0 (X509). You also have the option
of using a value assigned for private use (224 and up) for your
specific use case of indicating a search engine crawler willing to
provide a client cert.

Best,
Dennis

On 04/04/2024 11:17, Jonathan Hoyland wrote:

Hi all,

Thanks for the feedback here.

With respect to RFC 7250, as I mentioned earlier on list, there
seen to be two issues. First it changes the semantics of the
extension slightly, and second the RFC explicitly excludes x.509
certs.

IIUC the semantics of the extension are "I have a weird client
cert", not "I have a client cert".

With respect to whether this needs to be a working group item,
I'm not particularly averse to this being an independent document
if that's where the WG thinks it should go.
In my opinion, however, there are two things that it would be
good to get input from the TLS WG on.

One, this is a change from all previous versions of TLS in which
the client cannot induce auth, does enabling this break anyone's
assumptions?

Two, I'd like a low flag number because it saves bytes on the
wire, but there is a discussion to be had as to how common this
flag will be versus other flags.
(Non-attack) Bot traffic is very common, but it's not the
majority of traffic by any means.

Regards,

Jonathan



On Thu, 4 Apr 2024, 01:17 Christopher Patton,
 wrote:

It would be great to here from Jonathan (the author) if RFC
7250 is already sufficient for this use case.

On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi  wrote:

Please see my earlier comment regarding this draft:

https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/

In summary: the functionality of this draft is already
achievable by
using the client_certificate_type extension defined in
RFC 7250:
https://datatracker.ietf.org/doc/html/rfc7250 with
certificate type
value = 0:

https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3.

The table in section 4.2 of RFC8446 even mentions that
the extension can
be included in the ClientHello:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2,
thereby
ensuring that the server sends a CertificateRequest
message in response
to the ClientHello received.

OpenSSL already implements this extension since it was
needed for
support raw public keys (RPKs).

As stated earlier: if it is indeed the case that the
client_certificate_type extension is suitable for the
use-case, then
perhaps it is preferable to not have a separate flag.
Otherwise, it
would make the state machine at the server more
complicated (for
example: handling a ClientHello with both the mTLS flag
and the
client_certificate_type extension.

Therefore, like Ekr, I am mildly negative on adopting
this document but
for different reasons.

--Mohit

On 4/3/24 00:52, Sean Turner wrote:
> At the IETF 119 TLS session there was some interest in
the mTLS Flag I-D

(https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D=0

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Jonathan Hoyland]

Hi Dennis,

RFC 7250 Section 4.1 says:

If the client has no remaining certificate types to send in
   the client hello, other than the default X.509 type, it MUST omit the
   client_certificate_type extension in the client hello.


That seems to explicitly exclude sending the single entry 0 to me.


Regards,


Jonathan



On Thu, 4 Apr 2024, 16:43 Dennis Jackson,  wrote:

> Hi Jonathan,
>
> My reading of RFC 7250 is the same as Mohits. Although the RFC talks about
> raw public keys and a new codepoint for them, it is building on RFC 6091
> which defined a similar extension and the X509 codepoint.
>
> It seems fine for you to send the client_certificate_type extension with
> the single entry 0 (X509). You also have the option of using a value
> assigned for private use (224 and up) for your specific use case of
> indicating a search engine crawler willing to provide a client cert.
>
> Best,
> Dennis
> On 04/04/2024 11:17, Jonathan Hoyland wrote:
>
> Hi all,
>
> Thanks for the feedback here.
>
> With respect to RFC 7250, as I mentioned earlier on list, there seen to be
> two issues. First it changes the semantics of the extension slightly, and
> second the RFC explicitly excludes x.509 certs.
>
> IIUC the semantics of the extension are "I have a weird client cert", not
> "I have a client cert".
>
> With respect to whether this needs to be a working group item, I'm not
> particularly averse to this being an independent document if that's where
> the WG thinks it should go.
> In my opinion, however, there are two things that it would be good to get
> input from the TLS WG on.
>
> One, this is a change from all previous versions of TLS in which the
> client cannot induce auth, does enabling this break anyone's assumptions?
>
> Two, I'd like a low flag number because it saves bytes on the wire, but
> there is a discussion to be had as to how common this flag will be versus
> other flags.
> (Non-attack) Bot traffic is very common, but it's not the majority of
> traffic by any means.
>
> Regards,
>
> Jonathan
>
>
>
> On Thu, 4 Apr 2024, 01:17 Christopher Patton,  40cloudflare@dmarc.ietf.org> wrote:
>
>> It would be great to here from Jonathan (the author) if RFC 7250 is
>> already sufficient for this use case.
>>
>> On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi  wrote:
>>
>>> Please see my earlier comment regarding this draft:
>>> https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/
>>>
>>> In summary: the functionality of this draft is already achievable by
>>> using the client_certificate_type extension defined in RFC 7250:
>>> https://datatracker.ietf.org/doc/html/rfc7250 with certificate type
>>> value = 0:
>>>
>>> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3
>>> .
>>>
>>> The table in section 4.2 of RFC8446 even mentions that the extension can
>>> be included in the ClientHello:
>>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2, thereby
>>> ensuring that the server sends a CertificateRequest message in response
>>> to the ClientHello received.
>>>
>>> OpenSSL already implements this extension since it was needed for
>>> support raw public keys (RPKs).
>>>
>>> As stated earlier: if it is indeed the case that the
>>> client_certificate_type extension is suitable for the use-case, then
>>> perhaps it is preferable to not have a separate flag. Otherwise, it
>>> would make the state machine at the server more complicated (for
>>> example: handling a ClientHello with both the mTLS flag and the
>>> client_certificate_type extension.
>>>
>>> Therefore, like Ekr, I am mildly negative on adopting this document but
>>> for different reasons.
>>>
>>> --Mohit
>>>
>>> On 4/3/24 00:52, Sean Turner wrote:
>>> > At the IETF 119 TLS session there was some interest in the mTLS Flag
>>> I-D (
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D=0);
>>> also, see previous list discussions at [0]. This message is to judge
>>> consensus on whether there is sufficient support to adopt this I-D.  If you
>>> support adoption and are willing to review and contribute text, please send
>>> a message to the list.  If you do not support adoption of this I-D, please
>>> send a message to the list and indicate why.  This call will close on 16
>>> April 2024.
>>> >
>>> > Thanks,
>>> > Deirdre, Joe, and Sean
>>> >
>>> > [0]
>>> 

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Dennis Jackson]

Hi Jonathan,

My reading of RFC 7250 is the same as Mohits. Although the RFC talks 
about raw public keys and a new codepoint for them, it is building on 
RFC 6091 which defined a similar extension and the X509 codepoint.


It seems fine for you to send the client_certificate_type extension with 
the single entry 0 (X509). You also have the option of using a value 
assigned for private use (224 and up) for your specific use case of 
indicating a search engine crawler willing to provide a client cert.


Best,
Dennis

On 04/04/2024 11:17, Jonathan Hoyland wrote:

Hi all,

Thanks for the feedback here.

With respect to RFC 7250, as I mentioned earlier on list, there seen 
to be two issues. First it changes the semantics of the extension 
slightly, and second the RFC explicitly excludes x.509 certs.


IIUC the semantics of the extension are "I have a weird client cert", 
not "I have a client cert".


With respect to whether this needs to be a working group item, I'm not 
particularly averse to this being an independent document if that's 
where the WG thinks it should go.
In my opinion, however, there are two things that it would be good to 
get input from the TLS WG on.


One, this is a change from all previous versions of TLS in which the 
client cannot induce auth, does enabling this break anyone's assumptions?


Two, I'd like a low flag number because it saves bytes on the wire, 
but there is a discussion to be had as to how common this flag will be 
versus other flags.
(Non-attack) Bot traffic is very common, but it's not the majority of 
traffic by any means.


Regards,

Jonathan



On Thu, 4 Apr 2024, 01:17 Christopher Patton, 
 wrote:


It would be great to here from Jonathan (the author) if RFC 7250
is already sufficient for this use case.

On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi  wrote:

Please see my earlier comment regarding this draft:
https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/

In summary: the functionality of this draft is already
achievable by
using the client_certificate_type extension defined in RFC 7250:
https://datatracker.ietf.org/doc/html/rfc7250 with certificate
type
value = 0:

https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3.

The table in section 4.2 of RFC8446 even mentions that the
extension can
be included in the ClientHello:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2,
thereby
ensuring that the server sends a CertificateRequest message in
response
to the ClientHello received.

OpenSSL already implements this extension since it was needed for
support raw public keys (RPKs).

As stated earlier: if it is indeed the case that the
client_certificate_type extension is suitable for the
use-case, then
perhaps it is preferable to not have a separate flag.
Otherwise, it
would make the state machine at the server more complicated (for
example: handling a ClientHello with both the mTLS flag and the
client_certificate_type extension.

Therefore, like Ekr, I am mildly negative on adopting this
document but
for different reasons.

--Mohit

On 4/3/24 00:52, Sean Turner wrote:
> At the IETF 119 TLS session there was some interest in the
mTLS Flag I-D

(https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D=0

);
also, see previous list discussions at [0]. This message is to
judge consensus on whether there is sufficient support to
adopt this I-D.  If you support adoption and are willing to
review and contribute text, please send a message to the
list.  If you do not support adoption of this I-D, please send
a message to the list and indicate why.  This call will close
on 16 April 2024.
>
> Thanks,
> Deirdre, Joe, and Sean
>
> [0]

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Jonathan Hoyland]

Hi all,

Thanks for the feedback here.

With respect to RFC 7250, as I mentioned earlier on list, there seen to be
two issues. First it changes the semantics of the extension slightly, and
second the RFC explicitly excludes x.509 certs.

IIUC the semantics of the extension are "I have a weird client cert", not
"I have a client cert".

With respect to whether this needs to be a working group item, I'm not
particularly averse to this being an independent document if that's where
the WG thinks it should go.
In my opinion, however, there are two things that it would be good to get
input from the TLS WG on.

One, this is a change from all previous versions of TLS in which the client
cannot induce auth, does enabling this break anyone's assumptions?

Two, I'd like a low flag number because it saves bytes on the wire, but
there is a discussion to be had as to how common this flag will be versus
other flags.
(Non-attack) Bot traffic is very common, but it's not the majority of
traffic by any means.

Regards,

Jonathan



On Thu, 4 Apr 2024, 01:17 Christopher Patton,  wrote:

> It would be great to here from Jonathan (the author) if RFC 7250 is
> already sufficient for this use case.
>
> On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi  wrote:
>
>> Please see my earlier comment regarding this draft:
>> https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/
>>
>> In summary: the functionality of this draft is already achievable by
>> using the client_certificate_type extension defined in RFC 7250:
>> https://datatracker.ietf.org/doc/html/rfc7250 with certificate type
>> value = 0:
>>
>> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3
>> .
>>
>> The table in section 4.2 of RFC8446 even mentions that the extension can
>> be included in the ClientHello:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2, thereby
>> ensuring that the server sends a CertificateRequest message in response
>> to the ClientHello received.
>>
>> OpenSSL already implements this extension since it was needed for
>> support raw public keys (RPKs).
>>
>> As stated earlier: if it is indeed the case that the
>> client_certificate_type extension is suitable for the use-case, then
>> perhaps it is preferable to not have a separate flag. Otherwise, it
>> would make the state machine at the server more complicated (for
>> example: handling a ClientHello with both the mTLS flag and the
>> client_certificate_type extension.
>>
>> Therefore, like Ekr, I am mildly negative on adopting this document but
>> for different reasons.
>>
>> --Mohit
>>
>> On 4/3/24 00:52, Sean Turner wrote:
>> > At the IETF 119 TLS session there was some interest in the mTLS Flag
>> I-D (
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D=0);
>> also, see previous list discussions at [0]. This message is to judge
>> consensus on whether there is sufficient support to adopt this I-D.  If you
>> support adoption and are willing to review and contribute text, please send
>> a message to the list.  If you do not support adoption of this I-D, please
>> send a message to the list and indicate why.  This call will close on 16
>> April 2024.
>> >
>> > Thanks,
>> > Deirdre, Joe, and Sean
>> >
>> > [0]
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2F9e2S95H9YgtHp5HhqdlNqmQP0_w%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681208049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=eEU6ZPJ5cmfqLHQuM3UYXrFKCJuKaaJVc8Ssk5erRjk%3D=0
>> > ___
>> > TLS mailing list
>> > TLS@ietf.org
>> >
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681214744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=%2B9CGIKB31GI9RMQG62I1rTnbHaDPfSynvlmwrkPn%2FpQ%3D=0
>>
>> ___
>> 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 TLS Flag - Request mTLS

[Christopher Patton]

It would be great to here from Jonathan (the author) if RFC 7250 is already
sufficient for this use case.

On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi  wrote:

> Please see my earlier comment regarding this draft:
> https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/
>
> In summary: the functionality of this draft is already achievable by
> using the client_certificate_type extension defined in RFC 7250:
> https://datatracker.ietf.org/doc/html/rfc7250 with certificate type
> value = 0:
>
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3
> .
>
> The table in section 4.2 of RFC8446 even mentions that the extension can
> be included in the ClientHello:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2, thereby
> ensuring that the server sends a CertificateRequest message in response
> to the ClientHello received.
>
> OpenSSL already implements this extension since it was needed for
> support raw public keys (RPKs).
>
> As stated earlier: if it is indeed the case that the
> client_certificate_type extension is suitable for the use-case, then
> perhaps it is preferable to not have a separate flag. Otherwise, it
> would make the state machine at the server more complicated (for
> example: handling a ClientHello with both the mTLS flag and the
> client_certificate_type extension.
>
> Therefore, like Ekr, I am mildly negative on adopting this document but
> for different reasons.
>
> --Mohit
>
> On 4/3/24 00:52, Sean Turner wrote:
> > At the IETF 119 TLS session there was some interest in the mTLS Flag I-D
> (
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D=0);
> also, see previous list discussions at [0]. This message is to judge
> consensus on whether there is sufficient support to adopt this I-D.  If you
> support adoption and are willing to review and contribute text, please send
> a message to the list.  If you do not support adoption of this I-D, please
> send a message to the list and indicate why.  This call will close on 16
> April 2024.
> >
> > Thanks,
> > Deirdre, Joe, and Sean
> >
> > [0]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2F9e2S95H9YgtHp5HhqdlNqmQP0_w%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681208049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=eEU6ZPJ5cmfqLHQuM3UYXrFKCJuKaaJVc8Ssk5erRjk%3D=0
> > ___
> > TLS mailing list
> > TLS@ietf.org
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681214744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=%2B9CGIKB31GI9RMQG62I1rTnbHaDPfSynvlmwrkPn%2FpQ%3D=0
>
> ___
> 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 TLS Flag - Request mTLS

[Salz, Rich]

> The attitude I am trying to get away from is that the TLS WG has to
be involved in every extension to TLS. Rather, we should decide what things
are important and spend time on them and then let others extend TLS 
independently
in areas we don't think are important.

This is probably a worthwhile goal, but it will of course take a while to get 
there. It will help everyone when we can write down the criteria for knowing 
when something should be in the WG and when it should not. It is probably 
safest to still encourage the WG to look at things, and as we build up a body 
of knowledge we can draw conclusions.


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

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Eric Rescorla]

On Tue, Apr 2, 2024 at 10:36 PM Watson Ladd  wrote:

>
> On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla  wrote:
>
>> Adoption should not be required to register a code point [0], as the
>> policy is Specification Required.
>>
>> I'm mildly negative on adopting this document. What is the reason we need
>> to spend WG time on this, rather than just having a code point assignment?
>>
>
> Well, don't we want to say how this is supposed to work somewhere?
>

Why? The attitude I am trying to get away from is that the TLS WG has to
be involved in every extension to TLS. Rather, we should decide what things
are important and spend time on them and then let others extend TLS
independently
in areas we don't think are important.

-Ekr


> I doubt this will take much time.
>
>>
>> -Ekr
>>
>> [0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13
>> should clearly have
>> a policy which matches 8447 S 7, which is to say that an I-D is
>> sufficient.
>>
>>
>> On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton > 40cloudflare@dmarc.ietf.org> wrote:
>>
>>> I'd like to see this problem solved. There was some discussion about
>>> whether an I-D is needed or all we needed was to register a code point
>>> somewhere. If most agree that an I-D is needed, then let's adopt it. I'm
>>> happy to review.
>>>
>>> Chris P.
>>>
>>> On Tue, Apr 2, 2024 at 12:22 PM Sean Turner  wrote:
>>>
 At the IETF 119 TLS session there was some interest in the mTLS Flag
 I-D (https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/);
 also, see previous list discussions at [0]. This message is to judge
 consensus on whether there is sufficient support to adopt this I-D.  If you
 support adoption and are willing to review and contribute text, please send
 a message to the list.  If you do not support adoption of this I-D, please
 send a message to the list and indicate why.  This call will close on 16
 April 2024.

 Thanks,
 Deirdre, Joe, and Sean

 [0]
 https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
 ___
 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
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Watson Ladd]

On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla  wrote:

> Adoption should not be required to register a code point [0], as the
> policy is Specification Required.
>
> I'm mildly negative on adopting this document. What is the reason we need
> to spend WG time on this, rather than just having a code point assignment?
>

Well, don't we want to say how this is supposed to work somewhere? I doubt
this will take much time.

>
> -Ekr
>
> [0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13
> should clearly have
> a policy which matches 8447 S 7, which is to say that an I-D is sufficient.
>
>
> On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton  40cloudflare@dmarc.ietf.org> wrote:
>
>> I'd like to see this problem solved. There was some discussion about
>> whether an I-D is needed or all we needed was to register a code point
>> somewhere. If most agree that an I-D is needed, then let's adopt it. I'm
>> happy to review.
>>
>> Chris P.
>>
>> On Tue, Apr 2, 2024 at 12:22 PM Sean Turner  wrote:
>>
>>> At the IETF 119 TLS session there was some interest in the mTLS Flag I-D
>>> (https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also,
>>> see previous list discussions at [0]. This message is to judge consensus on
>>> whether there is sufficient support to adopt this I-D.  If you support
>>> adoption and are willing to review and contribute text, please send a
>>> message to the list.  If you do not support adoption of this I-D, please
>>> send a message to the list and indicate why.  This call will close on 16
>>> April 2024.
>>>
>>> Thanks,
>>> Deirdre, Joe, and Sean
>>>
>>> [0]
>>> https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
>>> ___
>>> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Mohit Sethi]

Please see my earlier comment regarding this draft: 
https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/


In summary: the functionality of this draft is already achievable by 
using the client_certificate_type extension defined in RFC 7250: 
https://datatracker.ietf.org/doc/html/rfc7250 with certificate type 
value = 0: 
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3.


The table in section 4.2 of RFC8446 even mentions that the extension can 
be included in the ClientHello: 
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2, thereby 
ensuring that the server sends a CertificateRequest message in response 
to the ClientHello received.


OpenSSL already implements this extension since it was needed for 
support raw public keys (RPKs).


As stated earlier: if it is indeed the case that the 
client_certificate_type extension is suitable for the use-case, then 
perhaps it is preferable to not have a separate flag. Otherwise, it 
would make the state machine at the server more complicated (for 
example: handling a ClientHello with both the mTLS flag and the 
client_certificate_type extension.


Therefore, like Ekr, I am mildly negative on adopting this document but 
for different reasons.


--Mohit

On 4/3/24 00:52, Sean Turner wrote:

At the IETF 119 TLS session there was some interest in the mTLS Flag I-D 
(https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D=0);
 also, see previous list discussions at [0]. This message is to judge consensus on whether 
there is sufficient support to adopt this I-D.  If you support adoption and are willing to 
review and contribute text, please send a message to the list.  If you do not support 
adoption of this I-D, please send a message to the list and indicate why.  This call will 
close on 16 April 2024.

Thanks,
Deirdre, Joe, and Sean

[0] 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2F9e2S95H9YgtHp5HhqdlNqmQP0_w%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681208049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=eEU6ZPJ5cmfqLHQuM3UYXrFKCJuKaaJVc8Ssk5erRjk%3D=0
___
TLS mailing list
TLS@ietf.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681214744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=%2B9CGIKB31GI9RMQG62I1rTnbHaDPfSynvlmwrkPn%2FpQ%3D=0


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

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Eric Rescorla]

Adoption should not be required to register a code point [0], as the policy
is Specification Required.

I'm mildly negative on adopting this document. What is the reason we need
to spend WG time on this, rather than just having a code point assignment?

-Ekr

[0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13
should clearly have
a policy which matches 8447 S 7, which is to say that an I-D is sufficient.


On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton  wrote:

> I'd like to see this problem solved. There was some discussion about
> whether an I-D is needed or all we needed was to register a code point
> somewhere. If most agree that an I-D is needed, then let's adopt it. I'm
> happy to review.
>
> Chris P.
>
> On Tue, Apr 2, 2024 at 12:22 PM Sean Turner  wrote:
>
>> At the IETF 119 TLS session there was some interest in the mTLS Flag I-D (
>> https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see
>> previous list discussions at [0]. This message is to judge consensus on
>> whether there is sufficient support to adopt this I-D.  If you support
>> adoption and are willing to review and contribute text, please send a
>> message to the list.  If you do not support adoption of this I-D, please
>> send a message to the list and indicate why.  This call will close on 16
>> April 2024.
>>
>> Thanks,
>> Deirdre, Joe, and Sean
>>
>> [0]
>> https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
>> ___
>> 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 TLS Flag - Request mTLS

[David Schinazi]

I support adoption.
David

On Tue, Apr 2, 2024 at 12:22 PM Sean Turner  wrote:

> At the IETF 119 TLS session there was some interest in the mTLS Flag I-D (
> https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see
> previous list discussions at [0]. This message is to judge consensus on
> whether there is sufficient support to adopt this I-D.  If you support
> adoption and are willing to review and contribute text, please send a
> message to the list.  If you do not support adoption of this I-D, please
> send a message to the list and indicate why.  This call will close on 16
> April 2024.
>
> Thanks,
> Deirdre, Joe, and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
> ___
> 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 TLS Flag - Request mTLS

[Christopher Patton]

I'd like to see this problem solved. There was some discussion about
whether an I-D is needed or all we needed was to register a code point
somewhere. If most agree that an I-D is needed, then let's adopt it. I'm
happy to review.

Chris P.

On Tue, Apr 2, 2024 at 12:22 PM Sean Turner  wrote:

> At the IETF 119 TLS session there was some interest in the mTLS Flag I-D (
> https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see
> previous list discussions at [0]. This message is to judge consensus on
> whether there is sufficient support to adopt this I-D.  If you support
> adoption and are willing to review and contribute text, please send a
> message to the list.  If you do not support adoption of this I-D, please
> send a message to the list and indicate why.  This call will close on 16
> April 2024.
>
> Thanks,
> Deirdre, Joe, and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
> ___
> 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 TLS Flag - Request mTLS

[Salz, Rich]

>If you support adoption and are willing to review and contribute text, please 
>send a message to the list.

"I do"


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

[TLS] Adoption call for TLS Flag - Request mTLS

[Sean Turner]

At the IETF 119 TLS session there was some interest in the mTLS Flag I-D 
(https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see 
previous list discussions at [0]. This message is to judge consensus on whether 
there is sufficient support to adopt this I-D.  If you support adoption and are 
willing to review and contribute text, please send a message to the list.  If 
you do not support adoption of this I-D, please send a message to the list and 
indicate why.  This call will close on 16 April 2024. 

Thanks,
Deirdre, Joe, and Sean

[0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls