Re: [TLS] draft-ietf-tls-record-limit-01

[Martin Thomson]

On Mon, Sep 25, 2017 at 9:01 PM, Hubert Kario  wrote:
> my understanding of this draft was that the TLS1.3 ContentType is included in
> the record limit while it is not included in the TLS 1.3 maximum payload size

That's right, I forgot this detail. I subtract 1 for TLS 1.3 when I
set the variable.

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

Re: [TLS] TLS specification clarification in case of client authentication: different CA with DN different only in case

[Geoffrey Keating]

devzero2000  writes:

> Hello everyone
> 
> >From the tls 1.2 specification, speaking of client authentication,
> https://tools.ietf.org/html/rfc5246#section-7.4.4 par 7.4.4 (but it is the
> same for the last tls draft 1.3 par. 4.2.4.)
> 
> when he says:
> 
> certificate_authorities
>   A list of the distinguished names [X501] of acceptable
>   certificate_authorities, represented in DER-encoded format.
> 
> What would be the right behavior if the server has the certificates of two
> different CAs (different subject key info, public key parameter) but whose
> subject DN differs only for the case (for example
> something like this
> 
> Subject: /C=US/ST=California/L=Mountain View/O=XXX Inc/CN=mail.xxx.com
> 
> and
> 
> 
> Subject: /C=US/ST=California/L=mountain View/O=XXX Inc/CN=mail.xxx.com

These are the same distinguished name under RFC 5280 section 7.1,
although in practice implementations may treat them as different, most
notably under the older RFC 3280 rules.  I believe the correct
behaviour is to Not Do That---do not generate certificates which have
distinguished names that match under RFC 5280 and are not
byte-for-byte identical in DER format, if you must do that make sure
they are not valid at the same time, and if you must do that, try to
ensure no piece of software is aware of both of them, and if you must
do that, don't be surprised if the behaviour is inconsistent and
especially don't be surprised if the LDAP StringPrep rules are not
implemented correctly or at all.

And if you value your sanity, don't rely on anything that might change
if the Unicode standard is revised.

However, the TLS specification doesn't say that the list must contain
each DN only once.  So in this situation I would suggest the software
should list both.  Indeed I would recommend listing every distinct DER
representation that's present in any acceptable certificate.

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

[TLS] TLS specification clarification in case of client authentication: different CA with DN different only in case

[devzero2000]

Hello everyone

>From the tls 1.2 specification, speaking of client authentication,
https://tools.ietf.org/html/rfc5246#section-7.4.4 par 7.4.4 (but it is the
same for the last tls draft 1.3 par. 4.2.4.)

when he says:

certificate_authorities
  A list of the distinguished names [X501] of acceptable
  certificate_authorities, represented in DER-encoded format.

What would be the right behavior if the server has the certificates of two
different CAs (different subject key info, public key parameter) but whose
subject DN differs only for the case (for example
something like this

Subject: /C=US/ST=California/L=Mountain View/O=XXX Inc/CN=mail.xxx.com

and


Subject: /C=US/ST=California/L=mountain View/O=XXX Inc/CN=mail.xxx.com

Note the different (M|m)ountain
)

1 - In one case the server could send both DNs to the client, the client
could choose the one that signed its certificate, and the server would be
able to validate, based on the autority key identier, the client with the
right CA.

2 - In another case, instead, the server chooses to send only one of the
two DNs, probably the first configured, and if that is not the one that
signed the client certificate, the authentication would not continue.

I have seen that some TLS implementations follow both of the behaviors
described and this creates interoperability issues, i think. It should not
be an ambiguous behavior, and it should be clarified.

Opinions ?


Thanks you very much for the attention

Ciao

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

Re: [TLS] draft-ietf-tls-record-limit-01

[Hubert Kario]

On Monday, 25 September 2017 04:12:09 CEST Martin Thomson wrote:
> Hi Hannes,
> 
> I appreciate that the way that you calculate the available space is
> difficult, but I did think very long and hard about this.
> 
> The current approach makes it easier for someone to *comply* with the
> size limit and I'd like to retain that property as much as possible.
> I want people to implement and deploy this extension in every stack
> even if they don't have a way to set a limit lower than 16k.
> 
> The only alternative metric I can think of is the size of the
> ciphertext.  The other overheads are either fixed or hard to measure
> at the (D)TLS layer.  Other measures are too situation-dependent, such
> as whether you need to count TCP headers, and leads to other problems
> like what you do about TCP header extensions.
> 
> A change to the length of ciphertext makes it more difficult to
> implement at the point when you fragment messages generically.  And
> that means more testing.  As it is, I replaced a constant
> (MAX_FRAGMENT_LENGTH) with a variable (recordSizeLimit) and the code
> was basically done.  

my understanding of this draft was that the TLS1.3 ContentType is included in 
the record limit while it is not included in the TLS 1.3 maximum payload size

> Requiring calculations here adds risk and you
> want as many people who are NOT building an implementation for
> constrained devices to implement this as possible.
> 
> Yes, if you want byte-accurate numbers, the configuration calculation
> is going to need:
> 
> * information about the lower layers of the stack (TCP/UDP/IP) and how
> much space they need
> * information about TLS versions for the explicit IV
> * information about enabled cipher suites and their maximum expansion
> 
> The good news is that if you use TLS 1.3, all the AEADs have an
> expansion of 16 octets (unless you are using the truncated CMAC suite,
> which I have never seen myself) and records add 5 octets.  The whole
> CBC EtM/MtE business is a mess for sure, but I think that we're
> putting the costs in the right place.
> 
> As Hubert observes, you can always assume the worst case expansion,
> which is safe and relatively easy.
> 
> Note that TLS 1.3 padding is covered, so no concern there.
> 
> On Thu, Sep 14, 2017 at 12:17 AM, Hannes Tschofenig
> 
>  wrote:
> > Hi Hubert,
> > 
> > your proposal to include the worst case calculations are indeed another
> > possibility. It provides more information for the developer than the
> > current version of the document.
> > 
> > A few additional remarks:
> > 
> > On 09/12/2017 08:11 PM, Hubert Kario wrote:
> >> On Tuesday, 12 September 2017 14:30:48 CEST Hannes Tschofenig wrote:
> >>> Hi Martin,
> >>> 
> >>> I have implemented the record size extension into mbed TLS. It can be
> >>> found at https://github.com/ARMmbed/mbedtls/pull/1088
> >>> 
> >>> There is only one problem that remains to be addressed IMHO. This
> >>> extension was developed to address the problem of devices with small
> >>> RAM. Application developers have to configure their embedded TLS stack
> >>> in such a way that the parameters configured with this TLS extensions
> >>> match the available hardware.
> >>> 
> >>> The record_size_limit helps a lot already but does not quite to the
> >>> final goal since it uses an artificial metric for deciding when to
> >>> fragment records.
> >>> 
> >>> Currently, a developer has to understand various security concepts to
> >>> get this right, namely
> >>> 
> >>>  * Ciphersuite negotiated (and the overhead associated with it, such as
> >>> 
> >>> tag length),
> >>> 
> >>>  * DTLS vs. TLS record layer header differences,
> >>>  * potential compression being applied.
> >>> 
> >>> Additionally, there is, of course, other header information that needs
> >>> to be considered in the overall buffer size calculation, such as TCP or
> >>> UDP, IP and potentially any lower layer headers.
> >>> 
> >>> I just think that this is too much to ask for from an ordinary
> >>> developer.
> >>> 
> >>> Hence, I would suggest to use a different metric so that the developer
> >>> can be certain that at least from a DTLS/TLS layer there are not records
> >>> being sent that exceed the indicated threshold.
> >>> 
> >>> If you think that this idea is worthwhile to entertain then I will make
> >>> a proposal.
> >> 
> >> yes, I too found the necessary calculation rather complex and thus hard
> >> to get right
> >> 
> >> that being said, if you are ok with "good enough" solutions (for memory
> >> allocation, for verifying correctness of packets it should be exact), the
> >> actual receive buffer for encrypted TLS records has to be only 85 bytes
> >> longer>> 
> >> than the value you send to server:
> >>  - max MAC size - 48 bytes
> >>  - max IV size - 16 bytes
> >>  - header size - 5 bytes
> > 
> > ... unless DTLS 1.2 is used where it is 13 bytes. For DTLS 1.3 is most
> > likely different since we are trying to optimize the record layer