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

[Lars Eggert via Datatracker]

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.

### 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`

### 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).

### 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

[Lars Eggert]

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



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Draft TLS Extension for Path Validation

[Ashley Kopman]

Hi TLS,

I have just submitted a draft TLS Extension for Path Validation  
https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt 


The proposal is for a Path Validation Extension to provide a new protocol for 
TLS/DTLS allowing inclusion of certificate path validation information in the 
TLS/DTLS handshake. Specifically, it covers the use of Server-based Certificate 
Validation Protocol (SCVP) for path validation.

We are also finalizing a use case for civil aviation air-to-ground 
communications which should be submitted in the next day.

Please have a look at the draft and provide feedback.

Thank you,

Ashley Kopman



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

Re: [TLS] Draft TLS Extension for Path Validation

[Robert Moskowitz]

I am working with Ashley and Rob Segers of FAA on this.  I don't make 
any claims of being able to comment on the TLS content.  I am providing 
IETF mentoring.  I work with Rob in ICAO TFSG items.



We want this discussed at IETF114.  Perhaps in SECDISPATCH if it does 
not need its own BOF.  Or as a TLS topic.


Bob

On 5/25/22 12:40, Ashley Kopman wrote:

Hi TLS,

I have just submitted a draft TLS Extension for Path Validation 
https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt 



The proposal is for a Path Validation Extension to provide a 
new protocol for TLS/DTLS allowing inclusion of certificate path 
validation information in the TLS/DTLS handshake. Specifically, 
it covers the use of Server-based Certificate Validation Protocol 
(SCVP) for path validation.


We are also finalizing a use case for civil aviation air-to-ground 
communications which should be submitted in the next day.


Please have a look at the draft and provide feedback.

Thank you,

Ashley Kopman




___
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] Draft TLS Extension for Path Validation

[Ilari Liusvaara]

On Wed, May 25, 2022 at 12:40:13PM -0400, Ashley Kopman wrote:
> Hi TLS,
> 
> I have just submitted a draft TLS Extension for Path Validation 
> https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt 
> 
> 
> The proposal is for a Path Validation Extension to provide a new
> protocol for TLS/DTLS allowing inclusion of certificate path
> validation information in the TLS/DTLS handshake. Specifically, it
> covers the use of Server-based Certificate Validation Protocol
> (SCVP) for path validation.

Looking at how this is integrated to (D)TLS:


For (D)TLS 1.2, the server extension does not seem to be technically
necressary, and omitting it could simplify things. Yes, this design
is the same as one used for OCSP stapling (status_request), but I
found the server hello extension in OCSP to be seemingly unnecressary
extra complexity.

For (D)TLS 1.3, why there are seemingly two server extensions, one in
server hello, which is usually only used for low-level crypto stuff,
which this is not, and another in certificate message (which makes
sense for certificate-related thing.


And this is maybe a stupid question, but I didn't find an answer by
quickly looking at the draft nor the SCVP RFC, does the server need to
send the certificate chain to the client if it sends the SCVP response,
or just the end-entity certificate? Omitting the chain could save
quite a bit of handshake size.



-Ilari

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

Re: [TLS] Better TLS Client Authentication

[Phillip Hallam-Baker]

On Tue, May 24, 2022 at 12:59 AM Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> Hi Phillip,
> I'm not able to figure out the merits of your proposal, but I see one
> major obstacle: Google have a de-facto monopoly (80%) on browser technology
> and your proposal seems to require a rather substantial upgrade.
>

NO!

No browser update needed! No server update needed!

The only thing missing is the private key management for the user. And that
can all be done by a standalone app.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Better TLS Client Authentication

[Phillip Hallam-Baker]

If we are looking at installed footprint, then TLS Client Auth wins. Don't
accuse me of re-inventing the wheel because TLS Client Auth predates FIDO
by decades.

It is a completely different application though. FIDO was designed to
enable use of physical authenticator tokens. As far as I can see, soft
tokens are an afterthought, they don't have a strategy for provisioning
multiple devices with a private key bound to the same account.

My starting point here was that I was looking at how to make use of the
Mesh to support FIDO auth without the need for a physical token. That is
the route I expected to take. It was only when I looked into it that I
suddenly realized that I don't need any of that, I can do everything I need
with legacy browsers and legacy servers. The only thing that changes is a
client enrollment app on the client side and an authorization module in the
server.

No protocol changes, just a certificate profile.

At this point FIDO has far less deployed base than TLS Client Auth, I am
happy to support FIDO as well but why wouldn't we want both?
I really don't think I am the person suffering from Not Invented Here.


I can provide the same key mobility capabilities in WebAuthn so that users
can register for a Web site with their phone browser and then log in from
their laptop without requiring an additional registration while maintaining
the End-to-End security of the private keys. But that would require some
significant extensions to FIDO and be more of a FIDO3.

The security properties of WebAuthn and TLS Client Auth are very
different.TLS Client Auth is not limited to Web for a start. We could use
it to secure IMAP, POP3 and SUBMIT client auth.



On Tue, May 24, 2022 at 1:11 AM Tim Cappalli 
wrote:

> You mentioned FIDO, but I didn't see a reason why you don't want to use
> it. The industry has largely accepted the mature FIDO standards stack
> (WebAuthn & CTAP) as the strong authentication method that replaces
> passwords in a privacy preserving and phishing resistant manner.
>
>
>
> Why create something new, especially using technologies that are not very
> user friendly?
>
>
>
> tim
>
>
>
> *From: *TLS  on behalf of Phillip Hallam-Baker <
> ph...@hallambaker.com>
> *Date: *Sunday, May 22, 2022 at 23:28
> *To: *tls@ietf.org 
> *Subject: *[TLS] Better TLS Client Authentication
>
> I am looking for people interested in discussing the following proposal to
> create a profile of TLS Client Authentication certificates to enable
> transparent Web Site authentication in Philadelphia:
>
>
>
> I have a three step plan for eliminating Password Authentication
>
>
>
> 1) Deploy an open standards based, E2E secure password vault
>
> 2) Transition Web sites to use of public key authentication
>
> 3) Deploy a 2FA type scheme to address 'ceremony' use cases
>
>
>
> I don't want to get into detail here, but I believe the trick to
> eliminating passwords is to deploy a password management solution in phase
> 1 that creates a sufficiently large base of users whose devices are
> provisioned with the necessary private keys to make use of public key auth
> practical.
>
>
>
> So, I had assumed that this was all about enabling FIDO. But when I look
> at what I want to achieve and what legacy deployments provide, I suddenly
> realized I can do everything I need using TLS client auth. The only
> question is what the BEST way to do it is going to be.
>
>
>
>
>
> So I have running code that can provision key pairs and credentials to
> every device Alice owns:
>
>
>
> https://www.youtube.com/watch?v=zrBv717w8yY
> 
>
>
>
> It would not take a great deal of extra effort to provision certificates
> into the Windows/MAC/etc keystores so that IE, Edge, Firefox, Chrome,
> Safari, etc. etc. can all make use of the certificates. Its just a question
> of writing a script.
>
>
>
>
>
> I am pretty sure I can get 'something' to work. But I would appreciate
> some help from folk who are closer to the real-world implementations.
>
>
>
> Reading through the specs, I think we can make it so that after an
> (optional) one time registration, Alice can just use the Web site without
> the need to ever log in ever again.
>
>
>
> The only reason Alice would ever need to repeat registration is if the Web
> Site had some policy requiring Alice to affirm that yes, this really is her
> device and she agrees to terms. That is what I call 'ceremony' and it is
> not an authentication issue. I have another way of addressing that issue.
>
>
>
>
>
> As far as I can tell, all that I really need is to write a certificate
> profile for