On Tue, Sep 20, 2016 at 3:39 AM, Hubert Kario <hka...@redhat.com> wrote:

> On Monday, 19 September 2016 18:12:22 CEST Eric Rescorla wrote:
> > Resolutions below.
>
> Thanks! I'll go over the post-merge text again later.
>
> > On Thu, Sep 8, 2016 at 11:08 AM, Hubert Kario <hka...@redhat.com> wrote:
> > > On Monday, 5 September 2016 11:02:57 CEST Eric Rescorla wrote:
> > > Finished section doesn't describe what to do if the contents don't
> match
> > > the
> > > expected value.
> > >
> > > Should it be illegal_parameter or bad_record_mac is more appropriate?
> >
> > This is specified in the decrypt_error section.
>
> on one hand, this give a side channel to detect mismatch between decryption
> error and finished value compare, on the other hand, the timing difference
> between those will be huge anyway...
>



>
> > > ---
> > >
> > > Record Layer doesn't describe what to do if a record with zero-length
> > > payload
> > > and handshake or alert type is received.
> >
> > I'm comfortable leaving these as-is.
>
> so what would be the expected alert description in such situation?
>

Probably bad_record_mac, because it's a deprotection failure.


> > Record Layer includes
> > >
> > >    legacy_record_version : (...) This field is deprecated and MUST be
> > >
> > > ignored
> > >
> > >    for all purposes.
> > >
> > > Record Layer Protection does not.
> >
> > I don't follow.
>
> in Record Layer there's the following text:
>
>     legacy_record_version : This value MUST be set to { 3, 1 } for all
>     records. This field is deprecated and MUST be ignored for all purposes.
>
> in Record Layer Protection there's the following text:
>
>     legacy_record_version : The legacy_record_version field is identical to
>     TLSPlaintext.legacy_record_version and is always { 3, 1 }. Note that
> the
>     handshake protocol including the ClientHello and ServerHello messages
>     authenticates the protocol version, so this value is redundant.
>
> which doesn't say if the version can be ignored completely (skipped while
> parsing) or if it should be verified.
>

These are different fields.


Less error-prone solution would be to have the same behaviour specified for
> encrypted and non-encrypted record layer.
>

The rationale for this is that we need to allow flexibility for the
plaintext messages
because there are stacks which don't conform already, but not for the
encrypted.

Please feel free to file a PR and start a discussion on the list if you
disagree, but
this is out of scope for this PR.

-Ekr


> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to