Re: [TLS] BoringSSL's TLS test suite

David Benjamin <davidben@google.com> Sun, 25 September 2016 21:23 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620C912B020 for <tls@ietfa.amsl.com>; Sun, 25 Sep 2016 14:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.016
X-Spam-Level:
X-Spam-Status: No, score=-5.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICVCOdkhM7yv for <tls@ietfa.amsl.com>; Sun, 25 Sep 2016 14:23:21 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D83012B028 for <tls@ietf.org>; Sun, 25 Sep 2016 14:23:21 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id r145so165365519ior.0 for <tls@ietf.org>; Sun, 25 Sep 2016 14:23:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qETFPF6S/W8rMqQWHN5l+rbO0foGQaqtnQomP/BdaEs=; b=LNvfFHjzbDWwYztKTKJQhqg/l80zhxryudaudU1fkfSgOYFva3k15yzNT0p2rmx4Rd rTJ1/tzj6d6SgjrOV+w9bDlQxpjWZOZ5NchdSb1nwfN2Px+2/6roW877a5uVaYOGbu1Q 8ww+v1FZbXdVuvm2V4XtUfjBitYWrQkwTBd1qarOAWQs6r74UZzCqeuni1COiUrDuAnZ umQGOSLqvPKqdvhv2zd/rYsuhOayrUx3XssistWeZVhBwHdJJNc+mLy5VTn+ssEH6sjA tJg7qYJ/U7bgSweixHt3CrPnUwoT5Ff2aMicBGWpyKOWIZwUxZKDGdr5DCrTZwbiJHSv SsdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qETFPF6S/W8rMqQWHN5l+rbO0foGQaqtnQomP/BdaEs=; b=MJjPc/WG+Pg2GaumC6lBdmkXMRabWDgJVIpyjOcEXnV+4yMknfX3VzJP8KZBYOPWdK cP4avMFwsfaMrZDbysaf5iPybXZMEVzzqKPY3rNJHIkyHdAt84j17O1IRG3Bybnp0Nj9 U20Hda0PeWlfVQinr0+zK1xFrEpwMw1qtCmYOyxOSsppIVXYBtquMBP/icplP7qNOkOn UXaS2LURLwfltPb+lWyQTpJP3rXr7WBfKYAQc0N7AAp3yNIehqG+zcEvECjimVE9ocOW N4qDxXUJRvPTQnXKOm008dcfFN2q1JwXoQIgt74KUatw4GdRf+5UQEdoKpznWkAjJ6NH Vfhw==
X-Gm-Message-State: AE9vXwPXpulhVt6VacrUKhtfGn/rDf2timQt7yRDEfXCgRXDAjOE0duuLpFzSLfYCQzW7AJ5f5bSwBDKQWZ91G7B
X-Received: by 10.107.44.3 with SMTP id s3mr18614353ios.115.1474838600624; Sun, 25 Sep 2016 14:23:20 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaBQkVy+wcK1-NFctBepV7TW93YmmPnxS2WoJ6F6=v-aEg@mail.gmail.com> <c70c6db3-5d1c-d2db-1e37-f8849166786e@streamsec.se>
In-Reply-To: <c70c6db3-5d1c-d2db-1e37-f8849166786e@streamsec.se>
From: David Benjamin <davidben@google.com>
Date: Sun, 25 Sep 2016 21:23:09 +0000
Message-ID: <CAF8qwaAQYwW9s0E_V-TqHhTqL9sBhobzsGUch5TDQynK2VNfEw@mail.gmail.com>
To: henrick@streamsec.se, tls@ietf.org
Content-Type: multipart/alternative; boundary="001a113986a0e48fed053d5b9e62"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/uBj2TeMBIJzs9QkkXj9jRrufGfg>
Subject: Re: [TLS] BoringSSL's TLS test suite
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2016 21:23:24 -0000

Do you mean in RSA SubjectPublicKeyInfos? For those, such encodings are not
actually standards-compliant. Per RFC 3279, 2.3.1:

   The rsaEncryption OID is intended to be used in the algorithm field
   of a value of type AlgorithmIdentifier.  The parameters field MUST
   have ASN.1 type NULL for this algorithm identifier.

https://tools.ietf.org/html/rfc3279#section-2.3.1

RFC 4055, section 1.2 also says:

   The rsaEncryption object identifier continues to identify the subject
   public key when the RSA private key owner does not wish to limit the
   use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP.
   In this case, the rsaEncryption object identifier MUST be used in the
   algorithm field within the subject public key information, and the
   parameters field MUST contain NULL.

https://tools.ietf.org/html/rfc4055#section-1.2

There are other contexts where (due to historical mistakes) specs declared
both are acceptable, but amazingly not RSA SPKIs. BoringSSL has enforced it
for quite some time now, so it seems this part of the specification matches
reality. If I recall, mozilla::pkix enforces this as well?

David

On Sun, Sep 25, 2016 at 5:07 PM Henrick Hellström <henrick@streamsec.se>
wrote:

> 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
>