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?

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

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

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

Attachment: signature.asc
Description: This is a digitally signed message part.

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

Reply via email to