Re: [TLS] Industry Concerns about TLS 1.3

[Hovav Shacham]

On Sun, Sep 25, 2016 at 2:20 PM, Ackermann, Michael 
wrote:

>
> Again, let me restate,  I don't think anyone is saying that we MUST have
> RSA.But, we, as the clients of the IETF TLS protocol, would like to
> work with you to assure we have workable, manageable  and affordable
> solutions,  that meets our needs as well as the needs of others.
>

I think TLS 1.3 as it is might actually be compatible with your
requirements.  The technology you need, Dual EC, was developed by the US
Government and has already been standardized by ANSI X9.  Here's a
whitepaper on how it would work:

http://dualec.org/DualECTLS.pdf

There are some organizations that would no doubt be happy to lend their
expertise, including RSA-the-company.

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

Re: [TLS] BoringSSL's TLS test suite

[Henrick Hellström]

On 2016-09-26 02:02, Jim Schaad wrote:

OPTIONAL and DEFAULT are not the same things.  A DEFAULT value is omitted
but not an OPTIONAL value.  A single field cannot be both OPTIONAL and
DEFAULT.


My point was that "DEFAULT" is not the same as "default" either, but 
let's leave it there.


You were listed as a co-author on RTC 5912, so maybe you could clarify 
whether the declaration of pk-rsa should still be considered to be correct:


   pk-rsa PUBLIC-KEY ::= {
IDENTIFIER rsaEncryption
KEY RSAPublicKey
PARAMS TYPE NULL ARE absent
-- Private key format not in this module --
CERT-KEY-USAGE {digitalSignature, nonRepudiation,
keyEncipherment, dataEncipherment, keyCertSign, cRLSign}
   }


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

Re: [TLS] BoringSSL's TLS test suite

[Jim Schaad]

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Henrick Hellström
> Sent: Sunday, September 25, 2016 4:35 PM
> To: David Benjamin ; Adam Langley
> 
> Cc: tls@ietf.org
> Subject: Re: [TLS] BoringSSL's TLS test suite
> 
> On 2016-09-25 23:55, David Benjamin wrote:
> > I believe we are also correct per spec. My interpretation of these
> > documents is that the general AlgorithmIdentifier structure may or may
> > not include parameters. However, whether a given parameter value or
> > omitting parameters altogether is legal is a question for the
> > particular algorithm. It's not overriding but plugging into the general
> framework.
> 
> THe ITU-T X.690 standard for DER might require some close reading to
interpret,
> and this is obviously a topic for debate. I would presume that the use of
> "default" in lower caps in section 11.5, refers to both the DEFAULT and
the
> OPTIONAL keyword:

OPTIONAL and DEFAULT are not the same things.  A DEFAULT value is omitted
but not an OPTIONAL value.  A single field cannot be both OPTIONAL and
DEFAULT.

Jim

> 
>11.5   Set and sequence components with default value
>The encoding of a set value or sequence value shall not include an
>encoding for any component value which is equal to its default value.
> 
> After all, this is the only interpretation that is consistent with the
description in
> section 12.5 of DER as unambiguous.
> 
> Since NULL is always empty, it should be omitted when OPTIONAL, given the
> above interpretation. But is it optional? The 1988 syntax did not feature
> information objects and classes, hence the use of the ANY keyword.
> 
> Luckily the ASN.1 modules were updated in RFC 5912 to modern ASN.1 syntax.
> There you have these declarations:
> 
> --  SIGNATURE-ALGORITHM
> --
> --  Describes the basic properties of a signature algorithm
> --
> --   - contains the OID identifying the signature algorithm
> --   - contains a type definition for the value structure of
> --  the signature; if absent, implies that no ASN.1
> --  encoding is performed on the value
> --   - if present, contains the type for the algorithm
> --   parameters; if absent, implies no parameters
> --   - parameter presence requirement
> --   - The set of hash algorithms used with this
> --  signature algorithm
> --   - the set of public key algorithms for this
> --  signature algorithm
> --   - contains the object describing how the S/MIME
> --  capabilities are presented.
> --
> --  Example:
> --  sig-RSA-PSS SIGNATURE-ALGORITHM ::= {
> -- IDENTIFIER id-RSASSA-PSS
> -- PARAMS TYPE RSASSA-PSS-params ARE required
> -- HASHES { mda-sha1 | mda-md5, ... }
> -- PUBLIC-KEYS { pk-rsa | pk-rsa-pss }
> -- }
> 
> 
> SIGNATURE-ALGORITHM ::= CLASS {
>   OBJECT IDENTIFIER UNIQUE,
>OPTIONAL,
>   OPTIONAL,
>ParamOptions DEFAULT absent,
>  DIGEST-ALGORITHM OPTIONAL,
> PUBLIC-KEY OPTIONAL,
>SMIME-CAPS OPTIONAL
> } WITH SYNTAX {
>  IDENTIFIER 
>  [VALUE ]
>  [PARAMS [TYPE ] ARE  ]
>  [HASHES ]
>  [PUBLIC-KEYS ]
> 
> AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
>  SEQUENCE {
>  algorithm   ALGORITHM-TYPE.({AlgorithmSet}),
>  parameters  ALGORITHM-TYPE.
> ({AlgorithmSet}{@algorithm}) OPTIONAL
>  }
> 
> pk-rsa PUBLIC-KEY ::= {
>  IDENTIFIER rsaEncryption
>  KEY RSAPublicKey
>  PARAMS TYPE NULL ARE absent
>  -- Private key format not in this module --
>  CERT-KEY-USAGE {digitalSignature, nonRepudiation,
>  keyEncipherment, dataEncipherment, keyCertSign, cRLSign}
> }
> 
> Hence, the correct encoding is for NULL to be absent.
> 
> ___
> 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] BoringSSL's TLS test suite

[Henrick Hellström]

On 2016-09-26 01:29, Jim Schaad wrote:

The ASN.1 module in RFC 5280 does not say anything about if the field is
optional for any specific algorithm.  The ASN.1 for algorithm identifier is

AlgorithmIdentifier  ::=  SEQUENCE  {
algorithm   OBJECT IDENTIFIER,
parameters  ANY DEFINED BY algorithm OPTIONAL

This very explicitly says that the value (and hence presence) of the
parameters fields is strictly defined by the algorithm identifier.  The
algorithm identifiers for RSA with the SHA2 algorithms explicitly say they
are required.


RFC 5912 shows that this is required with the way it defines the same
information

  sa-sha256WithRSAEncryption SIGNATURE-ALGORITHM ::= {
   IDENTIFIER sha256WithRSAEncryption
   PARAMS TYPE NULL ARE required
   HASHES { mda-sha256 }
   PUBLIC-KEYS { pk-rsa }
   SMIME-CAPS { IDENTIFIED BY sha256WithRSAEncryption }
   }

You can see that the parameters are required and not optional.


Thanks, you are absolutely correct about this, and this crucial for 
getting PKCS #1 v1.5 signatures right (since the algorithm identifier 
encoding is part of the data to be signed), but at the same time, NULL 
should be absent from the RSA public key:


   pk-rsa PUBLIC-KEY ::= {
IDENTIFIER rsaEncryption
KEY RSAPublicKey
PARAMS TYPE NULL ARE absent
-- Private key format not in this module --
CERT-KEY-USAGE {digitalSignature, nonRepudiation,
keyEncipherment, dataEncipherment, keyCertSign, cRLSign}
   }

and this is definitely not common practice.

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

Re: [TLS] BoringSSL's TLS test suite

[Henrick Hellström]

On 2016-09-25 23:55, David Benjamin wrote:

I believe we are also correct per spec. My interpretation of these
documents is that the general AlgorithmIdentifier structure may or may
not include parameters. However, whether a given parameter value or
omitting parameters altogether is legal is a question for the particular
algorithm. It's not overriding but plugging into the general framework.


THe ITU-T X.690 standard for DER might require some close reading to 
interpret, and this is obviously a topic for debate. I would presume 
that the use of "default" in lower caps in section 11.5, refers to both 
the DEFAULT and the OPTIONAL keyword:


  11.5  Set and sequence components with default value
  The encoding of a set value or sequence value shall not include an
  encoding for any component value which is equal to its default value.

After all, this is the only interpretation that is consistent with the 
description in section 12.5 of DER as unambiguous.


Since NULL is always empty, it should be omitted when OPTIONAL, given 
the above interpretation. But is it optional? The 1988 syntax did not 
feature information objects and classes, hence the use of the ANY keyword.


Luckily the ASN.1 modules were updated in RFC 5912 to modern ASN.1 
syntax. There you have these declarations:


--  SIGNATURE-ALGORITHM
--
--  Describes the basic properties of a signature algorithm
--
--   - contains the OID identifying the signature algorithm
--   - contains a type definition for the value structure of
--  the signature; if absent, implies that no ASN.1
--  encoding is performed on the value
--   - if present, contains the type for the algorithm
--   parameters; if absent, implies no parameters
--   - parameter presence requirement
--   - The set of hash algorithms used with this
--  signature algorithm
--   - the set of public key algorithms for this
--  signature algorithm
--   - contains the object describing how the S/MIME
--  capabilities are presented.
--
--  Example:
--  sig-RSA-PSS SIGNATURE-ALGORITHM ::= {
-- IDENTIFIER id-RSASSA-PSS
-- PARAMS TYPE RSASSA-PSS-params ARE required
-- HASHES { mda-sha1 | mda-md5, ... }
-- PUBLIC-KEYS { pk-rsa | pk-rsa-pss }
-- }


SIGNATURE-ALGORITHM ::= CLASS {
 OBJECT IDENTIFIER UNIQUE,
  OPTIONAL,
 OPTIONAL,
  ParamOptions DEFAULT absent,
DIGEST-ALGORITHM OPTIONAL,
   PUBLIC-KEY OPTIONAL,
  SMIME-CAPS OPTIONAL
} WITH SYNTAX {
IDENTIFIER 
[VALUE ]
[PARAMS [TYPE ] ARE  ]
[HASHES ]
[PUBLIC-KEYS ]

AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
SEQUENCE {
algorithm   ALGORITHM-TYPE.({AlgorithmSet}),
parameters  ALGORITHM-TYPE.
   ({AlgorithmSet}{@algorithm}) OPTIONAL
}

   pk-rsa PUBLIC-KEY ::= {
IDENTIFIER rsaEncryption
KEY RSAPublicKey
PARAMS TYPE NULL ARE absent
-- Private key format not in this module --
CERT-KEY-USAGE {digitalSignature, nonRepudiation,
keyEncipherment, dataEncipherment, keyCertSign, cRLSign}
   }

Hence, the correct encoding is for NULL to be absent.

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

Re: [TLS] BoringSSL's TLS test suite

[David Benjamin]

On Sun, Sep 25, 2016 at 5:49 PM Adam Langley  wrote:

> On Sun, Sep 25, 2016 at 2:35 PM, Henrick Hellström 
> wrote:
> > Then again, the ASN.1 module in
> https://datatracker.ietf.org/doc/rfc5280/
> > says differently. Strictly speaking, RFC 3279 does not override the PKIX
> > specification when it comes to X.509 certificates; only for formats such
> as
> > RSA PUBLIC KEY that rely solely on the ASN.1 module in RFC 3279.
>
> To answer your original question then, this is intentional.
>
> While there are certainly differences of opinion about the
> applicability of Postel's law in this space, in practical terms
> requiring a NULL in this location empirically has very good
> compatibility and we don't like adding flexibility without good
> reason.
>

I believe we are also correct per spec. My interpretation of these
documents is that the general AlgorithmIdentifier structure may or may not
include parameters. However, whether a given parameter value or omitting
parameters altogether is legal is a question for the particular algorithm.
It's not overriding but plugging into the general framework. Specifications
for individual algorithm OIDs say what to put in the parameters field:

For id-rsaEncryption, RFC 3279 (previously cited) says it is not optional
and the only legal value is NULL.
https://tools.ietf.org/html/rfc3279#section-2.3.1

For id-RSASSAS-PSS, RFC 4055 says the parameters are not optional and
specifies the structure.
https://tools.ietf.org/html/rfc4055#section-3.1

For id-ecPublicKey, RFC 5480 says something similar and gives the structure.
https://tools.ietf.org/html/rfc5480#section-2.1.1

For id-dsa, RFC 3279 says they are actually optional. (Although this was a
pretty bad idea since it's used in this bizarre parameter inheritance
thing...)
https://tools.ietf.org/html/rfc3279#section-2.3.2

None of these can be talking about standalone structures like RSAPublicKey.
Those structures usually don't even include AlgorithmIdentifiers (no need
when you already know the key type) and are usually specified in other
documents like RFC 3447.

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

Re: [TLS] BoringSSL's TLS test suite

[Henrick Hellström]

Have you noticed that BoringSSL seems to abort handshakes with an 
illegal_parameter alert, if the server certificate uses the standard 
compliant (albeit highly unusual) DER encoding of NULL OPTIONAL as the 
empty string, instead of the non-standard but ubiquitous 0x05 0x00 encoding?


Is this just a regression bug in BoringSSL, or is it an intentional 
restriction of the TLS protocol that should be propagated to other 
implementations as well?


On 2016-08-16 20:08, David Benjamin wrote:

Hi folks,

BoringSSL has developed a test harness[1] that consists of a fork of
Go’s crypto/tls package (recently dubbed “BoGo" at the Berlin hackathon)
plus a test runner that allows BoGo to be run against the TLS stack
under test. BoGo can be configured to behave in a number of unexpected
ways that violate the TLS standard, thus enabling the testing of many
scenarios that would be otherwise difficult to obtain with a standard
stack. We (David Benjamin and Eric Rescorla) have been getting it to
work with NSS and wanted to let others know in case they might find it
useful.

This system was initially designed to work with BoringSSL, but in
principle can be used with any stack. The portability is still a little
rough, and we'll likely make changes as we get more experience here, but
it has already been used to test NSS[2] and OpenSSL[3]. We've written up
some notes at [4].

The test suite should be fairly extensive for DTLS and TLS 1.2 (giving
around 75% line coverage in BoringSSL’s TLS code at last count). It
tests TLS 1.3 as well, though those tests are still in progress. They
track BoringSSL’s in-progress TLS 1.3 implementation.

David and Eric

[1] https://boringssl.googlesource.com/boringssl/+/master/ssl/test/
[2] https://hg.mozilla.org/projects/nss/file/tip/external_tests/nss_bogo_shim
[3] https://github.com/google/openssl-tests
[4] https://boringssl.googlesource.com/boringssl/+/master/ssl/test/PORTING.md


___
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