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] [Last-Call] Genart last call review of draft-ietf-tls-keylogfile-01

[Russ Housley]

Yes, indeed.

Russ

> On Apr 14, 2024, at 6:22 AM, Martin Thomson  wrote:
> 
> Thanks  Russ,
> 
> https://github.com/tlswg/sslkeylogfile/pull/11 and 
> https://mailarchive.ietf.org/arch/msg/media-types/5IW3tN6mJkqZMyuYWLwoOMNVhgM/
>  should address those issues.
> 
> Cheers,
> Martin
> 
> On Fri, Apr 12, 2024, at 14:30, Russ Housley via Datatracker wrote:
>> Reviewer: Russ Housley
>> Review result: Ready
>> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair. Please wait for direction from your
>> document shepherd or AD before posting a new version of the draft.
>> 
>> For more information, please see the FAQ at
>> .
>> 
>> Document: draft-ietf-tls-keylogfile-01
>> Reviewer: Russ Housley
>> Review Date: 2024-04-12
>> IETF LC End Date: 2024-04-18
>> IESG Telechat date: unknown
>> 
>> Summary: Ready
>> 
>> 
>> Major Concerns:
>> 
>> None
>> 
>> 
>> Minor Concerns:
>> 
>> Section 3: The text says: "Access to the content of a file in
>> SSLKEYLOGFILE format allows an attacker to break the
>> confidentiality protection on any TLS connections that are
>> included in the file."  This is clearly true.  However, the
>> attacker this access to the keys can also break the integrity
>> protections.
>> 
>> Section 4: The registration of the new application/sslkeylogfile
>> media-type for all IETF registrations in the standards tree
>> requires a posting to the media-ty...@iana.org mail list.  A search
>> of the mail archive id not uncover "sslkeylogfile".  To avoid delay,
>> that mail list discussion should probably get started now.
>> 
>> 
>> Nits:
>> 
>> Section 1: s/file format that logging/file format for logging/
> 
> -- 
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call

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

Re: [TLS] Genart last call review of draft-ietf-tls-keylogfile-01

[Martin Thomson]

Thanks  Russ,

https://github.com/tlswg/sslkeylogfile/pull/11 and 
https://mailarchive.ietf.org/arch/msg/media-types/5IW3tN6mJkqZMyuYWLwoOMNVhgM/ 
should address those issues.

Cheers,
Martin

On Fri, Apr 12, 2024, at 14:30, Russ Housley via Datatracker wrote:
> Reviewer: Russ Housley
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-tls-keylogfile-01
> Reviewer: Russ Housley
> Review Date: 2024-04-12
> IETF LC End Date: 2024-04-18
> IESG Telechat date: unknown
>
> Summary: Ready
>
>
> Major Concerns:
>
> None
>
>
> Minor Concerns:
>
> Section 3: The text says: "Access to the content of a file in
> SSLKEYLOGFILE format allows an attacker to break the
> confidentiality protection on any TLS connections that are
> included in the file."  This is clearly true.  However, the
> attacker this access to the keys can also break the integrity
> protections.
>
> Section 4: The registration of the new application/sslkeylogfile
> media-type for all IETF registrations in the standards tree
> requires a posting to the media-ty...@iana.org mail list.  A search
> of the mail archive id not uncover "sslkeylogfile".  To avoid delay,
> that mail list discussion should probably get started now.
>
>
> Nits:
>
> Section 1: s/file format that logging/file format for logging/

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

[TLS] Weekly github digest (TLS Working Group Drafts)

[Repository Activity Summary Bot]

Pull requests
-
* tlswg/draft-ietf-tls-esni (+1/-0/💬0)
 1 pull requests submitted:
 - Correct `ECHConfigList` length bounds (by ctz)
   https://github.com/tlswg/draft-ietf-tls-esni/pull/614 


* tlswg/tls13-spec (+1/-0/💬1)
 1 pull requests submitted:
 - Forbid the sender from sending duplicate supported groups entries. (by 
bob-beck)
   https://github.com/tlswg/tls13-spec/pull/1354 


 1 pull requests received 1 new comments:
 - #1354 Forbid the sender from sending duplicate supported groups entries. (1 
by ekr)
   https://github.com/tlswg/tls13-spec/pull/1354 



Repositories tracked by this digest:
---
* https://github.com/tlswg/draft-ietf-tls-semistatic-dh
* https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate
* https://github.com/tlswg/draft-ietf-tls-esni
* https://github.com/tlswg/certificate-compression
* https://github.com/tlswg/draft-ietf-tls-external-psk-importer
* https://github.com/tlswg/draft-ietf-tls-ticketrequest
* https://github.com/tlswg/tls13-spec
* https://github.com/tlswg/tls-flags
* https://github.com/tlswg/dtls13-spec
* https://github.com/tlswg/dtls-conn-id
* https://github.com/tlswg/tls-subcerts
* https://github.com/tlswg/oldversions-deprecate
* https://github.com/tlswg/sniencryption
* https://github.com/tlswg/tls-exported-authenticator
* https://github.com/tlswg/draft-ietf-tls-ctls
* https://github.com/tlswg/external-psk-design-team
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls