Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

[Andrei Popov]

Our telemetry shows that there are tons of machines (including recently 
manufactured tablets) without persistent clocks (i.e. no battery powering the 
system clock). Such machines indeed boot with date/time in the past millennium; 
they cannot hard-fail on OCSP errors (which greatly reduces the value of OCSP).

If we can avoid creating the same issue for ServerConfiguration, I think we 
should.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Thursday, July 23, 2015 7:02 AM
To: Bill Frantz
Cc: tls@ietf.org
Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date



On Thu, Jul 23, 2015 at 3:38 AM, Bill Frantz 
mailto:fra...@pwpconsult.com>> wrote:
One place we may run into a lot of those clients are on machines like the 
Raspberry Pi and Beaglebone machines. These boards do not include clock chips, 
so the machines must get the current time via NTP every time they power on. If 
there is a problem with NTP, or if the shell script to set the clock is not 
run, then the date will probably be 20 or 30 years back in the last millenium.

That's definitely a problem, but not a specific problem for ServerConfiguration 
since those implementations will also have problems
with certificates (and ironically, will accept ServerConfiguration just fine)

-Ekr

Cheers - Bill

On 7/22/15 at 2:14 PM, bmath...@fb.com (Blake Matheny) 
wrote:
Ahh. I can't tell, the data I have is only clients with very very broken clocks 
who failed validation as a result. My assumption would be that there is a much 
larger number of clients that fit what you described (cert/OCSP check passes, 
but ServerConfiguration would not be). Since I don’t have the data, I can’t say 
that for sure, but anecdotal evidence would indicate that this is the case.

-Blake




On 7/22/15, 10:58 PM, "Eric Rescorla" mailto:e...@rtfm.com>> 
wrote:
I guess what I'm trying to get at is the following:
Are there a lot of people whose clocks are accurate enough that they will be 
able to connect to the
server and check the certificate/OCSP but not accurate enough to process 
ServerConfiguration if it is in absolute time.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
---
Bill Frantz| Ham radio contesting is a| Periwinkle
(408)356-8506  | contact sport.   | 
16345 Englewood Ave
www.pwpconsult.com |  - Ken Widelitz K6LA / VY2TT | 
Los Gatos, CA 95032

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

Re: [TLS] new error alerts?

[Aaron Zauner]

Hi Dave,

Dave Garrett wrote:
> 
>   enum {
>handshake_failure(40),
>unsupported_cipher_suites(71),  /* formerly insufficient_security */
>unsupported_dh_groups(72),  /* new */
>client_authentication_failure(73),  /* new */
>(255)
>} AlertDescription;
> 

I mean I kinda agree that 'insufficent security' is a misleading name,
but as it has been used for decades in TLS I'm a bit hesitant if it's a
good idea to change the name now.

Aaron



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

Re: [TLS] A la carte concerns from IETF 93

[Hubert Kario]

On Wednesday 22 July 2015 16:10:27 Dave Garrett wrote:
> Consensus was my current WIP proposal is not viable, for some of the
> following main reasons:
> 
> 1) cost/benefit analysis doesn't seem to be worth it
> 2) backwards compatibility handling
> 3) some argue harder to implement; others argue easier
>
> cost:
> - change has risks of mistake at various points (implementation, deployment,
> admin, client config, etc.)

and server/client config is a huge cost

vast swaths of web servers are misconfigured; introducing a more complex 
mechanism to server configuration when the existing situation is 
incomprehensible to many administrators won't help (and even many people that 
write the various blog posts about "how to configure SSL [sic] in httpd" 
clearly haven't read openssl ciphers(1) man page)

any changes like this will require new APIs for configuration, that in turn 
means that not only libraries will need to be modified to add support for 
TLS1.3 configuration but applications too - that will slow adoption
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

[Hubert Kario]

On Wednesday 22 July 2015 19:55:58 Blake Matheny wrote:
> One of the topics of discussion at the WG discussion was whether
> ServerConfiguration.expiration_date should be an absolute or relative
> value. Subodh (CC) dug into our production data and found that nearly half
> of the TLS errors we see in production (end user to edge/origin) are due to
> date mismatch. This often occurs when people intentionally reset the clock
> on their phone, or for other various reasons.
 
> Due to the high rate of date mismatch errors we see, my preference would be
> that ServerConfiguration.expiration_date be a relative value instead of an
> absolute one. This provides the client an opportunity to correctly use a
> monotonic (or other similar) clock to minimizing exposure, without losing
> the value of the ServerConfiguration. Using an absolute value means that
> ServerConfiguration, for clients with invalid clocks, would essentially
> never be cacheable. These clients wouldn’t benefit from
> ServerConfiguration.
 
the hint on tickets is already relative, so +1 on relative in server 
configuration too
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] A la carte concerns from IETF 93

[Ilari Liusvaara]

On Wed, Jul 22, 2015 at 04:10:27PM -0400, Dave Garrett wrote:
> Consensus was my current WIP proposal is not viable, for some of the 
> following main reasons:
> 
> 1) cost/benefit analysis doesn't seem to be worth it
> 2) backwards compatibility handling
> 3) some argue harder to implement; others argue easier

IMO, the present situation is mainly problem for:

1) Users: Not having combinations they want (whitness the recent
   proposal for ECDHE_PSK ciphersuites). Sometimes leads to
   suboptimal ciphersuite choices.
2) TLS WG: Processing all the complaints about previous.
3) Admins: Configuring the mess.

What isn't in the list: TLS library authors: Most TLS libraries
have decoding tables (or equivalent) that break down ciphersuite
down to its component parts.


Using strict interpretation of TLS 1.2 rules, adding all the
relevant combinations would be about 100 ciphersuites (haven't
checked how many already exist).

Granted, not all of those are equally important. But that
brings question of what are important and what are not.

Also, if SHA-2 ever fails, defining the replacement ciphersuites
is going to be "fun".



-Ilari

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

Re: [TLS] new error alerts?

[Dave Garrett]

On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote:
> Dave Garrett wrote:
> > 
> >   enum {
> >handshake_failure(40),
> >unsupported_cipher_suites(71),  /* formerly insufficient_security */
> >unsupported_dh_groups(72),  /* new */
> >client_authentication_failure(73),  /* new */
> >(255)
> >} AlertDescription;
> 
> I mean I kinda agree that 'insufficent security' is a misleading name,
> but as it has been used for decades in TLS I'm a bit hesitant if it's a
> good idea to change the name now.

If that's really an issue, then it could just be insufficient_security, 
insufficient_dh_security, & client_authentication_failure. The name isn't as 
important as not producing errors without clear meanings.


Dave

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

[TLS] ban more old crap (was: A la carte concerns from IETF 93)

[Dave Garrett]

On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote:
> vast swaths of web servers are misconfigured; introducing a more complex 
> mechanism to server configuration when the existing situation is 
> incomprehensible to many administrators won't help (and even many people that 
> write the various blog posts about "how to configure SSL [sic] in httpd" 
> clearly haven't read openssl ciphers(1) man page)

We should just get more serious about banning old crap entirely to make 
dangerous misconfiguration impossible for TLS 1.3+ implementations.

Right now, the restrictions section prohibits:
RC4, SSL2/3, & EXPORT/NULL entirely (via min bits)
and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available

How about we stop being fuzzy? I'd like to make it "MUST" use AEAD with all TLS 
1.2+ connections, or abort with a fatal error. Plus, "MUST" use DHE or ECDHE 
for ALL connections, even back to TLS 1.0, or abort with a fatal error. (the 
wrench in this is plain PSK, which should be restricted to resumption within a 
short window; IoT people who want to use intentionally weak security can write 
their own known weak spec)

By the way, even IE6 on XP supports DHE. Windows XP, however, appears to be 
badly configured to only allow it with DSS, because missing combos from the 
cipher suite nonsense happen. If we actually have to care about IE on XP, we 
could state an exception that the only non-PFS cipher suite to be permitted on 
servers for backwards compatibility is TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Also add a requirement that all config provided by the admin must be validated 
to meet the TLS 1.3 requirements and auto-corrected if not, with a warning if 
there's an issue.

This doesn't have to be a mess for admins to sort out.


Dave

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

Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93)

[Viktor Dukhovni]

On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote:

> Right now, the restrictions section prohibits:
> RC4, SSL2/3, & EXPORT/NULL entirely (via min bits)
> and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available

So much for using NULL ciphers for client-server authentication on
loopback interfaces. :-(

Surely, in at least some cases, making it harder to make mistakes
needs to be addressed in toolkit and application interfaces, not
the protocol.  Removing weak algorithms that serve the same use-cases
poorly is fine, but removing non-traditional use-cases is perhaps
too drastic.

> Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0,
> or abort with a fatal error.

Who's going to police the Internet to remove all the legacy services?

> By the way, even IE6 on XP supports DHE.

But not Exchange server 2003, and various Windows-based email gateway
appliances.

> If we actually have to care about IE on
> XP, we could state an exception that the only non-PFS cipher suite to be
> permitted on servers for backwards compatibility is
> TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Exchange 2003 has a broken 3DES implementation.  The only working
ciphersuites are RC4-SHA/RC4-MD5.

And there are surely plenty of legacy system that are neither HTTPS
or email.  It sure sounds like the radical surgery is largely for
HTTPS, and should be implemented in web servers and clients, not
the TLS protocol.

-- 
Viktor.

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

Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93)

[Dave Garrett]

On Thursday, July 23, 2015 12:00:34 pm Viktor Dukhovni wrote:
> On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote:
> > Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0,
> > or abort with a fatal error.
> 
> Who's going to police the Internet to remove all the legacy services?

I'm not proposing a non-PFS diediedie RFC; just that no TLS 1.3+ server should 
ever be willing to negotiate non-PFS. (again, with very limited possible 
exceptions)

I was probably unclear, but I'm primarily talking about server-side here, as it 
was a reply to a server-side issue. Clients SHOULD only be negotiating PFS, but 
I think servers MUST only negotiate PFS.

> Exchange 2003 has a broken 3DES implementation.  The only working
> ciphersuites are RC4-SHA/RC4-MD5.

RC4 already got a diediedie RFC. If their 3DES stays broken, and nothing better 
is available, it's already considered illegitimate to continue using. Also, I 
don't care. It is not the role of the TLS 2015 WG to work around bugs in 
abandoned software from 12 years ago.


Dave

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

Re: [TLS] ban more old crap

[Stephen Farrell]

On 23/07/15 16:43, Dave Garrett wrote:
> We should just get more serious about banning old crap entirely to
> make dangerous misconfiguration impossible for TLS 1.3+
> implementations.
> 
> Right now, the restrictions section prohibits: RC4, SSL2/3, &
> EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS 1.3+
> compatible with TLS 1.2, if available

A suggestion - could we remove mention of anything that
is not a MUST or SHOULD ciphersuite from the TLS1.3 document
and then have someone write a separate draft that adds a
column to the registry where we can mark old crap as
deprecated?

Not sure if it'd work though.

S.

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

Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93)

[Yuhong Bao]

It is Windows Server 2003 SMTP service that has this problem.
There is a hotfix for it.
I had been asking for these fixes to be pushed out and the KB article corrected 
before Windows Server 2003 ended support.

> Date: Thu, 23 Jul 2015 16:00:34 +
> From: ietf-d...@dukhovni.org
> To: tls@ietf.org
> Subject: Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93)
> 
> On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote:
> 
>> Right now, the restrictions section prohibits:
>> RC4, SSL2/3, & EXPORT/NULL entirely (via min bits)
>> and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available
> 
> So much for using NULL ciphers for client-server authentication on
> loopback interfaces. :-(
> 
> Surely, in at least some cases, making it harder to make mistakes
> needs to be addressed in toolkit and application interfaces, not
> the protocol. Removing weak algorithms that serve the same use-cases
> poorly is fine, but removing non-traditional use-cases is perhaps
> too drastic.
> 
>> Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0,
>> or abort with a fatal error.
> 
> Who's going to police the Internet to remove all the legacy services?
> 
>> By the way, even IE6 on XP supports DHE.
> 
> But not Exchange server 2003, and various Windows-based email gateway
> appliances.
> 
>> If we actually have to care about IE on
>> XP, we could state an exception that the only non-PFS cipher suite to be
>> permitted on servers for backwards compatibility is
>> TLS_RSA_WITH_3DES_EDE_CBC_SHA.
> 
> Exchange 2003 has a broken 3DES implementation. The only working
> ciphersuites are RC4-SHA/RC4-MD5.
> 
> And there are surely plenty of legacy system that are neither HTTPS
> or email. It sure sounds like the radical surgery is largely for
> HTTPS, and should be implemented in web servers and clients, not
> the TLS protocol.
> 
> -- 
> Viktor.
> 
> ___
> 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] ban more old crap

[Eric Rescorla]

On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell 
wrote:

>
>
> On 23/07/15 16:43, Dave Garrett wrote:
> > We should just get more serious about banning old crap entirely to
> > make dangerous misconfiguration impossible for TLS 1.3+
> > implementations.
> >
> > Right now, the restrictions section prohibits: RC4, SSL2/3, &
> > EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS 1.3+
> > compatible with TLS 1.2, if available
>
> A suggestion - could we remove mention of anything that
> is not a MUST or SHOULD ciphersuite from the TLS1.3 document
> and then have someone write a separate draft that adds a
> column to the registry where we can mark old crap as
> deprecated?
>
> Not sure if it'd work though.
>

I'm starting to lean towards this. I don't generally think of TLS 1.3 as a
vehicle
for telling people how to configure use of TLS 1.2, and I think it might be
better
to move all that stuff out.

-Ekr


> S.
>
> ___
> 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] ban more old crap

[Hubert Kario]

On Thursday 23 July 2015 18:06:04 Stephen Farrell wrote:
> On 23/07/15 16:43, Dave Garrett wrote:
> > We should just get more serious about banning old crap entirely to
> > make dangerous misconfiguration impossible for TLS 1.3+
> > implementations.
> > 
> > Right now, the restrictions section prohibits: RC4, SSL2/3, &
> > EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS 1.3+
> > compatible with TLS 1.2, if available
> 
> A suggestion - could we remove mention of anything that
> is not a MUST or SHOULD ciphersuite from the TLS1.3 document
> and then have someone write a separate draft that adds a
> column to the registry where we can mark old crap as
> deprecated?
> 
> Not sure if it'd work though.

https://tools.ietf.org/html/rfc7525 lists 4 RECOMMENDED ciphers, 6 if you 
include ECDSA versions

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93)

[Hubert Kario]

On Thursday 23 July 2015 11:43:45 Dave Garrett wrote:
> On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote:
> > vast swaths of web servers are misconfigured; introducing a more complex
> > mechanism to server configuration when the existing situation is
> > incomprehensible to many administrators won't help (and even many people
> > that write the various blog posts about "how to configure SSL [sic] in
> > httpd" clearly haven't read openssl ciphers(1) man page)
> 
> We should just get more serious about banning old crap entirely to make
> dangerous misconfiguration impossible for TLS 1.3+ implementations.

there are valid use cases for both aNULL and eNULL
at the same time 3.5% of Alexa top 1 million will negotiate AECDH, somehow I 
doubt this many use it knowingly when ADH has just 0.2% market share

TLS is a universal protocol, that means that something that is a dangerous 
misconfiguration in one threat model is entirely valid and good configuration 
in other

IoT and cloud computing will create a market for an implementation that is 
compatible with many threat models

> Right now, the restrictions section prohibits:
> RC4, SSL2/3, & EXPORT/NULL entirely (via min bits)
> and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available
> 
> How about we stop being fuzzy? I'd like to make it "MUST" use AEAD with all
> TLS 1.2+ connections, or abort with a fatal error. Plus, "MUST" use DHE or
> ECDHE for ALL connections, even back to TLS 1.0, or abort with a fatal
> error. (the wrench in this is plain PSK, which should be restricted to
> resumption within a short window; IoT people who want to use intentionally
> weak security can write their own known weak spec)

yes, it would make situation better, thing is, nobody would implement this and 
nobody would deploy it (certainly not Red Hat).
People care more for availability of data than for confidentiality or 
integrity.

> By the way, even IE6 on XP supports DHE. Windows XP, however, appears to be
> badly configured to only allow it with DSS, because missing combos from the
> cipher suite nonsense happen. If we actually have to care about IE on XP,
> we could state an exception that the only non-PFS cipher suite to be
> permitted on servers for backwards compatibility is
> TLS_RSA_WITH_3DES_EDE_CBC_SHA.

and that would prevent the server from never selecting DHE+RSA or client 
aborting the connection when server selects DHE+RSA how exactly?

> Also add a requirement that all config provided by the admin must be
> validated to meet the TLS 1.3 requirements and auto-corrected if not, with
> a warning if there's an issue.
> 
> This doesn't have to be a mess for admins to sort out.

but it is, and for histerical reasons it will remain like this

so given choice I prefer my mess to be at least consistent between versions
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

[Subodh Iyengar]

Our data suggests that during successful handshakes the clock skew of mobile 
devices is within a few hours, and is within years for unsuccessful cases. 
Having relative time thus is definitely better from the client's perspective. 

With this however, there is a tradeoff on the server. The expiry time for the 
config is signed into the server config itself. So if the server wants to 
expire its server config in a predictable way it probably needs to resign it 
periodically. This adds some operational issues on the server, for example 
performance, and becomes more operationally challenging in situations where 
there is cryptographic offloading to either a different process or a different 
box. If we can come up with a reasonable solution to the resigning problem, 
then relative time seems superior. 

Cheers,
Subodh Iyengar


From: TLS [tls-boun...@ietf.org] on behalf of Hubert Kario [hka...@redhat.com]
Sent: Thursday, July 23, 2015 4:16 AM
To: tls@ietf.org
Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

On Wednesday 22 July 2015 19:55:58 Blake Matheny wrote:
> One of the topics of discussion at the WG discussion was whether
> ServerConfiguration.expiration_date should be an absolute or relative
> value. Subodh (CC) dug into our production data and found that nearly half
> of the TLS errors we see in production (end user to edge/origin) are due to
> date mismatch. This often occurs when people intentionally reset the clock
> on their phone, or for other various reasons.

> Due to the high rate of date mismatch errors we see, my preference would be
> that ServerConfiguration.expiration_date be a relative value instead of an
> absolute one. This provides the client an opportunity to correctly use a
> monotonic (or other similar) clock to minimizing exposure, without losing
> the value of the ServerConfiguration. Using an absolute value means that
> ServerConfiguration, for clients with invalid clocks, would essentially
> never be cacheable. These clients wouldn’t benefit from
> ServerConfiguration.

the hint on tickets is already relative, so +1 on relative in server
configuration too
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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

Re: [TLS] new error alerts?

[Jeffrey Walton]

On Wed, Jul 22, 2015 at 9:39 PM, Dave Garrett  wrote:
> Hubert Kairo found quite a few more spots in need of explicit error 
> designations, which have been amended into PR #201.
> https://github.com/tlswg/tls13-spec/pull/201
>
> I just noticed one error in the current draft text that was wrong and added a 
> fix for that as well. The Server Hello section said that lack of acceptable 
> group would result in an "insufficient_security" error, which is incorrect. 
> That error is clearly defined to be for lack of acceptable cipher suite. The 
> Negotiated Groups section says lack of acceptable group is a 
> “handshake_failure” error. I changed the text to state the error for suites, 
> as the other is already noted elsewhere. (this change is now in PR #201) This 
> brings up a problem, however: there is no distinct error for lack of group 
> support. The “handshake_failure” is a bit of a catchall, so there's no way 
> for a client to really know what's wrong if this happens. This is also why I 
> don't want to change the definition of the "insufficient_security" error. 
> Clients rely on these being relatively precise in order to show error 
> messages that are hopefully meaningful enough to get them fixed. As such, I'd 
> like to propose adding a new error just for this and renaming the old one to 
> focus precisely on its long defined meaning. While we're at it, a failure of 
> client authentication doesn't have its own error alert code either.
>
>   enum {
>handshake_failure(40),
>unsupported_cipher_suites(71),  /* formerly insufficient_security */
>unsupported_dh_groups(72),  /* new */
>client_authentication_failure(73),  /* new */
>(255)
>} AlertDescription;
>
> Pretty straightforward. Are there any other errors that can't be clearly 
> identified by the returned code? Debugging shouldn't be guesswork. ;)
>
Alert 40 shows up frequently in my debugging experiences. A few things
can cause it. It would be nice to see that one broken out.

Jeff

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

Re: [TLS] ban more old crap

[Dave Garrett]

On Thursday, July 23, 2015 01:10:30 pm Eric Rescorla wrote:
> On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell 
> wrote:
> > A suggestion - could we remove mention of anything that
> > is not a MUST or SHOULD ciphersuite from the TLS1.3 document
> > and then have someone write a separate draft that adds a
> > column to the registry where we can mark old crap as
> > deprecated?
> 
> I'm starting to lean towards this. I don't generally think of TLS 1.3 as a 
> vehicle
> for telling people how to configure use of TLS 1.2, and I think it might be 
> better
> to move all that stuff out.

If we've learned one thing from the past year of high-profile vulnerabilities 
with names and logos, it's that TLS is not really secure if you don't take into 
account its weakest/oldest feature that's still possible. I don't think any 
responsible TLS 1.3 spec can afford to not acknowledge this.

That said, if all you want to move out are things that aren't MUSTs or SHOULDs, 
I don't see a problem with that. (with possibly the exception of a "NOT 
RECOMMENDED" or two, though that's really just a synonym for "SHOULD NOT") What 
would that actually entail? Or, did you just mean to cut out all 
non-MUST/SHOULD cipher suites? I also don't see a problem with that. I just 
updated the list with everything. The full list can go in a separate document 
if we want to just focus on MUST/SHOULD support ciphers in the spec, proper.

Also on the topic of cutting out hunks of text, someone should write up a 
DSS/DSA removal PR. There's quite a bit of text scattered throughout the spec 
to handle it that we don't need anymore.


Dave

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

Re: [TLS] new error alerts?

[Dave Garrett]

On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote:
> I mean I kinda agree that 'insufficent security' is a misleading name,
> but as it has been used for decades in TLS I'm a bit hesitant if it's a
> good idea to change the name now.

Alternate bikesheddy response: what about renaming it to 
"insufficient_cipher_security" and adding a new "insufficient_dh_security"?

That keeps the legacy naming, but modifies it to include actual specific 
meaning, rather than a total replacement.


Dave

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

Re: [TLS] new error alerts?

[Aaron Zauner]

Dave Garrett wrote:
> On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote:
>> I mean I kinda agree that 'insufficent security' is a misleading name,
>> but as it has been used for decades in TLS I'm a bit hesitant if it's a
>> good idea to change the name now.
> 
> Alternate bikesheddy response: what about renaming it to 
> "insufficient_cipher_security" and adding a new "insufficient_dh_security"?
> 
> That keeps the legacy naming, but modifies it to include actual specific 
> meaning, rather than a total replacement.
> 

Fine with that. Now that I think about it again; I'm also fine with the
original proposal. The thing is 'insufficient security' has a nicer ring
to it than 'unsupported XYZ'.

Aaron



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

Re: [TLS] new error alerts?

[Dave Garrett]

On Thursday, July 23, 2015 03:31:06 pm Aaron Zauner wrote:
> Fine with that. Now that I think about it again; I'm also fine with the
> original proposal. The thing is 'insufficient security' has a nicer ring
> to it than 'unsupported XYZ'.

It's wrong, though. If a server rejects a client connection because the server 
only supports RC4 and the client doesn't, the correct error for the server to 
return is "insufficient_security". If you invert the meaning, I guess the 
server has insufficient security, but it's not the same.

If we're ok with a complete change, then I'll just go with the "unsupported_X" 
format as there's already an "unsupported_certificate" and 
"unsupported_extension".

I'll stick a commit for this into my ever growing PR #201 in a bit.


Dave

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

Re: [TLS] new error alerts?

[Aaron Zauner]

Dave Garrett wrote:>
> It's wrong, though. If a server rejects a client connection because the 
> server only supports RC4 and the client doesn't, the correct error for the 
> server to return is "insufficient_security". If you invert the meaning, I 
> guess the server has insufficient security, but it's not the same.
> 

Well that was kinda what I was getting at, yea :)

> If we're ok with a complete change, then I'll just go with the 
> "unsupported_X" format as there's already an "unsupported_certificate" and 
> "unsupported_extension".
> 
> I'll stick a commit for this into my ever growing PR #201 in a bit.
> 

Fine with me - didn't want to bikeshed here.

Aaron



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

Re: [TLS] new error alerts?

[Eric Rescorla]

It's not clear to me that there is consensus that more granular error
codes are a good idea. I'll defer to the chairs on the process question.

-Ekr


On Thu, Jul 23, 2015 at 3:39 AM, Dave Garrett 
wrote:

> Hubert Kairo found quite a few more spots in need of explicit error
> designations, which have been amended into PR #201.
> https://github.com/tlswg/tls13-spec/pull/201
>
> I just noticed one error in the current draft text that was wrong and
> added a fix for that as well. The Server Hello section said that lack of
> acceptable group would result in an "insufficient_security" error, which is
> incorrect. That error is clearly defined to be for lack of acceptable
> cipher suite. The Negotiated Groups section says lack of acceptable group
> is a “handshake_failure” error. I changed the text to state the error for
> suites, as the other is already noted elsewhere. (this change is now in PR
> #201) This brings up a problem, however: there is no distinct error for
> lack of group support. The “handshake_failure” is a bit of a catchall, so
> there's no way for a client to really know what's wrong if this happens.
> This is also why I don't want to change the definition of the
> "insufficient_security" error. Clients rely on these being relatively
> precise in order to show error messages that are hopefully meaningful
> enough to get them fixed. As such, I'd like to propose adding a new error
> just for this and renaming the old one to focus precisely on its long
> defined meaning. While we're at it, a failure of client authentication
> doesn't have its own error alert code either.
>
>   enum {
>handshake_failure(40),
>unsupported_cipher_suites(71),  /* formerly insufficient_security */
>unsupported_dh_groups(72),  /* new */
>client_authentication_failure(73),  /* new */
>(255)
>} AlertDescription;
>
> Pretty straightforward. Are there any other errors that can't be clearly
> identified by the returned code? Debugging shouldn't be guesswork. ;)
>
>
> Dave
> ___
> 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] new error alerts?

[Andrei Popov]

Rather than renaming and otherwise modifying the meaning of the existing 
alerts, would it be better to define new, more granular alerts in 1.3? We can’t 
ascribe new meanings to alerts generated by the code we’ve shipped in the past.

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, July 24, 2015 1:32 AM
To: Dave Garrett
Cc: tls@ietf.org
Subject: Re: [TLS] new error alerts?

It's not clear to me that there is consensus that more granular error
codes are a good idea. I'll defer to the chairs on the process question.

-Ekr


On Thu, Jul 23, 2015 at 3:39 AM, Dave Garrett 
mailto:davemgarr...@gmail.com>> wrote:
Hubert Kairo found quite a few more spots in need of explicit error 
designations, which have been amended into PR #201.
https://github.com/tlswg/tls13-spec/pull/201

I just noticed one error in the current draft text that was wrong and added a 
fix for that as well. The Server Hello section said that lack of acceptable 
group would result in an "insufficient_security" error, which is incorrect. 
That error is clearly defined to be for lack of acceptable cipher suite. The 
Negotiated Groups section says lack of acceptable group is a 
“handshake_failure” error. I changed the text to state the error for suites, as 
the other is already noted elsewhere. (this change is now in PR #201) This 
brings up a problem, however: there is no distinct error for lack of group 
support. The “handshake_failure” is a bit of a catchall, so there's no way for 
a client to really know what's wrong if this happens. This is also why I don't 
want to change the definition of the "insufficient_security" error. Clients 
rely on these being relatively precise in order to show error messages that are 
hopefully meaningful enough to get them fixed. As such, I'd like to propose 
adding a new error just for this and renaming the old one to focus precisely on 
its long defined meaning. While we're at it, a failure of client authentication 
doesn't have its own error alert code either.

  enum {
   handshake_failure(40),
   unsupported_cipher_suites(71),  /* formerly insufficient_security */
   unsupported_dh_groups(72),  /* new */
   client_authentication_failure(73),  /* new */
   (255)
   } AlertDescription;

Pretty straightforward. Are there any other errors that can't be clearly 
identified by the returned code? Debugging shouldn't be guesswork. ;)


Dave
___
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] Commentary on the client authentication presentation slides

[Andrei Popov]

Thanks for the detailed comments, Ilari.

Based on the discussion at the TLS WG meeting, I created a pull request: 
https://github.com/tlswg/tls13-spec/pull/209

> - Mechanism like proposed looks dangerous when combined with HTTP/2.
I believe the same issue already exists in HTTP/1 where multiple requests can 
be in flight at the same time.
The way we handle this in HTTP/1 is by having the server application query the 
HTTP stack for the client cred.
If there's no cred available, the HTTP stack triggers client authentication 
(and the server application waits until the client cred is provided so it can 
authorize the request).

> - Regarding last point about interleaving: Assuming the scheme works
  in 1RTT (and I see no reason for requiring more rounds), you can't
  prevent application_data transmission after certificate_request.
We discussed at the meeting that this restriction cannot be implemented.
Instead, a server may block the processing of any in-flight requests while 
waiting for the client to authenticate (if the server's architecture requires 
this).

> - 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 getting rid of certificate_types in the CertificateRequest. Except 
we may want to use this field when we introduce new certificate types (e.g. 
something like IEEE1609 certs).

> - How does extension_values work? If multiple values for one
  OID are allowed, then the OID/value pair is repeated, once for
  each value?
Multiple values are DER-encoded per RFC that defines the OID that allows 
multiple values.
The idea here is to simply reuse the existing OID-parsing code. A TLS 
implementation (or certificate API) that recognizes the OID in the cert, 
already knows how to parse 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.

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 separate
  connections), especially if dealing with something like web
  environment.
- Regarding last point about interleaving: Assuming the scheme works
  in 1RTT (and I see no reason for requiring more rounds), you can't
  prevent application_data transmission after certificate_request.
  The best that can be done is to require the client to send all
  the authentication-related data in one go.
- The certificate_types field in CertificateRequest is pretty much
  useless, since all supported algorithms are of signature type.
- One can't just remove fields without breaking parse compatiblity,
  but adding field breaks parse compatiblity too, so removing
  field at the same time isn't a problem.
- How does extension_values work? If multiple values for one
  OID are allowed, then the OID/value pair is repeated, once for
  each value?



-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

Re: [TLS] new error alerts?

[Dave Garrett]

On Thursday, July 23, 2015 10:52:59 pm Andrei Popov wrote:
> Rather than renaming and otherwise modifying the meaning of the existing 
> alerts, would it be better to define new, more granular alerts in 1.3? We 
> can’t ascribe new meanings to alerts generated by the code we’ve shipped in 
> the past.

I'm not proposing changing the meaning of existing alerts. At most, the 
Negotiated FF-DH draft would need to be updated/fixed.

I'm proposing renaming "insufficient_security" to "unsupported_cipher_suites", 
which is explicitly what it's been for since TLS 1.0. There isn't a specific 
error defined for lack of a supported group yet. RFC 4492 just says "fatal 
handshake failure alert". The Negotiated FF-DH draft has 
"insufficient_security" for unsupported group. _That_ does change the meaning, 
as previously it was explicitly defined for cipher issues only. What I want is 
to add a new "unsupported_groups" alert to use instead. (both here and there) 
The "client_authentication_failure" alert suggestion is to pull that out of the 
"handshake_failure" catchall.

I just want to clarify the existing alert, not reuse it for a related but 
distinctly different alert, and not lump stuff into a catchall that we can't 
debug. ;)


Dave

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

Re: [TLS] new error alerts?

[Andrei Popov]

> I'm proposing renaming "insufficient_security" to 
> "unsupported_cipher_suites", which is explicitly what it's been for since TLS 
> 1.0.

Not quite. Insufficient_security alert is defined as follows:
" Returned instead of handshake_failure when a negotiation has
   failed specifically because the server requires ciphers more
   secure than those supported by the client.  This message is always
   fatal."

This is a very narrow and specific definition. The server says "I know all the 
cipher suites the client advertises, and consider them too weak". By contrast, 
unsupported_cipher_suites means something like "I don't have a cipher suite in 
common with the client". The latter can happen when the client's cipher suites 
are more secure than the server's.

> What I want is to add a new "unsupported_groups" alert to use instead. (both 
> here and there) The "client_authentication_failure" alert suggestion is to 
> pull that out of the "handshake_failure" catchall.

I have absolutely no problem with the new alerts; my concern is about 
redefining existing alerts (and, for that matter, redefining existing cipher 
suites:)).

Cheers,

Andrei

-Original Message-
From: Dave Garrett [mailto:davemgarr...@gmail.com] 
Sent: Friday, July 24, 2015 7:09 AM
To: Andrei Popov; Eric Rescorla
Cc: tls@ietf.org
Subject: Re: [TLS] new error alerts?

On Thursday, July 23, 2015 10:52:59 pm Andrei Popov wrote:
> Rather than renaming and otherwise modifying the meaning of the existing 
> alerts, would it be better to define new, more granular alerts in 1.3? We 
> can’t ascribe new meanings to alerts generated by the code we’ve shipped in 
> the past.

I'm not proposing changing the meaning of existing alerts. At most, the 
Negotiated FF-DH draft would need to be updated/fixed.

I'm proposing renaming "insufficient_security" to "unsupported_cipher_suites", 
which is explicitly what it's been for since TLS 1.0. There isn't a specific 
error defined for lack of a supported group yet. RFC 4492 just says "fatal 
handshake failure alert". The Negotiated FF-DH draft has 
"insufficient_security" for unsupported group. _That_ does change the meaning, 
as previously it was explicitly defined for cipher issues only. What I want is 
to add a new "unsupported_groups" alert to use instead. (both here and there) 
The "client_authentication_failure" alert suggestion is to pull that out of the 
"handshake_failure" catchall.

I just want to clarify the existing alert, not reuse it for a related but 
distinctly different alert, and not lump stuff into a catchall that we can't 
debug. ;)


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

Re: [TLS] Commentary on the client authentication presentation slides

[Ilari Liusvaara]

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 getting rid of certificate_types in the
> CertificateRequest. Except we may want to use this field when we
> introduce new certificate types (e.g. something like IEEE1609 certs).

Don't confuse signature_algorithms extension and
supported_signature_algorithms field of CertificateRequest. Those two
carry similar tasks in opposite directions, except that ssa is REQUIRED
with signature certs.

There are seemingly no defaults for SSA, so it has to be non-empty
for signature certs to work at all.

And all present types of TLS 1.3 key exchange can only use signature
certs.

As for IEEE1609 certs, those are negotiated via certificate format
negotiation, which is entierely separate mechanism (described in
RFC 7250), not involving CertificateRequest message at all.


-Ilari

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

Re: [TLS] ban more old crap

[Ilari Liusvaara]

On Thu, Jul 23, 2015 at 06:06:04PM +0100, Stephen Farrell wrote:
> 
> 
> On 23/07/15 16:43, Dave Garrett wrote:
> > We should just get more serious about banning old crap entirely to
> > make dangerous misconfiguration impossible for TLS 1.3+
> > implementations.
> > 
> > Right now, the restrictions section prohibits: RC4, SSL2/3, &
> > EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS 1.3+
> > compatible with TLS 1.2, if available
> 
> A suggestion - could we remove mention of anything that
> is not a MUST or SHOULD ciphersuite from the TLS1.3 document
> and then have someone write a separate draft that adds a
> column to the registry where we can mark old crap as
> deprecated?

Checked the ciphersuite registry. Of 316 negotiable ciphers,
marking everything that doesn't work in TLS 1.3 or is DSS
ciphersuite (nobody uses that) would leave 52 ciphersuites
undeprecated.

Unfortunately, completing the various sets could add up to
31 new ciphersuites... :-/


Flags:
A => Anonymous (6+8)
D => Dubious use (6+1). I guess IoT devices don't appreciate FFDHE.
F => FFDHE (26+3)
I => IoT foucus (18+12)
N => New signature type (0+11), merging would take bending TLS 1.2 rules.
R => RSA signature type with ECDHE (6+1)
V => Vanity (24+8)

The 52 are:
--F-- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
--F-- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
A-F-- TLS_DH_anon_WITH_AES_128_GCM_SHA256
A-F-- TLS_DH_anon_WITH_AES_256_GCM_SHA384
- TLS_PSK_WITH_AES_128_GCM_SHA256
- TLS_PSK_WITH_AES_256_GCM_SHA384
-DFI- TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
-DFI- TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
R TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
R TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
--FV- TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256
--FV- TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384
A-FV- TLS_DH_anon_WITH_ARIA_128_GCM_SHA256
A-FV- TLS_DH_anon_WITH_ARIA_256_GCM_SHA384
---V- TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256
---V- TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384
---VR TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256
---VR TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384
---V- TLS_PSK_WITH_ARIA_128_GCM_SHA256
---V- TLS_PSK_WITH_ARIA_256_GCM_SHA384
-DFV- TLS_DHE_PSK_WITH_ARIA_128_GCM_SHA256
-DFV- TLS_DHE_PSK_WITH_ARIA_256_GCM_SHA384
--FV- TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
--FV- TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
A-FV- TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256
A-FV- TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384
---V- TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
---V- TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
---VR TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
---VR TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
---V- TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256
---V- TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384
-DFV- TLS_DHE_PSK_WITH_CAMELLIA_128_GCM_SHA256
-DFV- TLS_DHE_PSK_WITH_CAMELLIA_256_GCM_SHA384
-DFI- TLS_DHE_RSA_WITH_AES_128_CCM
-DFI- TLS_DHE_RSA_WITH_AES_256_CCM
-DFI- TLS_DHE_RSA_WITH_AES_128_CCM_8
-DFI- TLS_DHE_RSA_WITH_AES_256_CCM_8
---I- TLS_PSK_WITH_AES_128_CCM
---I- TLS_PSK_WITH_AES_256_CCM
-DFI- TLS_DHE_PSK_WITH_AES_128_CCM
-DFI- TLS_DHE_PSK_WITH_AES_256_CCM
---I- TLS_PSK_WITH_AES_128_CCM_8
---I- TLS_PSK_WITH_AES_256_CCM_8
-DFI- TLS_PSK_DHE_WITH_AES_128_CCM_8
-DFI- TLS_PSK_DHE_WITH_AES_256_CCM_8
---I- TLS_ECDHE_ECDSA_WITH_AES_128_CCM
---I- TLS_ECDHE_ECDSA_WITH_AES_256_CCM
---I- TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
---I- TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8

And the new 31 would be:
R TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
--F-- TLS_DHE_RSA_WITH_CHACHA20_POLY1305
- TLS_PSK_WITH_CHACHA20_POLY1305
---I- TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305
-DFI- TLS_DHE_PSK_WITH_CHACHA20_POLY1305
---I- TLS_ECDHE_PSK_WITH_AES_128_GCM
---I- TLS_ECDHE_PSK_WITH_AES_256_GCM
---I- TLS_ECDHE_PSK_WITH_AES_128_CCM_8
---I- TLS_ECDHE_PSK_WITH_AES_256_CCM_8
---I- TLS_ECDHE_PSK_WITH_AES_128_CCM
---I- TLS_ECDHE_PSK_WITH_AES_256_CCM
A TLS_ECDH_anon_WITH_AES_128_GCM_SHA256
A TLS_ECDH_anon_WITH_AES_256_GCM_SHA384
A--V- TLS_ECDH_anon_WITH_ARIA_128_GCM_SHA256
A--V- TLS_ECDH_anon_WITH_ARIA_256_GCM_SHA384
A--V- TLS_ECDH_anon_WITH_CAMELLIA_128_GCM_SHA256
A--V- TLS_ECDH_anon_WITH_CAMELLIA_256_GCM_SHA384
A TLS_ECDH_anon_WITH_CHACHA20_POLY1305
A-F-- TLS_DH_anon_WITH_CHACHA20_POLY1305
N TLS_ECDHE_ECIDSA_WITH_AES_128_GCM_SHA256
N TLS_ECDHE_ECIDSA_WITH_AES_256_GCM_SHA384
---VN TLS_ECDHE_ECIDSA_WITH_ARIA_128_GCM_SHA256
---VN TLS_ECDHE_ECIDSA_WITH_ARIA_256_GCM_SHA384
---VN TLS_ECDHE_ECIDSA_WITH_CAMELLIA_128_GCM_SHA256
---VN TLS_ECDHE_ECIDSA_WITH_CAMELLIA_256_GCM_SHA384
---IN TLS_ECDHE_ECIDSA_WITH_AES_128_CCM
---IN TLS_ECDHE_ECIDSA_WITH_AES_256_CCM
---IN TLS_ECDHE_ECIDSA_WITH_AES_128_CCM_8
---IN TLS_ECDHE_ECIDSA_WITH_AES_256_CCM_8
N TLS_ECDHE_ECIDSA_WITH_CHACHA20_POLY1305



-Ilari

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

Re: [TLS] Commentary on the client authentication presentation slides

[Andrei Popov]

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 on the client authentication presentation slides

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 getting rid of certificate_types in the 
> CertificateRequest. Except we may want to use this field when we 
> introduce new certificate types (e.g. something like IEEE1609 certs).

Don't confuse signature_algorithms extension and supported_signature_algorithms 
field of CertificateRequest. Those two carry similar tasks in opposite 
directions, except that ssa is REQUIRED with signature certs.

There are seemingly no defaults for SSA, so it has to be non-empty for 
signature certs to work at all.

And all present types of TLS 1.3 key exchange can only use signature certs.

As for IEEE1609 certs, those are negotiated via certificate format negotiation, 
which is entierely separate mechanism (described in RFC 7250), not involving 
CertificateRequest message at all.


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