Re: [TLS] Are we holding TLS wrong?

[Fossati, Thomas (Nokia - GB/Cambridge)]

Hi David,

A few quick notes below.

Cheers

The 11/08/2018 09:14, David Schinazi wrote:
> Hi everyone,
> 
> Over in the Babel working group we have a draft about securing Babel with
> DTLS:
> https://tools.ietf.org/html/draft-ietf-babel-dtls-01
> 
> It's 5 pages long, could any TLS experts please give it a quick read and
> let us know if we're using DTLS correctly?
> 
> Also, should the document contain guidance such as which DTLS version to
> use?
> 
> Thanks,
> David

Premise: I don't know Babel -- apologies for any nonsense!

One high level thing which I can't extrapolate from the draft (which is
probably due to my ignorance with Babel) is whether you envisage that
*every* node does DTLS on the unicast channel, IOW that non-DTLS nodes
are excluded from the mesh?  Or would it be acceptable to mesh HMAC and
DTLS neighbours?  What about clear-text speakers?  (It'd seem unwise to
let them in an otherwise secured enclave.)

You should probably provide some guidance about the kind of
credentials do you plan to use (certs, raw pkeys)?

It seems to me that the P2P nature of the protocol requires mutual
authentication, could you confirm it?  This seems to be a critical thing
to prevent a rogue node to spoof the lowest (highest, I have already
forgot, sorry) L-L address in a clear-text multicast Hello and bypass
authentication.

- s2.1
"Nodes SHOULD ensure that new client DTLS connections use different
 ephemeral ports from recently used connections to allow servers to
 differentiate between the new and old DTLS connections."

Maybe you could suggest using a sufficiently entropic connection id here
as a more robust alternative.

- s2.5
Not sure what the ceremonies around flushing a neighbor are, but I'd
make explicit signalling EOD at least a SHOULD?  It seems more polite
:-)

- s.3
Not sure which TLS stack Babel nodes will use (are you targeting
extremely constrained devices with custom TLS implementations?), but all
the stacks I know of let the application set the MTU and take care of
splitting the messages in MTU sized chunks transparently.

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

Re: [TLS] Connection ID in TLS

[Fossati, Thomas (Nokia - GB/Cambridge)]

On 20/03/2018, 16:38, "TLS on behalf of John Mattsson"  wrote:
> At the Monday afternoon TLS session, it was stated that Connection ID
> in TLS was unemployable in the wild due to middleboxes. Couldn't that
> be solved by placing the cid field after the length field?

Are you referring to slide 13 of [1]?

If so, the problem is not CID-specific.  It's more generally what
could happen if we try and reuse the top bit of the length field
for other purposes.

Yoav brought up the case of an intercepting middlebox - one that needs to
pretend to be a fully-fledged TLS server.  That kind of box might
either:
- let the extension that enables repurposing the length's MSB pass
  through, and subsequently choke on the invalid length [HARD FAIL];
- eat up the unknown extension and therefore break the feature
  negotiation [SOFT FAIL].

Cheers


[1] 
https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessb-record-header-extensions-for-dtls-00

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

Re: [TLS] a slightly different DTLSShortCiphertext

[Fossati, Thomas (Nokia - GB/Cambridge)]

On 05/03/2018, 00:27, "Eric Rescorla" mailto:e...@rtfm.com>> 
wrote:
I genuinely can't see what advantage we get by not having its
presence explicitly signalled.  Could you elaborate a bit on that?

Well, you're making every packet 1 byte bigger, for starters.

If the cost of having simple, straightforward implementations while at the same 
time easing the operational side of the world is 1 byte per packet, I’m happy 
to pay the price.

People with use cases where a 1-byte overhead really matters already think 
(D)TLS is too chatty.  In fact, that’s one of the main reasons OSCORE exists.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] a slightly different DTLSShortCiphertext

[Fossati, Thomas (Nokia - GB/Cambridge)]

On 04/03/2018, 23:12, "Martin Thomson"  wrote:
> We are about to remove that bit from the QUIC packet.  I don't see any
> advantage in adding it here.
> 
> Can you explain in more detail who you think consumes this bit?

Server or server-side middleware that doesn't know whether the packet
that needs parsing belongs to a session that negotiated CID or not.  I'm
not sure the analogy with QUIC holds here: AFAIU, in QUIC the server can
always say "use CID when you are talking to me"; in DTLS, the server has
to live with a mix of CID and non-CID sessions.

On-path diagnostic tooling.  E.g., if you have a huge fleet of sensors
deployed behind a NAT where rebindings happen basically every time the
sensor sends the update upstream (the 5-tuple is totally ephemeral), and
you need to do anomaly detection, being able to extract the CID from the
flows is pretty handy.  But in general, when you don't own the endpoints
and are asked to debug, having a working wireshark is nice.

I genuinely can't see what advantage we get by not having its
presence explicitly signalled.  Could you elaborate a bit on that?

Cheers, thanks

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

[TLS] a slightly different DTLSShortCiphertext

[Fossati, Thomas (Nokia - GB/Cambridge)]

Hi all,

In an off-list discussion on the wire format for DTLS CID Eric raised
the point that a DTLSShortCiphertext header is completely stuffed, and
it'd be impossible to grab another bit from the sequence number (already
down to 12 bits) to signal the presence of a CID.

I made a proposal for a slightly different layout of DTLSShortCiphertext
that makes room for the CID bit, which I'd like to bring to the list for
further scrutiny:

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|1|E|C|X|X|X|sequence   |   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +
|   |
+   +
|   |
+   [CID,] encrypted_record +
|   |
+   +
|   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 0   1   2   3

Where:
- First 4 bits are the same as in current DTLSShortCiphertext (demux +
  low order epoch bit)
- Subsequent 4 bits are: C, the connection-id indicator followed by 3
  reserved bits (to be greased, I suppose)
- Then, a 16-bit sequence number.

It'd still be 4 bytes shorter than usual DTLSCiphertext, so I guess it's
OK to keep calling it "short".  There is the question about these 3
reserved bits, which seem like good candidates for greasing, I guess.

What do people think?

Cheers, thanks

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

Re: [TLS] A question for TLS middle-box/middleware vendors/implementers

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Yoav,

On 28/01/2018, 19:38, "Yoav Nir"  wrote:
> > What I was thinking was rather "once handshake is done and client has
> > successfully passed the SNI checks, just blindly copy the byte stream
> > across." I had this specific mental model (that of an HTTPS filter) in
> > my head, which of course is just one of many.
> 
> When middleboxes just classify and route (at Check Point we called
> that “passive inspection” as opposed to “active inspection” which was
> a TLS proxy) then yes - as soon as the data becomes encrypted you
> either drop it or let it through. As this is much higher performance
> (a given piece of hardware can handle much more passive inspection
> that it can active inspection), it was preferred for domains that were
> considered low-risk. 
> 
> TLS 1.3 means that a passive proxy needs to make the decision earlier.
> 
> > If the use case is "check for data exfiltration or covert channels",
> > then the box is probably going to be a fully-fledged interception
> > proxy.  In that case the parser can't be sloppy, and the bit will
> > not go through unnoticed (as you correctly note above).
> > 
> > But - pardon a naive mind - these look like the kind of boxes that
> > you can't just switch on and forget about.  Instead, I'd imagine you
> > need to keep their release cycle aligned with that of the endpoints,
> > especially browsers, which tends to be pretty aggressive.  (But yes,
> > one thing is the vendor release cycle, and a completely different
> > one is the network operator's upgrade schedule…)
> 
> Vendors release updates at a good pace, some through software upgrades
> and some through updating data files. An upgrade from supporting TLS
> 1.2 to supporting TLS 1.3 as a proxy usually requires a software
> upgrade. But the changes for passive proxy can be done through issuing
> an update to some regular expression or other rule. Typically
> customers buy a piece of software and subscribe to updates. 
> 
> The Internet is full of old versions because the administrators don’t
> don’t want to rock the boat or are content with a good, stable
> release, the same way that Windows 7 is still so popular. In some
> cases the middlebox vendor has gone out of business.
> 
> The Internet is also full of middleboxes where the subscription was
> allowed to lapse. It seems like carelessness. 

Thanks a lot for the very instructive info.

> > Since you are here, and you have amassed a considerable amount of
> > wisdom in this space, I have a further question: Is, in your
> > opinion, DTLS in a better spot than TLS WRT the use of that bit?
> 
> With a firewall that doesn’t know about DTLS, there are three choices:
> 1. Allow all the DTLS
> 2. Block all the DTLS
> 3. Write a regular expression (or equivalent) that will check the DTLS
>handshake for sanity.
> 
> If DTLS becomes popular, newer versions of firewalls will be able to
> handle them the same as they do TLS. For now, DTLS is seeing little
> use.

So, if I read you correctly, in terms of overriding length's MSB both 1
and 3 are safe places - as long as we apply the new semantics only after
handshake has completed.

2, is either "easily" fixable via a configuration change to fall back to
one of 1 or 3, or completely unfixable - the path is totally broken for
DTLS anyway because this is how the policy maker has decided.

Cheers, t





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

Re: [TLS] A question for TLS middle-box/middleware vendors/implementers

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Yoav,

Thanks for the answers - much appreciated.

On 27/01/2018, 19:31, "Yoav Nir"  wrote:
> The length field is byte-aligned. So any implementation of a TLS
> parser or TLS proxy will do one of two things:
> 
> 1. Consider the MSB to be a must-be-zero bit and drop any length field
> that has it set as faulty.
> 
> 2. Ignore text about limits on length and assume the record is that
> big. Depending on what field that is, this may cause a drop on some
> other sanity check.
> 
> As always there’s option #3 (crash), but the industry is getting
> better at avoiding that.
> 
> You seem to want the behaviour that the middlebox masks out the
> must-be-zero bits and considers only the relevant length bits. I don’t
> think that would pass code review at my former employer.

What I was thinking was rather "once handshake is done and client has
successfully passed the SNI checks, just blindly copy the byte stream
across." I had this specific mental model (that of an HTTPS filter) in
my head, which of course is just one of many.

If the use case is "check for data exfiltration or covert channels",
then the box is probably going to be a fully-fledged interception proxy.
In that case the parser can't be sloppy, and the bit will not go through
unnoticed (as you correctly note above).

But - pardon a naive mind -  these look like the kind of boxes that you
can't just switch on and forget about.  Instead, I'd imagine you need to
keep their release cycle aligned with that of the endpoints, especially
browsers, which tends to be pretty aggressive.  (But yes, one thing is
the vendor release cycle, and a completely different one is the network
operator's upgrade schedule...)

Since you are here, and you have amassed a considerable amount of wisdom
in this space, I have a further question: Is, in your opinion, DTLS in a
better spot than TLS WRT the use of that bit?

Cheers and thanks again

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

[TLS] A question for TLS middle-box/middleware vendors/implementers

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi TLS middle-box/middleware folks,

If length's MSB in a D?TLS{Ciphertext,Plaintext,Compressed} record is
set, how does your software react?

Is it going to drop the session/record or not bothering at all?

I'm trying to understand a bit better whether and when it'd be safe to
grab that bit and give it new semantics (e.g., for signalling the
presence of a DTLS connection-id, an ext-header, or anything else
really) and your answers would help shedding some (*) light on the
matter.

Based on previous experience on similar (but not identical) changes to
the record format, Adam ([1], [2]) suggested that this bit is likely to
have already ossified in TLS, whereas DTLS might be still OK.  So, I'm
curious to hear from those who own the boxes' logics if they share the
same opinion - in particular if DTLS is in better shape than TLS?

Thanks in advance for your time.

(*) I'm pretty sure not every TLS middle-box vendor on earth is
subscribed to this list and, even among those who are, not everyone
might be willing or able to share this information with the wider
community.  This is to say that I'm aware of the limited value a poll
like this has, but I'm not in a position to do a large-scale measurement
campaign at the moment, so better start from somewhere... OTOH, I think
there is a valuable discussion to be had in cases like this with folks
that don't own the endpoints but are going to (or have already) put
their logics on the e2e path, so hopefully I'm not wasting everyone's
time :-)

cheers, t

[1] https://www.ietf.org/mail-archive/web/tls/current/msg25299.html
[2] https://www.ietf.org/mail-archive/web/tls/current/msg25304.html

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

Re: [TLS] extended headers for (D)TLS (and their use with connection-id)

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 24/01/2018, 15:53, "alang...@gmail.com on behalf of Adam Langley" 
 wrote:
> On Wed, Jan 24, 2018 at 6:31 AM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK)  wrote:
> >
> > A few months ago, Nikos (can't remember if on this list or on a side
> > conversation) came up with this thought of a generic way to extend
> > the TLS/DTLS record header.  So, I've stolen his idea and written it
> > up in [1] with the intention of using it to make room for the
> > connection-id.
> 
> Our experience with middleboxes suggests that this is likely to fault
> afoul of many flaws in these products if deployed with TLS on the
> wider internet.

Thanks for the insight.

I have thought a bit about this possibility when doing the write-up and
the "MUST NOT be used during handshake" was meant exactly to minimise
the possible impact of middle-boxes during session establishment.

So, the chances to survive handshake should be the same as usual.

After session establishment, the only thing that might look suspicious
to an on-path box is the invalid length.

Do you think this is likely to cause havoc?  Or, in your experience,
middle-boxes tend to not interfere after the TLS channel is up?

cheers

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

[TLS] extended headers for (D)TLS (and their use with connection-id)

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

How to make the existence of a connection id explicit on the wire?

We have looked at a few different approaches - in reverse hackery order:
defining new content types, using an invalid length and bumping the
version number.

Each of them comes with its small or big complications but, irrespective
of that, the basic trouble we have here is that the lack of spare bits
in the record header forces us to override semantics of existing fields
in a way that smells wrong.

A few months ago, Nikos (can't remember if on this list or on a side
conversation) came up with this thought of a generic way to extend the
TLS/DTLS record header.  So, I've stolen his idea and written it up in
[1] with the intention of using it to make room for the connection-id.

At a first glance, it seems to work quite smoothly and has a pretty
compact encoding (see [2] for the details), which would make it my first
choice over all other candidates.

Please have a look (the draft shouldn't take more than 5-10 minutes of
your time) and provide feedback if you feel like.

Thanks, cheers

[1] https://tools.ietf.org/html/draft-fossati-tls-ext-header-00
[2] https://tools.ietf.org/html/draft-fossati-tls-ext-header-00#section-3.4

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 03/11/2017, 09:28, "TLS on behalf of Martin Thomson"  wrote:
> On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell  wrote:
> > It was my understanding that it is precisely this sort of problem
> > that this draft was attempting to address. Explicit marking would
> > solve this.
> 
> Yes, and the connection ID is that marking.  The contention - I think
> - is what to do when there is a mix of marked connections and
> unmarked.

Specifically, the two lines of contention seem to be:
- On the receiver side, whether to favour survival of CID v non-CID
  bearing sessions;
- Packet analyser friendliness (i.e., being able to correctly parse
  the stream without requiring it to keep state.)

Cheers

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Martin,

sorry for taking so long to replay.

> On 18/10/2017, 09:08, "Martin Thomson" 
> wrote:
> 
> On Wed, Oct 18, 2017 at 5:44 PM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK)  wrote:
> > This is quite similar to the trial and error / heuristic that I was
> > mentioning in [1].
> 
> You didn't mention 5-tuples.  And it isn't trial and error: you use
> 5-tuple as your primary key and use connection ID to latch.

We seem to have a slightly different opinion on the meaning of trial and
error :-)  But more importantly, we seem to disagree on whether parsing
a binary header is orthogonal to context lookup (either via 5-tuple or
CID) or not.

> > Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails
> > to recognise A.1 as CID-enabled and sends it forward to the crypto
> > handler when it shouldn't.
> 
> As I said before, any connection without a connection ID monopolizes
> that 5-tuple making it inaccessible to other connections.  I think
> that in this case: too bad.

I'm not sure I agree with that.  CID should be the tie breaker exactly
in these situations.  When something like that happens, if your
implementation supports CID it should win/survive over one that doesn't.

> > And the already discussed limitations:i
> > - Fragility on corner cases (e.g., the 5-tuple swap above);
> 
> I don't see how you can avoid this in the general case.  Any
> connection without connection ID is going to be hard to correlate if
> it moves.  As for the connection that does have a connection ID but
> moves on top of a connection that doesn't, I don't think that is an
> acceptable loss.

I think you mean "I do think that is an acceptable loss", or "I don't
think that is an unacceptable loss", right?
 
> > - Forcing middleware to keep state;
> > - Breaking wireshark & co unless they can see the whole session;
> 
> Both of these are acceptable to me.  Unless you can describe a
> middlebox use case that needs access to this information and can't
> deal with the solution that I described.  Wireshark and co will need
> to see the handshake if they want to decrypt and that's the only case
> that is important.

For diagnostics, it'd be pretty useful if one could filter a capture by
CID and follow *that* session among lots of others.  Irrespective of
what's in the encrypted payloads (which one can probably get from the
endpoint, if needed).  This is one use case that seems very useful to me
and doesn't require wireshark to keep state.  I'm not saying that there
are no work-arounds: we know how to make do with pcap filters.  But I'd
prefer to design something that is simple and cheap to implement and use
in the first place, if possible.

What I'm asking for is a codepoint and an explicit length for the CID,
i.e., a total +1 byte per 1.2 record on the wire.  I'm not sure the
tiny saving we get with the current proposal justifies the increase in
complexity.

> > - (Depending on the use case, the cost of the two lookups per record
> >   on the parsing might have a performance impact.)
> 
> The second lookup only happens after a migration.

In the IoT use cases, re-binding during a sleep cycle is the common
pattern, so the second lookup is going to be fairly common.

> I neglected to mention that successful use of a connection ID causes
> the 5-tuple to be assigned to that connection; there's a trick there
> in that you need to watch for reordering, but it saves the double
> lookup.

The thing that makes me slightly nervous is that we are talking about
doing trial & errors (at least in my definition of the term) and other
implementation tricks to achieve the very trivial task of parsing a
binary header.  This is what makes red flags pop up and makes me
think that we can do better.

Cheers

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 17/10/2017, 22:35, "Martin Thomson"  wrote:
> On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK)  wrote:
> > The following case (NAT box reboot) is problematic:
> >
> > 1. Application '1' on host A (A.1) uses DTLS+CID with application
> >'1' on host B (B.1);
> > 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
> > 3. The NAT box reboots (all previous 5-tuple mappings are lost);
> > 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
> >meanwhile);
> >
> > How is B.1 supposed to correctly interpret the bytes starting at
> > offset +11?  (For what it knows, it could be CID from A.1 or the
> > length field from A.2.)
> 
> I don't think that this is a problem.
> 
> connection = five_tuples.lookup(packet.five_tuple)
> if (!connection) {
>   connection = 
> connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
> }
> if (!connection) {
>   // is this a ClientHello?  otherwise drop it
> }

This is quite similar to the trial and error / heuristic that I was
mentioning in [1].

Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails to
recognise A.1 as CID-enabled and sends it forward to the crypto handler
when it shouldn't. 

It looks simple, but it introduces subtle complexity in that parsing is
not self-contained anymore: it depends on a couple of things (the
connection_ids and five_tuples stores) that in principle should have
nothing to do with making sense of an incoming record.

And the already discussed limitations:
- Fragility on corner cases (e.g., the 5-tuple swap above);
- Forcing middleware to keep state;
- Breaking wireshark & co unless they can see the whole session;
- (Depending on the use case, the cost of the two lookups per record
  on the parsing might have a performance impact.)

> > I might be missing something fundamental here, but isn't the length
> > encoded in the CID field on the wire?
> 
> Not by my understanding.  There isn't any need (the intent is to have
> the CID only consumable by the entity that created it, and any others
> that it collaborates with, like a load balancer).

You are right.  For some reasons, I was implying cid was encoded as a
variable-length array.  That said, I don't think saving 1 byte here is
worth the self-inflicted pain of making tshark unusable :-)

Cheers

[1] https://www.ietf.org/mail-archive/web/tls/current/msg24575.html

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Nikos,

On 13/10/2017, 07:21, "TLS on behalf of Nikos Mavrogiannopoulos" 
 wrote:
> Another worrying feature is that the client can make the server send
> up to 255 verbatim bytes on the wire of his choice. Why was this
> feature added? Are there use cases related with it (intro doesn't
> mention any), or it was only thought as a make it as generic as
> possible approach? If it is the latter, I'd recommend to provide a
> simple approach that covers the described use cases.
> 
> The same argument applies to the server being able to set such a long
> sequence of verbatim bytes to each of the client packets.

I'd like to get a better understanding of your concern here.

Is it size?

Or is that it creates a potential sub-channel for sending identifying
information?

If the latter, it doesn't look much different from Random (except it's
larger)?  And then it gets hashed in the finished message, so, the room
for a third party to fiddle with it seems really limited.

Exactly, what risk do you foresee?

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Martin,

On 17/10/2017, 00:42, "Martin Thomson"  wrote:
> Thomas mentioned a heuristic, but I don't think that we need that.
> The only case that is difficult, and it's one that you might not care
> about, is one where a connection migrates to the same 5-tuple as an
> another connection.  There, you will match to an existing connection
> and find that the packet doesn't decrypt.  If the connection that you
> have associated with the 5-tuple supports and uses a connection ID,
> you can recover without trial decryption.  Otherwise, you just have to
> drop the packet when it doesn't decrypt.  (You could look up all the
> connections without connection IDs and use trial decryption, but why
> bother spending the effort and undermine the strength of your ciphers
> in that way.)

The following case (NAT box reboot) is problematic:

1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on
   host B (B.1);
2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
3. The NAT box reboots (all previous 5-tuple mappings are lost);
4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
   meanwhile);
 
How is B.1 supposed to correctly interpret the bytes starting at offset
+11?  (For what it knows, it could be CID from A.1 or the length field
from A.2.)
 
That's where the heuristic I mentioned in the other email comes in,
I think.

> Packet inspection boxes will have maintain state, I don't see a way
> around that.  The point here being that you need state to know how
> long the connection ID is, as well as how long it is.

I might be missing something fundamental here, but isn't the length
encoded in the CID field on the wire?

Cheers

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Matt,

On 13/10/2017, 14:15, "TLS on behalf of Matt Caswell"  wrote:
> Recently I met with Yin Xinxing and we have had much the same
> conversation about what a Connection ID draft would need to do, and
> how we could detect its use on the wire. Mechanisms we talked about
> included setting something in the "length" field, using ContentType or
> using version. IMO using "length" is just horrible. I'm also not keen
> on version - it further complicates the "is this version greater than,
> equal to, or less than this other version" question. It's already
> slightly complicated in code that implements both TLS and DTLS due to
> DTLS versions being high and decrementing for a new version. I foresee
> lots of subtle bugs and problems from reusing "version". In my mind
> ContentType is the way to go.

Re: the length hack.  I agree with you that it is not the right way to
go here.

Re: CT vs version, a couple of quick thoughts:
- I'm still unconvinced that CT is the right place to signify a change
  in the parsing logics that effectively spans all CTs;
- Besides, ISTM that version is the only field that would potentially
  work for 1.3 as well as 1.2?

Cheers,

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

First, thanks for the draft.

As discussed off-list, wrt framing / wire format, we probably have an 
opportunity to do slightly better than this, at least for 1.2.

The thing is that, since there is no flag in the record that says: "I'm 
carrying a CID", a receiver has no explicit way to know whether a record is 
coming from a CID-enabled session or a legacy-DTLS.

This ambiguity complicates the decoder because the receiving end now needs to 
implement a heuristic like:

-  let's first assume at offset +11 we have a CID

-  and then lookup the SAs store using this "maybe" CID

-  if found, OK (*), go on with the parsing

-  if not, fall back to assuming at offset +11 we have the length field 
and go on parsing

This is not ideal for a bunch of reasons:
1. For every incoming record, the receiver needs to lookup the CID store 
just to parse the record;
2. The implementation is more complicate;
3. Heuristics are intrinsically fragile and are known to deal badly with 
corner cases (think the many creative ways the many moving parts can conspire: 
5-tuple reshuffling because of NAT rebinding, lost state due to reboot/restart 
of one or more nodes, co-existing CID and legacy DTLS);
4. Wireshark & co will choke because they typically don't have enough 
context to handle the two different framings;

To solve this, we'd need a place in the wire image of the record with 
semantics: "I'm carrying a CID."

In 1.2, we could use CT or version.  (In 1.3, that would not be possible 
because the diet header doesn't have them - too bad.)  To me it'd make slightly 
more sense to use the version. (I had previous discussions on this topic with 
Nikos and he told me that though anyconnect does this version override for some 
reasons, there is no reported conflict with middle-boxes.)  Also, there would 
be only one code-point to allocate, instead of separate code-points for each 
CID-enabled content type variant.  I'm happy to be convinced of the opposite, 
though.

I guess my main point here is to make sure we do as much as we can to allow 
simple, efficient, robust implementations, which are also, en passant, 
Wireshark-friendly, and leave heuristics-based approaches only for when there 
is no real alternative.

Cheers, t

(*) assuming CID is entropic enough, which may or may not be the case.


On 13/10/2017, 00:13, "TLS on behalf of Eric Rescorla" 
mailto:tls-boun...@ietf.org> on behalf of 
e...@rtfm.com> wrote:

Hi folks,

I have just posted a first cut at a connection ID draft.
https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00

Comments welcome.

-Ekr



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

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Nick,

Your write-up is spot on, thanks.

Let me comment on a few points:

“How much Delegated Credentials can be rotated and diversified inside an 
organization is only limited by the operational ability of the organization 
that has control of the EE private key.”

The self-service/agile nature of D-C is great. With that, though, comes a cost 
of ownership that maybe not all players can afford.

- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must 
provide proof of domain possession to CA vs. internally managed credential 
minter for delegated credentials).

There should be ways to mitigate this, say allowing the next S-T in line to be 
available “long enough” before it becomes active.

-- There is no fallback if the CA has outage. With delegated credentials you 
can fall back to a LURK-style protocol with the long-lived certificate key.

I understand the logics but, since LURK boxes don’t scale, the cost to cover 
your entire footprint for the sporadic cases when the CA is down might be a bit 
prohibitive.

Cheers, t


On 18/07/2017, 14:35, "Nick Sullivan" 
mailto:nicholas.sulli...@gmail.com>> wrote:

Thomas,
Thanks for your comments. Let me see if I can summarize them:
- A disadvantage of delegated credentials vs short-lived certs is that it 
requires client opt-in. This is also a disadvantage of proxy certificates. If 
client support is below 100%, a LURK-type system may be required to keep 
long-term private keys off TLS termination endpoints.
- A disadvantage of delegated credentials is that it requires software updates 
on both client and server. This is also a disadvantage of proxy certificates. I 
think this is covered by my point below: "Short lived certs work with existing 
libraries, no new code changes."
- An advantage of short-lived certificates is that there is an audit log by a 
third party (either the CA's internal logs and optionally Certificate 
Transparency logs).
I should state that short-lived certificates are possible right now and it's 
supported by some CAs, though not necessarily at the scale needed to provide, 
say, a unique 7-day certificate for each server of a large Internet company. 
This draft's advantages apply most strongly to organizations who don't want to 
tie their ability to have functional TLS on the ability for CAs to maintain 
high-availability issuance services.  How much Delegated Credentials can be 
rotated and diversified inside an organization is only limited by the 
operational ability of the organization that has control of the EE private key.

Nick

On Tue, Jul 18, 2017 at 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) 
mailto:thomas.foss...@nokia.com>> wrote:
Hi Nick,

I am not against delegated credentials, in fact I think it’s a good thing per 
se.

I had expressed a couple of concerns at the time the call for adoption was 
first issued [1], which I think are still valid.

Could you please comment on / add them to your pro-cons analysis?

Cheers, thanks,
t

[1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html

On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan" 
mailto:tls-boun...@ietf.org> on behalf of 
nicholas.sulli...@gmail.com<mailto:nicholas.sulli...@gmail.com>> wrote:

Sean,
We've had some additional discussions in person here at IETF 99 with folks who 
were in the proxy certificates and short-lived certs camp, and we think there 
is now more agreement that the mechanism described in this draft is superior to 
the alternatives. I've included a summary of some of the pros and cons of the 
approaches:
Proxy certificates vs. Delegated Credentials
Pro proxy certificates:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key == certificate.
Con proxy certificates:
- Proxy certificates adds additional complexity to the delegation other than 
limiting the time period (full X.509, additional constraints  such as hostname).
- Encourages implementers to reuse PKIX libraries rather than build code as 
part of TLS:
-- There have been problems and inconsistencies around pathlen and constraints 
enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated 
creds (which can easily be implemented in TLS as demonstrated by the 3 
interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE 
cert. This is a binding weaker than delegated credentials which includes a 
signature over the EE certificate.

Short-lived certs vs. Delegated Credentials
Pro short-lived certs:
- Short lived certs work with existing libraries, no new code changes.
Con short-lived certs:
- Not widely available from CAs, especially for EV.
- Potentially problematic to the CT ecosystem (all certificates must be logged 
in CT

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Nick,

I am not against delegated credentials, in fact I think it’s a good thing per 
se.

I had expressed a couple of concerns at the time the call for adoption was 
first issued [1], which I think are still valid.

Could you please comment on / add them to your pro-cons analysis?

Cheers, thanks,
t

[1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html

On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan" 
mailto:tls-boun...@ietf.org> on behalf of 
nicholas.sulli...@gmail.com> wrote:

Sean,
We've had some additional discussions in person here at IETF 99 with folks who 
were in the proxy certificates and short-lived certs camp, and we think there 
is now more agreement that the mechanism described in this draft is superior to 
the alternatives. I've included a summary of some of the pros and cons of the 
approaches:
Proxy certificates vs. Delegated Credentials
Pro proxy certificates:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key == certificate.
Con proxy certificates:
- Proxy certificates adds additional complexity to the delegation other than 
limiting the time period (full X.509, additional constraints  such as hostname).
- Encourages implementers to reuse PKIX libraries rather than build code as 
part of TLS:
-- There have been problems and inconsistencies around pathlen and constraints 
enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated 
creds (which can easily be implemented in TLS as demonstrated by the 3 
interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE 
cert. This is a binding weaker than delegated credentials which includes a 
signature over the EE certificate.

Short-lived certs vs. Delegated Credentials
Pro short-lived certs:
- Short lived certs work with existing libraries, no new code changes.
Con short-lived certs:
- Not widely available from CAs, especially for EV.
- Potentially problematic to the CT ecosystem (all certificates must be logged 
in CT, which may bloat them).
- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must 
provide proof of domain possession to CA vs. internally managed credential 
minter for delegated credentials).
-- There is no fallback if the CA has outage. With delegated credentials you 
can fall back to a LURK-style protocol with the long-lived certificate key.

Given these comparisons, we think the proposed draft is the superior option and 
would like to continue the discussion about adopting it.

Nick

On Fri, May 19, 2017 at 12:58 AM Sean Turner 
mailto:s...@sn3rd.com>> wrote:
All,

During the WG call for adoption, a couple of questions were raised about 
comparison/analysis of sub-certs versus proxy and/or short-lived certificates.  
There is some discussion currently in the draft, but the chairs feel that these 
issues need further discussion (and elaboration in the draft) prior to WG 
adoption.  So let’s keep the conversation going.

J&S

> On Apr 12, 2017, at 15:31, Sean Turner 
> mailto:s...@sn3rd.com>> wrote:
>
> All,
>
> At our IETF 98 session, there was support in the room to adopt 
> draft-rescorla-tls-subcerts [0].  We need to confirm this support on the list 
> so please let the list know whether you support adoption of the draft and are 
> willing to review/comment on the draft before 20170429.  If you object to its 
> adoption, please let us know why.
>
> Clearly, the WG is going to need to work through the trade-offs between 
> short-lived certificates and sub-certs because both seem, to some, to be 
> addressing the same problem.
>
> Cheers,
>
> J&S
>
> [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts

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

Re: [TLS] Suggestions in draft-mavrogiannopoulos-tls-cid

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Ashok,

Thanks very much for your comments.

See inline.

Cheers, t

On 07/07/2017, 14:44, "Raja ashok" 
mailto:raja.as...@huawei.com>> wrote:

Hi Nikos, Hannes & Thomas,

This ConnectionID concept is really a useful feature for a client node which 
faces a change in transport and network layer. I am having few suggestions in 
the proposed draft, which are listed below.

1) In section 3 of this draft, explains about the modification in 
"DTLSCiphertext" structure. I feel instead of modifying existing DTLS and TLS 
record header, we can directly introduce a new record type (ContentType) for 
app data (application_data_with_cid(25)).

[tf] Why do you think a new record type would be better than the present 
construction?  (BTW, we would also need a new alert_with_cid, I guess.)

For this new record type, we can propose a modified record header for both TLS 
and DTLS.

[tf] If you are already modifying the record header, I am not sure why you also 
need to add new content type(s)?

2) More over section 3 says modification only in "DTLSCiphertext", not for 
"TLSCiphertext". I hope this CID mechanism should be used for both TLS and 
DTLS. Because this transport layer change problem is there for TLS based 
applications (HTTPS) also in Smartphone(when it switches from Wifi to LTE). But 
this TLS application problem is solved by MPTCP, but I dont think all 
webservers are supporting this MPTCP. So I feel CID is required for both TLS 
and DTLS.

[tf] In principle I’m not opposed to open the solution space to TLS, but we 
need to work out the implications.

3) As part of defining new record type, we can remove some unused fields like 
version, epoch. After removing epoch we can mandate that  both entity should 
not start renegotiation. Sample design for new record header with CID is 
mentioned below
struct {
uint8_t ContentType;
uint8_t CID_len;
CID cid;/* Length varies from 4 to 8 (or 16) */
uint48 sequence_number;
uint16_t record_length;
} DTLSRecordHeader;
opaque CID <4..8>;

struct {
uint8_t ContentType;
uint8_t CID_len;
CID cid;/* Length varies from 4 to 8 (or 16) */
uint16_t record_length;
} TLSRecordHeader;
opaque CID <4..8>;

4) Another option is we can keep CID_len as 4 bit to represent a CID of size. 
And this 4 bit can be placed in the MSB of the CID field.

uint8_t CID_len:4;
CID cid;/* Length varies from 28bit to 60 bit (or 124bit) */


5) Section 3.1 and 3.2 talks about the new extensions for negotiating this 
feature support. But I feel no need of new extensions to negotiate this, we can 
make client to add new SCSV cipher in its cipher list. If server accepts then 
after handshake the first application data send by server should be of type 
application_data_with_cid(25), which should hold the new record header with 
CID. The same CID should be used by client in the further messasge. If client 
sends the 1st application data after handshake, then it can send application 
data with default record type (application_data(23)). If the first application 
data record received from server is not of application_data_with_cid(25) means 
client should understand that server has not accepted the SCSV proposed. And 
client should continue app transfer with default record type 
(application_data(23)).

[tf] What is the problem with using a new extension?  How would negotiating 
parameters (e.g., CID type, CID length) work in your proposal?

Please provide your comments on this suggestion.

Regards,
Ashok



[ompany_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Hannes,

On 24/04/2017 16:39, "Hannes Tschofenig"  wrote:
> On 04/21/2017 12:48 PM, Ilari Liusvaara wrote:
> > Regarding clients, I think the draft specifies LURK as backup plan
> > for clients that don't support subcerts (which causes some extra
> > latency if triggered).
> I didn't got that impression.

Ilari is correct I think -- the fallback to LURK is what the draft in its
current version seems to imply.

> Isn't this something ACME was trying to solve as well?

We have proposed an extension to ACME that handles the full lifecycle of the
delegation, including the automatic renewal of the trail of short term
certificates.  It works in a pretty straightforward way and doesn't require any
modification in the endpoints' stack.

Cheers, t


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

Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

I've read draft-rescorla-tls-subcerts-01 and have a few comments.

It's a well written document and the low-level mechanics look ok.  However,
I think I have a couple of issues with the overall design.

First: it is not self-sufficient.  The fact that clients must opt-in implies
that servers must have a backup plan.  Since keeping the high-value key
material in the same node as the delegate credentials contradicts the basic
security goal, the only realistic fallback is to have a key-server / LURK box
at hand?  But this has the known and already discussed limitations --
complicated setup and operations, scaling issues, single point of failure,
etc. -- which make it inapplicable to some key use cases (CDN).

Second, we need to change the stack at the endpoints.  This might be OK for
browsers, but it's a bit more problematic when the UA is an STB or a
residential gateway, as these things tend to have much slower release and
upgrade cycles.

With regards to WG adoption, I guess I'm neutral.  I think it doesn't hurt
to have something like this, but for the reasons stated above, I'm not sure
it provides a solution to the LURK problem.

Cheers, t

PS: It'd be nice if the document discussed the implication of the "unregulated"
delegation mechanism especially with regards to its auditability.

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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 21/04/2017 16:50, "Salz, Rich"  wrote:
> > Speaking as one of the co-authors of [1]: it is not completely clear to me
> > what is the limitation in CT that would prevent it to cope with the
> > pervasive use of short-term certificates.  Can anyone shed a light on this?
> 
> I believe the concerns are scaling log servers and perhaps needing to
> "rotate" them if, say, 90% of their tree is invalid in a year.

Thanks Rich.  I need to double check that, but I guess there are remedies for
the issues you mention -- e.g., adding more logs / having separate logs for
very short term stuff.

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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 21/04/2017 11:48, "TLS on behalf of Ilari Liusvaara"  wrote:
On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote:
> > What is also not clear to my why some of the certificate management
> > protocols, which provide the necessary level of automation, cannot be
> > used with CAs to request short-lived certificates.
> 
> AFAIK, that would cause issues with CT and OCSP signing.

Speaking as one of the co-authors of [1]: it is not completely clear to me what
is the limitation in CT that would prevent it to cope with the pervasive use of
short-term certificates.  Can anyone shed a light on this?

Cheers, thanks,
t

[1] https://tools.ietf.org/id/draft-sheffer-acme-star-00.txt

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

Re: [TLS] Maximum Fragment Length negotiation

[Fossati, Thomas (Nokia - GB)]

Hi Thomas,

We encountered the same issue and suggested something similar in [1] --
although not at the same level of detail as you below.

I like your proposal, but I'm not convinced that overloading the semantics
of an already existing extension when used in combination with a specific
version of the protocol is necessarily the best strategy.  Besides, I'd
like to be able to deploy a similar mechanism in 1.2.

So, why not simply allocating a new code-point for an extension with the
semantics you describe and make it available across different protocol
versions?

Cheers, t

[1] 
https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00#section-
6

On 24/11/2016 19:50, "TLS on behalf of Thomas Pornin"
 wrote:
>Hello,
>
>I know that I am a bit late to the party, but I have a suggestion for
>the upcoming TLS 1.3.
>
>Context: I am interested in TLS support in constrained architectures,
>specifically those which have very little RAM. I recently published a
>first version of an implementation of TLS 1.0 to 1.2, that primarily
>targets that kind of system ( https://www.bearssl.org/ ); a fully
>functional TLS server can then run in as little as 25 kB of RAM (and
>even less of ROM, for the code itself).
>
>Out of these 25 kB, 16 kB are used for the buffer for incoming records,
>because encrypted records cannot be processed until fully received (data
>could be obtained from a partial record, but we must wait for the MAC
>before actually acting on the data) and TLS specifies that records can
>have up to 16384 bytes of plaintext. Thus, about 2/3 of the RAM usage is
>directly related to that maximum fragment length.
>
>There is a defined extension (in RFC 6066) that allows a client to
>negotiate a smaller maximum fragment length. That extension is simple
>to implement, but it has two problems that prevent it from being
>really usable:
>
> 1. It is optional, so any implementation is free not to implement it,
>and in practice many do not (e.g. last time I checked, OpenSSL did
>not support it).
>
> 2. It is one-sided: the client may asked for a smaller fragment, but
>the server has no choice but to accept the value sent by the client.
>In situations where the constrained system is the server, the
>extension is not useful (e.g. the embedded system runs a minimal
>HTTPS server, for a Web-based configuration interface; the client is
>a Web browser and won't ask for a smaller maximum fragment length).
>
>
>I suggest to fix these issues in TLS 1.3. My proposal is the following:
>
> - Make Max Fragment Length extension support mandatory (right now,
>   draft 18 makes it "recommended" only).
>
> - Extend the extension semantics **when used in TLS 1.3** in the
>following
>   ways:
>
>   * When an implementation supports a given maximum fragment length, it
> MUST also support all smaller lengths (in the list of lengths
> indicated in the extension: 512, 1024, 2048, 4096 and 16384).
>
>   * When the server receives the extension for maximum length N, it
> may respond with the extension with any length N' <= N (in the
> list above).
>
>   * If the client does not send the extension, then this is equivalent
> to sending it with a maximum length of 16384 bytes (so the server
> may still send the extension, even if the client did not).
>
>   Semantics for the extension in TLS 1.2 and previous is unchanged.
>
>With these changes, RAM-constrained clients and servers can negotiate a
>maximum length for record plaintext that they both support, and such an
>implementation can use a small record buffer with the guarantee that all
>TLS-1.3-aware peers will refrain from sending larger records. With, for
>instance, a 2048-byte buffer, per-record overhead is still small (about
>1%), and overall RAM usage is halved, which is far from negligible.
>
>
>RAM-constrained full TLS 1.3 is likely to be challenging (I envision
>issues with, for instance, cookies, since they can be up to 64 kB in
>length), but a guaranteed flexible negotiation for maximum fragment
>length would be a step in the right direction.
>
>Any comments / suggestions ?
>
>Thanks,
>
>
>   --Thomas Pornin
>
>___
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls
>


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

Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header

[Fossati, Thomas (Nokia - GB)]

Hi Achim,

On 16/11/2016 10:21, "TLS on behalf of Kraus Achim (INST/ESY1)"
 wrote:
>I'm still wondering, why the "clashing" calculations (section 4) are only
>based on the number of clients and not also on the length of the hash
>chain.

I guess you are right.  The left column should say "sessions x
window_size".

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

Re: [TLS] extending the un-authenticated DTLS header

[Fossati, Thomas (Nokia - GB)]

Sort of.  Client uses one HOTP value from the sequence at a time, until it sees 
fit — for example, until it's on the same network attachment.

When attachment changes (and its transport identifiers with it), before sending 
a new packet, it picks the next HOTP and sticks it in the record.
When Server sees this, it switches CID accordingly.

From: Martin Thomson mailto:martin.thom...@gmail.com>>
Date: Tuesday, 15 November 2016 10:12
To: "Fossati, Thomas (Nokia - GB)" 
mailto:thomas.foss...@nokia.com>>
Cc: Nikos Mavrogiannopoulos mailto:n...@redhat.com>>, 
"tls@ietf.org<mailto:tls@ietf.org>" mailto:tls@ietf.org>>, Hannes 
Tschofenig mailto:hannes.tschofe...@arm.com>>
Subject: Re: [ALU] Re: [TLS] extending the un-authenticated DTLS header


Okay, so you are saying that every packet has the same number?

On 15 Nov 2016 6:30 PM, "Fossati, Thomas (Nokia - GB)" 
mailto:thomas.foss...@nokia.com>> wrote:
On 15/11/2016 09:20, "TLS on behalf of Martin Thomson"
mailto:tls-boun...@ietf.org> on behalf of 
martin.thom...@gmail.com<mailto:martin.thom...@gmail.com>> wrote:
>This means that you can guarantee privacy, but it forces
>the server to do an exhaustive search of all of its active connections
>(that is, O(N)) when it gets a 5-tuple mismatch.

I don't think I follow.  You'd use CID as primary key to index your
security contexts.  So, regardless your 5-tuple matches or not you'd do
your O(1) lookup in the CID table and find the associated security context.

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

Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header

[Fossati, Thomas (Nokia - GB)]

On 15/11/2016 09:20, "TLS on behalf of Martin Thomson"
 wrote:
>This means that you can guarantee privacy, but it forces
>the server to do an exhaustive search of all of its active connections
>(that is, O(N)) when it gets a 5-tuple mismatch.

I don't think I follow.  You'd use CID as primary key to index your
security contexts.  So, regardless your 5-tuple matches or not you'd do
your O(1) lookup in the CID table and find the associated security context.

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

Re: [TLS] extending the un-authenticated DTLS header

[Fossati, Thomas (Nokia - GB)]

On 15/11/2016 07:36, "TLS on behalf of Martin Thomson"
 wrote:
>On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos 
>wrote:
>> TLDR; the privacy offered by this extension is the same as the privacy
>> of DTLS over UDP.
>
>I disagree.  All the privacy considerations of the QUIC connection ID
>apply here.  It would probably pay to follow that discussion.
>
>If the intent of this is simply to deal with the NAT rebinding issue,
>then I think that this is worth doing, but to say that this does not
>have privacy issues would be overstating the case.

I agree.  We had previous discussion on and off list about this and we
took Stephen's point to look at ways to make this identifier privacy
friendly.

The draft proposes two ways to allocate the identifier (see 3rd para of
https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1):
1. Server decides unilaterally a value that is fixed for the duration of
the session (SecAssocType.fixed);
2. Server and Client agree on a sequence of values generated using HOTP
[RFC 4226] seeded by the session shared secret (SecAssocType.hotp); Client
shifts to the next value when needed (e.g. on transport handover).


At first this might not look particularly elegant, but there are good
reasons for having both methods.

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

Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header

[Fossati, Thomas (Nokia - GB)]

On 15/11/2016 03:51, "TLS on behalf of Martin Thomson"
 wrote:
>On 15 November 2016 at 10:16, Eric Rescorla  wrote:
>>> I'd be interested in an analysis of the potential privacy
>>> impacts of this. Isn't this more or less the same as doing
>>> SPUD-for-DTLS? (If not, sorry for dragging in controversy:-)
>>
>>
>> It would no doubt depend what you put there.
>
>Which is why I'm interested in seeing Nikos' (unpublished?) draft.

Published:
https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-cid-00


Working copy:
https://thomas-fossati.github.io/draft-tls-cid/

Slides for today, "DTLS Optimizations for IoT Deployments":
https://www.ietf.org/proceedings/97/slides/slides-97-tls-dtls-optimizations
-for-iot-deployments-00.pptx

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

Re: [TLS] [ALU] extending the un-authenticated DTLS header

[Fossati, Thomas (Nokia - GB)]

Hi Nikos,

On 14/11/2016 12:58, "TLS on behalf of Nikos Mavrogiannopoulos"
 wrote:
>Hi,
> For draft-mavrogiannopoulos­-dtls­-cid­-00 and we needed to extend the
>DTLS un-authenticated part of the DTLS record header with an additional
>field. That works well if this is the only draft ever extending the
>DTLS record header. If not, modification order would be undefined.
>
>Would it make sense to introduce an extension header for DTLS 1.3 in
>the lines of the IPv6 extension headers? That would allow TLS extension
>negotiation to add more items on the un-authenticated header, and
>potentially also remove redundant headers.
>
>What do you think?

In DTLS 1.3 we could probably re-purpose the version field to signify
"header version" instead?

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

Re: [TLS] DTLS 1.3

[Fossati, Thomas (Nokia - GB)]

Hi Ilari,

On 08/07/2016 14:25, "ilariliusva...@welho.com on behalf of Ilari
Liusvaara"  wrote:
>However, turns out this doesn't actually work as well as hoped in
>practice. The problem is that client can't really change address
>voluntarily
>(even if it is behind CGNAT, it probably can't change the outgoing address
>until CGNAT triggers involuntary rebinding, and client can't react to
>such rebindings fast enough.

You are right.  If client doesn't know that a re-bind has happened and
therefore sends data using the same Id, it's trackable.  In this case I
think the trade-off you are doing is letting the session survive even you
are potentially trackable.  This is probably Nikos' use case.

>So it would be limited to cases where the client has non-NAT connection
>and is renumbered. And such pretty rarely happens.

My use case is an IoT device that voluntarily (or better, knowingly)
migrates its attachment from IP to GSM-SMS and vice-versa and wants to
keep the (painfully) negotiated session open.  Here the client is in
complete control of the situation and can do the Id rollover at the right
point in time.

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

Re: [TLS] DTLS 1.3

[Fossati, Thomas (Nokia - GB)]

Hi Nikos,

On 08/07/2016 10:55, "Nikos Mavrogiannopoulos"  wrote:
>On Fri, 2016-07-08 at 09:29 +0000, Fossati, Thomas (Nokia - GB) wrote:
>
>> > > > How would the hash chain matching work for a server handling
>> > > > multiple
>> > > > clients?
>> > > Sorry, I'm not sure I understand the question.  Are you asking
>> > > what
>> > > happens if there is an Id collision between two separate hash
>> > > chains?
>> > No, my question is much simpler. How would a server handling for
>> > example 2 clients, will figure to which chain a hash of H(x)
>> > belongs to? Will it have to iterate through all the chains (client
>> > states) and test for matching or there is something more clever
>> > than
>> > that?
>> Ah! The hash chain would be computed at the end of the handshake, so
>> all L
>> Ids can be put in a hash table that maps them to the same DTLS
>> context.
>> When a data record comes in, its Id can be used to look up the
>> context in
>> O(1).
>> Clearly the server needs to negotiate a sensible L if it doesn't want
>> to blow up.
>
>As long as both the client and the server are able to notify each other
>that they only support L=1 I'd be content with it.

In the straw man I proposed above, it is sufficient for the server to say
L=1.  In that case the client will trigger a re-handshake when its Id
rollover policy says so.

>However, I'd prefer
>a simple solution and defer the hash chain negotiation for a separate
>extension, since we cannot foresee how and if such an extension will be
>used. As we saw with heartbleed any unused complexity is not necessary
>adding value.

I wholeheartedly agree on the implementation simplicity goal.  I think the
proposal allows both sides to be as simple as they want to.

Cheers, t

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

Re: [TLS] DTLS 1.3

[Fossati, Thomas (Nokia - GB)]

On 08/07/2016 10:05, "Nikos Mavrogiannopoulos"  wrote:
>On Fri, 2016-07-08 at 08:59 +0000, Fossati, Thomas (Nokia - GB) wrote:
>
>> > How would the hash chain matching work for a server handling
>> > multiple
>> > clients?
>> Sorry, I'm not sure I understand the question.  Are you asking what
>> happens if there is an Id collision between two separate hash chains?
>
>No, my question is much simpler. How would a server handling for
>example 2 clients, will figure to which chain a hash of H(x)
>belongs to? Will it have to iterate through all the chains (client
>states) and test for matching or there is something more clever than
>that?

Ah! The hash chain would be computed at the end of the handshake, so all L
Ids can be put in a hash table that maps them to the same DTLS context.
When a data record comes in, its Id can be used to look up the context in
O(1).
Clearly the server needs to negotiate a sensible L if it doesn't want to
blow up.

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

Re: [TLS] DTLS 1.3

[Fossati, Thomas (Nokia - GB)]

Hi Nikos,

On 08/07/2016 09:44, "Nikos Mavrogiannopoulos"  wrote:
>On Fri, 2016-07-08 at 08:34 +0000, Fossati, Thomas (Nokia - GB) wrote:
>> Hi Nikos, Stephen,
>> 
>> It seems to me that both your views (high resistance to traceability
>> and
>> low resource investment on server side) can be accommodated in a
>> single scheme.
>> Going back to the hash chain proposal that Stephen did a few emails
>> ago on
>> this same thread. If:
>> 1. the length of the hash chain is the shortest between the lengths
>> each
>> peer proposes, and
>
>Hi,
> How would the hash chain matching work for a server handling multiple
>clients?

Sorry, I'm not sure I understand the question.  Are you asking what
happens if there is an Id collision between two separate hash chains?  If
so, in general the nature of the keyed hash used to produce the chain
would help keeping the number of collisions low.  In case an Id is a dup,
the server can spot the condition and signal it back to the client.

Cheers, t

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

Re: [TLS] DTLS 1.3

[Fossati, Thomas (Nokia - GB)]

Hi Nikos, Stephen,

It seems to me that both your views (high resistance to traceability and
low resource investment on server side) can be accommodated in a single
scheme.

Going back to the hash chain proposal that Stephen did a few emails ago on
this same thread. If:

1. the length of the hash chain is the shortest between the lengths each
peer proposes, and
2. the client is left in complete control of the rollover policy for the
session identifier (i.e. deciding when to switch to a new Id),

then we would have a lot of flexibility (ranging from one session
identifier which lives forever to one session identifier per packet --
that's entirely decided by the client), while at the same time giving the
server a voice in determining an upper bound to the resources it needs to
reserve per each session.

Cheers, t

On 07/07/2016 12:57, "TLS on behalf of Stephen Farrell"
 wrote:
>On 07/07/16 12:52, Nikos Mavrogiannopoulos wrote:
>> On Thu, 2016-07-07 at 10:37 +0100, Stephen Farrell wrote:
>>> Hiya,
>>>
>>> Just on this one thing...
>>>
>>> On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote:

  does not make the situation any worse
 than we have today.
>>> I don't accept that is the correct goal. That form of
>>> argument is what lead to us standardising the HTTP
>>> Forwarded header field, which IMO was a disimprovement.
>>> (An argument I lost in the end in that case [1], but
>>> 'twas close, and back in 2012 so might go the other
>>> way today;-)
>>> I would argue that the correct goal is to make things
>>> better whenever possible, with that being especially
>>> important for protocols like (D)TLS on which many
>>> other things depend.
>>> I do agree that any scheme developed would need to
>>> meet the state management requirements of servers.
>>> I'm not convinced those requirements call for a new
>>> super-cookie though:-)
>> 
>> I understand your point, I'm not fully convinced by that argumentation.
>> I may be wrong of course, but I'll try to explain my point. Indeed
>> putting privacy first should be a goal of TLS/DTLS, but to the extent
>> it covers the protocol goals. What you propose is to make a stream
>> anonymous, untrackable.
>
>Totally wrong, sorry. What I propose is not adding new ways to
>allow a network observer to track a tls client using the same
>tls session over multiple transport layer connections, unless
>that is really unavoidable.
>
>Exaggerating my argument is not useful. Not is it at all convincing.
>
>S.
>
>> However, that (anonymity or untrackability of
>> the stream) was never a stated goal of TLS/DTLS. In fact TLS is by
>> definition trackable over TCP and one can see in the clear the IPs of
>> the two peers communicating. That doesn't change by switching to DTLS,
>> except for unfortunate situations of routers losing state and client
>> roaming, which current servers cannot easily cope with, and that's the
>> problem I attempt to address.
>> 
>> I think the principle of doing one simple thing and doing it well,
>> applies to protocols as well. TLS and DTLS provide a layer of
>> confidentiality and authenticity. Anonymity, untrackability can be
>> provided by other protocols focused on that such as TOR.
>> 
>> regards,
>> Nikos
>> 
>> 
>
>


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

Re: [TLS] Accepting that other SNI name types will never work.

[Fossati, Thomas (Nokia - GB)]

On 04/03/2016 07:58, "EXT Yuhong Bao"  wrote:
>
>> From: thomas.foss...@nokia.com
>> To: a...@imperialviolet.org; tls@ietf.org
>> Date: Fri, 4 Mar 2016 07:10:06 +
>> Subject: Re: [TLS] Accepting that other SNI name types will never work.
>>
>> Trying again...
>>
>>> Hi Adam,
>>
>>
>> In CoRE we might need to allocate a new SNI NameType for non-DNS host
>> names [1].
>>
>> Removing SNI extensibility would make it unfeasible.
>>
>> Cheers, t
>>
>> [1]
>> 
>>https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-00#secti
>>on
>> -3.3
>Is limiting the list to only one SNI name entry feasible?

Yes, I think so.

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

Re: [TLS] Accepting that other SNI name types will never work.

[Fossati, Thomas (Nokia - GB)]

On 04/03/2016 08:42, "TLS on behalf of Martin Thomson"
 wrote:

>On 4 March 2016 at 18:10, Fossati, Thomas (Nokia - GB)
> wrote:
>> In CoRE we might need to allocate a new SNI NameType for non-DNS host
>> names [1].
>>
>> Removing SNI extensibility would make it unfeasible.
>
>Not at all.

It would, the way it is formulated at the moment.  But that doesn't
matter, we can change it to whatever as long as we can make it work.


>Define a new extension.  We have evidence that that works.

That can be done, of course.  Although it strikes me as odd to add another
extension given the exact same facility is already in place.

There are various ways SNI can be tightened other than removing the
parametrisation on NameType, e.g. limiting the number of ServerName
entries to 1.

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

Re: [TLS] Accepting that other SNI name types will never work.

[Fossati, Thomas (Nokia - GB)]

Trying again...

> Hi Adam,


In CoRE we might need to allocate a new SNI NameType for non-DNS host
names [1].

Removing SNI extensibility would make it unfeasible.

Cheers, t

[1] 
https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-00#section
-3.3


>On 03/03/2016 18:49, "TLS on behalf of Adam Langley" on behalf of a...@imperialviolet.org> wrote:
>>The Server Name Indication (SNI) extension in TLS has a provision to
>>provide names other than host names[1]. None have even been defined to
>>my knowledge, but it's there.
>>
>>OpenSSL (and possibly others) have had a long-standing bug[2] (fixed
>>in master) that means that different types of names will cause an
>>error. To be clear: I live in a glass house and am not throwing
>>stones; these things happen. However, it means that a huge fraction of
>>the TLS deployment will not be able to accept a different name type
>>should one ever be defined. (This issue might have been caused by the
>>fact that the original[3] spec didn't define the extension in such a
>>way that unknown name types could be skipped over.)
>>
>>Therefore we (i.e. BoringSSL, and thus Google) are proposing to give
>>up on this and implement our parser such that the SNI extension is
>>only allowed to contain a single host name value. (This is compatible
>>with all known clients.) We're assuming that since this is already the
>>de-facto reality that there will be little objection. I'm sending this
>>mostly to record the fact so that, if someone tries to define a new
>>name type in the future, they won't waste their time.
>>
>>If the community wishes to indicate a different type of name in the
>>future, a new extension can be defined. This is already effectively
>>the case because we wouldn't fight this level of incompatibility when
>>there's any other option.
>>
>>(I think the lesson here is that protocols should have a single joint,
>>and that it should be kept well oiled. For TLS, that means that
>>extensions should have minimal extensionality in themselves and that
>>we should generally rely on the main extensions mechanism for these
>>sorts of things.)
>>
>>[1] https://tools.ietf.org/html/rfc6066#section-3
>>[2] 
>>https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/ssl/t1_lib.c
>>#
>>L1066
>>­ note that the data pointer is not updated.
>>[3] https://tools.ietf.org/html/rfc4366#section-3.1
>>
>>
>>Cheers
>>
>>AGL
>>
>>-- 
>>Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
>>
>>___
>>TLS mailing list
>>TLS@ietf.org
>>https://www.ietf.org/mailman/listinfo/tls
>
>


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

Re: [TLS] Accepting that other SNI name types will never work.

[Fossati, Thomas (Nokia - GB)]

Hi Adam,


On 03/03/2016 18:49, "TLS on behalf of Adam Langley"  wrote:
>The Server Name Indication (SNI) extension in TLS has a provision to
>provide names other than host names[1]. None have even been defined to
>my knowledge, but it's there.
>
>OpenSSL (and possibly others) have had a long-standing bug[2] (fixed
>in master) that means that different types of names will cause an
>error. To be clear: I live in a glass house and am not throwing
>stones; these things happen. However, it means that a huge fraction of
>the TLS deployment will not be able to accept a different name type
>should one ever be defined. (This issue might have been caused by the
>fact that the original[3] spec didn't define the extension in such a
>way that unknown name types could be skipped over.)
>
>Therefore we (i.e. BoringSSL, and thus Google) are proposing to give
>up on this and implement our parser such that the SNI extension is
>only allowed to contain a single host name value. (This is compatible
>with all known clients.) We're assuming that since this is already the
>de-facto reality that there will be little objection. I'm sending this
>mostly to record the fact so that, if someone tries to define a new
>name type in the future, they won't waste their time.
>
>If the community wishes to indicate a different type of name in the
>future, a new extension can be defined. This is already effectively
>the case because we wouldn't fight this level of incompatibility when
>there's any other option.
>
>(I think the lesson here is that protocols should have a single joint,
>and that it should be kept well oiled. For TLS, that means that
>extensions should have minimal extensionality in themselves and that
>we should generally rely on the main extensions mechanism for these
>sorts of things.)
>
>[1] https://tools.ietf.org/html/rfc6066#section-3
>[2] 
>https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/ssl/t1_lib.c#
>L1066
>­ note that the data pointer is not updated.
>[3] https://tools.ietf.org/html/rfc4366#section-3.1
>
>
>Cheers
>
>AGL
>
>-- 
>Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
>
>___
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls

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