Re: [TLS] Malformed Finished handling

Hubert Kario <hkario@redhat.com> Wed, 04 July 2018 13:36 UTC

Return-Path: <hkario@redhat.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 D33C6130F58 for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 06:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Op9jnsdHUS53 for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 06:36:21 -0700 (PDT)
Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E22C130F49 for <tls@ietf.org>; Wed, 4 Jul 2018 06:36:21 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DE34177890; Wed, 4 Jul 2018 13:36:20 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6064C2166BA9; Wed, 4 Jul 2018 13:36:20 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Date: Wed, 04 Jul 2018 15:36:19 +0200
Message-ID: <10346670.25GZR1XrEq@pintsize.usersys.redhat.com>
In-Reply-To: <CABcZeBOFTKBUbCTGT-cLpqyfK9J2zre4EFmFz-9b8S-nQhJ=cg@mail.gmail.com>
References: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> <CABcZeBOFTKBUbCTGT-cLpqyfK9J2zre4EFmFz-9b8S-nQhJ=cg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3755769.mzyD5SKM1q"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 04 Jul 2018 13:36:20 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 04 Jul 2018 13:36:20 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:''
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PaVEsdlXCthCmXsHYX4QNRQJ3VQ>
Subject: Re: [TLS] Malformed Finished handling
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 04 Jul 2018 13:36:25 -0000

On Wednesday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote:
> I think it's a close call, because the length is sort of external to the
> language.

which language? the decode_error alert description literally says "length of 
the message was incorrect."

> That's why, for instance, NSS sends "illegal_parameter". So,
> absent specific text about this value, I think this is something we can
> leave to the implementations.

but the text is explicit, if a message continues past message boundary, the 
correct response is decode_error. Decode_error is also consistent with the way 
above-expected length Client Hello MUST be handled.

Just because the description of the message uses a single opaque array doesn't 
make this message syntactically any different from other Handshake protocol 
message.

if the interpretation of "I know this _message_ _length_ is wrong because of 
some other values I negotiated before, so I'll send illegal_parameter" was 
correct, then overflow_error, decrypt_error and probably few others would also 
need to be replaced with illegal_parameter...
 
> -Ekr
> 
> On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kario <hkario@redhat.com>; wrote:
> > Despite this, is it correct to terminate a connection with
> > "illegal_parameter"
> > upon receiving a Finished handshake message with a 100 byte payload? or a
> > 20
> > byte payload? My opinion is that it is not, "decode_error" is more
> > specific so
> > it should be used instead.
> > 
> > 
> > Specification says the following on the matter:
> > 
> > The draft 28 specifies the Finished message as having following structure:
> >       struct {
> >       
> >           opaque verify_data[Hash.length];
> >       
> >       } Finished;
> > 
> > At multiple places it also talks about handling messages that have sizes
> > that
> > don't match their structure as requiring termination of connection with
> > "decode_error".
> > 
> > The generic situation in Section 6:
> >    Peers which receive a message which
> >    cannot be parsed according to the syntax (e.g., have a length
> >    extending beyond the message boundary or contain an out-of-range
> >    length) MUST terminate the connection with a "decode_error" alert.
> > 
> > as description of the alert in Section 6.2:
> >    decode_error  A message could not be decoded because some field was
> >    
> >       out of the specified range or the length of the message was
> >       incorrect.  This alert is used for errors where the message does
> >       not conform to the formal protocol syntax.
> > 
> > In specific about Client Hello, in Section 4.1.2:
> >    If negotiating a version of TLS prior to 1.3, a server MUST check
> >    that the message either contains no data after
> >    legacy_compression_methods or that it contains a valid extensions
> >    block with no data following.  If not, then it MUST abort the
> >    handshake with a "decode_error" alert.
> > 
> > And specific handling of Certificate from server in Section 4.4.2.4:
> >    If the server supplies an empty Certificate message, the client MUST
> >    abort the handshake with a "decode_error" alert.
> > 
> > Description of "illegal_parameter" in Section 6:
> >    Peers which receive a message which is syntactically correct but
> >    semantically invalid (e.g., a DHE share of p - 1, or an invalid enum)
> >    MUST terminate the connection with an "illegal_parameter" alert.
> > 
> > Alert description in Section 6.2:
> >    illegal_parameter  A field in the handshake was incorrect or
> >    
> >       inconsistent with other fields.  This alert is used for errors
> >       which conform to the formal protocol syntax but are otherwise
> >       incorrect.
> > 
> > (it's also mentioned in over a dozen places in the draft)
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


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