Re: [TLS] draft-rescorla-tls-subcerts-01

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Hannes,

On 24/04/2017 16:39, "Hannes Tschofenig"  wrote:
> On 04/21/2017 12:48 PM, Ilari Liusvaara wrote:
> > Regarding clients, I think the draft specifies LURK as backup plan
> > for clients that don't support subcerts (which causes some extra
> > latency if triggered).
> I didn't got that impression.

Ilari is correct I think -- the fallback to LURK is what the draft in its
current version seems to imply.

> Isn't this something ACME was trying to solve as well?

We have proposed an extension to ACME that handles the full lifecycle of the
delegation, including the automatic renewal of the trail of short term
certificates.  It works in a pretty straightforward way and doesn't require any
modification in the endpoints' stack.

Cheers, t


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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Ilari Liusvaara]

On Mon, Apr 24, 2017 at 05:39:39PM +0200, Hannes Tschofenig wrote:
> Hi Ilari,
> 
> thanks for your response. A few remarks inline:
> 
> On 04/21/2017 12:48 PM, Ilari Liusvaara wrote:
> > On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote:
> >> I read through draft-rescorla-tls-subcerts-01 and I ran into some basic
> >> questions.
> >>
> >> I have been wondering why the TLS server operator obtains an end-entity
> >> certificate from a CA (which cannot be used to sign further
> >> certificates) instead of running an intermediate CA him-/herself
> >> instead. This would work without requiring any changes to the client
> >> side. The proposed solution, although technically feasible, will
> >> unfortunately take a long time to deploy since it requires cooperation
> >> from clients, servers, and also from CAs.
> > 
> > There is enormous amount of red tape obtaining intermediates, even
> > technically constrained ones. And as consequence, it is enormously
> > expensive (through not nearly as expensive as public CA).
> 
> In essence you are doing this through the extension as well just using a
> different format.
> 
> > 
> > Defining new extensions is much more deployable, as slow as it is
> > (AFAICT, no BR changes needed).
> 
> I hope that this is true since otherwise you have just traded one
> problem against the other one.

AFAICT, CAs can add arbitrary extensions if (logically sufficient but
not necressary):

- CA is "aware" of "a reason" to include it, and
- Extension has meaning on "public Internet", and
- Extension does not mislead w.r.t. CA validation performed

(CABForum Baseline Requirements, version 1.4.4, section 7.1.2.4).

For this, AFAICT:
- CSR requesting it or other kind of request is "a reason" to include
  it.
- Defined in RFCs for public use imples meaning on "public Internet".
- This extension does not affect CA validation.


Of course:
- Fixed process delay on CABForum for technical changes to BRs is
  ~7 weeks (1 week of discussion + 1 week of voting + ~4.3 weeks of
  IPR review + few days of misc. other). That's much faster than the
  time CAs take to actually offer this (if ever!).
- Nobody changes the extension rules in nasty ways for reasons I can't
  fathom of.

> >> What is also not clear to my why some of the certificate management
> >> protocols, which provide the necessary level of automation, cannot be
> >> used with CAs to request short-lived certificates.
> > 
> > AFAIK, that would cause issues with CT and OCSP signing.
> > 
> > The latter would be fixable by reintroducing CABForum ballot 153 and
> > passing it (the reasons 153 failed were obviously political instead of
> > technical).
> Isn't this something ACME was trying to solve as well?

ACME can perform fast rolling of certificates. What it can't deal with
is any possible downsides to actually doing that in real world.


-Ilari

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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Melinda Shore]

On 4/24/17 7:39 AM, Hannes Tschofenig wrote:
>> There is enormous amount of red tape obtaining intermediates, even
>> technically constrained ones. And as consequence, it is enormously
>> expensive (through not nearly as expensive as public CA).
> In essence you are doing this through the extension as well just using a
> different format.

In some sense the proposal is about having a trusted issuer who's not
included in public trust stores, which is a reasonable goal (there's
a fantastic amount of work, including external audits, in having
your intermediate included in browser trust stores, etc.).  We haven't
had a good delegation story since, like, ever, but now there's a
somewhat compelling use case (CDNs) that needs attention and will
benefit from a solution.

Melinda




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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Hannes Tschofenig]

Hi Ilari,

thanks for your response. A few remarks inline:

On 04/21/2017 12:48 PM, Ilari Liusvaara wrote:
> On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote:
>> I read through draft-rescorla-tls-subcerts-01 and I ran into some basic
>> questions.
>>
>> I have been wondering why the TLS server operator obtains an end-entity
>> certificate from a CA (which cannot be used to sign further
>> certificates) instead of running an intermediate CA him-/herself
>> instead. This would work without requiring any changes to the client
>> side. The proposed solution, although technically feasible, will
>> unfortunately take a long time to deploy since it requires cooperation
>> from clients, servers, and also from CAs.
> 
> There is enormous amount of red tape obtaining intermediates, even
> technically constrained ones. And as consequence, it is enormously
> expensive (through not nearly as expensive as public CA).

In essence you are doing this through the extension as well just using a
different format.

> 
> Defining new extensions is much more deployable, as slow as it is
> (AFAICT, no BR changes needed).

I hope that this is true since otherwise you have just traded one
problem against the other one.

> 
> Regarding clients, I think the draft specifies LURK as backup plan
> for clients that don't support subcerts (which causes some extra
> latency if triggered).
I didn't got that impression.

> 
>> What is also not clear to my why some of the certificate management
>> protocols, which provide the necessary level of automation, cannot be
>> used with CAs to request short-lived certificates.
> 
> AFAIK, that would cause issues with CT and OCSP signing.
> 
> The latter would be fixable by reintroducing CABForum ballot 153 and
> passing it (the reasons 153 failed were obviously political instead of
> technical).
Isn't this something ACME was trying to solve as well?

Ciao
Hannes

> 
> 
> -Ilari
> 



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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 21/04/2017 16:50, "Salz, Rich"  wrote:
> > Speaking as one of the co-authors of [1]: it is not completely clear to me
> > what is the limitation in CT that would prevent it to cope with the
> > pervasive use of short-term certificates.  Can anyone shed a light on this?
> 
> I believe the concerns are scaling log servers and perhaps needing to
> "rotate" them if, say, 90% of their tree is invalid in a year.

Thanks Rich.  I need to double check that, but I guess there are remedies for
the issues you mention -- e.g., adding more logs / having separate logs for
very short term stuff.

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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Salz, Rich]

> Speaking as one of the co-authors of [1]: it is not completely clear to me 
> what
> is the limitation in CT that would prevent it to cope with the pervasive use 
> of
> short-term certificates.  Can anyone shed a light on this?

I believe the concerns are scaling log servers and perhaps needing to "rotate" 
them if, say, 90% of their tree is invalid in a year.

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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 21/04/2017 11:48, "TLS on behalf of Ilari Liusvaara"  wrote:
On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote:
> > What is also not clear to my why some of the certificate management
> > protocols, which provide the necessary level of automation, cannot be
> > used with CAs to request short-lived certificates.
> 
> AFAIK, that would cause issues with CT and OCSP signing.

Speaking as one of the co-authors of [1]: it is not completely clear to me what
is the limitation in CT that would prevent it to cope with the pervasive use of
short-term certificates.  Can anyone shed a light on this?

Cheers, thanks,
t

[1] https://tools.ietf.org/id/draft-sheffer-acme-star-00.txt

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

Re: [TLS] draft-rescorla-tls-subcerts

[Ilari Liusvaara]

On Fri, Jul 15, 2016 at 05:34:40PM +, Andrei Popov wrote:
> > The I-D actually covers this.
> Understood; the I-D lists a few cons, but arguably none of them are
> blocking issues. It seems unnecessary to create a new TLS-specific
> mechanism that duplicates existing PKI semantics.

IMO, the draft severly understates the cons. Basically, NC certs aren't
feasible except for the bigger shops that can afford the $$$ and the
difficulty needed.

Also, it doesn't look like the semantics are complicated. E.g one
can completely skip revocation by making things short-lived (because
revocation on short timescales simply does not work anyway).


-Ilari

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

Re: [TLS] draft-rescorla-tls-subcerts

[Andrei Popov]

> The I-D actually covers this.
Understood; the I-D lists a few cons, but arguably none of them are blocking 
issues. It seems unnecessary to create a new TLS-specific mechanism that 
duplicates existing PKI semantics.

> Those two serve different purposes. Sometimes you really need the ES/KS 
> split, sometimes short-lived certs would be more useful.
Possibly so.

Cheers,

Andrei

-Original Message-
From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] 
Sent: Friday, July 15, 2016 2:14 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: Eric Rescorla <e...@rtfm.com>; tls@ietf.org
Subject: Re: [TLS] draft-rescorla-tls-subcerts

On Fri, Jul 15, 2016 at 12:28:18AM +, Andrei Popov wrote:
> Naïve question: why not simply get a constrained CA certificate and 
> issue short-validity end entity certs? Unless I’m missing something, 
> this would work with existing TLS implementations, no extensions 
> required.

The I-D actually covers this. Additionally, I think getting NC certificate is 
quite expensive/difficult.

> Short-lived credential approach seems more viable than
> draft-mglt-lurk-tls-requirements-00 (which requires an additional 
> round-trip between the Edge Server and Content Provider).

Those two serve different purposes. Sometimes you really need the ES/KS split, 
sometimes short-lived certs would be more useful.


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

Re: [TLS] draft-rescorla-tls-subcerts

[Ilari Liusvaara]

On Fri, Jul 15, 2016 at 12:28:18AM +, Andrei Popov wrote:
> Naïve question: why not simply get a constrained CA certificate and
> issue short-validity end entity certs? Unless I’m missing something,
> this would work with existing TLS implementations, no extensions
> required.

The I-D actually covers this. Additionally, I think getting NC
certificate is quite expensive/difficult.

> Short-lived credential approach seems more viable than
> draft-mglt-lurk-tls-requirements-00 (which requires an additional
> round-trip between the Edge Server and Content Provider).

Those two serve different purposes. Sometimes you really need the
ES/KS split, sometimes short-lived certs would be more useful.


-Ilari

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

Re: [TLS] draft-rescorla-tls-subcerts

[Salz, Rich]

> Naïve question: why not simply get a constrained CA certificate and issue 
> short-validity end entity certs?

Wouldn't you need one for every potential user? And the nameConstraints then 
becomes a union of all SAN fields?

> Short-lived credential approach seems more viable than 
> draft-mglt-lurk-tls-requirements-00 (which requires an additional round-trip 
> between the Edge Server and Content Provider).

Except that the RSALG and/or "keyless SSL" approach are already deployed.

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

Re: [TLS] draft-rescorla-tls-subcerts

[Andrei Popov]

Naïve question: why not simply get a constrained CA certificate and issue 
short-validity end entity certs? Unless I’m missing something, this would work 
with existing TLS implementations, no extensions required.

Short-lived credential approach seems more viable than 
draft-mglt-lurk-tls-requirements-00 (which requires an additional round-trip 
between the Edge Server and Content Provider).

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Thursday, July 7, 2016 12:29 PM
To: tls@ietf.org
Subject: [TLS] draft-rescorla-tls-subcerts

We've talked several times about designing some sort of TLS delegation
mechanism. A few of us got together and put together some initial thoughts
about the options at:
https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt

The general idea here is to have some mechanism for allowing what
are effectively end-entities to issue short-lived credentials that allow other
entities to act on their behalf (e.g., for CDN use cases).
Comments welcome.

In terms of the security analysis, it's obviously very important that this 
mechanism
not present a risk to existing TLS servers. The mechanism designed here is
intended to be future safe in that sense, though perhaps we've missed something.

I also wanted to clarify a couple points about attacks where the certificate 
that signs the delegated credential is also used for ordinary TLS operation 
(which generally is a practice that's pretty scary). As noted above it's 
important that existing certs not be usable this way, but maybe future certs 
would be.

1. It's important to construct the delegated credential in such a way that you 
can't use a TLS server as a signing oracle. If you choose "option 2" where you 
define a new structure, then it's probably sufficient to use the TLS 1.3 
"context-including" digitally-signed production proposed by AGL. If you you 
choose "option 1" where the delegated credential is an X.509 cert, then you'd 
need to make some rules about fixing portions of the cert that the TLS client 
can't control.

2. If you're concerned about attacks like those of Jager et al. which exploit 
RSA decryption, what's important is that the attacker not be able to get the 
server to do TLS 1.2-style static RSA with the key. Playing with the usage bits 
definitely makes it harder to configure the server this way (because it's 
likely to cause bustage) but may not be enough, because sufficiently busted 
clients and server might be willing to use them that way anyway.

In the next rev, we'll update the draft to make these points more clearly.

-Ekr



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

Re: [TLS] draft-rescorla-tls-subcerts

[David Benjamin]

On Thu, Jul 7, 2016 at 7:29 PM Watson Ladd  wrote:

> I don't think we can use name constraints here. Yes, they are opt-in
> and clients can indicate support, but it may well be that a TLS
> implementation doesn't know if its X509 validation code will support
> them as it hands the certificate to a system provided validator. (I
> believe there was a longstanding Chrome on Windows XP bug for a
> similar reason).
>

What are you referring to? I think one would know well enough whether our
validators support a given feature. If there's weird cases, one can always
decline to advertise if unsure.

If you're thinking ECDSA and Chrome/XP, I believe it only got reflected in
the cipher list and not sigalgs, but that's just because we never routed
that bit through, not because we didn't know if we could do ECDSA. (And by
now it's irrelevant since Chrome/XP is no longer supported.)

David


> Sincerely,
> Watson
>
> >
> > In the next rev, we'll update the draft to make these points more
> clearly.
> >
> > -Ekr
> >
> >
> >
> >
> > ___
> > 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-rescorla-tls-subcerts

[Ilari Liusvaara]

On Thu, Jul 07, 2016 at 07:29:08PM -0700, Watson Ladd wrote:
> On Jul 7, 2016 12:29 PM, "Eric Rescorla"  wrote:
> 
> How about limit to ECDSA certificates? This eliminates the
> Bleichenbacher issues. We can also make this opt in via an extension
> to the EE certificate: since the certificate is not a CA certificate
> (even if used that way) the extension can be noncritical.

You mean ECDSA legacy signature type (TLS_ECDHE_ECDSA_WITH_*
ciphersuites)? There's EdDSA too (and it would meet the above definition)?

New extension would need CAs to issue it, and getting them to do that
could be, erm... "laborious".

> As for format we know we have a TLS 1.3 signed structure that doesn't
> overlap. Option 2 is easy: throw a key and TAI seconds for interval
> start and end. I hope we won't need more structure then that. Using
> X509 runs a risk of cross-format issues, and showing there aren't any
> is likely to be hard.

Or use POSIX time notation if you can tolerate being off by a second
due to leap secods.

Then the proposal had server name or server name list. Dunno if those
are needed.

> I don't think we can use name constraints here. Yes, they are opt-in
> and clients can indicate support, but it may well be that a TLS
> implementation doesn't know if its X509 validation code will support
> them as it hands the certificate to a system provided validator. (I
> believe there was a longstanding Chrome on Windows XP bug for a
> similar reason).

The nasty Chrome on WinXP bug I was aware of was that WinXP code couldn't
handle certificates that were like "allow all, except .foo". LE X1
intermediate hit that bug, causing lots of trouble, even with WinXP being
EoL'd.



-Ilari

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

Re: [TLS] draft-rescorla-tls-subcerts

[Ilari Liusvaara]

On Thu, Jul 07, 2016 at 08:08:11PM -0400, Kyle Rose wrote:
> On Thu, Jul 7, 2016 at 6:13 PM, Ilari Liusvaara 
> wrote:
> 
> >
> > I also checked if one could do some funky stuff with credential lifetime
> > notation to limit the lifetime. Nothing came up (apart for using 16-bit
> > count in decaseconds (das) only allowing presenting lifetimes up to 7
> > days, 14 hours, 2 minutes and 30 seconds). :->
> >
> 
> What would it be anchored to if it's not an absolute time? 

There is validity start time in there, the relative end time would
be relative to that.

That is, instead of saying "this is valid from t1 to t2", saying "this
is valid from t to t+dt".

No real perference either way, it was just an experiment to play with
time notations.


-Ilari

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

Re: [TLS] draft-rescorla-tls-subcerts

[Russ Housley]

Eric:

I have not had a chance to look at the draft yet, but based on your cover note 
you seem to have several requirements in common with RFC 3820.

Russ


On Jul 7, 2016, at 3:28 PM, Eric Rescorla  wrote:

> We've talked several times about designing some sort of TLS delegation
> mechanism. A few of us got together and put together some initial thoughts
> about the options at:
> https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
> 
> The general idea here is to have some mechanism for allowing what
> are effectively end-entities to issue short-lived credentials that allow other
> entities to act on their behalf (e.g., for CDN use cases).
> Comments welcome.
> 
> In terms of the security analysis, it's obviously very important that this 
> mechanism
> not present a risk to existing TLS servers. The mechanism designed here is
> intended to be future safe in that sense, though perhaps we've missed 
> something.
> 
> I also wanted to clarify a couple points about attacks where the certificate 
> that signs the delegated credential is also used for ordinary TLS operation 
> (which generally is a practice that's pretty scary). As noted above it's 
> important that existing certs not be usable this way, but maybe future certs 
> would be.
> 
> 1. It's important to construct the delegated credential in such a way that 
> you can't use a TLS server as a signing oracle. If you choose "option 2" 
> where you define a new structure, then it's probably sufficient to use the 
> TLS 1.3 "context-including" digitally-signed production proposed by AGL. If 
> you you choose "option 1" where the delegated credential is an X.509 cert, 
> then you'd need to make some rules about fixing portions of the cert that the 
> TLS client can't control.
> 
> 2. If you're concerned about attacks like those of Jager et al. which exploit 
> RSA decryption, what's important is that the attacker not be able to get the 
> server to do TLS 1.2-style static RSA with the key. Playing with the usage 
> bits definitely makes it harder to configure the server this way (because 
> it's likely to cause bustage) but may not be enough, because sufficiently 
> busted clients and server might be willing to use them that way anyway.
> 
> In the next rev, we'll update the draft to make these points more clearly.
> 
> -Ekr
> 
> 
> 
> ___
> 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-rescorla-tls-subcerts

[Peter Gutmann]

Eric Rescorla  writes:

>We've talked several times about designing some sort of TLS delegation
>mechanism. A few of us got together and put together some initial thoughts
>about the options at:
>https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt

That's going to be a tricky one.  The PKIX standing committee has always
rigidly (and in some cases I'd say rabidly) opposed anything that would allow
end users to bypass CAs (in one case the WG chair killed a proposal for
delegated certs with the comment "we don't want to turn X.509 into PGP").
Admittedly PKIX is now defunct, but there are still enough PKIX members in the
IETF that it could be tricky getting anything done.

Another issue is how you're going to do it.  You really need to have an EE
able to use a standard cert to issue short-term certs for high-exposure
environments, so only the high-risk key needs to be online.  One of the
proposals for this (which I have a link to, since I wrote it in this case)
was:

https://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt

This talks about all of the issues involved.

The alternative is to use a cert to sign "credentials", whatever form that may
take.  That's going to get ugly since you're now introducing something that's
in effect a certificate, but isn't called a certificate (yes, you can whittle
it down a bit, but eventually you'll want to add more features, and end up
reinventing certs). 

I would go for delegated certs, since 99% of the work is already done for you
(formats, data types, how to process them, code to handle them, etc).

Peter.


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

Re: [TLS] draft-rescorla-tls-subcerts

[Eric Rescorla]

On Thu, Jul 7, 2016 at 3:13 PM, Ilari Liusvaara 
wrote:

> On Thu, Jul 07, 2016 at 12:28:33PM -0700, Eric Rescorla wrote:
> > We've talked several times about designing some sort of TLS delegation
> > mechanism. A few of us got together and put together some initial
> thoughts
> > about the options at:
> > https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
> >
> > The general idea here is to have some mechanism for allowing what
> > are effectively end-entities to issue short-lived credentials that allow
> > other entities to act on their behalf (e.g., for CDN use cases).
> > Comments welcome.
> >
> > In terms of the security analysis, it's obviously very important that
> this
> > mechanism
> > not present a risk to existing TLS servers. The mechanism designed here
> is
> > intended to be future safe in that sense, though perhaps we've missed
> > something.
>
> - I think most browsers ignore KeyUsage presently, allowing the broken RSA
>   key exchange even when KeyUsage does not permit it. And as for server
> side,
>   I don't think many server products check the certificate they try to
> load,
>   just serve it mostly blindly.
>

This is my sense as well. That text in the document probably needs to be
rewritten.



> Also, what is the ServerNameList for? As far as I see, the delegated
> credential structure only contains one name. Or was it supposed to have
> multiple, but there was a typo in definition?
>
> Also why "SignatureScheme algorithm;" ... Doesn't digitally-signed already
> have a algorithm field?
>
> Also, doesn't digitally-signed "eat" all the fields inside? So if you
> want to actually transfer the data, you need the actual fields the second
> time?


All good catches. This was supposed to be more evocative than definitive,
and
we probably would have been better not providing any definition at all :)

-Ekr


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

Re: [TLS] draft-rescorla-tls-subcerts

[Ilari Liusvaara]

On Thu, Jul 07, 2016 at 12:28:33PM -0700, Eric Rescorla wrote:
> We've talked several times about designing some sort of TLS delegation
> mechanism. A few of us got together and put together some initial thoughts
> about the options at:
> https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
> 
> The general idea here is to have some mechanism for allowing what
> are effectively end-entities to issue short-lived credentials that allow
> other entities to act on their behalf (e.g., for CDN use cases).
> Comments welcome.
> 
> In terms of the security analysis, it's obviously very important that this
> mechanism
> not present a risk to existing TLS servers. The mechanism designed here is
> intended to be future safe in that sense, though perhaps we've missed
> something.

- I think most browsers ignore KeyUsage presently, allowing the broken RSA
  key exchange even when KeyUsage does not permit it. And as for server side,
  I don't think many server products check the certificate they try to load,
  just serve it mostly blindly.
- I would definitely use TLS 1.3 signature construct for digitally-signed
  instead of TLS 1.2 one, as it mitigates some attacks (oh, you arlready
  mentioned it below).

Also, instead of extension one way that came to mind would be a new
CertficateType, where Cert#0 is the delgated credential and Cert#1 is
X.509 EE cert, and then comes the normal CA certs. Dunno which would be
better.

I also checked if one could do some funky stuff with credential lifetime
notation to limit the lifetime. Nothing came up (apart for using 16-bit
count in decaseconds (das) only allowing presenting lifetimes up to 7
days, 14 hours, 2 minutes and 30 seconds). :->


Also, what is the ServerNameList for? As far as I see, the delegated
credential structure only contains one name. Or was it supposed to have
multiple, but there was a typo in definition?

Also why "SignatureScheme algorithm;" ... Doesn't digitally-signed already
have a algorithm field?

Also, doesn't digitally-signed "eat" all the fields inside? So if you
want to actually transfer the data, you need the actual fields the second
time?


-Ilari

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