Andrei Popov wrote:
> Hi Ilari,
>
>>
>> What sort of usecase you have in mind for this?
>
> This is to support a fairly common website design where the landing
> page does not require client auth, but subsequent request to a
> protected resource triggers client authentication within an existing
>
Subject: Re: [TLS] Commentary on the client authentication presentation slides
Before people get too far down that road, here:
https://tools.ietf.org/html/draft-thomson-httpbis-cant-01
https://tools.ietf.org/html/draft-thomson-tls-care-00
Andrei has made it clear that these do not work for his
Before people get too far down that road, here:
https://tools.ietf.org/html/draft-thomson-httpbis-cant-01
https://tools.ietf.org/html/draft-thomson-tls-care-00
Andrei has made it clear that these do not work for his use case (I'm
not yet convinced that they are inadequate, but I am convinced of t
On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote:
> > What sort of usecase you have in mind for this?
>
> This is to support a fairly common website design where the landing page does
> not require client auth, but subsequent request to a protected resource
> triggers client authenticati
On Mon, Aug 10, 2015 at 07:33:53PM +, David Benjamin wrote:
>
> Why not do this using HTTP's own auth framework? Have the client sign
> something which includes a channel binding, placing it and the certificate
> chain in an Authorization header. You could even transition to it in TLS
> 1.2 de
t the time there was no client
credential. This page probably needs to be a resource that requires client auth.
-Original Message-
From: Yoav Nir [mailto:ynir.i...@gmail.com]
Sent: Monday, August 10, 2015 12:53 PM
To: Andrei Popov
Cc: Ilari Liusvaara ; tls@ietf.org
Subject: Re: [TLS] Comm
> On Aug 10, 2015, at 10:04 PM, Andrei Popov wrote:
>
>> Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS 1.3,
>> HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2.
> Correct, anything less than this will create deployment problems.
>
>> I’d like to point out
oes not necessarily have to block other requests that do not require
> client auth.
>
> Cheers,
>
> Andrei
>
> -Original Message-
> From: Yoav Nir [mailto:ynir.i...@gmail.com]
> Sent: Monday, August 10, 2015 10:28 AM
> To: Andrei Popov
> Cc: Ilari Liusvaara ; tls@
uire client
auth.
Cheers,
Andrei
-Original Message-
From: Yoav Nir [mailto:ynir.i...@gmail.com]
Sent: Monday, August 10, 2015 10:28 AM
To: Andrei Popov
Cc: Ilari Liusvaara ; tls@ietf.org
Subject: Re: [TLS] Commentary on the client authentication presentation slides
> On Aug 10, 2
> On Aug 10, 2015, at 8:10 PM, Andrei Popov wrote:
>
> Hi Ilari,
>
>> What sort of usecase you have in mind for this?
> This is to support a fairly common website design where the landing page does
> not require client auth, but subsequent request to a protected resource
> triggers client aut
vid Benjamin ; tls@ietf.org
Subject: Re: [TLS] Commentary on the client authentication presentation slides
On Tue, Aug 04, 2015 at 12:37:47AM +, Andrei Popov wrote:
> > Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS.
> > There one likely "preconfigures&qu
On Tue, Aug 04, 2015 at 12:37:47AM +, Andrei Popov wrote:
> > Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS.
> > There one likely "preconfigures" client certificates if needed.
> The proposed client authentication mechanism specifically addresses
> the case where the c
in
Cc: Andrei Popov ; tls@ietf.org
Subject: Re: [TLS] Commentary on the client authentication presentation slides
On Sun, Aug 02, 2015 at 03:38:00PM +, David Benjamin wrote:
> On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara
>
> wrote:
> >
> > What I think would be very useful:
On Sun, Aug 02, 2015 at 03:38:00PM +, David Benjamin wrote:
> On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara
> wrote:
> >
> > What I think would be very useful: A way for client to signal it has a
> > client certificate it expects to use, regardless of if valid configuration
> > is known. The
On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara
wrote:
> > On Tue, Jul 28, 2015 at 6:28 PM David Benjamin
> wrote:
> >
> > > Are you intending that this mechanism be enabled by default for HTTP/2
> or
> > > would the prohibition against renego still apply? Without any way for
> the
> > > client t
> On Tue, Jul 28, 2015 at 6:28 PM David Benjamin wrote:
>
> > Are you intending that this mechanism be enabled by default for HTTP/2 or
> > would the prohibition against renego still apply? Without any way for the
> > client to tie the CertificateRequest to the HTTP request that triggered it,
> >
se its representation. A TLS implementation (or
>> certificate API) that does not recognize the OID in the cert will also skip
>> this OID in the extension_values. In the degenerate case, an implementation
>> may choose to skip all extension_values.
>>
>>
Sound good to me; if the group agrees to remove certificate_types, I'll make
this change in the PR.
-Original Message-
From: Ilari Liusvaara [mailto:ilari.liusva...@elisanet.fi]
Sent: Friday, July 24, 2015 8:33 AM
To: Andrei Popov
Cc: tls@ietf.org
Subject: Re: [TLS] Commentary o
On Fri, Jul 24, 2015 at 05:01:37AM +, Andrei Popov wrote:
>
> > - The certificate_types field in CertificateRequest is pretty much
> > useless, since all supported algorithms are of signature type.
> If the signature_algorithms extension officially becomes MTI, then
> perhaps we can discus ge
implementation may
choose to skip all extension_values.
Cheers,
Andrei
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara
Sent: Monday, July 20, 2015 4:11 PM
To: tls@ietf.org
Subject: [TLS] Commentary on the client authentication presentation slides
Some commentary on client authentication slides (there is no linked draft
nor other material yet).
- Mechanism like proposed looks dangerous when combined with HTTP/2.
Multiplexed protocols are in general not safe to authenticate without
application-layer signaling (which can be implicit via s
21 matches
Mail list logo
