Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

[Tony Arcieri]

On Monday, August 8, 2016, Martin Rex  wrote:
>
> The urban myth about the advantages of the RSA-PSS signature scheme
> over PKCS#1 v1.5 keep coming up.
>

Do you think we'll see real-world MitM attacks against RSA-PSS in TLS
similar to those we've seen with PKCS#1v1.5 signature forgery, such as
BERserk?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

[Brian Smith]

Martin Rex  wrote:
> The urban myth about the advantages of the RSA-PSS signature scheme
> over PKCS#1 v1.5 keep coming up.

PKCS#1 v1.5 is a partial-domain scheme, not a full-domain scheme. So,
RSA-PSS (without a salt, or with a fixed salt) might still have an
advantage over PKCS#1 v1.5 because it is a full-domain scheme.

> The advantages of the RSA-PSS signature scheme are limited to situations
> where the rightful owner of the private signing key is not supposed
> to have access to the bits of the private key (i.e. key kept in hardware).

RSA-PSS is the only (IETF) (proposed) standard for full-domain hashing
we have for RSA, AFAIK. This is why I think it might still make sense
to use it, in a deterministic fashion.

Cheers,
Brian
-- 
https://briansmith.org/

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

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

[Salz, Rich]

 
> Is that limited, so limited today? Aren't we at a time where the majority of
> servers will use an HSM (either real hardware or virtualized)?

Without even defining "virtualized HSM" the answer is no.

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

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

[Nikos Mavrogiannopoulos]

On Mon, 2016-08-08 at 14:55 +0200, Martin Rex wrote:

> > Please see the paper "Another Look at ``Provable Security''" from
> > Neal
> > Koblitz and Alfred Menezes.
> > 
> > https://eprint.iacr.org/2004/152
> > 
> > Section 7: Conclusion
> > 
> > "There is no need for the PSS or Katz-Wang versions of RSA;
> > one might as well use just the basic ?hash and exponentiate?
> > signature
> > scheme (with a full-domain hash function)."
> The advantages of the RSA-PSS signature scheme are limited to
> situations
> where the rightful owner of the private signing key is not supposed
> to have access to the bits of the private key (i.e. key kept in
> hardware).

Is that limited, so limited today? Aren't we at a time where the
majority of servers will use an HSM (either real hardware or
virtualized)?

regards,
Nikos

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

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

[Martin Rex]

Hanno Böck wrote:
> 
> Actually there is some info on that in the PSS spec [1]. What I write
> here is my limited understanding, but roughly I'd interpret it as this:
> It says that if you use a non-random salt the security gets reduced to
> the security of full domain hashing, which was kinda the predecessor of
> PSS.
> I'd conclude from that that even in a situation where the salt
> generation is a non-random value nothing really bad happens. The
> security of a PSS scheme without randomness is still better than that
> of a PKCS #1 1.5 signature.

The urban myth about the advantages of the RSA-PSS signature scheme
over PKCS#1 v1.5 keep coming up.

It has been mentioned here before:

Fedor Brunner wrote on 4 Mar 2016 17:45:19:
> 
> Please see the paper "Another Look at ``Provable Security''" from Neal
> Koblitz and Alfred Menezes.
> 
> https://eprint.iacr.org/2004/152
> 
> Section 7: Conclusion
> 
> "There is no need for the PSS or Katz-Wang versions of RSA;
> one might as well use just the basic ?hash and exponentiate? signature
> scheme (with a full-domain hash function)."


The advantages of the RSA-PSS signature scheme are limited to situations
where the rightful owner of the private signing key is not supposed
to have access to the bits of the private key (i.e. key kept in hardware).

-Martin

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

Re: [TLS] TLS1.3 + PSK with multiple identities

[Nikos Mavrogiannopoulos]

On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote:
> On Mon, Aug 08, 2016 at 10:17:40AM +0200, Nikos Mavrogiannopoulos
> wrote:
> > 
> > Hello,
> >  I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3
> > draft [0], and I noticed quite some deviations (IMO) from typical
> > TLS
> > protocol behavior. No rationale is given about them so I ask on
> > list.
> > 
> > To summarize, the client sends a list of identitities and the
> > server
> > replies with an index indicating which identity is approved.
> > 
> > 1. The server reply with an index is unique in TLS. It is not used
> > in
> > ciphersuite selection or in any other negotiation in TLS where the
> > client sends multiple options. Why not have the server reply with
> > the
> > selected username.
> 
> More compact and makes the option where server sends some bad option
> more clear.

I'm not sure about being more clear. What I immediately notice is that
it requires the client to remember not only the values that it sent,
but also the indexes. I guess that's no big deal, but it is used
nowhere else in TLS.

> > 2. Why does the client send multiple identities? In TLS-SRP a
> > single
> > identity is sent, and the same in the existing TLS-PSK rfc. How is
> > this
> > envisioned to be used? A client sends: I'm probably one of Bob,
> > Nikos,
> > George, take a look on that list and tell me who I really am? In
> > that
> > case why not allow the server, to reply with a username outside
> > that
> > list (i.e., assign a new one to be used at the next session - see
> > point
> > 1).
> You already need multiple if you try to "resume"[1] DHE-PSK session
> (since "resumption" shares the PSK space).

That's very awkward. That way the protocol mandates code like:

if (!id_in_resumption_db()) {
    if (!valid_ticket())
      if (!try_find_user_in_psk_userfile())
        proceed_with_random_psk(); /* hide the fact that username
doesn't exist in db */
}

which is not really sane code. Not only that, but servers who would
like to prevent valid username testing in their PSK key file as above,
would be forced to make resumption attempts with unknown or long-
expired tickets fail.

A protocol must have clarity on the data sent on the wire and their
purpose. Cross protocol attacks work by exploiting data which may be
interpreted in multiple ways and such generic purpose identifiers seem
to be like a good candidate for that.

I think at minimum identities known to the protocol (e.g., resumption)
should be distinguishable from PSK usernames. The draft leaves that to
the server implementor to do, but I do think such identifiers should be
tagged at the protocol level since it affects all implementations.

> 3. The maximum size of the username is 2^16. Isn't that excessive
> > for a
> > user name or a user identifier? Why not set 2^8? That would fit a
> > uuid
> > or anything similarly large.
> If one wants to do the equivalent of tickets in TLS 1.2, one needs
> pretty large usernames.

I find that, as another unfortunate side-effect of combining unrelated
protocol fields.

regards,
Nikos

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

Re: [TLS] TLS1.3 + PSK with multiple identities

[Ilari Liusvaara]

On Mon, Aug 08, 2016 at 10:17:40AM +0200, Nikos Mavrogiannopoulos wrote:
> Hello,
>  I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3
> draft [0], and I noticed quite some deviations (IMO) from typical TLS
> protocol behavior. No rationale is given about them so I ask on list.
> 
> To summarize, the client sends a list of identitities and the server
> replies with an index indicating which identity is approved.
> 
> 1. The server reply with an index is unique in TLS. It is not used in
> ciphersuite selection or in any other negotiation in TLS where the
> client sends multiple options. Why not have the server reply with the
> selected username.

More compact and makes the option where server sends some bad option
more clear.
 
> 2. Why does the client send multiple identities? In TLS-SRP a single
> identity is sent, and the same in the existing TLS-PSK rfc. How is this
> envisioned to be used? A client sends: I'm probably one of Bob, Nikos,
> George, take a look on that list and tell me who I really am? In that
> case why not allow the server, to reply with a username outside that
> list (i.e., assign a new one to be used at the next session - see point
> 1).

You already need multiple if you try to "resume"[1] DHE-PSK session
(since "resumption" shares the PSK space).

Additionally, TLS 1.2 had identity hint, but TLS 1.3 eliminates that
due to flight limits.

> 3. The maximum size of the username is 2^16. Isn't that excessive for a
> user name or a user identifier? Why not set 2^8? That would fit a uuid
> or anything similarly large.

If one wants to do the equivalent of tickets in TLS 1.2, one needs
pretty large usernames.



[1] IMO, TLS 1.3 does not have session resumption (doesn't stop others
from calling the relevant features "resumption").


-Ilari

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

[TLS] TLS1.3 + PSK with multiple identities

[Nikos Mavrogiannopoulos]

Hello,
 I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3
draft [0], and I noticed quite some deviations (IMO) from typical TLS
protocol behavior. No rationale is given about them so I ask on list.

To summarize, the client sends a list of identitities and the server
replies with an index indicating which identity is approved.

1. The server reply with an index is unique in TLS. It is not used in
ciphersuite selection or in any other negotiation in TLS where the
client sends multiple options. Why not have the server reply with the
selected username.

2. Why does the client send multiple identities? In TLS-SRP a single
identity is sent, and the same in the existing TLS-PSK rfc. How is this
envisioned to be used? A client sends: I'm probably one of Bob, Nikos,
George, take a look on that list and tell me who I really am? In that
case why not allow the server, to reply with a username outside that
list (i.e., assign a new one to be used at the next session - see point
1).

3. The maximum size of the username is 2^16. Isn't that excessive for a
user name or a user identifier? Why not set 2^8? That would fit a uuid
or anything similarly large.

regards,
Nikos


[0]. https://tlswg.github.io/tls13-spec/#rfc.section.4.2.5

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

Re: [TLS] draft-sullivan-tls-post-handshake-auth-00

[Martin Thomson]

On 8 August 2016 at 16:14, Ilari Liusvaara  wrote:
> In 2, I would imagine the context is probably usually a sequence
> number of some kind.

The draft defines some rules for construction of identifiers that
prevent collisions and the like.

>> Good question.  Errors in encoding or otherwise problems following the
>> rules in the spec should result in a connection-level fatal error.
>> But if the certificate isn't trusted, handling that will be up to the
>> application.
>
> And that should presumably be communicated somehow...

Of course.  See
https://github.com/grittygrease/tls13-post-handshake-auth/issues/18
(feel free to contribute)

> Being able for application to to wait for certificate/cv/finised
> message to be sent, so it can do something special in application
> layer immediately after that.

Sure.  The usual async API guarantees apply here; I don't know that
this needs special treatment in the spec though.  If you disagree, I'm
sure that my coauthors would be happy to take suggestions for
improvements.

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

Re: [TLS] draft-sullivan-tls-post-handshake-auth-00

[Ilari Liusvaara]

On Mon, Aug 08, 2016 at 11:19:39AM +1000, Martin Thomson wrote:
> On 7 August 2016 at 03:26, Ilari Liusvaara  wrote:
> 
> > Can applications specify and receive the context values used? E.g.
> > to act as handles to refer to the resulting authority objects
> > (HTTP/2 absolutely needs to be able to refer to client authority).
> 
> The API might take one of two forms:
> 1. an application requests that authentication happen and get the
> identifier that TLS uses in return
> 2. an application requests authentication and specifies the identifier
> (the TLS stack will have to verify that this is unique and conforms to
> the restrictions)

In 2, I would imagine the context is probably usually a sequence
number of some kind.
 
> > Also, are all errors (including things like getting extensions
> > wrong or CA wrong) fatal to the whole connection, or how is error
> > reporting handled? One can't use alerts for non-fatal reports.
> 
> Good question.  Errors in encoding or otherwise problems following the
> rules in the spec should result in a connection-level fatal error.
> But if the certificate isn't trusted, handling that will be up to the
> application.

And that should presumably be communicated somehow...

> > Also, are applications expected to be able to specify exactly
> > where in stream to put an authentication (response)? Especially
> > so they can immediately follow with appdata coordinating the
> > usage.
> 
> Not sure where you are going here.

Being able for application to to wait for certificate/cv/finised
message to be sent, so it can do something special in application
layer immediately after that.



-Ilari

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