Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Martin Thomson]

On Wed, May 30, 2018 at 2:53 PM Andrey Jivsov  wrote:
> The quoted text quoted is old. The need to upgrade TLS 1.2 code if I
> support TLS 1.3 is new.

No, I'm certain we had that discussion too.

> I am curious about the scenarios when is this upgrade of TLS 1.2 to PSS
> will take place?

When people deploy TLS 1.3.  Which is happening already.  You can avoid the
need as a server because a client willing to do TLS 1.2 will probably offer
RSASSA PKCS#1 v1.5 and you can rely on that being there.  But yeah, clients
are going to have to suck it up.  Here's the text, which I think is pretty
clear:
"
Implementations that advertise support for RSASSA-PSS (which is mandatory
in TLS 1.3), MUST be prepared to accept a signature using that scheme even
when TLS 1.2 is negotiated. "

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

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Andrey Jivsov]

On 05/29/2018 06:17 PM, Martin Thomson wrote:
> On Wed, May 30, 2018 at 7:20 AM Andrey Jivsov  wrote:
>> The issue here is that some hardware devices don't implement RSA CRT
>> method with PSS, because they hard-wide RSA, legacy padding, and CRT
>> method in one operation. RSA PSS can still be done, but only via a
>> general modexp operation, which will be ~2x shower. Therefore, in these
>> scenarios PSS incurs 2x performance penalty.
> 
> I'm fairly certain that we've had this discussion before.  What is new?
> 

The quoted text quoted is old. The need to upgrade TLS 1.2 code if I
support TLS 1.3 is new.

I am curious about the scenarios when is this upgrade of TLS 1.2 to PSS
will take place?

- This upgrade of TLS 1.2 can only be done by servers that support TLS 1.3.
- TLS 1.2 clients won't advertise TLS 1.3 Signature Algorithm IDs; only
TLS 1.3 clients will have e.g. rsa_pss_rsae_sha256 and others in
signature_algorithms.

Therefore, TLS 1.3 should get negotiated between these peers.

The relevant paragraph from the TLS 1.3 draft seems to add uncertainty
in unexplained cases when TLS 1.3 server decides to drop the negotiated
version to TLS 1.2. What problem does this paragraph try to solve?

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

[TLS] Publication has been requested for draft-ietf-tls-tls13-vectors-05

[Sean Turner]

Sean Turner has requested publication of draft-ietf-tls-tls13-vectors-05 as 
Informational on behalf of the TLS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/

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

[TLS] I-D Action: draft-ietf-tls-tls13-vectors-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : Example Handshake Traces for TLS 1.3
Author  : Martin Thomson
Filename: draft-ietf-tls-tls13-vectors-05.txt
Pages   : 60
Date: 2018-05-29

Abstract:
   Examples of TLS 1.3 handshakes are shown.  Private keys and inputs
   are provided so that these handshakes might be reproduced.
   Intermediate values, including secrets, traffic keys and ivs are
   shown so that implementations might be checked incrementally against
   these values.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-05
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors

[Martin Thomson]

Ack, that makes it easier for me :)
On Wed, May 30, 2018 at 11:22 AM Sean Turner  wrote:

> I think changing the Intended Status is all we’re looking.

> spt

> > On May 29, 2018, at 21:05, Martin Thomson 
wrote:
> >
> > The thought occurs, do you want a version with the final version number
in
> > it?  I see that TLS 1.3 is in front of the RFC editor right now, so I
don't
> > anticipate any changes and changing the examples creates a lot of churn
> > (check out the diffs on this draft to get an idea).
> > On Wed, May 30, 2018 at 12:35 AM Sean Turner  wrote:
> >
> >
> >
> >>> On May 8, 2018, at 20:30, Martin Thomson 
> > wrote:
> >>>
> >>> On Wed, May 9, 2018 at 2:56 AM Salz, Rich  wrote:
>  I dislike standard, and am fine with Informational or BCP.
> >>>
> >>> Agree regarding standard.
> >>>
> >>> I don't understand why BCP would be used for this.  Besides, we
probably
> >>> don't want to enshrine some of the choices we made in NSS as "best
> >>> practice".  I'm not saying that those choices aren't defensible, but
> > that
> >>> might be going too far.
> >
> >> Since this draft is really about “examples” (i.e., it’s just for
> > illustration), I’m going to suggest that Martin go ahead and merge the
> > following PR that I submitted changing the intended status:
> >> https://github.com/tlswg/draft-ietf-tls-tls13-vectors/pull/6
> >
> >> Once a new version is spun, I’ll push the draft toward Ben.
> >
> >> spt

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

Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors

[Sean Turner]

I think changing the Intended Status is all we’re looking.

spt

> On May 29, 2018, at 21:05, Martin Thomson  wrote:
> 
> The thought occurs, do you want a version with the final version number in
> it?  I see that TLS 1.3 is in front of the RFC editor right now, so I don't
> anticipate any changes and changing the examples creates a lot of churn
> (check out the diffs on this draft to get an idea).
> On Wed, May 30, 2018 at 12:35 AM Sean Turner  wrote:
> 
> 
> 
>>> On May 8, 2018, at 20:30, Martin Thomson 
> wrote:
>>> 
>>> On Wed, May 9, 2018 at 2:56 AM Salz, Rich  wrote:
 I dislike standard, and am fine with Informational or BCP.
>>> 
>>> Agree regarding standard.
>>> 
>>> I don't understand why BCP would be used for this.  Besides, we probably
>>> don't want to enshrine some of the choices we made in NSS as "best
>>> practice".  I'm not saying that those choices aren't defensible, but
> that
>>> might be going too far.
> 
>> Since this draft is really about “examples” (i.e., it’s just for
> illustration), I’m going to suggest that Martin go ahead and merge the
> following PR that I submitted changing the intended status:
>> https://github.com/tlswg/draft-ietf-tls-tls13-vectors/pull/6
> 
>> Once a new version is spun, I’ll push the draft toward Ben.
> 
>> spt

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

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Martin Thomson]

On Wed, May 30, 2018 at 7:20 AM Andrey Jivsov  wrote:
> The issue here is that some hardware devices don't implement RSA CRT
> method with PSS, because they hard-wide RSA, legacy padding, and CRT
> method in one operation. RSA PSS can still be done, but only via a
> general modexp operation, which will be ~2x shower. Therefore, in these
> scenarios PSS incurs 2x performance penalty.

I'm fairly certain that we've had this discussion before.  What is new?

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

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

[Jeffrey Walton]

On Tue, May 29, 2018 at 4:21 PM, Salz, Rich
 wrote:
>>There's a tradeoff between respecting the official allocation processes
> and avoiding real-world breakage.  I think we can all make our own 
> assessments
> on the former, but for the latter, all the evidence we have so far is a 
> claim
> from Peter that there exists software that hardcodes this number, with no
> indication of scale of deployment or ease of updating such software.
>
> Peter tried very hard to play by all the rules, whether they were enshrined 
> in formal documents, or "just" decisions by WG chairs, and everything 
> in-between.
>
> Peter says the number is in use.
>
> I believe him.
>
> Give him the damn number.

+1.

I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers
working group for their smart locks last year. I have no idea how much
of the code they are going to reuse (if any at all).

Jeff

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

Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors

[Martin Thomson]

The thought occurs, do you want a version with the final version number in
it?  I see that TLS 1.3 is in front of the RFC editor right now, so I don't
anticipate any changes and changing the examples creates a lot of churn
(check out the diffs on this draft to get an idea).
On Wed, May 30, 2018 at 12:35 AM Sean Turner  wrote:



> > On May 8, 2018, at 20:30, Martin Thomson 
wrote:
> >
> > On Wed, May 9, 2018 at 2:56 AM Salz, Rich  wrote:
> >> I dislike standard, and am fine with Informational or BCP.
> >
> > Agree regarding standard.
> >
> > I don't understand why BCP would be used for this.  Besides, we probably
> > don't want to enshrine some of the choices we made in NSS as "best
> > practice".  I'm not saying that those choices aren't defensible, but
that
> > might be going too far.

> Since this draft is really about “examples” (i.e., it’s just for
illustration), I’m going to suggest that Martin go ahead and merge the
following PR that I submitted changing the intended status:
> https://github.com/tlswg/draft-ietf-tls-tls13-vectors/pull/6

> Once a new version is spun, I’ll push the draft toward Ben.

> spt

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

[TLS] Protocol Action: 'Record Size Limit Extension for Transport Layer Security (TLS)' to Proposed Standard (draft-ietf-tls-record-limit-03.txt)

[The IESG]

The IESG has approved the following document:
- 'Record Size Limit Extension for Transport Layer Security (TLS)'
  (draft-ietf-tls-record-limit-03.txt) as Proposed Standard

This document is the product of the Transport Layer Security Working Group.

The IESG contact persons are Benjamin Kaduk and Eric Rescorla.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/





Technical Summary

This draft defines a TLS extension to negotiate the maximum size of protected 
records that each peers sends.
This mechanism replaces the maximum fragment length extension defined in RFC 
6066.
It’s standards track because it updates RFC 6066, which is a Proposed Standard.

Working Group Summary

The draft was very well received by the WG, resulting in minimal, minor 
comments.
Unlike other TLS-related topics, this WG settled on a solution quickly and 
consensus was very easily found.

Document Quality

This document received careful review from several participants, including 
pointing out
some subtle edge cases and differences between TLS 1.2 and TLS 1.3 that got 
resolved in the
document.

Personnel

Sean Turner is the document shepherd.
Benjamin Kaduk is the responsible Area Director.



RFC Editor Note

  Two late-breaking changes, both in Section 1:

OLD
   Implementing Transport Layer Security (TLS) [TLS] or Datagram TLS
   (DTLS) [DTLS] constrained devices can be challenging.  However,

NEW
   Implementing Transport Layer Security (TLS) [TLS] or Datagram TLS
   (DTLS) [DTLS] for constrained devices can be challenging.  However,

OLD
   authenticated data until the entire record is present.  Incremental
   processing of records could expose endpoints to the risk of forged
   data.

NEW
   authenticated data until the entire record is present.  Incremental
   processing of records exposes endpoints to the risk of forged
   data.

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

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Andrey Jivsov]

On 05/29/2018 01:58 PM, David Benjamin wrote:
> On Tue, May 29, 2018 at 4:26 PM Andrey Jivsov  > wrote:
> 
> On 05/29/2018 01:07 PM, David Benjamin wrote:
> > I'm not sure I follow this. So, in this scenario, you are the client.
> > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS
> > 1.3, and this is fine. You are able to verify RSA-PSS signatures from
> > the server at TLS 1.3.
> >
> > At the same time, you still talk to some TLS 1.2 servers, so you
> may get
> > a response from them. As TLS 1.2 and TLS 1.3 use the same signature
> > algorithms negotiation, that same ClientHello obligates your client
> > (newly updated to support TLS 1.3) to also verify RSA-PSS signatures
> > from TLS 1.2. But this causes troubles somehow.
> >
> > I'm confused how a client would have an RSA-PSS function available at
> > one version, but not the other. Or am I misunderstanding your
> situation?
> 
> There is a need to upgrade TLS 1.2 stack, just because one can now
> negotiate TLS 1.3.
> 
> 
> I think this came up on the list earlier which way to go here, and folks
> seemed to generally prefer this one. In our implementation, we unified
> the TLS 1.2 and TLS 1.3 signature logic which made things simpler
> overall. I think this was true for most folks.
>  
> 
> Does this "upgrade" to TLS 1.2 extends to client authentication? Then
> this adds more work.
> 
> 
> There can be a performance penalty with RSA-PSS v.s. RSA legacy and more
> issues when private keys are used in client authentication (because e.g.
> they are HSM keys).
> 
> 
> The client authentication scenario seems unrelated to me. In both TLS
> 1.2 and TLS 1.3, there is no relation between the client's advertised
> signature algorithm list (which is the algorithms it will *accept* from
> the server) and the client's signing preferences (which control the
> CertificateVerify it will *send*). The latter is never even sent over
> the wire.
> 
> As a client, you get to choose which signature algorithm you use.
> Offering RSA-PSS to the server for its TLS 1.2 ServerKeyExchange does
> not obligate you to select it in your TLS 1.2 CertificateVerify. You
> select out of what the server offered in CertificateRequest. This code
> point allocation means the server *may* offer RSA-PSS and you *may*
> select it if offered. But if that is difficult for whatever reason, you
> also can still select PKCS#1 if the server offers it. (Of course, the
> server may offer you only things you can't handle, but that's not a new
> concern.)

OK. We don't know, though, what will happen in practice with TLS 1.2
CertificateRequest if the server upgraded TLS 1.2 ServerKeyExchange.
Will it be more likely that the choices in CertificateRequest will be
narrower?

> 
> Chrome does just that. Our verify preferences include RSA-PSS, but our
> signing preferences when configured for client certificates are
> separate, precisely because of issues with smartcards and the like.
> 
> As for the performance penalty, I think it was clearly the WG's
> consensus that the benefits of migrating to PSS outweighed the entropy
> draw and hash operations that PSS takes.

The issue here is that some hardware devices don't implement RSA CRT
method with PSS, because they hard-wide RSA, legacy padding, and CRT
method in one operation. RSA PSS can still be done, but only via a
general modexp operation, which will be ~2x shower. Therefore, in these
scenarios PSS incurs 2x performance penalty.

( Maybe RSA verification should be done on CPU, but this will require
changes to TLS 1.2 code. )

The limitations are similar to what you wrote about smartcards. There
are some odd hardware limitations. That hardware was just fine years ago
with TLS 1.2.

Higher entropy consumption is negligible here.

>  
> 
> >
> > On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov  
> > >> wrote:
> >
> >     On 05/29/2018 12:42 PM, Benjamin Kaduk wrote:
> >     > On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote:
> >     >> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote:
> >     >>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote:
> >      Greetings.
> >     
> >      TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells
> that if
> >     a client
> >      wants to negotiate TLS 1.3, it must support an upgraded (and
> >      incompatible) version of TLS 1.2, the one that changes
> RFC 5246
> >     to allow
> >      RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.
> >     
> >      You might recall that the possibility to negotiate
> between PSS and
> >      RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed
> >     for X.509
> >      signatures, was 

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Benjamin Kaduk]

On Tue, May 29, 2018 at 01:26:27PM -0700, Andrey Jivsov wrote:
> On 05/29/2018 01:07 PM, David Benjamin wrote:
> > I'm not sure I follow this. So, in this scenario, you are the client.
> > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS
> > 1.3, and this is fine. You are able to verify RSA-PSS signatures from
> > the server at TLS 1.3.
> > 
> > At the same time, you still talk to some TLS 1.2 servers, so you may get
> > a response from them. As TLS 1.2 and TLS 1.3 use the same signature
> > algorithms negotiation, that same ClientHello obligates your client
> > (newly updated to support TLS 1.3) to also verify RSA-PSS signatures
> > from TLS 1.2. But this causes troubles somehow.
> > 
> > I'm confused how a client would have an RSA-PSS function available at
> > one version, but not the other. Or am I misunderstanding your situation?
> 
> There is a need to upgrade TLS 1.2 stack, just because one can now
> negotiate TLS 1.3.
> 
> Does this "upgrade" to TLS 1.2 extends to client authentication? Then
> this adds more work.

In short: no.  CertificateRequest/CertificateVerify have a separate 
signature+hash
negotiation from the initial handshake, and the server is highly unlikely
to only list the new signature schemes.  (And I think you could decline the
authentication in that case anyway, but didn't double-check.)

The answer could also be "yes" in that if both sides *want* to, it can be done
for client authentication, but in your case you don't want to and are not
obligated to do so.

-Ben

> There can be a performance penalty with RSA-PSS v.s. RSA legacy and more
> issues when private keys are used in client authentication (because e.g.
> they are HSM keys).

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

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[David Benjamin]

On Tue, May 29, 2018 at 4:26 PM Andrey Jivsov  wrote:

> On 05/29/2018 01:07 PM, David Benjamin wrote:
> > I'm not sure I follow this. So, in this scenario, you are the client.
> > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS
> > 1.3, and this is fine. You are able to verify RSA-PSS signatures from
> > the server at TLS 1.3.
> >
> > At the same time, you still talk to some TLS 1.2 servers, so you may get
> > a response from them. As TLS 1.2 and TLS 1.3 use the same signature
> > algorithms negotiation, that same ClientHello obligates your client
> > (newly updated to support TLS 1.3) to also verify RSA-PSS signatures
> > from TLS 1.2. But this causes troubles somehow.
> >
> > I'm confused how a client would have an RSA-PSS function available at
> > one version, but not the other. Or am I misunderstanding your situation?
>
> There is a need to upgrade TLS 1.2 stack, just because one can now
> negotiate TLS 1.3.
>

I think this came up on the list earlier which way to go here, and folks
seemed to generally prefer this one. In our implementation, we unified the
TLS 1.2 and TLS 1.3 signature logic which made things simpler overall. I
think this was true for most folks.


> Does this "upgrade" to TLS 1.2 extends to client authentication? Then
> this adds more work.
>

There can be a performance penalty with RSA-PSS v.s. RSA legacy and more
> issues when private keys are used in client authentication (because e.g.
> they are HSM keys).
>

The client authentication scenario seems unrelated to me. In both TLS 1.2
and TLS 1.3, there is no relation between the client's advertised signature
algorithm list (which is the algorithms it will *accept* from the server)
and the client's signing preferences (which control the CertificateVerify
it will *send*). The latter is never even sent over the wire.

As a client, you get to choose which signature algorithm you use. Offering
RSA-PSS to the server for its TLS 1.2 ServerKeyExchange does not obligate
you to select it in your TLS 1.2 CertificateVerify. You select out of what
the server offered in CertificateRequest. This code point allocation means
the server *may* offer RSA-PSS and you *may* select it if offered. But if
that is difficult for whatever reason, you also can still select PKCS#1 if
the server offers it. (Of course, the server may offer you only things you
can't handle, but that's not a new concern.)

Chrome does just that. Our verify preferences include RSA-PSS, but our
signing preferences when configured for client certificates are separate,
precisely because of issues with smartcards and the like.

As for the performance penalty, I think it was clearly the WG's consensus
that the benefits of migrating to PSS outweighed the entropy draw and hash
operations that PSS takes.


> >
> > On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov  > > wrote:
> >
> > On 05/29/2018 12:42 PM, Benjamin Kaduk wrote:
> > > On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote:
> > >> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote:
> > >>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote:
> >  Greetings.
> > 
> >  TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if
> > a client
> >  wants to negotiate TLS 1.3, it must support an upgraded (and
> >  incompatible) version of TLS 1.2, the one that changes RFC 5246
> > to allow
> >  RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.
> > 
> >  You might recall that the possibility to negotiate between PSS
> and
> >  RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed
> > for X.509
> >  signatures, was discussed on the mailing list. The WG decision
> > then was
> >  to hard-wire PSS in the TLS 1.3 handshake.
> > 
> >  I don't recall any discussion on going further than this, all
> > the way to
> >  changing the 10-year old TLS 1.2.
> > 
> >  Unfortunately, our products have issues with PSS beyond our
> > control. The
> >  only solution left to avoid receiving PSS with TLS 1.2 is to
> never
> >  negotiate TLS 1.3 as a client. Another solution is insecure
> > fallback,
> >  but we presently don't do this.
> > 
> >  Is my reading of the situation correct? Thank you.
> > >>>
> > >>> Sounds like it:
> > >>>
> > >>>RSASSA-PKCS1-v1_5 algorithms  Indicates a signature algorithm
> > using
> > >>>   RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash
> > algorithm
> > >>>   as defined in [SHS].  These values refer solely to
> signatures
> > >>>   which appear in certificates (see Section 4.4.2.2) and are
> not
> > >>>   defined for use in signed TLS handshake messages, although
> > they
> > >>>   MAY appear in "signature_algorithms" and
> > >>>   

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

[Salz, Rich]

>There's a tradeoff between respecting the official allocation processes
and avoiding real-world breakage.  I think we can all make our own 
assessments
on the former, but for the latter, all the evidence we have so far is a 
claim
from Peter that there exists software that hardcodes this number, with no
indication of scale of deployment or ease of updating such software.
  
Peter tried very hard to play by all the rules, whether they were enshrined in 
formal documents, or "just" decisions by WG chairs, and everything in-between.

Peter says the number is in use.

I believe him.

Give him the damn number.


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

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

[Benjamin Kaduk]

On Sun, May 27, 2018 at 09:56:30AM -0700, Eric Rescorla wrote:
> Well, this is a bit premature because the document hasn't actually been
> published, just approved.

It's also not properly addressed -- regular allocations under the
"specification required" policy go directly to IANA, whereas RFC 7120 early
allocations it is the WG chairs and ADs that need to judge the level of
interest in the community.

> In any case, I don't think we should assign code point 26 to this
> extension. I recognize that you have existing implementations that happen
> to use it, but that's a result of the unfortunate decision to squat on a
> code point which was right in the way of near future assignments, and those
> implementations can change to the new code point. Of course, it might be
> useful to add a note to implementations of the compression draft as well.

There's a tradeoff between respecting the official allocation processes
and avoiding real-world breakage.  I think we can all make our own assessments
on the former, but for the latter, all the evidence we have so far is a claim
from Peter that there exists software that hardcodes this number, with no
indication of scale of deployment or ease of updating such software.

-Ben

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

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[David Benjamin]

I'm not sure I follow this. So, in this scenario, you are the client. You
wish to support TLS 1.3, which requires supporting RSA-PSS in TLS 1.3, and
this is fine. You are able to verify RSA-PSS signatures from the server at
TLS 1.3.

At the same time, you still talk to some TLS 1.2 servers, so you may get a
response from them. As TLS 1.2 and TLS 1.3 use the same signature
algorithms negotiation, that same ClientHello obligates your client (newly
updated to support TLS 1.3) to also verify RSA-PSS signatures from TLS 1.2.
But this causes troubles somehow.

I'm confused how a client would have an RSA-PSS function available at one
version, but not the other. Or am I misunderstanding your situation?

On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov  wrote:

> On 05/29/2018 12:42 PM, Benjamin Kaduk wrote:
> > On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote:
> >> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote:
> >>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote:
>  Greetings.
> 
>  TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a
> client
>  wants to negotiate TLS 1.3, it must support an upgraded (and
>  incompatible) version of TLS 1.2, the one that changes RFC 5246 to
> allow
>  RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.
> 
>  You might recall that the possibility to negotiate between PSS and
>  RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for
> X.509
>  signatures, was discussed on the mailing list. The WG decision then
> was
>  to hard-wire PSS in the TLS 1.3 handshake.
> 
>  I don't recall any discussion on going further than this, all the way
> to
>  changing the 10-year old TLS 1.2.
> 
>  Unfortunately, our products have issues with PSS beyond our control.
> The
>  only solution left to avoid receiving PSS with TLS 1.2 is to never
>  negotiate TLS 1.3 as a client. Another solution is insecure fallback,
>  but we presently don't do this.
> 
>  Is my reading of the situation correct? Thank you.
> >>>
> >>> Sounds like it:
> >>>
> >>>RSASSA-PKCS1-v1_5 algorithms  Indicates a signature algorithm using
> >>>   RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm
> >>>   as defined in [SHS].  These values refer solely to signatures
> >>>   which appear in certificates (see Section 4.4.2.2) and are not
> >>>   defined for use in signed TLS handshake messages, although they
> >>>   MAY appear in "signature_algorithms" and
> >>>   "signature_algorithms_cert" for backward compatibility with TLS
> >>>   1.2,
> >>>
> >>> -Ben
> >>>
> >>
> >> I was referring to
> >>>
> >>>-  Implementations that advertise support for RSASSA-PSS (which is
> >>>   mandatory in TLS 1.3), MUST be prepared to accept a signature
> >>>   using that scheme even when TLS 1.2 is negotiated.  In TLS 1.2,
> >>>   RSASSA-PSS is used with RSA cipher suites.
> >>
> >> I am OK with what you quoted. What I just quoted represents a
> >> significant change in behavior in TLS 1.2 and there is no way to opt out
> >> of this change to TLS 1.2.
> >
> > Ah, I misread your original message, but all is clear now.
> >
> >> I will add that I've seen this behavior by servers already, even when
> >> client doesn't advertise TLS 1.3. Just the fact of including some 08 xx
> >> IDs in signature_algorithms in ClientHello, without protocol_version
> >> extension, gets the TLS 1.2 upgraded to RSA-PSS.
> >>
> >> IMO this paragraph should be removed. Those that want PSS in the
> >> handshake should negotiate TLS 1.3. Preservation of current behavior of
> >> TLS 1.2 is important, at least as an option.
> >
> > First off, it's basically too late to make substantive changes like that;
> > the bar to meet is something like "a huge outcry from deployments" or
> > "a critical security flaw".
> >
> > Second, what's going on here is that TLS 1.3 is defining some new
> signature
> > algorithms for TLS messages, and making them mandatory to support for
> TLS 1.3.
> > But negotiation of TLS signature algorithms has *always* been
> independent of
> > protocol version.  If you support TLS 1.3, you also support the new
> signature
> > algorithms; if you support TLS 1.3 and TLS 1.2, you support the new
> signature
> > algorithms and you support TLS 1.2, therefore by the longstanding
> negotiation
> > rules you are obligated to support the combination.  You are in effect
> proposing
> > that we make a break in the signature (and hash) algorithm space with
> individual
> > algorithms supported either in <=1.2 or >=1.3, but not both -- we did
> this for
> > ciphersuites since we fundamentally changed the meaning of what a
> ciphersuite is.
> > But the signature scheme does not seem to have undergone such a
> fundamental change,
> > so it seems hard to justify introducing this sort of split.
> >
> > -Ben
> >
>
> We are talking about TLS 1.3-specific IDs:
>
>  /* RSASSA-PSS 

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Benjamin Kaduk]

On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote:
> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote:
> > On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote:
> >> Greetings.
> >>
> >> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client
> >> wants to negotiate TLS 1.3, it must support an upgraded (and
> >> incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow
> >> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.
> >>
> >> You might recall that the possibility to negotiate between PSS and
> >> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509
> >> signatures, was discussed on the mailing list. The WG decision then was
> >> to hard-wire PSS in the TLS 1.3 handshake.
> >>
> >> I don't recall any discussion on going further than this, all the way to
> >> changing the 10-year old TLS 1.2.
> >>
> >> Unfortunately, our products have issues with PSS beyond our control. The
> >> only solution left to avoid receiving PSS with TLS 1.2 is to never
> >> negotiate TLS 1.3 as a client. Another solution is insecure fallback,
> >> but we presently don't do this.
> >>
> >> Is my reading of the situation correct? Thank you.
> > 
> > Sounds like it:
> > 
> >RSASSA-PKCS1-v1_5 algorithms  Indicates a signature algorithm using
> >   RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm
> >   as defined in [SHS].  These values refer solely to signatures
> >   which appear in certificates (see Section 4.4.2.2) and are not
> >   defined for use in signed TLS handshake messages, although they
> >   MAY appear in "signature_algorithms" and
> >   "signature_algorithms_cert" for backward compatibility with TLS
> >   1.2,
> > 
> > -Ben
> > 
> 
> I was referring to
> > 
> >-  Implementations that advertise support for RSASSA-PSS (which is
> >   mandatory in TLS 1.3), MUST be prepared to accept a signature
> >   using that scheme even when TLS 1.2 is negotiated.  In TLS 1.2,
> >   RSASSA-PSS is used with RSA cipher suites.
> 
> I am OK with what you quoted. What I just quoted represents a
> significant change in behavior in TLS 1.2 and there is no way to opt out
> of this change to TLS 1.2.

Ah, I misread your original message, but all is clear now.

> I will add that I've seen this behavior by servers already, even when
> client doesn't advertise TLS 1.3. Just the fact of including some 08 xx
> IDs in signature_algorithms in ClientHello, without protocol_version
> extension, gets the TLS 1.2 upgraded to RSA-PSS.
> 
> IMO this paragraph should be removed. Those that want PSS in the
> handshake should negotiate TLS 1.3. Preservation of current behavior of
> TLS 1.2 is important, at least as an option.

First off, it's basically too late to make substantive changes like that;
the bar to meet is something like "a huge outcry from deployments" or
"a critical security flaw".

Second, what's going on here is that TLS 1.3 is defining some new signature
algorithms for TLS messages, and making them mandatory to support for TLS 1..3.
But negotiation of TLS signature algorithms has *always* been independent of
protocol version.  If you support TLS 1.3, you also support the new signature
algorithms; if you support TLS 1.3 and TLS 1.2, you support the new signature
algorithms and you support TLS 1.2, therefore by the longstanding negotiation
rules you are obligated to support the combination.  You are in effect proposing
that we make a break in the signature (and hash) algorithm space with individual
algorithms supported either in <=1.2 or >=1.3, but not both -- we did this for
ciphersuites since we fundamentally changed the meaning of what a ciphersuite 
is.
But the signature scheme does not seem to have undergone such a fundamental 
change,
so it seems hard to justify introducing this sort of split.

-Ben

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

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Andrey Jivsov]

On 05/29/2018 12:13 PM, Benjamin Kaduk wrote:
> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote:
>> Greetings.
>>
>> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client
>> wants to negotiate TLS 1.3, it must support an upgraded (and
>> incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow
>> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.
>>
>> You might recall that the possibility to negotiate between PSS and
>> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509
>> signatures, was discussed on the mailing list. The WG decision then was
>> to hard-wire PSS in the TLS 1.3 handshake.
>>
>> I don't recall any discussion on going further than this, all the way to
>> changing the 10-year old TLS 1.2.
>>
>> Unfortunately, our products have issues with PSS beyond our control. The
>> only solution left to avoid receiving PSS with TLS 1.2 is to never
>> negotiate TLS 1.3 as a client. Another solution is insecure fallback,
>> but we presently don't do this.
>>
>> Is my reading of the situation correct? Thank you.
> 
> Sounds like it:
> 
>RSASSA-PKCS1-v1_5 algorithms  Indicates a signature algorithm using
>   RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm
>   as defined in [SHS].  These values refer solely to signatures
>   which appear in certificates (see Section 4.4.2.2) and are not
>   defined for use in signed TLS handshake messages, although they
>   MAY appear in "signature_algorithms" and
>   "signature_algorithms_cert" for backward compatibility with TLS
>   1.2,
> 
> -Ben
> 

I was referring to
> 
>-  Implementations that advertise support for RSASSA-PSS (which is
>   mandatory in TLS 1.3), MUST be prepared to accept a signature
>   using that scheme even when TLS 1.2 is negotiated.  In TLS 1.2,
>   RSASSA-PSS is used with RSA cipher suites.

I am OK with what you quoted. What I just quoted represents a
significant change in behavior in TLS 1.2 and there is no way to opt out
of this change to TLS 1.2.

I will add that I've seen this behavior by servers already, even when
client doesn't advertise TLS 1.3. Just the fact of including some 08 xx
IDs in signature_algorithms in ClientHello, without protocol_version
extension, gets the TLS 1.2 upgraded to RSA-PSS.

IMO this paragraph should be removed. Those that want PSS in the
handshake should negotiate TLS 1.3. Preservation of current behavior of
TLS 1.2 is important, at least as an option.

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

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Benjamin Kaduk]

On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote:
> Greetings.
> 
> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client
> wants to negotiate TLS 1.3, it must support an upgraded (and
> incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow
> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.
> 
> You might recall that the possibility to negotiate between PSS and
> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509
> signatures, was discussed on the mailing list. The WG decision then was
> to hard-wire PSS in the TLS 1.3 handshake.
> 
> I don't recall any discussion on going further than this, all the way to
> changing the 10-year old TLS 1.2.
> 
> Unfortunately, our products have issues with PSS beyond our control. The
> only solution left to avoid receiving PSS with TLS 1.2 is to never
> negotiate TLS 1.3 as a client. Another solution is insecure fallback,
> but we presently don't do this.
> 
> Is my reading of the situation correct? Thank you.

Sounds like it:

   RSASSA-PKCS1-v1_5 algorithms  Indicates a signature algorithm using
  RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm
  as defined in [SHS].  These values refer solely to signatures
  which appear in certificates (see Section 4.4.2.2) and are not
  defined for use in signed TLS handshake messages, although they
  MAY appear in "signature_algorithms" and
  "signature_algorithms_cert" for backward compatibility with TLS
  1.2,

-Ben

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

[TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Andrey Jivsov]

Greetings.

TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client
wants to negotiate TLS 1.3, it must support an upgraded (and
incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow
RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.

You might recall that the possibility to negotiate between PSS and
RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509
signatures, was discussed on the mailing list. The WG decision then was
to hard-wire PSS in the TLS 1.3 handshake.

I don't recall any discussion on going further than this, all the way to
changing the 10-year old TLS 1.2.

Unfortunately, our products have issues with PSS beyond our control. The
only solution left to avoid receiving PSS with TLS 1.2 is to never
negotiate TLS 1.3 as a client. Another solution is insecure fallback,
but we presently don't do this.

Is my reading of the situation correct? Thank you.
 

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

Re: [TLS] New Version Notification for draft-wood-tls-ticketrequests-00.txt

[Christopher Wood]

On Tue, May 29, 2018 at 8:25 AM Sean Turner  wrote:
>
> As Martin noted, this seems to be a pretty simple idea, but am curious if 
> others feel that way.
>
> Curious about the choice on the limit of 255 identifiers versus something 
> smaller.  If the max ticket age is one week that could theoretically be 
> almost 5 years of tickets right?

We went with 255 since we did not want anything larger. If others
think the limit should be lowered, we can certainly do so. That said,
the server is free to bound the number of tickets it vends, so this
may not be needed.

Best,
Chris

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

Re: [TLS] New Version Notification for draft-wood-tls-ticketrequests-00.txt

[Sean Turner]

As Martin noted, this seems to be a pretty simple idea, but am curious if 
others feel that way.

Curious about the choice on the limit of 255 identifiers versus something 
smaller.  If the max ticket age is one week that could theoretically be almost 
5 years of tickets right?

spt

PS - Thanks for not code squatting ;)

> On Apr 12, 2018, at 23:15, Chris Wood  wrote:
> 
> Hi everyone,
> 
> Below is a pointer to a new I-D describing an approach for clients to request 
> session tickets via a new post-handshake message. This is useful for 
> applications that perform parallel connection establishment and racing, e.g., 
> via Happy Eyeballs. It should also help reduce ticket waste. More uses and 
> details are given in the document. 
> 
> We would very much appreciate feedback on the mechanism utility and design.
> 
> Best,
> Chris 
> 
> Begin forwarded message:
> 
>> From: internet-dra...@ietf.org
>> Date: April 12, 2018 at 8:07:35 PM PDT
>> To: David Schinazi , Christopher Wood 
>> , Tommy Pauly , "Christopher A. Wood" 
>> 
>> Subject: New Version Notification for draft-wood-tls-ticketrequests-00.txt
>> 
>> 
>> A new version of I-D, draft-wood-tls-ticketrequests-00.txt
>> has been successfully submitted by Christopher A. Wood and posted to the
>> IETF repository.
>> 
>> Name:draft-wood-tls-ticketrequests
>> Revision:00
>> Title:TLS Ticket Requests
>> Document date:2018-04-12
>> Group:Individual Submission
>> Pages:6
>> URL:
>> https://www.ietf..org/internet-drafts/draft-wood-tls-ticketrequests-00.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/
>> Htmlized:   https://tools.ietf.org/html/draft-wood-tls-ticketrequests-00
>> Htmlized:   
>> https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests
>> 
>> 
>> Abstract:
>>   TLS session tickets enable stateless connection resumption for
>>   clients without server-side per-client state.  Servers vend session
>>   tickets to clients, at their discretion, upon connection
>>   establishment.  Clients store and use tickets when resuming future
>>   connections.  Moreover, clients should use tickets at most once for
>>   session resumption, especially if such keying material protects early
>>   application data.  Single-use tickets bound the number of parallel
>>   connections a client may initiate by the number of tickets received
>>   from a given server.  To address this limitation, this document
>>   describes a mechanism by which clients may request tickets as needed
>>   during a connection.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
> ___
> 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] WGLC for draft-ietf-tls-tls13-vectors

[Sean Turner]

> On May 8, 2018, at 20:30, Martin Thomson  wrote:
> 
> On Wed, May 9, 2018 at 2:56 AM Salz, Rich  wrote:
>> I dislike standard, and am fine with Informational or BCP.
> 
> Agree regarding standard.
> 
> I don't understand why BCP would be used for this.  Besides, we probably
> don't want to enshrine some of the choices we made in NSS as "best
> practice".  I'm not saying that those choices aren't defensible, but that
> might be going too far.

Since this draft is really about “examples” (i.e., it’s just for illustration), 
I’m going to suggest that Martin go ahead and merge the following PR that I 
submitted changing the intended status:
https://github.com/tlswg/draft-ietf-tls-tls13-vectors/pull/6

Once a new version is spun, I’ll push the draft toward Ben.

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

Re: [TLS] TLS@IETF102: Agenda Topics

[Sean Turner]

Just a reminder we’re going to submit our agenda request this week so get your 
agenda time request in soon.

spt

> On May 22, 2018, at 20:13, Sean Turner  wrote:
> 
> The TLS WG will be meeting @ IETF 102 in Montreal.  To help the chairs get a 
> better handle on how much time we will need for our session, please send in 
> your agenda requests to tls-cha...@ietf.org.  Along with your request please 
> provide an estimate for how much time you will need.
> 
> Cheers,
> 
> J

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

Re: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression)

[Sean Turner]

> On May 24, 2018, at 13:42, Adam Langley  wrote:
> 
> It's also been pointed out that 26 collides with the value in
> https://tools.ietf.org/html/draft-ietf-quic-tls-12#section-9.2, authored by
> Sean :)

f2p (face to plam).

spt

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