Re: [TLS] Draft TLS Extension for Path Validation

[Peter Gutmann]

An indirect question on the overall premise here: Given that SCVP is
essentially nonexistent (unless there's some niche market somewhere using it
that I'm not aware of, which is why I didn't use an unqualified
"nonexistent"), does it really matter much?  If an RFC falls in the forest and
all that...

Peter.

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

Re: [TLS] Draft TLS Extension for Path Validation

[Robert Moskowitz]

Peter,

SCVP *IS* being used in aviation applications today in ground-to-ground 
cases.  But the comm cost for air-to-ground is excessive.  So this is 
directly what at least US FAA and EU EUROCONTROL are implementing.


Aviation, through ICAO, is building their own PKI.  The CP is in final 
drafting and a number of CA companies have signed on.  Testbed testing 
for various applications are in progress.  I just got off a video call 
for a PoC planning session that will cover activities through the end of 
the year.


Aviation is finally going digital.

Ashley is working on the use case draft which will point to a slide deck 
as well that shows the use case.


So this is important in one community:  Civil Aviation.

Bob

On 5/26/22 04:46, Peter Gutmann wrote:

An indirect question on the overall premise here: Given that SCVP is
essentially nonexistent (unless there's some niche market somewhere using it
that I'm not aware of, which is why I didn't use an unqualified
"nonexistent"), does it really matter much?  If an RFC falls in the forest and
all that...

Peter.

___
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

[Robert Moskowitz]

Oh, and it is this community's input to see that this is well designed 
as once something is put into a plane, it tends to be there for years...


On 5/26/22 04:46, Peter Gutmann wrote:

An indirect question on the overall premise here: Given that SCVP is
essentially nonexistent (unless there's some niche market somewhere using it
that I'm not aware of, which is why I didn't use an unqualified
"nonexistent"), does it really matter much?  If an RFC falls in the forest and
all that...

Peter.

___
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

[Ashley Kopman]

Ilari,

Thank you for your feedback.

You are correct in assuming that this was designed after the OCSP 
status_request extension. It is a valid point that the extension can likely be 
omitted from the server hello. The intent was to communicate to the client that 
the server supports the extension and will respond with the path validation 
information. However, since it is allowed for the server to respond with the 
extension and then not supply the path validation, it is not very useful 
overhead. I will remove the extension from the server hello.

You are also correct that sending the certificate chain becomes unnecessary. It 
was my intent to communicate that, but looking back at the draft, I don’t think 
I made it clear. I will add it.

Thank you,

Ashley


> On May 25, 2022, at 2:23 PM, Ilari Liusvaara  wrote:
> 
> 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

[Blumenthal, Uri - 0553 - MITLL]

This is not about what was there earlier, nor what has been in wider use so far 
(in which case, password clearly wins ;). 

 

Rather – what is the best (from security and usability point of view) mechanism 
now. I say – FIDO (or U2F, whatever) is the closest contender, if not the 
outright winner.

 

Thanks

-- 

V/R,

Uri

 

 

From: TLS  on behalf of Phillip Hallam-Baker 

Date: Wednesday, May 25, 2022 at 21:01
To: Tim Cappalli 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Better TLS Client Authentication

 

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 

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

Re: [TLS] Draft TLS Extension for Path Validation

[Salz, Rich]

>So this is important in one community:  Civil Aviation.

Thanks for the explanation Bob.

That's very cool, and I am grateful to those behind the scenes who worked to 
bring this to the IETF.

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

Re: [TLS] Better TLS Client Authentication

[Phillip Hallam-Baker]

Let me be clear here, I was not asking for permission. I am just asking for
people with technical contributions to the proposal.

WebAuthn is not going to work for non Web applications of TLS.

You know, this type of response is the reason people stop coming to the
IETF to get things done. I am well aware of the work in question, it
attempts to address a different need. It is not a new proposal by any
means, it has seen some use but they are still looking at a user
authentication model which is hardly going to work for Web Service to Web
Service.


On Thu, May 26, 2022 at 8:38 AM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> This is not about what was there earlier, nor what has been in wider use
> so far (in which case, password clearly wins ;).
>
>
>
> Rather – what is the best (from security and usability point of view)
> mechanism *now*. I say – FIDO (or U2F, whatever) is the closest
> contender, if not the outright winner.
>
>
>
> Thanks
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
> *From: *TLS  on behalf of Phillip Hallam-Baker <
> ph...@hallambaker.com>
> *Date: *Wednesday, May 25, 2022 at 21:01
> *To: *Tim Cappalli 
> *Cc: *"tls@ietf.org" 
> *Subject: *Re: [TLS] Better TLS Client Authentication
>
>
>
> 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
> 

Re: [TLS] Draft TLS Extension for Path Validation

[Ashley Kopman]

The use case for the D(TLS) Path Validation extension in civil aviation has
been submitted
https://www.ietf.org/archive/id/draft-segers-tls-cert-val-ext-use-case-00.txt
there
is also referenced slide deck available
http://conceptsbeyond.com/resources/SCVPValidationRequest_UseCase_CB.pdf

Thank you,
Ashley Kopman

On May 26, 2022, at 8:36 AM, Ashley Kopman 
wrote:

Ilari,

Thank you for your feedback.

You are correct in assuming that this was designed after the OCSP
status_request extension. It is a valid point that the extension can likely
be omitted from the server hello. The intent was to communicate to the
client that the server supports the extension and will respond with the
path validation information. However, since it is allowed for the server to
respond with the extension and then not supply the path validation, it is
not very useful overhead. I will remove the extension from the server hello.

You are also correct that sending the certificate chain becomes
unnecessary. It was my intent to communicate that, but looking back at the
draft, I don’t think I made it clear. I will add it.

Thank you,

Ashley


On May 25, 2022, at 2:23 PM, Ilari Liusvaara 
wrote:

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

[Robert Moskowitz]

This is the Aviation use case I mentioned in earlier mails.

I will be submitting a BOF request tomorrow, performa.

Of course it is for the ADs to decide if this is a standalone BOF or a 
20min slot in SECDISPATCH.


How much time people want to discuss it is in large measure related to 
the discussion we engender here.


Thank you for your attention.  And thank you for reviewing and making 
this a solid design that we can get deployed for avaiation Air-to-ground 
and any similar use case.


Bob

On 5/26/22 19:43, Ashley Kopman wrote:


The use case for the D(TLS) Path Validation extension in civil 
aviation has been submitted 
https://www.ietf.org/archive/id/draft-segers-tls-cert-val-ext-use-case-00.txt there 
is also referenced slide deck available 
http://conceptsbeyond.com/resources/SCVPValidationRequest_UseCase_CB.pdf


Thank you,
Ashley Kopman

On May 26, 2022, at 8:36 AM, Ashley Kopman 
 wrote:


Ilari,

Thank you for your feedback.

You are correct in assuming that this was designed after the OCSP 
status_request extension. It is a valid point that the extension can 
likely be omitted from the server hello. The intent was to 
communicate to the client that the server supports the extension and 
will respond with the path validation information. However, since it 
is allowed for the server to respond with the extension and then not 
supply the path validation, it is not very useful overhead. I will 
remove the extension from the server hello.


You are also correct that sending the certificate chain becomes 
unnecessary. It was my intent to communicate that, but looking back 
at the draft, I don’t think I made it clear. I will add it.


Thank you,

Ashley


On May 25, 2022, at 2:23 PM, Ilari Liusvaara 
 wrote:


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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls