Re: [TLS] [lamps] [EXTERNAL] Distinguished names for self certified TLS client authj

[Jeffrey Walton]

On Tue, Jun 14, 2022 at 11:14 PM Phillip Hallam-Baker
 wrote:
>
> Hmm... looks like this is a piece of brokenness in the browsers.

I don't think client certs are a priority for Browsers. That would
significantly hinder support of interception, which is a browser
design goal under Priority of Constituencies [1]. Browsers see
interception as a valid use case for DLP programs.

Instead of client certificates (and Origin Bound Certificates), the
browsers prefer transport schemes so traffic can be intercepted like
FIDO and token binding gear.

(The open question for me is, how does a browser tell "good"
interception from a "good" guy opposed to "bad" interception from a
bad guy).

Jeff

[1] https://w3ctag.github.io/design-principles/#priority-of-constituencies

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

Re: [TLS] [EXTERNAL] [lamps] Distinguished names for self certified TLS client authj

[Phillip Hallam-Baker]

Hmm... looks like this is a piece of brokenness in the browsers.

I see this as a two step thing. First there is 'getting it to work in the
legacy browsers' and then there is 'doing it the right way'.


For the second step, I have actually written my own browser (yes really)
and one of the goals of that work is precisely so that I can control the
privacy etc. profiles and show how I think it can be done right.

The idea of the client cert selection extension was to avoid the need for
that cert selector extension. But as the article points out... privacy
hole! Ooops. What does Firefox do if a server specifies a list of client
cert DNs that only matches a single cert? The goal was to avoid the need
for the selection box. But we definitely need that 'do you want to send a
cert' dialog.


My plan for Phill's Hypothetical Browser is to allow users to specify site
profiles and apply their own security policies to them.

So Alice has 3 machines A, B and C. She wants to have a seamless experience
across all of these. So log into the NYT on A and she will automatically
log in on B.

Alice uses a number of different sites

X, Y, Z are sites she uses for work and it is important TO ALICE that the
site X knows that she is the same Alice who is doing something on site Y.
P, Q, R are random Websites that Alice uses but she certainly does not want
P to know that she also uses site Q.

So my plan here is that Alice can declare security policies 'Work' and
'Pseudonymous' so that context is shared between X, Y, Z but P and Q and R
are each isolated with entirely separate cache and cookie settings.

For investigation work, I would also want to be able to specify that a site
be accessed through a forensic proxy, for personal privacy I might bounce
requests to different sites off different proxies.

So for my extreme privacy browser, I can specify that a site should use a
shared certificate as specified by the security label applied to that site
or a site specific certificate to prevent linkage.

The github is here:
https://github.com/hallambaker/PhillsHypotheticalBrowser


My thanks to the Microsoft WebView2 team for making this possible.


On Tue, Jun 14, 2022 at 4:44 PM Mike Ounsworth 
wrote:

> Hi Phillip,
>
> What clients are you trying to use this with? Browsers? This almost feels
> like a user-agent question: "What CA DN do you want the server to prompt
> for so that you put up the right certs in the popup?". Is there a CA DN
> that you can specify that will cause FF / Chrome to show the user all their
> loaded certs?
>
> Note: back in 2018 I was fiddling around with this for a stackexchange
> question and found that (by default) Firefox politely waits for you to
> select a client cert from the popup, whereas Chrome just starts spamming
> client certs at the server until it accepts one. I feel like user-agent
> behaviour is going to affect the viability of your idea here.
>
> https://security.stackexchange.com/a/199518/61443
>
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>
> From: Spasm  On Behalf Of Phillip Hallam-Baker
> Sent: June 14, 2022 2:58 PM
> To: SPASM ; tls@ietf.org
> Subject: [EXTERNAL] [lamps] Distinguished names for self certified TLS
> client authj
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> 
> [Yes, I am aware of the FIDO work and it is a completely different use
> case, does not apply to non web applications. TLS Client Auth is an IETF
> spec and thus within IETF scope.]
>
> I have an infrastructure that makes private key management really simple
> for end users. They can manage private keys across devices without being
> aware they are doing it. This technology has obvious applications for
> existing public key authentication schemes including EAP, FIDO and TLS
> Client Auth.
>
> When looking at TLS client auth it seems to me that it is much closer to
> being a viable replacement for some uses of passwords than experience leads
> us to believe. In particular, I have maybe 5 accounts I might use a
> hardware token to secure but I have several hundred Web accounts that all
> use the same password because when it's not my asset and I am not being
> paid, I don't use my brain power to remember the password.
>
> So my basic idea here is that Alice connects all her devices to her
> personal Mesh and they are automatically provisioned with a device specific
> cert that is chained up to one of Alice's personal PKIX CAs. The CA in turn
> being (optionally) credentialed under Alice's personal Mesh via an
> extension if the goal is to establish that the 'Alice' visiting site A is
> the same as the Alice visiting site B. For cases where we want to prevent
> linkage, we develop a separate CA per site.
>
> This is not how PKIX is intended to work of course. But the deployed
> infrastructure supports PKIX and so that is the framework we have to work
> 

Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)

[Eric Vyncke (evyncke)]

Thank you Nick for your reply and for the changes.

Hope that this helped to improve the document,

Regards

-éric

From: Nick Sullivan 
Date: Tuesday, 14 June 2022 at 12:47
To: Eric Vyncke 
Cc: The IESG , "draft-ietf-tls-subce...@ietf.org" 
, tls-chairs , 
"" , Joseph Salowey , Sean Turner 

Subject: Re: Éric Vyncke's No Objection on draft-ietf-tls-subcerts-14: (with 
COMMENT)

Hi Éric,

Thank you for your review. Responses inline and edits in Github 
(https://github.com/tlswg/tls-subcerts/pull/108/files).


--
COMMENT:
--

# Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD, review of
draft-ietf-tls-subcerts-14

Thank you for the work put into this document. It solves a common and important
issue while keeping backward compatibility.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Joe Salowey for the shepherd's write-up including the WG
consensus and the intended status.

I hope that this helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 1

```
   Furthermore, this mechanism allows the server to use modern signature
   algorithms such as Ed25519 [RFC8032] even if their CA does not
   support them.
```
Does it also mean that the signature algorithm could be weaker ?

In theory, TLS 1.3 (and by extension DCs) do not support weak signature schemes.


I found the use of `(D)TLS termination services`, `(D)TLS server`, `(D)TLS
peer` a little confusing on whether they represent the same entity.

I added some text in the introduction to clarify.

### Section 3.2

The small graphic in the text is really useful but:

* should include a figure legend
* the bottom part would be welcome in the introduction

Added

## Section 4.2

Thanks to Sean Turner for providing the explanation about the use of Cloudflare
OID into an IETF standard.

## Section 5.1

Unsure whether having such a short subsection is useful (albeit being harmless)
especially when there is only one subsection.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments


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

Re: [TLS] [EXTERNAL] [lamps] Distinguished names for self certified TLS client authj

[Mike Ounsworth]

Hi Phillip,

What clients are you trying to use this with? Browsers? This almost feels like 
a user-agent question: "What CA DN do you want the server to prompt for so that 
you put up the right certs in the popup?". Is there a CA DN that you can 
specify that will cause FF / Chrome to show the user all their loaded certs?

Note: back in 2018 I was fiddling around with this for a stackexchange question 
and found that (by default) Firefox politely waits for you to select a client 
cert from the popup, whereas Chrome just starts spamming client certs at the 
server until it accepts one. I feel like user-agent behaviour is going to 
affect the viability of your idea here.

https://security.stackexchange.com/a/199518/61443

---
Mike Ounsworth
Software Security Architect, Entrust

From: Spasm  On Behalf Of Phillip Hallam-Baker
Sent: June 14, 2022 2:58 PM
To: SPASM ; tls@ietf.org
Subject: [EXTERNAL] [lamps] Distinguished names for self certified TLS client 
authj

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the 
content is safe.

[Yes, I am aware of the FIDO work and it is a completely different use case, 
does not apply to non web applications. TLS Client Auth is an IETF spec and 
thus within IETF scope.]

I have an infrastructure that makes private key management really simple for 
end users. They can manage private keys across devices without being aware they 
are doing it. This technology has obvious applications for existing public key 
authentication schemes including EAP, FIDO and TLS Client Auth.

When looking at TLS client auth it seems to me that it is much closer to being 
a viable replacement for some uses of passwords than experience leads us to 
believe. In particular, I have maybe 5 accounts I might use a hardware token to 
secure but I have several hundred Web accounts that all use the same password 
because when it's not my asset and I am not being paid, I don't use my brain 
power to remember the password.

So my basic idea here is that Alice connects all her devices to her personal 
Mesh and they are automatically provisioned with a device specific cert that is 
chained up to one of Alice's personal PKIX CAs. The CA in turn being 
(optionally) credentialed under Alice's personal Mesh via an extension if the 
goal is to establish that the 'Alice' visiting site A is the same as the Alice 
visiting site B. For cases where we want to prevent linkage, we develop a 
separate CA per site.

This is not how PKIX is intended to work of course. But the deployed 
infrastructure supports PKIX and so that is the framework we have to work 
within.


Looking at how TLS Client Auth works as deployed, a server sends a message back 
to a client saying 'client certificate required' and a list of distinguished 
names of CAs it will accept.

So what I want to know is not 'should I do this', but 'what is the string I 
should send when I do'. That is, this is something I am planning to do and so I 
am asking what approach is least likely to have unintended effects.

I see a need for two distinguished names:

A) 'Self signed CA speaking to any relying party'
B) 'Self signed CA speaking to a specific relying party'

The server is going to check the certificate chain itself on the other end of 
course.


And again, yes, I do fully understand the limitations of transport layer client 
auth. That is why I make use of my own authentication layer for Web Service 
transactions.

Any email and files/attachments transmitted with it are confidential and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If this message has been sent to you in error, you must not copy, 
distribute or disclose of the information it contains. Please notify Entrust 
immediately and delete the message from your system.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Distinguished names for self certified TLS client authj

[Phillip Hallam-Baker]

[Yes, I am aware of the FIDO work and it is a completely different use
case, does not apply to non web applications. TLS Client Auth is an IETF
spec and thus within IETF scope.]

I have an infrastructure that makes private key management really simple
for end users. They can manage private keys across devices without being
aware they are doing it. This technology has obvious applications for
existing public key authentication schemes including EAP, FIDO and TLS
Client Auth.

When looking at TLS client auth it seems to me that it is much closer to
being a viable replacement for some uses of passwords than experience leads
us to believe. In particular, I have maybe 5 accounts I might use a
hardware token to secure but I have several hundred Web accounts that all
use the same password because when it's not my asset and I am not
being paid, I don't use my brain power to remember the password.

So my basic idea here is that Alice connects all her devices to her
personal Mesh and they are automatically provisioned with a device specific
cert that is chained up to one of Alice's personal PKIX CAs. The CA in turn
being (optionally) credentialed under Alice's personal Mesh via an
extension if the goal is to establish that the 'Alice' visiting site A is
the same as the Alice visiting site B. For cases where we want to prevent
linkage, we develop a separate CA per site.

This is not how PKIX is intended to work of course. But the deployed
infrastructure supports PKIX and so that is the framework we have to work
within.


Looking at how TLS Client Auth works as deployed, a server sends a message
back to a client saying 'client certificate required' and a list of
distinguished names of CAs it will accept.

So what I want to know is not 'should I do this', but 'what is the string I
should send when I do'. That is, this is something I am planning to do and
so I am asking what approach is least likely to have unintended effects.

I see a need for two distinguished names:

A) 'Self signed CA speaking to any relying party'
B) 'Self signed CA speaking to a specific relying party'

The server is going to check the certificate chain itself on the other end
of course.


And again, yes, I do fully understand the limitations of transport layer
client auth. That is why I make use of my own authentication layer for Web
Service transactions.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Francesca Palombini's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)

[Nick Sullivan]

Francesca and Christian,

Thank you for the review. Answers inline below and changes in Github (
https://github.com/tlswg/tls-subcerts/pull/108/files).

Best,
Nick

On Tue, May 31, 2022 at 11:49 AM Francesca Palombini via Datatracker <
nore...@ietf.org> wrote:

> Francesca Palombini has entered the following ballot position for
> draft-ietf-tls-subcerts-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for the work on this document.
>
> Many thanks to Christian Amsüss for his ART ART review:
> https://mailarchive.ietf.org/arch/msg/art/7lzdOaiccRnXFtSuX3aUyh9ffV8/.
> Authors, please take a look at Christian's comments (also reported below),
> especially the one about the "delegated_credential" usage in the
> Certificate
> message.
>
> Francesca
>
> --
>
> Reviewer: Christian Amsüss
> Review result: Ready with Nits
>
> Thanks for this well-written document
>
> ART topics:
>
> The document does not touch on any of the typical ART review issues; times
> are
> relative in well understood units, and versioning, formal language (ASN.1,
> which is outside of my experience to check) and encoding infrastructure
> (struct) follows TLS practices.
>
> General comments:
>
> * The introduction of this mechanism gives the impression of a band-aid
> applied
> to a PKI ecosystem that has accumulated many limitations as outlined in
> section
> 3.1. The present solution appears good, but if there is ongoing work on the
> underlying issues (even experimentally), I'd appreciate a careful
> reference to
> it.
>

Unfortunately, there are no good references for alternative approaches.

>
> * Section 7.6 hints at the front end querying the back-end for creation of
> new
> DCs -- other than that, DC distribution (neither push- nor pull-based) is
> discussed. If there are any mechanisms brewing, I'd appreciate a reference
> as
> well.
>

There are no formal mechanisms moving towards standardization at this time.

>
> Please check:
>
> * The IANA considerations list "delegated_credential" for CH, CR and CT
> messages. I did not find a reference in the text for Ct, only for CH and
> CR.
>

See section 4.1.2, where it states:
"The client MUST send the DC as an extension in the CertificateEntry of its
end-entity certificate" which is where CT extensions live.

>
> Editorial comments:
>
> * (p5) "result for the peer.." -- extraneous period.
> * (p9, p15, p16) The "7 days" are introduced as the default for a
> profilable
> prarameter, but later used without further comment.
>
> Addressed
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Lars Eggert's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)

[Nick Sullivan]

Hi Lars,

Comments addressed inline and changes to the document are in Github (
https://github.com/tlswg/tls-subcerts/pull/108/files).

Best,
Nick

On Wed, May 25, 2022 at 5:20 AM Lars Eggert via Datatracker <
nore...@ietf.org> wrote:

> Lars Eggert has entered the following ballot position for
> draft-ietf-tls-subcerts-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
>
>
>
> --
> COMMENT:
> --
>
> # GEN AD review of draft-ietf-tls-subcerts-14
>
> CC @larseggert
>
> Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review
> (https://mailarchive.ietf.org/arch/msg/gen-art/QDnSqLec7uKP9GcyuL-8p8nS-2s
> ).
>
> ## Comments
>
> ### Section 6, paragraph 2
> ```
>  This document also defines an ASN.1 module for the DelegationUsage
>  certificate extension in Appendix A.  IANA has registered value 95
>  for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX
>  Module Identifier" (1.3.5.1.5.5.7.0) registry.  An OID for the
>  DelegationUsage certificate extension is not needed as it is already
>  assigned to the extension from Cloudflare's IANA Private Enterprise
>  Number (PEN) arc.
> ```
> See Martin Duke's comment on using the Cloudflare space; I have the same
> question.
>

This has been addressed by Sean Turner on the list.

>
> ### Inclusive language
>
> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and
> more
> guidance:
>
>  * Term `man`; alternatives might be `individual`, `people`, `person`
>  * Term `invalid`; alternatives might be `not valid`, `unenforceable`, `not
>binding`, `inoperative`, `illegitimate`, `incorrect`, `improper`,
>`unacceptable`, `inapplicable`, `revoked`, `rescinded`
>

Fixed in link below

>
> ### IP addresses
>
> Found IP blocks or addresses not inside RFC5737/RFC3849 example ranges:
> `1.3.5.1` and `5.5.7.0`.
>

> ## Nits
>
> All comments below are about very minor potential issues that you may
> choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so
> there
> will likely be some false positives. There is no need to let me know what
> you
> did with these suggestions.
>
> ### Typos
>
>  Section 4.2, paragraph 1
> ```
> -This documnt defines a new X.509 extension, DelegationUsage, to be
> +This document defines a new X.509 extension, DelegationUsage, to be
> +  +
> ```
>
> ### Outdated references
>
> Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this
> may
> be on purpose).
>

Yes, it's referencing an attack

>
> ### Grammar/style
>
>  Paragraph 2
> ```
> his document describes a mechanism to to overcome some of these limitations
>^
> ```
> Possible typo: you repeated a word.
>
>  Section 5.1, paragraph 1
> ```
> tial's private key is thus important and access control mechanisms SHOULD
> be
> 
> ```
> Use a comma before "and" if it connects two independent clauses (unless
> they
> are closely connected and short).
>
>  Section 6, paragraph 1
> ```
> f early revocation. Since it is short lived, the expiry of the delegated
> cre
> ^^^
> ```
> This word is normally spelled with a hyphen.
>
>  Section 7, paragraph 1
> ```
> ime could be unique and thus privacy sensitive clients, such as browsers
> in i
>  ^
> ```
> This word is normally spelled with a hyphen.
>
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> [IRT]: https://github.com/larseggert/ietf-reviewtool
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Last-Call] Genart last call review of draft-ietf-tls-subcerts-12

[Nick Sullivan]

Thanks Elwyn,

I've updated the document in Github to address your nits (
https://github.com/tlswg/tls-subcerts/pull/108/files).

Best,
Nick

On Wed, May 25, 2022 at 5:20 AM Lars Eggert  wrote:

> Elwyn, thank you for your review. I have entered a No Objection ballot for
> this document.
>
> Lars
>
>
> > On 2022-4-9, at 3:18, Elwyn Davies via Datatracker 
> wrote:
> >
> > Reviewer: Elwyn Davies
> > Review result: Ready with Nits
> >
> > 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 treat these comments just
> > like any other last call comments.
> >
> > For more information, please see the FAQ at
> >
> > .
> >
> > Document: draft-ietf-tls-subcerts-??
> > Reviewer: Elwyn Davies
> > Review Date: 2022-04-08
> > IETF LC End Date: 2022-04-08
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> > Ready with nits.Just a few editrial level nits.
> >
> > Major issues:
> > None
> >
> > Minor issues:
> > None.
> >
> > Nits/editorial comments:
> > Abstract: The exact form of the abbreviation (D)TLS is not in the set of
> > well-known abbreviations.  I assume it is supposed to mean DTLS or TLS -
> This
> > ought to be expanded on first use.
> >
> > Abstract:  s/mechanism to to/mechanism to/
> >
> > s1, para 2: CA is used before its expansion in para 3.
> >
> > s1, next to last para: "this document proposes"  Hopefully when it
> becomes an
> > RFC it will do more than propose.  Suggest "this document introduces".
> >
> > s1, next to last para:  "to speak for names"  sounds a bit
> anthropomorphic to
> > me, but I can't think of a simple alternative word.
> >
> > s1, last para: s/We will refer/This document refers/  [Not an academic
> paper!]
> >
> > s3.1, 2nd bullet: s/provide are not necessary/provide is not necessary/
> >
> > s4, definition of expected_cert_verify_algorithm:  " Only signature
> algorithms
> > allowed for use in CertificateVerify message are allowed."  Does this
> need a
> > reference to the place where the list of such algorithms is recorded?
> >
> > s4.1.1 and s4.1.2:  In s4.1.1:  "the client SHOULD ignore delegated
> credentials
> > sent as extensions to any other certificate."  I would have though this
> ought
> > to be a MUST.  There is an equivalent in s4.1.2. I am not sure what the
> > client/server might do if it doesn't ignore the DC.
> >
> > s4.1.3, para 1: s/same way that is done/same way that it is done/
> >
> > s4.2, para 1: s/We define/This docuent defines/
> >
> > sS/s5.1: RFC conventions prefer not to have sections empty of text:  Add
> > something like: "The following operational consideration should be taken
> into
> > consideration when using Delegated Certificates:"
> >
> >
> >
> > --
> > 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] Éric Vyncke's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)

[Nick Sullivan]

Hi Éric,

Thank you for your review. Responses inline and edits in Github (
https://github.com/tlswg/tls-subcerts/pull/108/files).


> --
> COMMENT:
> --
>
> # Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD, review of
> draft-ietf-tls-subcerts-14
>
> Thank you for the work put into this document. It solves a common and
> important
> issue while keeping backward compatibility.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
>
> Special thanks to Joe Salowey for the shepherd's write-up including the WG
> consensus and the intended status.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> ## COMMENTS
>
> ### Section 1
>
> ```
>Furthermore, this mechanism allows the server to use modern signature
>algorithms such as Ed25519 [RFC8032] even if their CA does not
>support them.
> ```
> Does it also mean that the signature algorithm could be weaker ?
>

In theory, TLS 1.3 (and by extension DCs) do not support weak signature
schemes.


> I found the use of `(D)TLS termination services`, `(D)TLS server`, `(D)TLS
> peer` a little confusing on whether they represent the same entity.
>

I added some text in the introduction to clarify.

>
> ### Section 3.2
>
> The small graphic in the text is really useful but:
>
> * should include a figure legend
> * the bottom part would be welcome in the introduction
>

Added

>
> ## Section 4.2
>
> Thanks to Sean Turner for providing the explanation about the use of
> Cloudflare
> OID into an IETF standard.
>
> ## Section 5.1
>
> Unsure whether having such a short subsection is useful (albeit being
> harmless)
> especially when there is only one subsection.
>
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] DTLS support of SCHC

[Robert Moskowitz]

I have been doing more research on using SCHC with DTLS for general UDP 
applications.


For this I am using MAVlink

https://mavlink.io/en/

As my UDP app example.

I see EKR's point on the small header design of DTLS 1.3 per RFC9147 fig 
3.  I will use:


2-byte CID
1-byte Seq# (same as MAVlink)
2-byte Length (max MAVlink after compression is 263 bytes)

The SCHC rules allow for compressing 16 bytes within MAVlink and 
eliminating transport of the UDP header.


The challenge is without the UDP header, and assuming NextHeader is UDP, 
how does the UDP layer handle this datagram?  The UDP Destination Port 
is the DTLS Seq and 1st byte of the length.


This seems to fraught with failure modes, and that the NextHeader really 
MUST be SCHC as I have defined in draft-moskowitz-lpwan-ipnumber.


This is really the first question:  Is there anyway to do this without 
adding SCHC as an IP Number?


Next is does the RuleID need to be explicit in the packet or can it be 
implicit?  I think that would depend on the IP Source Addr.  If this is 
the ONLY SCHC RuleID from that addr, then, yes it can be implicit, 
saving the byte.


Finally setting up SCHC.  Is static configuration the only option? Well 
for MAVlink use, this is not so much an issue, as there is a limited 
pairing between UA/GCS.  But should there be a DTLS SCHC negotiation as 
link in draft-mglt-ipsecme-ikev2-diet-esp-extension?


I welcome your comments/observations.

Oh, why work hard to save 24 bytes over the 'wire'?  For some wireless 
links that might be all it takes to result in fragmentation and 
potentially doubling the link usage.


Other UDP apps might have other savings.  This might have general 
aviation usage beyond what I have looked at todate.


Thanks.

Bob

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