Subject: [TLS] Proposed working group charter update

From: Joe Salowey <[email-masked]>
Date: Sun, 10 Apr 2011 14:25:44 -0700

Sean has asked that we update the working group charter.  An overview of the update was given at IETF 80.  Below is a proposed text along the lines of what was discussed.   Please send comments on this text to the list.  

Thanks,

Joe

The TLS Working Group was established in 1996 to standardize a
'transport layer' security protocol. The working group began with SSL
version 3.0. The TLS Working Group has completed a series of
specifications that describe the Transport Layer Security protocol
versions 1.0, 1.1, and 1.2, extensions to the protocol, and new
ciphersuites to be used with TLS.

The primary goals of the WG are to maintain:
  - The TLS protocol, RFC 5346;
  - The TLS extension definitions, RFC 6066;
  - The DTLS protocol, RFC 4347bis.
The WG will attempt to avoid gratuitous changes to these protocols.

The secondary goals of the WG are to publish:
  - Recommendations for use of TLS;
  - Extensions to TLS and DTLS; and,
  - Cipher suites.

---

From: Robert Cragie <[email-masked]>
Date: Sun, 10 Apr 2011 23:03:37 +0100

That should be RFC 5246.

Robert

On 10 Apr 2011 22:25, "Joe Salowey" <[email-masked]> wrote:

Sean has asked that we update the working group charter.  An overview of the
update was given at IETF 80.  Below is a proposed text along the lines of
what was discussed.   Please send comments on this text to the list.

Thanks,

Joe

The secondary goals of the WG are to publish:
 - Recommendations for use of TLS;
 - Extensions to TLS and DTLS; and,
 - Cipher suites.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 10 Apr 2011 16:10:11 -0700

>  - The TLS protocol, RFC 5346;

That *could* be read to mean that the WG is not supposed to work on TLS 1.3. If that is the intention, then the charter should say so explicitly. If it is not the intention, than the charter should say "The TLS 1.2 protocol and its successors".

>  - The TLS extension definitions, RFC 6066;

That document does not define all extensions. Also, that document probably does not need maintenance outside what is covered in the second bullet in the secondary goals. Please consider removinv this bullet.

>  - The DTLS protocol, RFC 4347bis.

That specific document will hopefully be an RFC within a few months. Similar to the above, maybe say "The DTLS 1.2 protocol and its successors".
>  - Extensions to TLS and DTLS; and,

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 10 Apr 2011 21:48:37 -0700

On Sun, Apr 10, 2011 at 4:10 PM, Paul Hoffman <[email-masked]> wrote:
> That *could* be read to mean that the WG is not supposed to work on TLS 1.3. If that is the intention, then the charter should say so explicitly.

I hope that's how it should be read. I don't see any pressing need for
the TLS WG to do a TLS 1.3.

> That document does not define all extensions. Also, that document probably does not need maintenance outside what is covered in the second bullet in the secondary goals. Please consider removinv th…

I'm fine with that.

> That specific document will hopefully be an RFC within a few months. Similar to the above, maybe say "The DTLS 1.2 protocol and its successors".

Yes, I agree that we should do to address that point.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 11 Apr 2011 08:38:28 +0200

> the TLS WG to do a TLS 1.3.

Over the years, I've kept a list of issues of TLS (apply to TLS 1.2).

(I skip all the issues already reported by Peter Gutmann at:
http://www.ietf.org/mail-archive/web/tls/current/msg07608.html )

* Renegotiation semantics are unclear. When one is supposed to
do renegotiation? How to distinguish data before a renegotiation
and after? (especially since application data are allowed
to be processed during a renegotiation). See also
http://www.ietf.org/mail-archive/web/tls/current/msg05607.html

* RFC6066 Max fragment size cannot be used to increase the TLS fragment,
thus punishing hardware accelerated implementations, that have
to stick to the maximum 16k header.

* The RFC6066 truncated HMAC extension is very limited as it
only truncates to 80-bits. It could be very useful especially
in DTLS where the fragment size is very limiting, but not
in its current form. 80-bits should be enough for everybody
is not very convincing. Common security levels should
be allowed at least (64/80/96/128/192/256). This extension
might belong to the core TLS protocol if it is ever made aware
of security levels.

* Short finished message signature fixed to 12 bytes. The provisioning
of TLS 1.2 for ciphersuites to increase it was never used
by ciphersuites that aimed high security levels (AES-256, HMAC-384),
thus it is pretty much already obsolete. It seems the finished
message size should be defined by the TLS protocol itself
to be usable. (this is another argument of TLS being made
aware of security levels).

* TLS version negotiation. If 1.1 and 1.3 is implemented, then
negotiation will always fail if talking to a 1.2 server. This
requires a client to implement all possible TLS protocols
instead of the latest and a fallback (e.g. TLS 1.0).

* AEAD interface was defined only for stream ciphers. If a block
cipher emerges for AEAD it will not be usable with TLS.

* It is not known when is record version acceptable. Is a record
version of 3.55 acceptable? Is 4.0 acceptable? What about 65.35?
There should be at least a ranges of acceptable record version
numbers (for the initial hello message).

Thus for me there should be work to solve those issues.

regards,
Nikos

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Apr 2011 20:33:33 +1200

Nikos Mavrogiannopoulos <[email-masked]> writes:

>* RFC6066 Max fragment size cannot be used to increase the TLS fragment, thus
>punishing hardware accelerated implementations, that have to stick to the
>maximum 16k header.

Is there any server around that implements this?  I know that some
implementations advertise support for it, but I've never found anything where
I could actually test my code (which has been commented out pretty much
forever due to lack of anything else that does it).

>* The RFC6066 truncated HMAC extension is very limited as it only truncates
>to 80-bits.

Since, according to the Wikipedia TLS implementation survey, there are
precisely zero implementations of this, I don't think it matters much what it
truncates to.

>* Short finished message signature fixed to 12 bytes. The provisioning of TLS
>1.2 for ciphersuites to increase it was never used by ciphersuites that aimed
>high security levels (AES-256, HMAC-384),

We kinda went through this one recently, but I agree that it should be the
output size of the MAC used and not the IPsec cargo-cult 96 bits.

>* AEAD interface was defined only for stream ciphers. If a block cipher
>emerges for AEAD it will not be usable with TLS.

Again, support for any kind of AEAD is practically nonexistent.  We can solve
this one if it ever becomes an issue.

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 11 Apr 2011 10:51:41 +0200

> forever due to lack of anything else that does it).

GnuTLS supports it. We have a test server at
http://www.gnu.org/software/gnutls/server.html.

> precisely zero implementations of this, I don't think it matters much what it

If you do DTLS using the fancy-pancy SHA256 would take 32-bytes of your datagram
(which might be limited to 1400 bytes or so due to MTU), and having a truncation
mechanism that is really extensible in a sense that you could cut the MAC on
the security level negotiated would save precious bytes without reducing the
level. (given that the highest TLS security level is 96-bits due to
the finished
message MAC, having a 256-bit MAC at the record messages is pointless).

> this one if it ever becomes an issue.

Given that there is hardware support in modern CPUs for GCM I think AEAD
support would increase.

regards,
Nikos

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 11 Apr 2011 10:03:18 -0700

> the TLS WG to do a TLS 1.3.

I hear that you don't, but at least a few other people on the list have said that they do. The charter needs to be clear one way or the other.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Apr 2011 12:16:05 -0500

> http://www.ietf.org/mail-archive/web/tls/current/msg05607.html

I thought it was clear enough: when the client wants to do it (even
though the server can ask the client to do it, the client needn't do
it until it's ready).  But of course, the devil's in the detail...
And ultimately this ties into what the actual APIs look like, because
the application really needs to be in charge of renegotiation
boundaries (i.e., when the server wants it, and when the client starts
it).

> [...]

Hopefully there will not be a TLS 1.3.  Instead we should use all the
extensibility in 1.2 to avoid the need for 1.3.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 11 Apr 2011 12:06:32 -0600

On 4/11/11 11:03 AM, Paul Hoffman wrote:
>>>> The primary goals of the WG are to maintain: - The TLS
>>>> protocol, RFC 5346;
>>> 
>>> That *could* be read to mean that the WG is not supposed to work
>>> on TLS 1.3. If that is the intention, then the charter should say
>>> so explicitly.
>> 
>> I hope that's how it should be read. I don't see any pressing need
>> for the TLS WG to do a TLS 1.3.
> 
> I hear that you don't, but at least a few other people on the list
> have said that they do. The charter needs to be clear one way or the
> other.

Well, rechartering isn't that expensive, so the WG could always
recharter again when folks think it needs to work on TLS 1.3. But I'd
agree that this needs to be clear in this version of the charter.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Marsh Ray <[email-masked]>
Date: Mon, 11 Apr 2011 13:58:39 -0500

> agree that this needs to be clear in this version of the charter.

The idea that the charter would actively prohibit the group from 
considering what might go in TLS 1.3 seems strange to me.

If someone wanted to develop a version increment on the standard does 
this mean they would have to do it outside the WG?  Would the WG then 
refuse to look at it? Of course, this may be something of a moot point 
given the acceptance level of TLS 1.1 and 1.2.

But some recent extensions have the potential to give a significant 
performance improvement at the cost of added complexity. There have also 
been questions about the strength of Finished.verify_data, which is 
really not negotiable via an extension.

If a significant protocol improvement, the natural expression of which 
needed a version bump, were to be proposed is the group charter a good 
basis for rejecting it out-of-hand?

Recent extension proposals have been coming from vendors and other 
interested parties. Why does the WG feel the need to tie its own hands 
with respect to base protocol versioning?

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 Apr 2011 21:23:32 +0200

> considering what might go in TLS 1.3 seems strange to me.

The charter cannot limit what the group considers. You can start a discussion on the mailing list for almost anything, and the best WG chairs or ADs can do is ask you to pretty please get back to discussing charter items.

> given the acceptance level of TLS 1.1 and 1.2.

You can always submit draft-ray-tls-1-3-00.txt, and tell everyone on the list about it. If the group wants to accept it as a working group item, then it will have to recharter.

Also, all the big browsers now support TLS 1.1 and 1.2. Microsoft and GNU-TLS based servers also support them. OpenSSL still doesn't, but that's bound to change sometime.

> really not negotiable via an extension.

I don't see why it's not negotiable via an extension, but if it's not, go ahead and write that draft.

> basis for rejecting it out-of-hand?

No. It's a good basis for saying, "Hold on. We have to go to the ADs and recharter for this"

> with respect to base protocol versioning?

If you compare the proposed charter to the ipsecme charter ( http://tools.ietf.org/wg/ipsecme/charters ) you can see that this one is far broader and more open-ended. While this one says that the WG goal is to publish extensions, the ipsecme charter enumerates the specific extensions. To add any new item to the agenda, the ipsecme group has to recharter.

I don't know what level of open-endedness is best, but as Peter said, rechartering is not all that difficult.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 11 Apr 2011 21:26:33 +0200

On 04/11/2011 07:16 PM, Nico Williams wrote:

>> * Renegotiation semantics are unclear. When one is supposed to do
>> renegotiation? How to distinguish data before a renegotiation and
>> after? (especially since application data are allowed to be
>> processed during a renegotiation). See also 
> And ultimately this ties into what the actual APIs look like,
> because the application really needs to be in charge of
> renegotiation boundaries (i.e., when the server wants it, and when
> the client starts it).

I wasn't clear enough. RFC5246 mentions:
    "HelloRequest is a simple notification that the client should begin
     the negotiation process anew.  In response, the client should send
     a ClientHello message when convenient. "
So when is convenient? For how long should a server wait for
renegotiation? Would it be wait for 10 application data packets? 10
seconds? Forever? If I want to require renegotiation as a server
what should I do? It is not possible to implement the described semantics.

>> [...] * TLS version negotiation. If 1.1 and 1.3 is implemented,
>> then negotiation will always fail if talking to a 1.2 server. This 
>> requires a client to implement all possible TLS protocols instead
>> of the latest and a fallback (e.g. TLS 1.0).
> Hopefully there will not be a TLS 1.3.  Instead we should use all
> the extensibility in 1.2 to avoid the need for 1.3.

The same problem exists for TLS 1.2 and TLS 1.0. I cannot skip
the implementation of TLS 1.1, if I would like to. This is not
a problem for my implementation in particular, but newcomers
would probably want to implement the latest version and a
fallback such as TLS 1.0 or SSL 3.0. This is not possible today.
One has to implement the whole list of published protocols.

regards,
Nikos

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Apr 2011 00:28:23 +0200 (MEST)

Nikos Mavrogiannopoulos wrote:
> > > Nikos Mavrogiannopoulos wrote:
> > > * Renegotiation semantics are unclear.

The issue is two fold:

  - the TLS spec says so little about renegotiation that this protocol
    feature went completely unreviewed for 15 years.  And the security
    ramifications of the little that is says are not described, either.

  - there is just about any conceivable behaviour present in the
    installed base.  It would seem unreasonable to limit any future
    guidance to what might have been conceived by the original authors
    of the renegotiation at Netscape.

> >
> > >   When one is supposed to do renegotiation?

  1.)  DON'T
  2.)  If you can't be good, at least be good at it: rfc5746
  3.)  pray that your peer doesn't abort on renegotiation requests

> > >   How to distinguish data before a renegotiation and after?
> > >    (especially since application data are allowed to be processed
> > >     during a renegotiation). See also 

If you take into account HTTP Request pipelining, then there could be
a lot of app-data records sitting in the network OS receive buffer of
a server that decides to request renegotiation from a client.

> what should I do? It is not possible to implement the described semantics.

An even more difficult question is about "when is the client authenticated
during renegotiation"?  If a TLS server uses an event-based API, and
that event-based API is called when the server processes the Client
Certificate handshake message, then you already have a security problem,
since the authentication of the client requires at least the successful
validation of the CertificateVerify handshake message of an rfc5746-
protected renegotiation to be secure.

The following requirement in the spec looks dangerous for
assumptions of calling applications:

TLSv1.2, Section 6.2.1  Fragmentation (last paragraph)
http://tools.ietf.org/html/rfc5246#section-6.2.1

   Note: Data of different TLS record layer content types MAY be
   interleaved.  Application data is generally of lower precedence for
   transmission than other content types.  However, records MUST be
   delivered to the network in the same order as they are protected by
   the record layer.  Recipients MUST receive and process interleaved
   application layer traffic during handshakes subsequent to the first
   one on a connection.

> One has to implement the whole list of published protocols.

I believe the problem is worse:

Due to version intolerance interop problems, it seems currently
not advisable to send a client version higher than TLSv1.0 unless there
already is an application-level reconnect fallback in place.

Or in other words: the existing TLS protocol version negotiation
does not work in the installed base as designed and ought to be
replaced.

While SSLv3 -> TLSv1.0 -> TLSv1.1 could mostly be seen as generally
useful security improvements, I doubt that this characterization
applies to rfc5246.  So yes, I also see a need to sidestep
TLS protocol versions by now.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 11 Apr 2011 12:56:26 -0700

On Apr 11, 2011, at 12:23 PM, Yoav Nir wrote:
> The charter cannot limit what the group considers.

Er, yes it can, if the WG chairs want to use it as a tool to do so. It sounds like Ekr, in fact, wants this tool.

> You can start a discussion on the mailing list for almost anything, and the best WG chairs or ADs can do is ask you to pretty please get back to discussing charter items.

And then you have an uphill battle.

> You can always submit draft-ray-tls-1-3-00.txt, and tell everyone on the list about it. If the group wants to accept it as a working group item, then it will have to recharter.

In such a situation, the WG does not *have* to recharter. The chairs can set up roadblocks. (I say this as a chair who has, in the past, set up such roadblocks.)

> I don't know what level of open-endedness is best, but as Peter said, rechartering is not all that difficult.

He said that it was not expensive, not that it wasn't difficult. Rechartering is difficult when one or both chairs doesn't want it.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Apr 2011 00:42:46 +0200 (MEST)

Joe Salowey wrote:
>   - The TLS protocol, RFC 5246;

I'm irritated by this particular combination of statements.

It creates the impression that you want to preclude the TLS WG
from working on fixes for the problems of TLSv1.2 that have already
been identified.

Personally, I'm seeing so many problems with the original TLS protocol
version negotiation, that I think that needs to be changed as well
in order to improve the interop with the installed base and improved
migration to future protocol updates.

During its lifetime IPv4 was faced with challenges to its original
design.  Anyhow, the IETF adopted CIDR at some point, and in spite
of initial fierce resistance against it, the IETF at some point accepted
the existence and use of NAT to address problems of the real world.

I believe that we are seeing a divergence with the TLS specs from
the necessities and (interop) problems of the real world, and the TLS WG
ought to be pragmatic and propose remedies for the real world, rather
than start religious wars about what a perfect world should look like.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Apr 2011 18:07:29 -0500

> from working on fixes for the problems of TLSv1.2 that have already

I suppose it depends on what is meant by "maintain the protocol".  I
assumed "fix bugs", "clarify", that sort of activity -- what else
could be meant by that?  Specific proposals to fix protocol or
specification bugs may or may not be "gratuitous".

Taken together, and unless I'm misreading the meaning of "maintain", I
think the above means that simple fixes to protocol and/or
specification bugs will generally be adopted, while fixes that would
amount to, say, a new minor version of the protocol would not be.

If the proposed charter text confuses you regarding this, then it
should be clarified.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 Apr 2011 22:23:23 +0200

> And then you have an uphill battle.

A lot of pushing documents forward feels like an uphill battle. If you can get enough people to support the idea, these battles can be won.

> In such a situation, the WG does not *have* to recharter. The chairs can set up roadblocks. (I say this as a chair who has, in the past, set up such roadblocks.)

Did you set up roadblocks against WG consensus?  If so, then the ADs should have intervened.  This was not the case in ipsecme where the chairs and ADs limited the amount of items on the group's agenda. Sure, some people didn't like it that their pet drafts were excluded, but I think there was consensus for not taking on a dozen items at the same time.

> He said that it was not expensive, not that it wasn't difficult. Rechartering is difficult when one or both chairs doesn't want it.

I think the chairs could make it just as difficult, even if the charter said "maintain TLS 1.2 and write future versions if needed".

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Apr 2011 01:25:27 +0200 (MEST)

> to stick to the maximum 16k header.

It it really weird to deny communication peers to consensually negotiate
fragments larger than 16 KByte.

> might belong to the core TLS protocol if it is ever made aware

I hadn't noticed that limitation of this TLS extension.

Considering the guidance in rfc2104 and the work in the IPSEC area,
it seems strange that truncation for the data HMACS to half the
underlying hash output size is not part of the TLS base spec already.

> aware of security levels).

Yup, that should be fixed along the way.

> instead of the latest and a fallback (e.g. TLS 1.0).

The most significant problem that I have with the existing TLS
specs is that every implementor has to work out the differences
all by himself.  And the less experience one has with any of
the protocols (SSLv3,TLSv1.0,TLSv1.1,TLSv1.2) the more difficult
it is to start a new implementation with the necessary generality
that it will support all protocol versions with no changes to
the architecture of the implementation.

As you can see from the discussion in the TLS WG archives, for the
original design of SSLv3, you did not need to memorize handshake
messages to compute the handshake message hash that was used by
the ClientVerify handshake message and by the PRF(), and that
design was explicitly carried over to TLSv1.0 (and TLSv1.1).

The design of the TLSv1.2 signature algorithm extension as well as
the CertificateRequest handshake message break with this design
in a very bad way -- and neither does TLSv1.2 indicate that it
breaks that design, not does it give any rationale why breaking
this would be necessary.  

> numbers (for the initial hello message).

That particular question should be easy to answer by common sense.

The protocol version on the record layer gives you the protocol
version of the PDU(!).  Sending { 0x03,0x00 } ist the most sensible
default for ClientHello on the initial handshake of a new connection.

If a client does not care about getting back a TLS alert from old servers,
the client may use the lowest protocol version in the record layer, that
it would be willing to negotiate (because the server will have to be able
to parse protocol PDUs of that protocol version).

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Apr 2011 14:52:04 -0500

> what should I do? It is not possible to implement the described semantics.

If you distinguish between "TLS" and "application" server then the
answer should be obvious: the TLS implementation on the server side
doesn't "wait" -it just sends the request on behalf of the
application- while the application on the server side does whatever is
appropriate for it.  For example, an LDAP server might request
renegotiation and treat the connection as unauthenticated until the
client either renegotiates or, perhaps, does some acceptable LDAP SASL
Bind operation.  Similarly for IMAP, and other protocols for that
matter.  It seems silly to discuss renegotiation as a way to
authenticate the client user without distinguishing between TLS and
the application.

This is why I keep harping on the need for abstract APIs: it helps
draw such distinctions and delineate responsibility for different
actions (e.g., TLS vs. application), and it helps implementors design
actual APIs that provide the necessary functionality.

Without abstract APIs we end up writing text like what you quote.

Fortunately it is often/usually possible to analyze a situation such
as this one from an API point of view and make the inference I drew
above, and which I called "obvious" -- it's obvious to me, though only
because I applied that p.o.v.  Of course, you and/or others might
disagree with this point of view, or you might point to examples where
what got implemented conflicts with my interpretation of that text
(though this latter wouldn't invalidate that interpretation).

> One has to implement the whole list of published protocols.

That is very sad.  How much work is it to implement 1.1 though, if you
already have 1.0 and 1.2?  I suspect it's not that much.  Implementing
1.2 if you have 1.1 and 1.3 might be a huge PITA, however, depending
on what ever goes into 1.3.

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 13 Apr 2011 01:54:01 +1200

Nikos Mavrogiannopoulos <[email-masked]> writes:

>If you do DTLS using the fancy-pancy SHA256 would take 32-bytes of your
>datagram (which might be limited to 1400 bytes or so due to MTU), and having
>a truncation mechanism that is really extensible in a sense that you could
>cut the MAC on the security level negotiated would save precious bytes
>without reducing the level. (given that the highest TLS security level is 96-
>bits due to the finished message MAC, having a 256-bit MAC at the record
>messages is pointless).

Ah, good point.  In fact you could truncate every MAC to about 64 bits without
losing any security.

>Given that there is hardware support in modern CPUs for GCM I think AEAD

AES-GCM is a stream cipher, so there isn't a problem with this anyway.  What
you'd need is some as-yet-unspecified AEAD block cipher, if we haven't even
got GCM support deployed then I don't think unspecified-block-cipher support
is anything to worry about.

Peter.

---

From: Joe Salowey <[email-masked]>
Date: Tue, 12 Apr 2011 11:36:01 -0700

> from working on fixes for the problems of TLSv1.2 that have already

[Joe]  This is not the intention.  Fixes problems or clarifying the protocol would be part of maintenance as long as the changes are not too great.   If the changes are significant then the work would require adding to the charter.  Depending upon the consensus around the issue this can be difficult or not.  Given the problems discussed on this thread, if there were consensus to address them, it does not seem to me they would require a modification to the charter.   There could be some approaches to solving these problems (such as changing the TLS version number) that would require changing the charter.   I'll try to come up with some better wording.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 12 Apr 2011 14:18:22 -0500

On 04/12/2011 08:54 AM, Peter Gutmann wrote:
> Nikos Mavrogiannopoulos<[email-masked]>  writes:
>

Does that really follow in practice?

In order for the bad guy to arrange a situation where Finished messages 
could be collided he may need 2^49 or so active server and/or client 
sessions or handshake attempts in play at the same time. But a collision 
on a DTLS record MAC may simply need that quantity of data records in 
order to be useful. Most protocols will hopefully have far more data 
packets than handshake messages. So a Finished message collision seems 
categorically harder than a data record collision.

Many of us feel that the 96-bit Finished.verify_data length is too 
short, but thankfully there are some mitigating factors that seem to 
make an attack impractical.

We should not then interpret it as an absolute 48-bit ceiling on the 
security factor which justifies adjusting the strength of other parts of 
the system downwards.

- Marsh

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 12 Apr 2011 22:28:18 +0200

> categorically harder than a data record collision.

Why is that? Both are fatal if verification fails, thus any attack would
have the same effect being on finished message or record message.

> make an attack impractical.

The same factors make the attack impractical for application data
records that have much larger MAC attached to them. I don't see why
there needs to be a different handling of those two MACs.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 12 Apr 2011 22:30:01 +0200

> Ah, good point.  In fact you could truncate every MAC to about 64 bits without

Do you mean to 96-bits? With 64-bits you lower your security level to
64-bits from 96.

regards,
Nikos

---

From: Marsh Ray <[email-masked]>
Date: Tue, 12 Apr 2011 16:27:20 -0500

On 04/12/2011 03:28 PM, Nikos Mavrogiannopoulos wrote:
>> So a Finished message collision seems categorically harder than a
>> data record collision.
>
> Why is that? Both are fatal if verification fails, thus any attack
> would have the same effect being on finished message or record
> message.

The DTLS RFC sums up one way they are different:

http://tools.ietf.org/html/rfc4347#section-4.1.2
>
> Note that one important difference between DTLS and TLS MAC handling
> is that in TLS MAC errors must result in connection termination.  In
> DTLS, the receiving implementation MAY simply discard the offending
> record and continue with the connection.  This change is possible
> because DTLS records are not dependent on each other in the way that
> TLS records are.
>
> In general, DTLS implementations SHOULD silently discard data with
> bad MACs.

This is comparing DTLS and TLS record MACs, but Finished messages are 
analogous to TLS record MACs in that they are consipcuously fatal.

I admit it's not a rigorous argument, but it just seems a bit more 
plausible that a DTLS endpoint would silently discard 2^(security 
factor) datagrams than that a client or server experiencing a similar 
number of handshake failures would go unnoticed.

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Apr 2011 14:39:38 -0700

On Tue, Apr 12, 2011 at 2:27 PM, Marsh Ray <[email-masked]> wrote:
> I admit it's not a rigorous argument, but it just seems a bit more plausible
> that a DTLS endpoint would silently discard 2^(security factor) datagrams
> than that a client or server experiencing a similar number of handshake
> failures would go unnoticed.

I agree that DTLS is significantly more vulnerable to packet forgery at a given
MAC length than TLS.

For a given MAC length, the chance that an arbitrary packet/MAC pair
will verify is 2^{-k} where k is the number of bits in the MAC. With TLS, as
the consequence of a failed MAC is that the connection is terminated, an
attacker only gets one try per connection. With DTLS, because the packet
is just dropped, you get an arbitrary number of trials per connection. However,
even for a 64-bit MAC, that means you would need to send 2^{64} packets
in order to get a single accepted forgery, so that seems like a pretty high
level of security.

-Ekr

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 13 Apr 2011 19:00:44 +1200

Nikos Mavrogiannopoulos <[email-masked]> writes:

>Do you mean to 96-bits? With 64-bits you lower your security level to 64-bits 
>from 96.

No, I meant 64.  Having a 1 in 2^64 chance to guess a MAC isn't going to make 
things any easier for an attacker than a 1 in 2^96 chance (for pure TLS, where 
you get one guess and then get disconnected).  For DTLS it's a little bit 
easier, but still astronomically remote.

Peter.